最近给一个日均产生不少用户附件的站点做容灾架构，一台主节点对外承接流量，另一台备用机做冷备待命。之前一直靠每天凌晨定时打包备份到对象存储，虽然稳妥，但真遇到主节点硬件故障，最多可能会丢整整一天的数据。为了做到更细粒度的数据安全，这几天把网站附件目录的多机增量同步调通了，顺便把几个关键配置和踩坑点记下来备忘。
1. 为什么用单向增量而不是双向实时？
刚开始很多人容易走入误区，总想着做“双机双向实时同步”，以为这样两边都能随便改。实际跑起来之后，很容易遇到双向死锁、文件覆盖冲突或者循环同步把 CPU 跑满的问题。
对于大部分站长的主备容灾场景，业务逻辑上永远是主节点写入、从节点只读镜像：
- 权限清晰：主节点负责产生文件（用户上传的图片、静态资源），通过文件系统事件触发推送到从节点。
- 避免冲突：从节点不开启写入权限，即使备用机宕机或网络短时间断开，重新连上后也只是主节点往从节点补齐差量，不会引起版本混乱。
- 隔离动态文件：像 runtime 缓存目录、日志目录、临时上传目录绝对不要放进同步列表，否则微小的缓存变动都会引起无休止的网络 IO。
2. 关键内核参数与监听配置参考
底层不管是自己写脚本还是用图形化工具，实时同步核心大多依赖 Linux 的 inotify 机制来捕获文件变动。如果网站文件量比较大（比如几万张图片以上），系统默认的监听上限很容易被打爆，表现为同步进程默默死掉，也不报错。
通常需要根据服务器配置，调整 /etc/sysctl.conf 里的系统监听参数：
| 服务器内存配置 | max_user_watches（最大监听数） | max_queued_events（队列长度） | 推荐并发限制 | 说明 |
|---|---|---|---|---|
| 1G 内存轻量机 | 1048576 (100万) | 16384 | 1 - 2 | 内存有限，避免大队列占用过多内存 |
| 2G 内存标准机 | 2097152 (200万) | 32768 | 2 - 4 | 绝大部分中小型博客/企业站完全够用 |
| 4G 及以上机器 | 4194304 (400万) | 65536 | 4 - 8 | 适合附件多、日更新高频的电商或论坛 |
改完后记得执行 sysctl -p 重新载入。另外，排除规则（Exclude）一定要先在主节点配好，通常建议排除：
*.tmp、*.log、runtime/*、.git/* 以及网站程序自动生成的静态 HTML 缓存目录。只同步真正的用户上传资源（如 /wp-content/uploads/ 或 /data/upload/）。
3. 同步过程中常遇到的卡顿排查
在实际压测测试过程中，有两处细节极易被忽略：
第一是大量碎小文件初次同步。如果主节点上已经攒了十多万个小文件，第一次全量拉取时千万不要开高并发，否则两台机器的 CPU 和磁盘 IO 会瞬间被拉满，甚至导致主节点的 Web 服务产生 502 假死。初次建立同步时，最好限制带宽和并发数，等基准文件全部对齐后，再切回增量监听模式。
第二是密钥权限与 SSH 端口异常。多机数据打通通常依赖 SSH 密钥通道，很多人直接用 root 账号，但私钥权限给得太宽松（比如 777），或者服务器开启了高位 SSH 端口、改过主机密钥，都会导致同步静默失败。确保主备机之间的密钥文件权限为 600，且通过命令行手动验证能免密连通一次，才能保证同步守护进程正常常驻。
4. 后续运维与更省心的方案考量
如果是日常运维几台轻量机器，按照上面的参数自己写 inotifywait 加 rsync 脚本，挂在 nohup 或者 supervisor 里跑，基本能解决 80% 的问题。但这种方案最大的痛点在于缺乏监控与断点自愈——一旦某次网络波动导致进程异常退出，你很难第一时间发现，往往直到备机接管时才发现数据早就停更了。
如果服务器承载着比较重要的线上业务，或者需要管理多个站点的分布式节点，直接借助宝塔成熟的官方插件会省心很多。比如宝塔自带的【网站文件多机实时同步】插件，底层就是针对大文件增量分块传输和毫秒级变更做了封装，自带断点续传和异常报警机制；再配合【企业级多云自动备份】，异地打包多一份对象存储归档，整个数据容灾链路基本就闭环了。
需要注意的是，宝塔官方这类高级功能插件如果单独单月购买，长期算下来成本并不低。但要是你的机器升到了宝塔企业版，包括多机同步、网站安全防火墙在内的 30+ 款高级插件都是直接全部免费解锁的。如果大家打算长期稳定运营自己的服务器环境，也可以了解一下我们站提供的正版终身授权方案，一次买断、永久有效，后台也支持随时自主更换绑定的服务器 IP，用起来相对更划算也更踏实。