跨 VPN 的 DFS 复制：锁不是你得到的东西

链路已加密、始终在线、速度也足够快，所以共享文件夹理应在两个站点表现得像同一个文件夹。这正是大多数 DFS 复制设计背后的假设，也正是它们后来让人吃亏的地方。DFSR 是多主、异步的：每个副本独立跟踪版本，协议里没有任何东西能在服务器之间持有锁。VPN 只在两者之间传输流量，不会补上这个假设所需的任何协调。请把写入方式和容量模型设计清楚，否则第一次真正的冲突就会变成一张支持工单。

迷思：VPN 让多个副本变成一个文件系统

隧道只是一种传输。它给你一条两台服务器之间被允许的路径，并把中间的跳数藏起来。它不说明谁能编辑文件、版本以什么顺序到达，也不说明两次编辑撞在一起会发生什么。

加密和可用性属于链路；一致性属于复制引擎，也属于你的工作流程。

DFSR 实际复制的是什么

每台服务器各留一份副本和各自的版本元数据。连接和时间表允许时，变更才会传播；引擎用远程差分压缩只发送文件中变化的部分。当两个副本在任何更新到达之前修改了同一个文件，一个版本胜出，另一个被挪到一边成为冲突副本。没有服务器拦住第二次编辑，因为拦截需要分布式锁，而 DFSR 并不提供。

命名空间路径让副本容易访问，却不会让它们保持一致。

暂存空间是工作容量，不是备份

暂存是复制在整理变更时使用的临时区域。微软的容量指南把被复制文件夹中最大的 32 个文件的总大小作为下限，首次复制期间留出额外余量会有帮助。因此，小文档构成的目录树与存放若干大归档的文件夹，需要的暂存形态并不一样。暂存耗尽时，复制会以看起来像网络故障的方式停住。请按数据量估算，并随着数据变化持续观察。

暂存不是备份，传播变更也不是版本历史。

预播种是优化，不是捷径

对于庞大的现有目录树，受支持的 Robocopy 预播种可以减少首次同步时需要跨链路传输的数据，微软的指南也涵盖了保留文件信息以及处理被锁定或被跳过的文件。它是优化，并不保证目标端已经正确，所以首次复制仍然必须完成并通过验证。跳过这一步验证，站点就会开始提供那些从未进入复制集的文件。

请在用户依赖目标端之前验证初始状态，而不是等到第一起投诉之后。

选好窗口，并定义当前是什么意思

复制时间表和带宽控制决定双方何时可以交换数据。狭窄的非工作时段窗口是一种合理设计，代价是白天留下积压，前提是所有人都同意，远端副本只需在早上之前保持最新。

把这句话写下来，因为积压是四十分钟只有在没人定义过目标时才显得可怕。

按工作流程验收，而不是按单个文件

用人们真正在用的文件来测试：一份大文档、一次日常编辑、一次删除，以及在两个站点故意同时编辑。确认冲突行为与你向业务方承诺的一致，并确认从备份恢复的路径与副本相互独立。然后在几周内，对照服务窗口观察变更量、队列增长和暂存余量。VPN 容量只是若干限制之一，而且很少是你最先撞上的那一个。

把延迟和编辑规则写进文档的设计，远比承诺完全一致副本的设计更容易维护。