多台 VPS 数据怎么同步？Rsync、Lsyncd 与 P2P 加密工具 Syncthing 实时镜像

延伸阅读

更多相关攻略推荐：Ollama AI系列(2)：VPS上的AI推理与API应用、Ollama AI系列(2)：VPS上的AI推理与API应用、【CPU选型 01】搭载 AMD Ryzen 9950X 的 VPS、ARM / Ampere 席卷 VPS：性价比真香还是兼容陷阱？、Ollama AI系列(2)：VPS上的AI推理与API应用。

一、为什么要把多台 VPS 的数据保持一致

先聊个特别常见的场景。你在某个商家买了一台美国机房的 VPS 跑主站，又买了一台欧洲机房的 VPS 专门存媒体库或者做镜像备份。用户的头像、上传的附件、博客配图，这些文件会同时散落在两台机器上。如果你不主动管它们，过不了几天两边就会各长各的，谁也不认识谁。

再比如你做主备架构：一台是线上机器，一台是冷备机器。哪天主机器炸了，你希望备机器能立刻顶上，文件一分不差。又或者你是个爱折腾的人，家里一台小机器、云上两台 VPS，想让配置文件和无损音乐库在这三处都保持一模一样。

这种需求说白了就一句话：让文件在多个节点之间自动、可靠地保持一致。手动 scp 复制当然能跑，但人不是机器，今天记得明天忘，漏一个文件就是事故。所以我们需要工具来干这件事。下面这三套方案，从简单到高级，从定时到实时，从中心化到去中心化，基本上覆盖了 99% 的玩法。

二、地基工具 Rsync：增量同步的瑞士军刀

不管你最后选哪条路，Rsync 都值得先认识一下。它是 Andrew Tridgell 在 1996 年写出来的老牌工具，到现在依然活跃维护，最新稳定版是 2025 年 1 月发布的 3.4.1，绝大多数 Linux 发行版默认就带着它。它的核心本领叫增量传输：只把源和目标之间不一样的部分传过去，而不是每次都全量搬。

举个直观的例子。你有个 100GB 的日志目录要从 A 机器同步到 B 机器。用 scp 的话每次都是全量 100GB，断了还从头来。用 rsync，第一次可能也是全量 100GB，但第二天再跑，可能只传了变化的几百 MB。这就是增量同步的威力，省时又省带宽。

几个最常用的参数你得记住。-a 是归档模式，保留权限、时间戳等属性；-v 是显示进度；-z 是传输时压缩，对文本和日志特别有效；-P 等于 --partial --progress，既能显示进度又支持断点续传；--delete 会把目标端多出来的文件删掉，让目标跟源一模一样；--bwlimit 后面跟数字，单位是 KB/s，用来限速；--link-dest 配合硬链接可以做空间极省的版本化备份；-c 是用校验和判断文件是否变化，但要小心，它非常吃 CPU。

这里有个新手必踩的坑：源目录结尾的斜杠。rsync -av /data/logs/ /backup/ 是同步 logs 目录里面的内容；rsync -av /data/logs /backup/ 则是把整个 logs 目录本身搬过去，结果变成 /backup/logs/logs。日常用记得加斜杠。还有，正式删东西之前，先加 -n 或 --dry-run 跑一遍，看看它到底要删什么，确认无误再真删。

远程同步的写法是 rsync -avzP /本地目录/ user@远程IP:/远程目录/，走的是 SSH。如果对方 SSH 端口不是 22，加 -e ssh -p 端口号 就行。Rsync 还能脱离 SSH 跑 daemon 模式，地址长这样 rsync://用户名@主机/模块名，适合内网大量机器批量同步，不过配置稍微麻烦点。

三、方案1：Rsync 加 Cron 定时增量同步

最简单、最稳的方案，就是用 Rsync 配合系统的 crontab 定时任务。它的定位很清晰：不是实时镜像，而是定时备份。比如你每天凌晨 3 点把线上数据增量同步到另一台机器，平时两边允许有几小时的时间差，这完全够用。

写法也极简。SSH 配好免密登录后，在 crontab -e 里加一行，比如 0 3 * * * rsync -avz --delete /home/user/data/ user@备机IP:/backup/current/ 大于号 /var/log/rsync_backup.log 2 大于号 1。意思是每天 3 点把 data 目录镜像到备机，多出来的文件删掉，日志写进文件方便排查。如果你不想删目标端多余文件，把 --delete 拿掉就是纯增量备份。

这个方案的优点是简单到不需要学新东西，cron 和 rsync 哪个系统都有，排错也直观。缺点也很明显：它不是实时的。假设你在凌晨 2 点 50 分写了一个重要文件，主机器 3 点 10 分挂了，那这份文件就丢了，因为它还没来得及同步。所以它适合做备份，不适合做需要秒级一致的镜像。

想更省空间还能玩出版本感：用 --link-dest 指向上一次备份目录，没变化的文件直接硬链接过去，不占额外空间。这样你保留 7 天备份，实际磁盘占用只比一份稍多一点，性价比极高。

四、方案2：Lsyncd 基于 inotify 的秒级实时同步

如果你觉得每天同步一次太慢，想要文件一变就立刻传过去，那就轮到 Lsyncd 出场了。它全称 Live Syncing Daemon，翻译成人话就是实时同步守护进程。它的思路很聪明：用 Lua 脚本把 Linux 内核的 inotify 机制和 Rsync 包在一起。

inotify 是 Linux 内核提供的文件系统事件通知接口，文件一创建、修改、删除，内核马上就知道。Lsyncd 盯着这些事件，但它不会每个事件都立刻触发一次 rsync，而是先攒几秒（默认 15 秒），把短时间内的密集改动合并成一批，再跑一次 rsync。这样既做到了近实时，又不会在批量写入时把 rsync 打爆。

它有三种同步模式。default.rsync 是最常用的一路，把变化推到远程 rsync 模块；default.rsyncssh 走 SSH，还能在目标端用 mv 命令移动文件，比删了重传聪明；default.direct 适合两台本地目录互相同步，平时用 cp、rm、mv 来保持同步，性能更好。配置文件是 Lua 语法，一般放在 /etc/lsyncd.conf.lua。

一个能直接抄的配置长这样：settings 里设 logfile、statusFile、statusInterval；sync 块里写 default.rsync，source 填源目录，target 填 user@备机IP::模块名，delete 设成 running，delay 设 3 秒，rsync 子块里开 archive、compress，还能通过 _extra 传 --bwlimit=200 这种参数做限速。Lsyncd 2.2.x 要求两端 rsync 版本不低于 3.1。

这里有个运维老鸟都知道的坑：inotify 能监控的文件数量是有限的，内核参数 fs.inotify.max_user_watches 默认往往只有 8192。如果你的项目目录节点特别多，比如前端工程的 node_modules，很容易超限导致监控静默失效。解决方法是 sysctl -w fs.inotify.max_user_watches=524288 临时调大，再写进 /etc/sysctl.conf 永久生效。另一个坑是实时同步里的 --delete 比定时同步更危险，因为来不及反应，所以生产环境一定要先 --dry-run 或把 init 设成 false 只同步启动后的新改动。

五、方案3：Syncthing 去中心化 P2P 实时镜像

前面两个方案本质上都是一主一从的中心化思路：一个源，一个目标。但如果你有三台、五台机器要互相保持一致，谁主谁从就乱了。这时候该请出 Syncthing，一个用 Go 写的、去中心化的 P2P 实时同步工具。

它的核心特点是没有中心服务器。每台设备靠一个唯一的设备 ID 互认身份，你手动批准谁连谁，之后它们之间直接点对点同步，文件不经过任何第三方中转（除非走中继，下面会说）。通信全程用 TLS 加密，还带完美前向保密，就算密钥以后泄露，历史流量也解不开。协议是自己定义的 Block Exchange Protocol，开源协议是 MPL-2.0。

Syncthing 用的是块级同步，思路很巧妙：它给文件算分块哈希，只传那些哈希对不上的块。比如你改了一个 2GB 视频里的一小段，它不会重传整个文件，只传变化那几块，流量省到极致。它还内置文件版本控制，有回收站模式、交错版本等，误删了能找回来；文件夹还能设成发送 only 或接收 only，防止被别人覆盖。

管理界面是个 Web UI，默认开在 http://localhost:8384。同步流量走 TCP 22000 端口，局域网发现走 UDP 21027。部署方式很多，Linux 直接 apt install syncthing，也能跑 Docker，映射 8384、22000、21027 这几个端口就行。设备之间靠中继服务器（relay）穿透 NAT，重点是中继看到的全是加密流量，内容它解不开，所以相对安全。

它也有自己的小脾气。因为是 P2P 且要做块哈希计算，资源占用比 rsync 高一些，机器上小文件特别多的时候，哈希计算会吃 CPU。跨大洲节点之间如果走中继，延迟和速度取决于中继质量。还有，当两个节点同时改了同一个文件，Syncthing 不会擅自覆盖，而是把旧的那份重命名成带 sync-conflict 后缀的文件，留给你自己裁决，这点对数据安全很友好。

六、异地跨机房：带宽占用和 CPU 消耗怎么压

当你同步的不是同机房的两台机器，而是美国到欧洲这种跨国、跨大洋链路时，账单和性能就开始说话了。国际带宽贵，线路也容易被打满，所以控制带宽和 CPU 是必修课。

先说压缩。rsync 的 -z 对纯文本、日志、代码压缩比很高，能省一大笔流量；但对视频、jpg、zip、mp4 这类本来就已经压缩过的文件，再压基本没用还白费 CPU。所以高级玩法可以加 --skip-compress=gz/jpg/mp4/zip/rar，让这些格式直接跳过压缩。Syncthing 和 Lsyncd 也都有各自的限速入口，比如 Lsyncd 的 _extra 里塞 --bwlimit=200，Syncthing 界面里能设每设备的最大发送速率。

再说限速。跨国线路你最好别跑满，留点余量给其他业务。rsync 用 --bwlimit，单位是 KB/s，比如 --bwlimit=50000 就是限速 50MB/s。Lsyncd 同样能透传这个参数。这样即便同步任务在跑，也不至于把国际出口堵死，SSH 还登得进去。

CPU 方面，最忌讳的就是乱开校验和。rsync 的 -c 选项会逐文件算 MD5 来比对，CPU 直接拉满，平时没事别开，时间戳加大小已经够用。inotify 面对海量小文件写入时，把 Lsyncd 的 maxDelays 调大（比如 500），让更多事件合并成一次 rsync，能明显减少进程数和 CPU 抖动。Syncthing 启动时会自动 benchmark 选最快的 SHA256 实现，一般不用管，但机器太弱的话，把它跑在独立小核或限制进程优先级会更稳。

给个直观数字：一个 100GB 的媒体库，首次同步不管哪种方案都得全量传一遍，顶多靠压缩省点；但之后每天的变化可能只有几十 MB。所以真正决定体验和成本的是增量阶段的效率和限速策略，而不是首次那一下。

七、三个方案横向对比，到底选哪个

看到这你可能纠结：到底用哪个？我给你一个速查思路。

• 只是想做定时备份、不要求实时：选 Rsync 加 Cron。零学习成本，最稳，适合每天增量备份网站数据、用户上传。
• 想要近实时、而且是一主一从的镜像：选 Lsyncd。它本质还是 rsync 那套，但靠 inotify 把延迟压到秒级，资源占用低，适合把线上目录实时镜像到备机或 CDN 源。
• 多台机器互相保持一致、还想要加密和版本控制：选 Syncthing。去中心化、P2P、端到端加密、带版本历史，适合三台以上节点、跨地点互相同步、或者你就是不信任中心服务器。

简单说，备份用 rsync，单向近实时镜像用 lsyncd，多向加密同步用 syncthing。三者不是替代关系，很多人是组合用的：用 syncthing 在几台机器间互相同步，再用 rsync 每天往冷备机落一份，既实时又保险。

八、实操避坑与监控小贴士

最后说几个能救命的习惯。第一，凡是带 --delete 的操作，先跑 --dry-run 看清楚再执行，这个习惯能救你无数次。第二，SSH 一定配密钥免密，别让 cron 或 lsyncd 卡在密码输入上。第三，防火墙把对应端口放开：rsync daemon 用 873，lsyncd 走的是 ssh 的 22，syncthing 要开 22000 和 21027。

监控也不能少。rsync 把输出重定向到日志文件，出问题翻日志；lsyncd 有 statusFile，能看到当前堆积了多少待同步事件、起了几个进程，命令行里 tail -f 一下就知道状态；syncthing 直接看 Web UI 的传输速度和错误提示，最直观。建议给关键同步任务配个简单的健康检查，比如比对两边文件数，数量对不上就报警，别等用的时候才发现早就不通了。