先说一个在工单里反复出现的真实场景：某公司在华东机房有一台主力服务器，华北和华南两个办事处各放一台小机器，三地共享的东西主要有两类——产品图库（几万张图，改动频繁但单张不大）和合同扫描件（PDF 为主，写完基本不动）。最早的做法是写一条 rsync 定时任务，每半小时从总部往两个分支推一次。问题很快来了：分支的设计在本地改了一张图，半小时后总部的旧版本又把它覆盖回去；有人误删了一个目录，半小时后这个删除动作被忠实复制到另外两台机器上；更麻烦的是 rsync 的推是单向的，谁在哪个时间点改了什么谁都说不清。改用网盘吧，数据要落到别人的存储上，合同扫描件这一关法务过不去。于是有人开始问：能不能不设中心，让几台机器自己对等同步？Syncthing 就是这条路上被提到最多的一个答案。
本文要回答的不是"Syncthing 怎么装"，而是更靠前的三个问题：没有中心服务器时这条去中心化路线能撑多大规模；带宽、磁盘、内存这三笔账怎么估，才不至于上线两周才发现机器被拖垮；以及哪些场景干脆不该用它。凡是官方公开文档写明的端口、协议与机制，我会直接引用；凡是需要实测才能定的吞吐、内存占用与扫描耗时，我给估算方法而不编数字。读者是需要维护多台租用服务器或多个办公点之间文件一致性的站长、运维与多地办公的 IT 负责人。
把开篇那个场景拆细一点，能更清楚看到 rsync 这类"定时单向推送"方案的失效边界。rsync 本质是一次性的镜像传输工具，比较源和目的的差异后把源的状态覆盖到目的端，它并不维护"这个文件被谁改过、改了几次"的历史，也不区分"目的端的新改动"和"目的端的旧状态"。所以只要两个方向都有人写，就会互相踩：总部推过去覆盖了分支的改动，分支若也跑一条反向任务，又把总部的改动覆盖回来。很多团队靠"同步窗口错开"或"规定分支不许改"来绕开，但规定是人执行的，出事后没人能回溯是哪一次任务覆盖的。
第二类是删除的传播。rsync 加 --delete 之后，源端删掉的文件在目的端也会被删掉。可一旦有人在源端误删，或者某个挂载点临时掉线让 rsync 认为"源目录是空的"，后果就是目的端整片数据被清空。反过来不加 --delete，删除又永远同步不过去，目录里堆满早该清掉的旧文件。这个两难在同步类工具里是结构性的，不是配置能解决的。
第三类是并发与锁。rsync 跑的时候文件若正在被写入，传过去的就是半截文件；业务程序同时读它，读到的就是中间状态。对图片、PDF 这类"一次写完就只读"的文件风险窗口很短，可以接受；对数据库文件、正在追加的日志则致命。所以先把数据类型分清楚，比调参数重要得多。持续同步程序在这点上比 rsync 好一些——传输中的文件会先写临时文件再改名落位——但"好一些"不等于"可以同步数据库"，后面会专门讲边界。
第一类明确不该放进去的是数据库的主数据文件。无论是 MySQL 的 ibd、PostgreSQL 的 base 目录，还是 SQLite 的 db 文件，共同特点是内部有复杂页结构、有 WAL 或 redo 日志、依赖文件系统层面的 fsync 语义与加锁来保证一致性。同步程序看到的是"这个文件变了，我传一下"，是字节层面的变化而不是事务。传过去的文件在另一侧几乎必然损坏或需要崩溃恢复，且在高写入压力下这个损坏窗口持续存在。数据库的复制应走它自己的主从、逻辑备份或快照，不要指望文件同步。
第二类是被持续写入的大日志文件。一个每秒追加几千行的访问日志，会让同步程序不停检测到它变化、不停触发哈希计算与传输，形成"扫描—传输—又变了—再扫描"的循环。这类文件要么放进忽略规则不参与同步，要么改用日志采集链路——即便真的要把日志集中到一台机器上，也该用 rsyslog、filebeat 这类为流式数据设计的工具。
第三类是需要强一致和锁机制的业务数据，比如靠文件锁协调的队列目录、工单系统的附件与索引、"要么全改要么不改"的批量写入。Syncthing 的模型是双向最终一致——保证的是"过一段时间后大家会一样"，不是"任何时刻读到的都一样"，也不提供跨设备分布式锁。两个节点同时改同一个文件，它不会仲裁谁赢，只会把两边都保留下来产生冲突副本。这个行为对图片文档友好，对需要仲裁的业务数据是灾难。
第四类是超大单文件的频繁改动，两个条件同时成立才危险：文件很大（几十 GB 的镜像、视频母带、虚拟机磁盘）且改动频繁。文件被修改后要先算出哪些块变了，若改动位置靠前或块边界整体偏移，重传量可能接近整个文件——一个 40GB 的虚拟磁盘里改了几百 MB，实际传出去的可能是几十 GB。这类数据要么拆成固定大小的分片只同步变化的片，要么别放进同步目录，改用对象存储的版本化管理。
这是最容易在出事后才被理解的一条。同步工具的语义是"让 A 和 B 一样"，那么 A 上删了东西，B 上也必须删掉，否则就不叫同步。这意味着误删、勒索软件加密、程序 bug 导致的批量覆写，都会被高保真地传播到所有节点。你以为有多点冗余，实际只是多点同步的"同一份错误"。
破解这一点靠的不是关掉删除同步（那就退化成单向增量堆积），而是分层：同步层负责"多地一致"，备份层负责"可回滚"。做法按成本从低到高：在其中一个节点上开启文件版本历史，把被删除和被覆盖的旧版本保留在不参与同步的独立历史目录里；给同步目录做定时快照或打包归档到另一个与同步网络隔离的存储；以及真正的异地冷备，周期性把整份数据放到另一家、另一个地域的存储上。
还有个常被忽略的细节：某个节点的存储整体损坏（磁盘坏掉、文件系统损坏）时，同步程序可能把这个"空目录"当成一次真实删除向其它节点广播。所以磁盘挂载必须是硬依赖——确保挂载成功再启动同步服务，挂载点不存在时目录应为空且不可写，或者干脆不启动服务。这个检查要用 systemd 依赖关系或启动前的挂载校验脚本固化，不能靠人记得。
Syncthing 是开源（MPL 2.0）的持续文件同步程序，用 Go 语言实现，官方对自己的定位是"私有、加密、认证、开源、强大、可移植"。它的数据模型里没有服务器和客户端的区分，只有对等的"设备"。每一台设备在安装时生成自己的 X.509 证书，设备 ID 就是这张证书的 SHA-256（32 字节），通常以一串分组的 Base32 字符呈现。官方明确说明：数据只存在你自己的设备上，没有中央服务器保存数据；所有通信使用 TLS，并具备前向保密；每个设备由强加密证书标识，只有显式允许的设备才能连接。这几句话是理解整个安全模型的基础——认证不是靠账号密码，而是靠证书，靠你把对方的设备 ID 加进白名单。
第一道关口是互认。两台机器要同步，必须在各自配置里添加对方的设备 ID，并且至少一边同意共享某个文件夹。单向添加不会建立连接，必须双向确认，这个设计避免了"我知道你的 ID 就能读你数据"的问题。设备 ID 的交换通常靠扫码或复制字符串，注意这个过程要在可信渠道里做，别在不加密的聊天工具里随手发。
第二道关口是发现，也就是"我知道你的 ID，但怎么知道你现在的 IP 和端口"。发现分两层：本地发现用于同一二层网络内的设备，基于 IPv4 UDP 广播与 IPv6 组播；全局发现默认使用项目提供的公共发现服务器集群，设备上线时登记自己的地址再查询其它设备。跨机房多点组网真正起作用的是全局发现，因为三台机器分属不同网络，本地广播根本到不了。依赖公共发现服务意味着设备地址与 ID 会提交给该集群，合规要求高的单位要自行评估或自建发现服务。
第三道关口是 NAT 打洞。绝大多数服务器和办公网络都在 NAT 后，Syncthing 支持 UPnP/NAT-PMP 自动打洞，也支持 SOCKS5 代理出网。成败取决于 NAT 类型：锥形 NAT 通常能打通，双方都在对称型 NAT 后时基本打不通。机房里还有另一种情况——机器有公网 IP，但安全组只放行 80、443 和 SSH，22000 根本进不来，现象与对称 NAT 一样：能出去，进不来。
第四道关口是中继兜底。直连打不通时连接回落到中继节点，中继只是加密数据的转发通道，读不到明文——官方说得很清楚，中继看到的是 TLS 加密后的流量。但官方同样明确：没有端口转发时中继能连上，性能却远不如直连。所以"能连上"和"连得快"是两件完全不同的事——状态页显示"已连接"、文件确实在同步，实际吞吐却可能只有直连的一小部分。最直接的判断办法是看连接类型显示的是直连还是中继。
端口这一节建议直接抄进上线清单。按官方文档：22000/TCP 承载同步协议（BEP）流量；22000/UDP 承载基于 QUIC 的同步协议流量；21027/UDP 用于本地发现广播（IPv4 广播与 IPv6 组播）；8384 是 Web GUI，默认只监听 127.0.0.1。前三个是同步本身需要的，最后一个是管理界面。很多人只开 TCP 忘了 UDP，结果 QUIC 那条路走不通、本地发现也失效，表面还能同步，实际靠中继在跑。
本地发现协议的细节值得单独说一句，它经常在"明明同一网段却互相看不到"的排查里被忽略。本地发现协议 v4 的通告报文，IPv4 广播到 255.255.255.255:21027，IPv6 组播到 [ff12::8384]:21027，官方建议每 30 到 60 秒发送一次。这里的隐含要求是同一个二层广播域——跨 VLAN、跨三层、云上 VPC 之间广播与组播默认不通，本地发现必然失效，这不是故障而是网络结构决定的。跨机房组网请直接依赖全局发现或手动指定对端地址。
机房环境里安全组和 iptables 是两道独立关卡，经常只配了一道。云上安全组默认通常只放行 22、3389、80、443，22000 需显式添加；机器内部的 firewalld/iptables 也要同步放行，否则包到了网卡也被内核丢掉。排查顺序建议：先在本机确认服务确实在端口上监听，再从对端做连通性测试，最后看应用层状态。中间若隔着硬件防火墙，UDP 被丢的概率明显高于 TCP，这也是 UDP 不通时至少还能靠 TCP 保底的原因。
8384 的处理要单独强调：不要暴露到公网。Web GUI 默认只监听 127.0.0.1，这个默认值是对的。需要远程管理时正确做法是走 SSH 隧道（本地端口转发到服务器的 127.0.0.1:8384），或在前面挂反向代理并加身份认证与 HTTPS。GUI 一旦被外部访问到，等于把整个同步网络的控制权交了出去——可以添加设备、可以把目录改成接收模式、可以看到全部文件清单。
中继的存在让 Syncthing 的"零配置可用"成为可能——两台机器装上、互加 ID，即使网络条件再差也能同步起来。但对于服务器之间的多点同步，中继应该被看作"兜底"而不是"方案"。它的代价体现在三个地方，而且这三个地方会互相放大。
其一是带宽瓶颈。所有流量都要经中继节点转发，中继的上行带宽是共享的、不是你独享的。三台机器都靠中继，等于把三份流量压在别人的链路上，实际吞吐取决于中继当时的负载，波动很大——"白天慢夜里快"这种玄学现象，很多就是中继负载变化造成的。做容量规划时中继这一段不能写进服务承诺，因为你无法控制它。
其二是延迟与往返。中继引入一跳，跨地域部署时这一跳可能绕到完全不同的方向。同步协议里有大量小报文交互（索引交换、请求与响应），往返时间拉长会拉低整体吞吐，即使带宽本身够用。表现就是大文件速度还行、几万张小图却同步得极慢，目录结构几分钟不动一下——这是小文件场景的典型症状，根源往往不在磁盘而在往返次数。
其三是抖动与重试。链路不稳定时连接会断开重连，重连后要重新协商、重新比对索引，若正赶上一次全量扫描或一个大文件在传，就会出现"进度反复回退"的观感。更麻烦的是抖动会触发额外的扫描与哈希开销，把 CPU 也拖进来，形成"网络差—重试—CPU 高—扫描更慢"的循环。
什么时候该放弃中继、改做端口映射？三个判据：节点是长期运行的服务器而非临时笔记本、有固定公网出口，那就没有理由不走直连；同步数据量超过"偶尔几 MB"的量级，尤其图片库、视频素材，直连收益非常明显；对同步完成时间有要求，比如"分支十分钟内必须看到总部的新图"，中继满足不了。做法也不复杂：在机房边界把 22000/TCP 与 22000/UDP 映射到这台机器，安全组放行，确认监听地址正确，最后在连接状态里确认类型变成直连，这才算真正上线。
资源这一节我给的是推算方法而不是确定数字，因为实际占用与文件数量、文件平均大小、目录层级深度、硬件性能和版本都有关，具体数值以实测为准。但推导的框架是有用的，你可以在自己的环境里套进去。
先说内存。常驻内存主要由程序本身开销与维护的文件索引元数据构成，后一项与文件数量近似成正比——关键是文件数量，不是文件总大小。存了 500 万个小文件的图库与存了 500 个大视频的素材库，总容量可能都是几个 TB，但前者的索引规模是后者的上万倍。所以评估内存前请先把"目录里有多少个文件"数清楚；层级很深、文件名很长的目录也会让单条元数据开销变大。
再说 CPU。主要开销来自扫描与哈希计算：文件被修改时要重新计算变化部分的块哈希，以判断哪些块需要传输，因此 CPU 消耗与"改动数据量"成正比，而不是与"文件总大小"成正比。真正的峰值出现在首次全量扫描——新加入一个已有几 TB 数据的目录时，所有文件都要哈希一遍，过程可能持续很久，期间 CPU 与磁盘 IO 都被显著占用。所以首次同步要安排在业务低峰，并限制扫描与传输速率上限，避免把生产机器的 IO 打满。
另有两个容易被忽略的 CPU 来源：一是文件监听。程序可以监听文件系统事件来感知改动，减少轮询扫描的开销，但在文件数量极大或内核监听队列不足时监听会失效，回落到定时扫描后 CPU 开销随之上升。二是压缩与加密——传输层的 TLS 加密是强制的，再叠加压缩选项 CPU 会再吃一份，小机器上宁可牺牲带宽也别开压缩。
磁盘这块要算三笔：数据本身、版本历史与冲突副本、暂存空间。版本历史是文件被覆盖或删除时保留下来的旧版本，占用额外空间，不设保留策略就会一直累积；冲突副本是双方同时改同一文件时留下的两份，都要占地方直到你手工处置；暂存空间则是传输过程中临时文件占用的地方，传大文件时需要足够余量，否则会出现"磁盘明明还有空间却传输失败"。
可套用的估算方法：设同步目录数据量为 D，平均每天改动量占总量比例为 r，版本历史保留 n 天，那么额外占用量级约为 D × r × n（粗略上界，实际取决于改动集中在少数文件还是分散在很多文件）。1TB 的图库、每天改动 0.5%、保留 30 天，额外占用量级约 150GB。这个公式的价值是让你在配置保留策略之前就知道代价——保留天数翻倍，磁盘占用也翻倍。容量紧张的机器要么缩短保留天数，要么只在容量最充裕的那一个节点上开版本历史。
带宽的核心公式是：出网总量约等于改动量乘以副本数。注意乘的是副本数而不是节点数——一个文件夹同步给 N 个设备，源端就要出 N 份，所以拓扑对出网量影响很大。星型拓扑（总部为中心，两分支只与总部同步）里总部出 2 份、每分支出 1 份；网状拓扑（三台两两互连）里每台都要发给另外两台，更健壮但连接数与处理开销更高。节点越多差异越明显：星型下中心节点的出网量随节点数线性增长，最终成为瓶颈。
还有个容易漏掉的带宽项：索引与元数据的同步。每次文件变化不只传内容，还要传索引更新。在文件数量巨大、改动频繁的场景里，元数据本身就能占到可观流量，这也是"几万张小图的目录"比"同样大小的几个大文件"更吃链路的原因。海量小文件场景做容量规划时，请把这一项单独留出余量。
下面这张表把前面几节的结论压成一张可对照的清单。表中"出网带宽量级"是以"单次改动量为 1 个单位"为假设的相对估算，用于比较拓扑之间的量级差异，不是实测带宽；实际数值取决于改动频率、文件大小分布与连接质量，请以实测为准。
| 拓扑 / 场景 | 直连还是中继 | 出网带宽量级 | 磁盘额外占用 | 同步时延体感 | 常见坑 |
|---|---|---|---|---|---|
| 两机互备，均有公网 IP 并放行 22000 | 稳定直连，QUIC 优先 | 改动量 × 1，最省 | 仅版本历史与冲突副本 | 改动后数秒内可见 | 只开 TCP 忘了 UDP，QUIC 走不通 |
| 总部星型下发到两个分支，分支有公网 IP | 总部到分支直连 | 总部出 2 份，中心节点是瓶颈 | 分支可不开版本历史以省盘 | 分支间差异需经总部中转 | 分支改的文件要绕总部才到另一分支 |
| 三地网状互连，两两互认 | 多数直连，视 NAT 而定 | 每台出 2 份，总流量最大 | 三份版本历史叠加 | 最健壮，单点故障影响最小 | 连接数与元数据交互成倍增长 |
| 办公点宽带后，无端口映射 | 大概率回落中继 | 与直连同量级但受中继限制 | 暂存与重试产生的临时文件较多 | 分钟级到不稳定，抖动明显 | 对称型 NAT 打不通，看状态页别只看"已连接" |
| 单向发布目录（源 sendonly，其余 receiveonly） | 取决于网络，与拓扑无关 | 只有源端出网，最可控 | 接收端不产生冲突副本 | 单向传播，回传需另设目录 | 接收端本地改动会被覆盖，需提前宣贯 |
| 海量小文件图库（百万级文件数） | 直连也未必快 | 元数据流量占比显著上升 | 索引元数据吃内存多于吃盘 | 首次全量扫描耗时很长 | 内存按文件数估、首扫放低峰、监听队列要调 |
| 超大单文件频繁改动（几十 GB 级） | 直连是前提，中继基本不可行 | 块偏移可能接近整文件重传 | 暂存空间需预留整文件余量 | 单次传输耗时长，易被抖动打断 | 应拆分为固定大小分片或改用对象存储 |
要理解冲突，先理解 Syncthing 判断"谁更新"的依据——版本向量。直观地说，就是给每个文件记一组计数器：每台设备自己有一个计数，每次这台设备修改了这个文件，就把自己那一位加一。比较两台设备上的同一个文件时，不是比时间戳（时间戳在不同机器上可能不准、可能被手动改过），而是比这组计数器：若 A 的每一项都大于等于 B，说明 A 包含 B 的全部修改历史，A 更新，直接同步；反之同理。
麻烦出在"互不覆盖"的情况：A 的计数器里 A 自己那一位是 3、B 那一位是 1；B 的计数器里 A 那一位是 1、B 那一位是 3。两边各自都改过，谁也不包含谁的完整历史，系统无法判断该留哪一个，它的选择是两个都留——被"输掉"的那份改名保存，文件名带冲突标记与来源设备信息，原文件保留另一份。目录里多出的那个文件，就是冲突文件的由来。
这个设计其实是诚实的：无法仲裁时宁可都保留让你自己决定，也不悄悄丢掉一份。但运维负担是真实的——冲突频繁发生，目录里会迅速堆满带标记的副本，磁盘占用上升，业务人员打开文件时会看到"莫名其妙多出来的旧版"。所以减少冲突靠事前设计，不是事后清理。
还有一点容易被误解：冲突与否取决于对端在同一时间窗口里有没有也改过同一个文件，与同步快慢相关但不等价。两台机器长时间断连、各自积累了一周的修改后重连，这些修改会一次性比对，冲突概率远高于平时。断连后的首次重连是冲突高发时刻，要有心理准备和处置流程。
第一件是错峰写入。对必须双向可写的目录，最有效的做法不是"规定大家别同时改"，而是从业务流程上做归属划分：总部维护产品主图，分支只补本地实拍图，两个子目录分开，各自对自己那部分有写权限。把"一个目录谁都能写"改成"每个目录只归一个人写"，冲突就基本消失了。这看着是管理手段，效果却比任何技术调参都好。
第二件是善用单向目录类型。文件夹可设为 sendreceive、sendonly、receiveonly 等类型。sendonly 的节点只往外发，持续把本地状态广播出去；receiveonly 的节点只接收，本地修改不会上传，远端有更新时会被覆盖。把"发布类"数据——官网静态资源、产品手册、安装包——设成源端 sendonly、各分支 receiveonly，就天然不会有冲突，因为只有一个写入方。分支若要回传数据，另开一个反向目录，而不是把同一个目录设成双向。
第三件是忽略规则，把不该参与同步的文件挡在外面，既省带宽省磁盘，也顺带消除大量潜在冲突。典型该忽略的：编辑器与办公软件的临时文件和锁文件、操作系统生成的缩略图与隐藏文件、程序缓存目录、正在写入的日志、构建产物。规则文件本身也可以放进目录里共享，让所有节点的规则保持一致，不会出现"这台忽略了、那台没忽略"的混乱。
忽略规则有自己的语法：支持通配符，支持以特定前缀开头表示"不忽略"的反向规则，也支持指定只匹配某一层目录。几条实战经验：先忽略再放开——把大范围的临时文件模式先忽略掉，再用反向规则把确实需要的少数例外挑回来，比一条条列举更省事也不容易漏；规则顺序有意义，后面的覆盖前面的，所以例外规则要写在通用规则之后。
还要留意日志轮转这个陷阱。很多程序写日志是"写满一个就改名成 .1，再开一个新的"，同步目录若包含日志，轮转会产生大量重命名与新建，被当成真实内容变化去处理。日志确实需要集中就走日志采集链路，不重要就把整个日志目录排除。判断标准很简单：这个文件的变化是不是业务需要被其它节点看到的？不是，就忽略。
第四，忽略规则变更后的生效范围：已经被同步的文件不会因为新规则而自动从对端删除，规则只影响"以后哪些文件参与同步"。上线后期调整规则时容易踩这个坑——加了规则磁盘不会立刻降下来，规划时要考虑这个滞后。
Syncthing 感知文件变化有两条路：基于文件系统事件的监听，改动发生时立刻感知，几乎实时；以及定时全量扫描，作为兜底保证最终一致。两者是配合关系——监听负责快，扫描负责不漏。监听可能因内核监听队列不足、网络文件系统不支持事件或容器挂载的特殊性而失效，此时定时扫描就是唯一保障。
扫描间隔本质上是"及时性"与"资源消耗"的权衡：间隔短则改动发现快，但扫描的 IO 与 CPU 开销出现得更频繁；间隔长则省资源但发现得晚，海量小文件场景下尤其明显。默认值通常是较大的分钟级数值，多数场景够用。真正的调节点在于：若目录文件数量巨大，一次全量扫描的耗时可能接近甚至超过间隔本身，就要把间隔调大，避免扫描任务叠在一起。
对大文件改动要额外注意。大文件在写入过程中会持续触发"文件已变化"，若每次都立刻哈希与传输，会产生大量无效工作。相关行为视版本而定，需在你自己的版本上验证；若不支持，就让写文件的程序先写到目录外的临时位置，写完再原子性地移入同步目录。此外把业务写入时间与扫描窗口错开——批量生成报表的时段不要同时跑全量扫描，这个调整零成本但对 CPU 曲线的平滑效果很明显。
磁盘告警不要等到 90% 才报。同步网络里的磁盘增长是多节点同时发生的（每个节点都积累版本历史与冲突副本），速度取决于改动频率而非你的预期，且暂存文件会在传输期间突然占用一大块。建议按"剩余空间能否容纳一次最大文件的完整暂存"设底线，再叠加版本历史的预期增长量，两者之和作为告警线。监控项也不能只有容量，还要包括 inode——海量小文件场景下 inode 可能比容量先耗尽。
设备吊销必须提前想清楚。由于认证基于证书而非账号，一旦某台设备的私钥可能泄露（机器被搬走、被入侵、员工离职带走笔记本），正确处置是在其它所有节点上移除这台设备的 ID，而不是改密码。移除后该设备即使握有自己的证书也无法连接。处置要快，并随后检查同步目录里有没有异常的版本历史或冲突副本——泄露者可能在断连前已拿到一份完整数据。
证书轮换在默认配置下不需要手动做，程序自己管理。但两件事应纳入运维规范：一是备份配置目录，配置里含设备证书与密钥，机器整体重建时若丢失，新机器会以新设备 ID 出现，需要在所有对端重新添加并可能触发一次大规模重新同步；二是定期检查设备列表，白名单里可能残留早已下线的设备，它们不占资源却是一个被遗忘的访问入口。
另外提醒一句：管理界面若通过反向代理暴露，请确认代理层做了身份校验与来源限制。同步网络里的一次误操作——把目录改成只发送、或添加了错误的设备——影响的是全部节点的数据，代价远高于单点故障。
回到开篇那句：同步会把删除也同步过去。所以无论同步网络建得多健壮，它解决的都是"多地一致"，不是"可回滚"。完整方案里必须有一层独立备份，且与同步网络在物理和管理上都隔离——另一台机器、另一个地域、另一份凭据。这样即使同步网络整体被污染（误删、勒索加密、程序 bug），备份这一层仍然干净。
分层之后职责就清楚了：同步层负责让各办公点读到最新共享文件，追求及时性；备份层负责出事时能把数据拉回来，追求可回溯的时间点。两者对存储的要求也不同——同步层要在线、低延迟的磁盘，备份层可以用更便宜的大容量存储，甚至周期性打包上传的对象存储。分开做成本反而更低，因为备份层不需要实时在线。
备份的验证同样不能省。很多单位的备份一直在跑却从没恢复过，直到真出事才发现脚本早就在报错。最低限度：每季度挑一批文件做一次恢复演练，确认文件完整可读并记下恢复耗时——这个数字决定了你的恢复目标能否达成，也是容量规划的一部分。对合同扫描件这类合规文件，还应保留校验值，恢复后做一次完整性比对。
第一步，单机试跑。在闲置机器上装好，挂上真实同步目录，先不做网络配置，只观察首次全量扫描的耗时、CPU 与内存曲线、磁盘占用。目的是拿到你自己环境的真实数字，而不是照抄别人的经验值。特别留意文件总数与目录层级，它们决定后续资源需求。
第二步，两机直连验证。加第二台机器，手动配置对端地址，放行 22000/TCP 与 22000/UDP，确认连接类型显示为直连。然后造测试改动——新增、修改、删除、重命名——观察对端反应时间与结果是否符合预期。故意制造一次冲突（两边同时改同一文件），看看冲突副本长什么样、落在哪里，让运维提前熟悉处置流程，而不是第一次遇到时慌张。
第三步，引入弱网络节点。把办公点那台没有端口映射的机器加进来，观察它走直连还是中继，记录实际吞吐与完成时间。这一步是确认"最差节点"的体验能否接受；不可接受就回到端口映射那条路上去——与其事后调优，不如一开始就把网络条件准备好。
第四步，写死运维规范：忽略规则放在哪里、由谁修改；版本历史保留多久、在哪几个节点开；冲突副本的检查频次与处置责任人；磁盘与 inode 的告警阈值和接收人；设备添加与吊销的审批流程；备份的执行时间、保留周期与恢复演练安排。这些规范写下来，比任何技术配置都更能决定这套系统能跑多久。
第五步才是铺开。按业务归属把目录拆细，能单向的坚决单向，能分开归属的就分开，剩下真正需要双向可写的部分再配错峰与冲突处置流程。铺开后保持一周高频观察，重点看三件事：连接类型有没有意外退回中继、磁盘增长是否符合估算、冲突副本数量是否在预期之内。
把信息源分层，能省下大量试错时间。第一层是官方来源，必须优先看：协议与端口、设备 ID 与证书机制、发现机制、中继行为的官方表述，都以上游文档为准，版本升级后可能有变化，特别是 QUIC 相关行为与扫描默认值，务必按你实际运行的版本核对。第二层是自身实测数据：文件总数、首次扫描耗时、内存与 CPU 曲线、实际吞吐。这两层决定了方案能不能成立。
第三层才是基础设施这一侧能提供的帮助，而这一侧恰恰是自建同步网络最容易卡住的地方。三类常见卡点：安全组没放行 22000 的 TCP 与 UDP；机器公网出口与 NAT 类型导致打洞失败；机器本身的磁盘 IO 扛不住首次全量扫描。前两类属于网络与权限配置，通常可通过工单协调；第三类是机型与磁盘选型问题，需要在租用阶段就考虑清楚——同步目录这种"大量小文件随机读写"的负载，对磁盘的要求和"存大文件顺序读"完全不同。
一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时信息或咨询确认为准。多点组网这件事上，节点地理位置的选择会直接影响直连成功率与往返延迟——把三个节点放在同一个运营商的同一个区域内，和把它们分散在不同地域，得到的连接质量差别很大。选点之前先把你的节点分布画出来，比事后调参有效得多。
回到开篇那个三地共享的场景，一套能长期跑下去的方案最终落地的是三个决定。第一个是扫描窗口：首次全量扫描放在业务低峰并限速，日常扫描间隔按文件数量而不是数据量来定，大文件写入采用"写到目录外再原子移入"避开半截状态。这三个动作做完，资源曲线基本就平了。第二个是中继依赖：服务器这类有固定出口的节点一律做端口映射走直连，中继只作为临时接入与故障期间的兜底，监控里把"连接类型"当作独立指标盯住，而不是只看"是否连接"。
第三个是冲突处置：把目录按业务归属拆开，能单向的坚决单向，剩下真正需要双向的部分配好错峰规则与责任人，并约定断连重连后的例行检查。这三件事不是配置技巧而是制度设计——技术只负责在制度确定的边界内把事情做对，边界之外的仲裁永远要人来拍板。定死这三条，点对点同步才能从"能跑的玩具"变成"敢放生产数据的系统"。
最后再强调一次边界：同步解决的是多地一致，备份解决的是可回滚，二者不能互相替代。无论同步网络节点有多少、连接有多稳，都请留一份与同步网络隔离的异地冷备，并定期做恢复演练。一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时信息或咨询确认为准。
Copyright © 2013-2020 idc10000.net. All Rights Reserved. 一万网络 科技有限公司 版权所有 深圳市科技有限公司 粤ICP备07026347号
本网站的域名注册业务代理北京新网数码信息技术有限公司的产品
