DFSR数据库损坏会导致Sysvol同步彻底卡死，必须人工介入：先验证服务状态与事件日志（ID 2104/2004/2212），再备份Private目录并用esentutl确认损坏，最后执行dfsrmig元数据重置，禁用快照、安装KB2780453、确保StopReplicationOnAutoRecovery=0。

dfsr数据库损坏会导致sysvol同步彻底卡死，不会随服务重启恢复，必须人工介入。核心思路是：先确认真损坏、再安全备份、最后用微软推荐的元数据重置方式恢复，避免删库或强行修复。

确认是否真是数据库损坏

别一看到同步停就直接动数据库。先做三件事：

• 在services.msc里检查DFS Replication服务状态——必须是“正在运行”，启动类型为“自动(延迟启动)”
• 打开事件查看器 → Applications and Services Logs → DFS Replication，筛选错误事件，重点看ID 2104（内部数据库错误）、2004（复制已停止）、2212（数据库初始化失败）
• 运行命令：dfsrdiag ReplicationState /v，如果某DC长期显示State = Initial Sync Required且无进展，再结合上述日志，基本可判定数据库异常

停服并验证数据库完整性

确认问题后，立即执行安全操作：

• 先停止DFS Replication服务（不要禁用）
• 完整备份整个%systemroot%\System32\DFSR\Private目录（含DB.edb、log文件和checkpoint）
• 运行：esentutl /g "C:\Windows\System32\DFSR\Private\DB.edb"，若返回“Database is corrupt”，说明损坏属实，不可用 /p 强行修复
• 检查系统盘剩余空间，特别是C:\System Volume Information\DFSR所在卷，确保≥20%，否则重建会失败

执行非破坏性恢复

微软官方不建议删库重建，优先采用元数据重置流程：

• 在一台正常运行的域控制器上导出配置：dfsrmig /export c:\dfsr-config.xml
• 在故障DC上执行：dfsrmig /setglobalstate 0（仅重置本机状态）
• 再导入配置：dfsrmig /import c:\dfsr-config.xml
• 重启DFS Replication服务，观察事件日志是否出现ID 4002（初始化开始）和4112（同步成功）
• 若仍卡住，可删除并重加成员身份：dfsradmin Membership Delete /RGName:"Domain System Volume" /MemName:%computername%，再用Add重新加入

同步恢复后必须做的加固

防止下次再坏，这几个动作不能省：

• 禁用虚拟机对DC的快照功能；如必须使用，务必先暂停DFSR服务再拍
• 确保所有DC都安装了KB2780453等关键补丁，注册表项StopReplicationOnAutoRecovery值设为0（十进制）
• 把DFSR暂存目录（Staging）和数据库目录分设在不同物理磁盘上
• 检查时间同步——域控间偏差超5分钟会静默中止DFSR，用w32tm /query /status确认，PDC必须指向可靠NTP源