TL;DR 以粗体显示
你好， 我已经为软件和用户共享设置了新的 DFS 命名空间和复制，从较旧的 2012R2 服务器到我们希望迁移到的较新的 2019 服务器。我已经让服务器运行了几天，但复制似乎没有任何进展。
运行dfsrdiag backlog显示“没有 Backlog 成员 x 与合作伙伴 y 同步”，但事实显然并非如此。运行 DFS 复制报告显示，没有复制任何文件或文件夹，并且新服务器上的驱动器自设置复制时最初消耗的 753MB 以来大小没有改变。
在旧服务器上的 DFS 复制事件日志中，我有一个每分钟大约 25000 个事件的滚动日志，所有事件都表明事件 4308：“DFS 复制服务已成功从文件上遇到的共享冲突中恢复。”它似乎正在为共享中的每个文件逐一触发事件。
有一次，它到达了一个已损坏的文件夹，并不断地向文件夹名称发送垃圾邮件。我停止并重新启动了 DFS 服务，它似乎重新启动了我已经看到的文件的整个垃圾邮件发送过程。我已安排在chkdsk /f今晚重新启动以处理损坏问题。但是，我认为系统可以同时复制未损坏的文件，这似乎是合乎逻辑的。
为什么日志中会出现这么多 4308 事件？它基本上每分钟都会滚动 15MB 的日志，除了 4308 个事件之外，日志中没有任何内容。我不想让日志变得更大或强制存档，因为这样只会让我的系统充满更多无用的事件。同时，我看到了所有这些恢复，但没有初始错误。没有任何明显的进展。
更多详细信息（可能不相关）：旧服务器位于 Hyper-V 故障转移群集中，使用 iSCSI 群集磁盘作为驱动器。共享由服务器内部的直接 iSCSI 安装托管。新服务器是 VMware，驱动器由 vSAN（跨本地主机复制的虚拟数据存储）提供。两台服务器都设置了 Windows 备份，旧服务器备份大约需要 18 小时，每天只留下 6 小时用于复制（Windows 备份似乎暂停了 DFS 复制）。但是，在这 6 个小时内没有任何进展，所以我不认为备份是罪魁祸首。我dfsrdiag pollad对两台机器都做了什么，什么都没有改变。收件人大部分时间都坐在那里查看日志，只是偶尔每天抱怨 Windows 备份使复制脱机约 30 分钟。旧服务器确实发送了上述垃圾邮件。
答案1
TL;DR：看起来驱动器上的损坏是导致该问题的原因。
在驱动器上执行chkdsk /f重启后，我仍然看到 chkdsk 错误。执行chkdsk /f强制卸载并确认没有更多错误后chkdsk /f，chkdsk /scanDFS-R 开始工作。读取磁盘上的文件需要一段时间（我猜是数据库的哈希值？）然后它开始暂存文件，我开始看到数据流向目标服务器。