域控快照回滚后如何核查AD复制?

快照回滚最容易制造一种错觉：域控起来了，目录查询也能响应，仿佛服务已经恢复。但对 AD 来说，真正的风险在复制层面。回滚会把目录数据库、复制元数据和计算机账户密码带回旧时间点，而其他域控仍在继续演进。此时表面可用不等于复制一致，若不先核查复制状态，后续可能出现认证异常、复制停滞，甚至旧数据被重新引入。

先判断回滚域控当前扮演什么角色

核查的第一步不是立刻强制复制，而是确认回滚域控是否持有 FSMO 角色、是否为全局编录、是否属于只读域控，以及它所在的站点和入站复制伙伴。角色不同，影响范围不同。尤其要确认回滚时间点之后，是否已有其他域控发生过目录变更或密码轮换；这些变化不会自动回到回滚域控上。

接下来用复制健康检查建立基线。repadmin /replsummary 适合先看整体失败分布，repadmin /showrepl 用来定位具体入站邻居、上次成功时间和失败原因，dcdiag 的复制相关测试用于确认基本复制链路是否正常。事件日志中与复制、安全通道、目录服务相关的告警同样需要集中查看，而不是只看一个汇总结果。

重点排查 USN 回滚与安全通道

快照回滚后，回滚域控的更新序列号可能低于其他域控已记录的高水位。邻居可能因此认为该域控没有新变化，导致入站复制停滞，出现目录数据不一致。核查时要观察复制是否长期无法推进、是否反复失败，而不能仅凭一次成功响应就判定恢复完成。若确认存在回滚导致的复制异常，应暂停该域控的常规复制，评估隔离、非权威恢复或重建路径，避免把旧状态继续传播到其他域控。

安全通道也要单独检查。计算机账户密码随快照回退后，域控与成员服务器、域控之间的安全通道可能出现认证失败。可通过登录、Kerberos 票据获取和受信任关系测试来验证，而不要只看服务是否启动。对于依赖 LDAP 绑定的业务系统，还应抽测几个真实查询路径，确认认证和组信息与预期一致。

最后把核查结果落到可审计记录：回滚时间点、受影响域控、复制检查结果、安全通道测试结果、处置动作和后续观察窗口。快照回滚不是一次性的恢复动作，而是一次复制一致性风险的重置。只有确认复制正常、安全通道可用、旧状态没有被继续扩散，才算完成核查，而不是完成开机。