Windows DFSR - 更改了复制目录权限，现在有 350,000 个积压超过一周

Question

问题：有没有办法让这 350,000 个文件积压完成得更快？对于几乎每个文件，唯一的变化是对每个受影响文件的 ACL 进行了更改。某些文件已更改内容，但在这种情况下这不是常见情况。

这可能是固定的。经过一段时间和验证后，我将编辑此文本以确认成功/失败。在此问题文本的末尾，我详细介绍了最近可能已修复它的更改。

我们有一个 DFSR 复制组，大约有 450,000 个文件，占用 1.5TB 空间。在这种情况下，有两台相距约 500 英里的 Windows Server 2008 R2 服务器。还有其他服务器，但它们不参与此复制组。Server ALPHA 是主服务器，也是大部分员工使用的服务器。Server BETA 是远程办公室的服务器，不太忙。

这是此复制组（在 Google Drive 上托管的 PNG）的积压图表，显示了缓慢的同步进度。

我需要删除该复制组根目录中的权限条目，当然，大多数子文件夹都继承了该权限条目。我在服务器 ALPHA 上进行了此更改。在那之后，DFSR 立即有 350,000 个文件积压。已经一个多星期了，现在是 267,000。唯一改变的（最初）是单一权限的改变。

这就是发生的事情（这不是解决方案，只是对导致此问题的原因的另一种解释）：http : //blogs.technet.com/b/askds/archive/2012/04/14/saturday-mail-sack -因为它变成了星期五晚上是好的战斗。aspx#dfsr

服务器 BETA 上发生的任何更改都会非常快速地复制到服务器 ALPHA，因为该方向没有积压。在 BETA 上更改的任何文件都可以毫无问题地转换为 ALPHA。

它通过一端的 50Mbps 连接全速复制 24/7 到另一端的 100Mbps 光纤。每台服务器上的暂存区为 100GB。事件日志中根本没有什么有趣的东西。有一个不相关的高水位线事件显示了一个不相关的复制组，该组既不是针对此特定复制，也不是针对此 ALPHA/BETA 服务器对。特别是没有高水印和连接错误的事件日志条目。

ALPHA 对复制组的看法：

带宽节省：减少 99.83%（复制 30.85 MB 而不是 18.1 GB）

我相信自从我上次在 ALPHA 和 BETA 上重新启动 DFSR 服务以来，发生了 30.85MB/18.1GB。如果是这样，这表明即使花费了很长时间（比我认为应该花费的时间更长），它实际上并没有通过网络传输文件内容。

复制文件夹：1.46TB（实际大小）、439,387（文件）、52,886（文件夹）

冲突和已删除文件夹：100.00GB（配置大小）、34.01GB（实际大小）、19,620（文件）、2,393（文件夹）

暂存文件夹：200.00GB（配置大小），92.54GB（实际大小）

我在日志中发现了一个高水印错误（5 月 14 日晚上 7 点），因此将暂存配额从 100GB 提高到 200GB。我知道微软批准的路线是增加 20%，但我并没有在玩这个。我们有足够的磁盘空间可用于暂存磁盘阵列。

在所有服务器上禁用防病毒软件并没有帮助，尽管我认为它会有所帮助。现在，我已重新启用防病毒功能，但将复制组的路径设置为从扫描中排除，以便从等式中删除该变量。

有没有办法让它更快？我也会在服务器 BETA 上进行此更改，但是有些文件在 ALPHA 上已更改但尚未复制到 BETA 并且通过对 BETA 进行继承的权限更改会将旧文件从 BETA推送到 ALPHA（因为 DFSR 似乎在比较冲突中哪个文件是赢家时忽略文件时间戳）。发生这种情况会很糟糕。

积压正在缓慢减少。非常非常缓慢。不过，它正在向前发展。但按照这个速度，它需要几周时间才能完成。我正在考虑将数据集的副本推送到 3TB 驱动器上，然后将其运送到远程办公室。有没有更好的办法？

5 月 16 日，美国太平洋时间凌晨 4 点：什么可能解决了问题（假设它确实已修复，无论如何）：

我对 DC 进行了多次更改，这些更改本应在很久以前进行。问题是这个网络是从其他人那里继承来的，其他人可能从其他人那里继承了它，等等。我不能保证哪个改变解决了这个问题。在这里，它们没有特定的顺序：

• 所有 DC 都不在“域控制器”OU 中。我从未见过在其他地方拥有 DC 的 Windows 域。我把它们搬回了它们所属的地方。他们以前在 OU 中，这些 OU 由每个办公室所在的城市的名称分隔。（我感觉我现在有一些管道工作要处理，因为我移动了它们，但目前似乎一切正常......）
• AVG Anti-Virus 正在所有 DC 和参与 DFSR 的服务器上运行。我从主动/按访问扫描中排除了复制的文件夹和暂存文件夹。我认为这并没有解决问题，我可能会在稍后测试这个问题，看看撤消该更改是否会干扰 DFSR 的复制速度。这是另一天的挑战。
• dcdiag.exe抱怨有关 RODC 的 DNS 问题。即使域上根本没有 RODC，我也解决了该问题。我怀疑这解决了任何问题。
• 其中一个 DC（不是 DFSR 服务器之一）缺少 _ldap._tcp.domain.GUID._msdcs.DOMAIN.NET SRV 记录之一，我对此进行了补救。我认为这也没有帮助。
• 有一次我重新启动服务器 BETA，它抱怨 DFSR 数据库关闭错误（事件 2212），然后它继续花费数小时来重建数据库。完成后，它报告了事件 2214，让我知道它已完成。在那之后，复制仍然运行得非常缓慢，但它可能有助于解开任何卡住的东西。
• 其中一个 DC 的接口配置中没有 127.0.0.1 作为辅助 DNS 服务器。我加了。这不是 DFSR 服务器之一，因此可能与它无关。
• 我关注了TechNet 博客：在 DFSR推荐的 DFSR 服务器注册表设置中调整复制性能。除了AsyncIoMaxBufferSizeBytes设置为4194304之外，我使用了所有“测试的高性能值”值，该值比高值低一个档次。这可能有助于解决问题……或者可能没有。很难判断何时改变了太多变量。
• dcdiag.exe抱怨在 BETA 上与 RPC 服务通信出现问题，但前提是已经进行了上述更改。这似乎是最有可能发生的问题，但我没有采取任何措施来纠正它。VPN 运行正常，防火墙没有阻止它。可能是上述项目之一导致并修复了 RPC 问题，也可能只是巧合。我现在没有收到该错误，目前复制运行顺​​利。

这个故事的寓意是：一次改变一件事，否则你永远不会真正知道是什么修复了它。但是我很绝望并且没有时间修复它，所以我只是向这个问题发射了一堆子弹。如果我查明修复方法，我会在这里报告。不过，不要指望我缩小范围。

2012 年 5 月 21 日编辑： 我昨天用备用服务器 (GAMMA) 驾驶大约 7 个小时到远程办公室解决了这个问题。GAMMA 现在充当他们的主要本地服务器，而他们通常的服务器 (BETA) 赶上复制。自从我把它安装到位后，服务器的复制速度已经提高了一倍。虽然这告诉我这可能是与 VPN 相关的问题，但我不太相信这是因为所有新更新似乎从 ALPHA 复制到 GAMMA 的速度非常快且进展顺利。

编辑 5/22/2012： 现在是 12000，应该在几个小时内完成。我将发布一个很好的图表，显示从缓慢开始到快速完成的进度。问题是唯一真正“修复”它的是本地服务器连接。我目前认为 VPN 可能是问题的一部分。如果是这样的话，我觉得这个问题还没有得到很好的回答。在我有更多时间检查通过 VPN 复制的情况并看到任何故障后，我将进行调试并报告进度。

如果有什么变化，我会在这里更新。

Answer 1

您可以调整复制计划以允许 DFS-R 在非工作时间（甚至在适当情况下甚至在工作时间）全速复制。

您还可以尝试增加后台登录服务器上的暂存大小。在这种情况下，它应该会提高性能。

您没有提到它是否有上限，但我认为是因为您在 WAN 上进行了复制。

Answer 2

非常奇怪的问题，尤其是在审查编辑之后。

我将检查 DFSR 调试日志，该日志位于此处：%systemroot%\debug 默认情况下，应该有 9 个之前已 GZ 存档的日志文件，以及当前正在写入的日志文件。

在文本文件中打开它，然后搜索文本“警告”或“错误”。您可以查看此博客系列，了解有关调试日志的更多详细信息： http://blogs.technet.com/b/askds/archive/2009/03/23/understanding-dfsr-debug-logging-part-1-日志记录级别-日志格式-guid-s.aspx

其他问题/建议：

查看资源监视器时是否有任何异常？硬盘驱动器或 CPU 活动是否超出基线？

如果可能的话，我会重新启动 Alpha 和 Beta 服务器。如果它解决了您的问题，您可能永远不知道真正的问题是什么，但如果问题很快就能得到解决，那么值得一试。

根据问题更新进行编辑

您提到了与 850 MB 文件相关的两个条目，以及 DFSR 调试日志中的错误。

您可以尝试将暂存位置更改为每台服务器上的不同文件夹或驱动器吗？如果当前正在暂存的文件已损坏或以某种方式阻止复制。