我们一直存在 DFS 问题，但最近它变得越来越糟，没有明显原因，而且危害很大。我们有一台主服务器和与其他四台服务器的 DFS 连接。这四台服务器不修改任何文件，因此所有复制总是从主服务器传播到其他四台服务器。复制目录有大约 900,000 个文件。最近几周，每次我们检查 DFS 积压文件时，都会发现有数十万个文件。例如，目前，主服务器将大约 700,000 个文件复制到四台服务器中的三台，而第四台服务器正常。有时，只有一台关闭，有时是两台，这次是三台。而且，它从来都不是同一组服务器。难以想象有什么东西会定期触及所有 900,000 个文件。发生的最大变化是每六个小时对几千个文件的定期更新。
有人遇到同样的问题吗？这是一个已知问题吗？
更新：（这也是对 Jeff Miles 提出的一些问题的回答）。几个小时前，问题再次出现。我早上设置了一些探测器，并在白天监控服务器，在一个看似随机的时间，三个积压在一分钟内膨胀到 300 万个更改（这比文件总数还多）。DFS 事件日志中没有任何有趣的内容。甚至没有“开始初始复制”。只有几个“DFS 连接丢失或无响应”错误，但它们发生在事发后约 10 分钟。很可能是因为某些东西堵塞了巨大的积压。更重要的是，第四台服务器很好。这表明 300 万个更改很可能是假的。此外，我无法想象在这么短的时间间隔内会更改这么多文件。关于技术设置；它是 Win2003R2 和 Win2008R2 的组合。这会是个问题吗？
答案1
首先，验证您的拓扑。仔细检查复制集属性中“连接”选项卡下的复制连接：
- 集线器应该与每个遥控器之间有一个出站连接
- 每个遥控器应该只有一个出站连接，从其自身回到集线器
我曾见过意外添加的全网状拓扑导致出现您所看到的问题。
其他可能的罪魁祸首： - 在一台或多台服务器或其客户端之一上进行防病毒扫描或文件索引。（打开文件会更新其访问时间，然后必须将其复制到所有对等点。） - 一个或多个非常大的文件阻塞了复制 - 这应该会显示在您的 DFS-R 日志中。
最后，您是否需要 DFS-R，或者可以使用常规 robocopy 来保持文件夹同步？
答案2
如果您定期看到积压文件中有数十万个文件，我猜测某些东西正在更改您文件的安全 ACL，尤其是当您在积压清除期间没有看到太多网络流量时。
检查修改这些文件的内容的一种方法是启用审核。Microsoft Directory Services 团队的 Ned Pyle 最近发布了一篇博客，其中介绍了使用全局对象访问审核的功能，这可能有助于您确定正在发生哪些更改： http://blogs.technet.com/b/askds/archive/2011/03/10/global-object-access-auditing-is-magic.aspx
我也会检查您的 DFSR 事件日志，并查找任何事件 ID 4102（开始初始复制）或 4104（初始复制完成）。如果您的文件未被修改，我能想到的积压数十万个文件的唯一原因就是初始复制。如果您的 DFSR 服务崩溃，它可能会损坏 DFSR 数据库并触发初始复制。
如果可以的话，我会尝试使用只读 DFSR，如下所述： http://blogs.technet.com/b/askds/archive/2010/03/08/read-only-replication-in-r2.aspx
我想象根据您的 Server 2003 标签您还不能做到这一点，但是根据您的使用情况值得一提。
http://blogs.technet.com/b/askds/archive/2010/03/08/read-only-replication-in-r2.aspx
答案3
由于您看到在很短的时间内复制了不合理的文件数量，因此一定有一个应用程序在不更改文件数据的情况下更改了文件属性或 USN 日志值，例如，更改存档位的备份软件以及一些 AV 软件会触发此操作。
我将成立一个测试复制组来排除故障，并测试备份软件、AV 软件等项目对复制的影响。除了您收到的其他建议之外，我还将记录并观察 USN 日志中的变化，而无需更改文件数据。提供的链接是一篇很好的文章，介绍了检查应用程序是否更改了 USN 日志，但没有更改文件数据，从而导致过度复制。
还要注意文件屏蔽、配额等。我见过一些文件屏蔽完全停止复制的情况。
您是否将防病毒软件设置为扫描 DFSR-Private 文件夹（暂存、冲突和已删除等）？
-肯