问题：有没有办法让这 350,000 个文件积压更快地完成？对于几乎每个文件，唯一的变化是更改每个受影响文件的 ACL。有些文件的内容已更改，但在这种情况下，这不是常见的情况。
这个问题可能会得到解决。我会在经过一段时间和验证后编辑此文本以确认成功/失败。在这个问题文本的末尾，我详细介绍了最近所做的可能已经修复该问题的更改。
我们有一个 DFSR 复制组，其中包含约 450,000 个文件，占用 1.5TB 的空间。在这种情况下，有两台相距约 500 英里的 Windows Server 2008 R2 服务器。还有其他服务器，但它们不参与此复制组。服务器 ALPHA 是主服务器，是大多数员工使用的服务器。服务器 BETA 是远程办公室的服务器，不太繁忙。
这里有一个此复制组的积压图表（PNG 托管在 Google Drive 上）显示同步进度缓慢。
我需要删除该复制组根目录中的权限条目，该条目当然在大多数子文件夹中都继承了。我在服务器 ALPHA 上进行了此更改。此后，DFSR 立刻积压了 350,000 个文件。已经过去一周多了，现在积压文件数量为 267,000。唯一改变（最初）的是单个权限更改。
发生了什么事（这不是解决方案，只是对导致此问题的原因的另一种解释）：http://blogs.technet.com/b/askds/archive/2012/04/14/saturday-mail-sack-because-it-turns-out-friday-night-was-alright-for-fighting.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。我知道 Microsoft 批准的路线是增加 20%，但我不是在开玩笑。我们在暂存磁盘阵列上有足够的磁盘空间。
在所有服务器上禁用防病毒软件不是帮助，尽管我认为它会有所帮助。目前，我已重新启用防病毒软件，但将复制组的路径设置为从扫描中排除，以便从等式中删除该变量。
有没有办法让这个过程更快？我也会在服务器 BETA 上进行此更改，但有些文件在 ALPHA 上已更改但尚未复制到 BETA，而通过在 BETA 上进行继承权限更改将推动老的文件从 BETA 变为 ALPHA（因为 DFSR 在比较哪个文件是冲突中的赢家时似乎忽略了文件时间戳）。发生这种情况会相当糟糕。
积压工作正在慢慢减少。非常非常慢。不过，它正在向前推进。但按照这个速度，它还需要几周时间才能完成。我正在考虑将数据集的副本推送到 3TB 驱动器上，然后将其发送到远程办公室。有没有更好的方法？
5 月 16 日，美国太平洋时间凌晨 4 点：什么方法可以解决这个问题（假设问题确实已经解决）：
我对 DC 进行了多次更改，这些更改早就应该进行了。问题是这个网络是从其他人那里继承的，而其他人可能又从其他人那里继承了它，等等。我不能保证哪个更改解决了问题。以下是它们（无特定顺序）：
- 并非所有 DC 都位于“域控制器”OU 中。我从未见过 Windows 域将 DC 放在其他地方。我将它们移回了原来的位置。它们以前位于按每个办公室所在城市的名称分隔的 OU 中。（我觉得现在我移动了它们，需要处理一些管道工作，但所有似乎目前还好……）
- AVG Anti-Virus 在所有 DC 和参与 DFSR 的服务器上运行。我将复制文件夹和暂存文件夹排除在主动/访问时扫描之外。我认为这并没有解决问题，我可能会在稍后测试此问题，看看撤消该更改是否会影响 DFSR 的复制速度。这是另一天的挑战。
- 诊断工具抱怨与 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，比最高值低一个档次。这可能有助于解决问题……也可能没有。很难判断何时更改了太多变量。
- 诊断工具抱怨 BETA 版中与 RPC 服务通信存在问题，但只有在进行了上述更改后才出现。这似乎是最有可能出现的问题，但我没有采取任何措施来纠正它。VPN 运行正常，防火墙也没有阻止它。上述某项可能是导致 RPC 问题的原因，然后又解决了该问题，也可能只是巧合。我不是现在得到该错误并且复制目前运行顺利。
这个故事的寓意是：一次只改变一件事，否则你永远不知道是什么修复了它。但我当时很绝望，而且没有时间修复它，所以我只是对这个问题进行了大量的尝试。如果我能找到解决办法，我会在这里报告。不过，不要指望我能缩小范围。
编辑于2012年5月21日： 昨天，我开车带着备用服务器 (GAMMA) 去了远程办公室，花了大约七个小时才解决了这个问题。GAMMA 现在充当他们的主要本地服务器，而他们常用的服务器 (BETA) 则负责复制。自从我安装好它之后，服务器的复制速度大约翻了一番。虽然这告诉我这可能是与 VPN 相关的问题，但我不太相信这是 VPN 相关的问题，因为所有从 ALPHA 复制到 GAMMA 的新更新似乎都非常快，而且进展顺利。
编辑于2012年5月22日： 现在它已经达到 12000 了，几个小时后应该就能完成。我会发布一张从缓慢开始到快速完成的进度图。问题是，唯一真正“修复”它的是本地服务器连接。我现在想，也许 VPN 是问题的一部分。如果是这样的话，我觉得这个问题还没有完全得到解答。等我有更多时间检查 VPN 的复制情况并发现任何故障后，我会调试并报告进度。
如果有变化我会在这里更新。
答案1
非常奇怪的问题，特别是在查看了编辑之后。
我将检查 DFSR 调试日志，它位于此处：%systemroot%\debug 默认情况下，应该有 9 个已被 GZ 存档的以前的日志文件，以及一个当前正在写入的日志文件。
在文本文件中打开它，然后搜索文本“警告”或“错误”。您可以查看此博客系列以获取有关调试日志的更多详细信息： http://blogs.technet.com/b/askds/archive/2009/03/23/understanding-dfsr-debug-logging-part-1-logging-levels-log-format-guid-s.aspx
其他问题/建议：
查看资源监视器时，是否有任何异常？硬盘或 CPU 活动是否超出基线？
如果可能的话，我会重启 Alpha 和 Beta 服务器。如果这能解决您的问题，您可能永远不知道真正的问题是什么，但如果这个问题亟待解决，那么值得一试。
根据问题更新进行编辑
您提到了与 850 MB 文件相关的两个条目，以及 DFSR 调试日志中的错误。
您能否尝试将暂存位置更改为每台服务器上的其他文件夹或驱动器？以防当前暂存的文件已损坏或以某种方式阻止复制。
答案2
您可以调整复制计划以允许 DFS-R 在非工作时间（或者在适当的情况下，甚至在工作时间）全速复制。
您还可以尝试增加后台登录服务器上的暂存大小。在这种情况下，它应该可以提高性能。
您没有提到它是否有上限，但我认为是有上限的，因为您通过 WAN 进行了复制。
答案3
我的经验是，这就是它的工作原理。
我在对 4 个 DFS 复制组（共 550 GB 数据、58k 个文件、3.4k 个文件夹）的较小集合进行安全性更新后偶然发现了这一点。实际通过网络传输的数据很少，因此似乎不会因为安全性更改而移动整个文件，但磁盘活动感觉就像整个层次结构正在被重新复制 - 持续的磁盘传输速率在 60-100 MB/秒之间，磁盘队列为 30 个，在 SSD 分层存储空间上最高可达 500 个。
我的感觉是，DFS 在其暂存和取消暂存过程中存在大量混乱，这会导致极端的磁盘 I/O。两个千兆 LAN 连接盒之间的初始复制过程所花的时间比在盒之间简单复制相同数据文件所花的时间要长几倍，这似乎表明复制的每个字节都需要多个字节的磁盘读写。
安全更新似乎没有任何特殊的复制逻辑，除非使用 2012 基于声明的安全性（据我所知并未广泛使用），从而导致数据更改时出现相同的阶段/降级流失。