我们有一个包含 3 台服务器和 93 个已复制文件夹的 DFS 基础架构。当我从 DFS 管理控制台运行健康报告时，其中一个文件夹的状态显示为“未初始化”。此文件夹之前已正常复制。
重新启动所有 3 个 DFS 服务器可解决“未初始化”状态，文件夹似乎开始正常复制。但是，它会很快回到“未初始化”状态，通常在一周内。
我一直在 DFS 中监控此文件夹，确实发现在很短的时间内会有大量更改进入此文件夹 - 即在工作日的清晨，复制积压将跃升至超过 100,000 个条目。通常，积压会在接下来的几个小时内迅速减少，所以我并不担心。
但是，现在这个“未初始化”状态意味着文件夹处于此状态的服务器上根本没有进行复制。这意味着现在我们遇到了问题。我还没有找到具体的文件或原因，但我已经向桌面团队发出了询问，以帮助确定导致积压的原因。
我没有发现与此文件夹或状态相关的事件日志错误。我认为可能是卷上的大量文件更改导致了日志覆盖错误，但我没有发现任何与 USN 日志覆盖相关的事件日志。该文件夹确实存在一致的共享违规，但在出现此“未初始化”问题之前关闭文件后，这些问题最终都会自行解决。
我的研究没有任何结果，除了可能的配置 xml 损坏，但在这些情况下问题仅仅出在 sysvol 复制上。
我唯一的假设是，当差异数量超过某个阈值时，DFSR 会自动将状态设置为“未初始化”。但我无法验证这个假设，也找不到任何文档来支持它。即使这是真的，我也不知道该如何“重新初始化”文件夹。
涉及的服务器为：
A：发送服务器，2008r2，暂存配额 25 GB，状态：正常
B：接收服务器，2008r2，暂存配额 175 GB，状态：未初始化
C：接收服务器，2012r2，暂存配额 25 GB，状态：正常
所有三台服务器都承担着 AD 域控制器的双重职责。所有 93 个复制文件夹都位于同一个复制组中，因此删除并重新创建 RG 会耗费大量时间。当此问题首次出现时，少数其他文件夹也显示此状态，但只有这一个文件夹在重新启动后再次出现此问题。受影响的文件夹大小为 202 GB，包含 547,252 个文件。
是什么原因导致文件夹变为“未初始化”？我该如何解决这个问题？
-编辑- 更多信息。接收服务器昨天午夜（约 36 小时前）重新启动。这使文件夹进入“正常”状态，并开始产生积压。当我昨天检查时，此文件夹的积压文件为 205,662 个文件。当我今天检查时，积压文件为 579,447 个文件。该文件夹目前只有 551,706 个文件。积压文件大于文件夹大小。DFS 健康报告显示此文件夹中已收到 851,592 个文件。到目前为止，没有其他文件夹遇到这样的问题。
我不知道是积压导致复制失败，还是复制失败并导致积压，或者是否有一些底层数据库或日志损坏导致复制失败和积压。我也不知道在这两种情况下如何解决问题。
目前，93 个文件夹只有一个复制组。我准备放弃它并配置 93 个复制组。如果这不能解决问题，至少它会让故障排除变得更容易。