我们是一家在全国各地都有分支机构的公司。每个分支机构至少有 1 个 T1，最多有 2 个 T1。我们在每个分支机构和总部都有一个 DFS 服务器。在过去的一周里，一个特别麻烦的共享中有一些我们的用户文件，它从来没有出现过 0 个文件的积压。我一直在调整复制计划，试图清除它，我管理的最低限度是该特定共享的 1500 个文件。
我的问题是：
- 我们在 WAN 上设置 DFS 是否错误？
- 对于我们所拥有的文件数量和更改量来说，我们的带宽是否太少了？
- 是不是还有一些神奇的配置还没做呢？
答案1
我在 Windows Server 2003 R2 上为 70 个 WAN 站点提供了与您的设置完全相同的支持，其中大部分站点使用的是 T-1。效果非常好。DFSR 是我们的 WAN 文件服务器备份方法。您可以使用 MRTG 来监控 T-1 路由器的带宽，以验证是否存在任何带宽问题吗？
我们使用 MRTG 查看带宽使用情况图表，并使用基于站点的 GPO 控制 DFSR 上 BITS 使用的带宽。我们将 GPO 设置为白天使用 ~700kb，晚上将 T-1 最大化。有时我们会遇到积压不断增加的情况，如果它们从未清空，那么我们通过服务器和 MRTG 监控知道唯一的选择就是为它们提供更多带宽。DFSR 已经是压缩的和块级的，所以我不知道其他用于异地复制数据的第三方解决方案是否会使其变得更好（如果您确实可以证明它的带宽有限）。
2008 或 2008 R2 中的 DFSR 可能有进一步的优化，因此也请研究该升级选项。
答案2
您似乎已经在这里回答了自己的问题。考虑到您的用户对此共享所做的大量修改，无论多少 DFS 配置调整都无法解决这个问题。您的积压取决于带宽，如果您的用户修改速度快于同步例程同步它们的速度，则永远不会清除为 0。您可能需要重新考虑在此设置中使用 DFS 的架构。文档管理/协作群件系统听起来可能比尝试在文件系统级别运行所有内容更适合这里。
答案3
使用 2008，您可以切换到使用分支缓存 - 它不会盲目地复制所有已更改的内容，而是将已打开的文件保存在缓存中，如果中央副本更新，缓存也会更新。据我记得，在 2003 下，DFS 用作已更改文件复制器。您在 100mb 文件中更改 1 个字节，它会重新复制 100mb。在 2008 下，它只复制 1 个字节。
我很惊讶你没有看到更多问题。几年前我使用过类似的 DFS，但在复制大约 70gb 的文件时开始遇到问题。经过调查，我发现了一份 MS 文档，其中指出它不支持超过神奇的 50gb 标记。问题包括删除未复制的文件……而且是在局域网而不是广域网上。
Linux 有一些分布式文件系统和文件复制工具，但如果带宽不足，它们都会遇到同样的问题。
另一种选择是使用 cifs 加速器。我们使用 packeteer（现在是 bluecoat 的一部分），人们可以通过普通 DSL 打开和编辑 20mb CAD 图表。打开和保存时间都很合理。