我们目前正在使用 Server 2008 中的 DFSR 通过 VPN 链接从总部复制到 3 个分支机构。
这样，我们在每个站点都有一份公司文件的本地副本，以便快速访问和容错。出于成本和速度方面的考虑，我们决定不使用 WAN 加速器和集中文件。
但是，DFSR 对我们来说并不适用。由于我们在中心站点同时打开了 100 个文件，因此 DFSR 重试打开文件所花的时间比传输已关闭文件所花的时间要多，从而造成了积压。每天上午 11 点左右，积压文件数量接近 500 个，直到晚上才会清理完毕。
这是一个大问题，因为一天中的大部分时间服务器都不同步。据我所知，这是无法纠正的问题，所以我们现在正在寻找 DFSR 的替代方案来保持这些服务器同步。
目前是否有人使用这样的系统来处理他们的文件？如果是，您能推荐您正在使用的软件吗？
我发现的一些例子是 GlobalScape WAFS 和 PeerSync。
答案1
任何同步工具都无法同步打开的文件，而且不会冒制作不一致副本的风险。除非该工具与保持文件打开的应用程序挂钩，以请求它“静止”文件，否则始终存在打开文件副本不一致且无法使用的风险。
在我看来，考虑到您谈论的打开文件的情况，几乎任何工具都无法为您提供良好的服务。我想知道版本控制系统/文档管理系统是否可能更适合您。
我用过同步Software Pursuits 的同步工具，虽然不适用于您分发的场景，但我一直对它非常满意。它作为 Windows 服务在复制集中的服务器上运行，并执行增量传输（使用“SPI Agent”附加组件）。它可以复制打开的文件（可以使 VSS 感知应用程序静止），但您可能会遇到一致性问题，正如我上面所说的。
回复：评论：
这是典型的快速/廉价/优质三角权衡。如果您希望副本全天保持同步，则需要为快速连接花费大量资金。如果您不介意副本不同步（但一夜之间“赶上”），那么您可以在快速连接上花费更少的钱。
我没有任何客户期望以这种方式复制的所有文件在所有服务器上始终“同步”。他们没有钱花在 LAN 速度的 WAN 连接上来支持它。
如果您有少量文件需要更严格地保持同步，您可以考虑使用这种更实时的复制解决方案来覆盖这些文件，并使用速度较慢、带宽密集度较低的复制解决方案来覆盖其余文件。
我想，我想说的是，你必须以某种方式付出代价。
答案2
我们已经解决了 DFSR 的性能问题，该问题与我们正在使用的第三方文件锁定软件 Peerlock 的一些错误配置有关。
过去三周以来，一切看上去都进展得相当顺利。
感谢 Evan 和 Tatas 的回答，我们非常感激。