Windows DFSR – 更改复制的目录权限，现在有超过一个星期的350,000积压

问题：有没有办法使这个35万文件的积压工作更快完成？ 对于几乎每个文件，唯一的变化是每个受影响文件的ACL更改。 一些文件已经改变了内容，但在这种情况下并不常见。

这可能是固定的。 我将在一段时间和validation后编辑这个文本以确认成功/失败。 在这个问题文本的末尾，我已经详细介绍了最近可能修正的变化。

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

以下是此复制组 （在Google Drive上托pipe的PNG） 的积压图表，显示慢同步进度。

• 如何将VHD映像复制回物理光盘？
• 运行一个没有3GB日志文件的MongoDBconfiguration服务器
• RODC和RWDC之间的带宽消耗是否有差异？
• 恢复文件复制linux
• 如何在复制大文件时减less资源使用量？

我需要删除该复制组的根目录中的权限条目，这当然是在大多数子文件夹中inheritance的。 我在服务器ALPHA上做了这个改变。 在此之后，DFSR有35万个文件积压。 已经有一个多星期了，现在是26.7万。 唯一改变的（最初）是单个权限更改。

这就是发生了什么事（这不是解决scheme，只是解释导致此问题的原因）： http : //blogs.technet.com/b/askds/archive/2012/04/14/saturday-mail-sack -因为，它匝数出周五夜-为-好吧换fighting.aspx＃DFSR

在服务器BETA上发生的任何更改都会非常快速地复制到服务器ALPHA，因为在该方向上没有积压。 任何在BETA上更改的文件都可以顺利地进入ALPHA。

它将一个24端口全速复制，一端连接50Mbps连接，另一端连接100Mbps光纤。 每台服务器上的临时区域为100GB。 事件日志根本没有什么有趣的地方。 有一个不相关的高水位事件显示了一个不相关的复制组，既不适用于此特定的复制，也不适用于此ALPHA / BETA服务器对。 特别是没有高水位事件日志条目和连接错误。

ALPHA对复制组的看法：

带宽节省 ：减less99.83％（复制30.85 MB而不是18.1 GB）

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

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

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

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

日志中（5月14日晚7点）我得到了一个高水印错误，所以从100GB升级了200GB的升级配额。 我知道微软批准的路线是增加20％，但我并没有在这方面玩弄。 我们有足够的磁盘空间来备用磁盘arrays。

禁用所有服务器上的反病毒软件并没有帮助，但我认为这会有所帮助。 现在，我已经重新启用了防病毒，但将复制组的path设置为从扫描中排除，以便从等式中删除该variables。

有没有办法让这个更快？ 我也只是在服务器BETA上进行这种更改，但是有些文件在ALPHA上已经更改，但没有复制到BETA，并且通过在BETA上inheritance权限更改将OLD文件从BETA推到ALPHA（因为DFSR似乎当比较哪个文件是碰撞中的胜利者时忽略文件时间戳）。 而发生这种情况将是相当糟糕的。

积压正在缓慢下降。 非常，非常缓慢。 不过，这是前进的。 但按照这个速度，它将在数周之后才能完成。 我正在考虑将数据集的副本放到3TB的硬盘上，然后运送到远程办公室。 有没有更好的办法？

5月16日凌晨4点，美国太平洋时间：什么可能解决了这个问题（无论如何，假设它是诚实的固定的）：

我对很早以前就应该做的区议会做了很多改变。 问题是这个networking是从别人那里inheritance下来的，他可能从别人那里inheritance过来，等等。我不能保证哪个变化解决了这个问题。 这里他们没有特别的顺序：

• 所有DC都不在“域控制器”OU中。 我从来没有见过一个在其他地方有他们的DC的Windows域。 我把他们移回到他们所属的地方。 他们以前是在每个办公室所在城市的名称隔离的OU（我有一种感觉，我现在有一些pipe道工作来处理，现在我感动了，但目前似乎都没问题…）
• AVG Anti-Virus正在所有DC和DFSR参与服务器上运行。 我从主动/读写扫描中排除了复制的文件夹和暂存文件夹。 我不认为这解决了这个问题，我很可能稍后再testing这个问题，看看撤消这个改变是否会干扰DFSR的复制速度。 这是另一天的挑战。
• dcdiag.exe抱怨有关RODC的DNS问题。 即使我们在域上没有RODC，我也可以解决这个问题。 我怀疑这固定任何东西。
• 其中一个DC（不是DFSR服务器之一）缺less_ldap._tcp.domain.GUID._msdcs.DOMAIN.NET SRVlogging之一，我补救了这一点。 我不认为这也有帮助。
• 有一次，我重新启动了服务器BETA，它抱怨DFSR数据库closures不正常（事件2212），然后花了几个小时重build数据库。 完成后，报告事件2214，让我知道它完成。 之后，复制仍然运行得非常缓慢，但它可能有助于解决任何被卡住的问题。
• 其中一个DC在其接口configuration中没有127.0.0.1作为辅助DNS服务器。 我添加了它。 这不是DFSR服务器之一，所以可能没有任何关系。
• 我遵循TechNet博客：在DFSR中调整复制性能为DFSR服务器build议的registry设置。 除了AsyncIoMaxBufferSizeBytes被设置为4194304之外，我使用了所有“经过testing的高性能值”值，这是比高值低一个档位 。 这可能有助于解决这个问题…或者不是。 很难判断什么时候变化太多的variables。
• dcdiag.exe抱怨在与BETA上的RPC服务进行通信时出现问题，但是只有在已经进行上述更改之后。 这似乎是最可能发生的问题，但我没有做任何改正。 VPN运行正常，防火墙没有阻塞它。 上述其中一项可能是造成这种情况的原因之一，也是纠正RPC问题的原因之一，也可能是简单的巧合。 目前我没有收到这个错误，目前复制运行正常。

故事的寓意是：一次改变一件事，否则你永远不会真正知道是什么修复了它。 但是我很绝望，没有时间去修理，所以我刚刚解决了一堆子弹。 如果我find了解决办法，我会在这里报告。 尽pipe如此，不要把钱缩小。

编辑5/21/2012：我解决了这个问题，通过一个备用服务器（GAMMA）昨天驾驶了七个小时到远程办公室。 GAMMA现在作为他们的主要本地服务器，而他们通常的服务器（testing版）赶上复制。 自从我把它放到位后，服务器的复制速度已经翻了一番。 虽然这告诉我这可能是一个VPN相关的问题，但我并不认为这是因为所有新的更新似乎都从ALPHA复制到GAMMA，这个过程非常迅速，进展顺利。

编辑5/22/2012：现在在12000，应该在几个小时内完成。 我会张贴从慢启动到快速完成的一个很好的图表。 问题是唯一真正“固定”的是本地服务器连接。 我目前认为，也许VPN是问题的一部分。 如果是这样的话，我觉得这个问题还没有完全回答。 在我有更多的时间来检查通过VPN复制事件并看到任何失败之后，我将debugging并报告进度。

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