用 rsync 做服务器文件同步与备份：增量同步、断点续传与定时备份的完整做法

为什么用 rsync，而不是直接 cp 或 scp

服务器之间传文件、做备份时，很多人第一反应是 scp 或者打包后 cp。文件小、次数少的时候没问题，但文件一多、体积一大、需要反复同步时，这两个工具的短板就很明显：scp 每次都要完整重传，cp 不知道远端已经有了什么。

rsync 的核心优势就三点：增量同步（只传变化的部分）、断点续传（中途断了能接着传）、属性保留（权限、属主、时间戳都能原样带过去）。本文用一个真实场景串起来：把一台应用服务器上的 /data/www 目录，定期同步到备份服务器，并保留 7 天的备份记录。

一、先确认 rsync 可用

两端都要装 rsync，源端和目标端缺一不可：

rsync --version
# 未安装时（以常见的 yum / apt 为例）
# yum install -y rsync
# apt install -y rsync

同时确认 SSH 能免密登录目标机，否则每次同步都要输密码，定时任务也没法跑。先用 ssh user@备份服务器IP 验证一次连通性，再继续往下做。

二、本地同步：先把基本用法练熟

最常用的组合是 -av：-a 是归档模式（递归、保留权限、时间戳、软链接等），-v 是输出过程信息：

rsync -av /data/www/ /backup/www/

注意一个最容易踩的坑：源目录末尾的斜杠。

• /data/www/：同步目录“里面”的内容到目标目录；
• /data/www（没有斜杠）：会把 www 这个目录本身同步过去，目标下会多一层 www。

写脚本前先在测试目录试一次，确认目标结构符合预期，再对生产目录动手。

需要“目标与源完全一致”、删掉目标端多余文件时，加上 --delete，但一定要先演练（见第六节），否则误删无法恢复。

rsync -av --delete /data/www/ /backup/www/

三、远程同步：通过 SSH 传到备份服务器

生产中最常见的就是这种写法，数据走 SSH 加密通道：

rsync -avz -e ssh /data/www/ user@192.168.1.20:/backup/www/

其中 -z 是传输时压缩，对文本、日志、代码这类可压缩内容效果明显；对已经压缩过的图片、视频包则收益很小，可以不加。-e ssh 显式指定走 SSH，如果目标 SSH 端口不是默认 22，改成 -e "ssh -p 2222"。

第一次同步会传全部数据，之后每天只传新增和改动的文件，这就是增量同步带来的时间节省：一个几十 GB 的站点目录，日常同步往往几分钟就能完成。

四、大文件与弱网络：断点续传

传大文件最怕中途断网。加上 --partial（保留已传的部分文件）和 --progress（显示进度），断了重跑同一条命令就能接着传，不用从头开始：

rsync -avz --partial --progress /data/bigfile.tar.gz user@192.168.1.20:/backup/

如果网络实在不稳定，还可以配合 --bwlimit=5000 把速率限制在约 5MB/s，避免同步占满带宽影响线上业务。

五、排除不需要同步的文件

日志、缓存、临时文件没必要进备份，既占空间又拖慢同步。用 --exclude 排除：

rsync -av --delete \
  --exclude='*.log' \
  --exclude='cache/' \
  --exclude='tmp/' \
  /data/www/ user@192.168.1.20:/backup/www/

排除规则多的时候，可以写进一个文件统一管理，例如 exclude.txt，每行一条规则，再用 --exclude-from=exclude.txt 引用，脚本会干净很多。

六、上线前先演练：–dry-run

任何带 --delete 的同步命令，第一次执行前都要先加 -n（即 --dry-run）看一遍它“打算”做什么：

rsync -av --delete -n /data/www/ user@192.168.1.20:/backup/www/

输出里出现意料之外的删除，先停下来查原因。确认无误后去掉 -n 再真正执行。这个习惯能避免大多数同步事故。

七、做成定时备份：cron + 日志

把同步命令写进脚本 /usr/local/bin/backup-www.sh，加上日志输出，方便事后排查：

#!/bin/bash
LOG=/var/log/backup-www.log
echo "$(date '+%Y-%m-%d %H:%M:%S') 开始同步" >> "$LOG"
rsync -avz --delete --exclude='*.log' /data/www/ user@192.168.1.20:/backup/www/ >> "$LOG" 2>&1
 echo "$(date '+%Y-%m-%d %H:%M:%S') 同步结束，退出码：$?" >> "$LOG"

记得 chmod +x /usr/local/bin/backup-www.sh，再用 cron 每天凌晨 2 点执行：

crontab -e
# 每天 02:00 执行备份
0 2 * * * /usr/local/bin/backup-www.sh

建议头几天每天看一次日志，确认同步成功、耗时正常、没有报错；稳定后再放宽到每周检查一次。

八、备份做完不等于能恢复：定期验证

备份最容易被忽视的一环是验证。建议每月做一次恢复演练：把备份目录同步到一台测试机或临时目录，检查关键文件是否完整、应用能否正常启动。

# 把备份恢复到临时目录验证
rsync -av user@192.168.1.20:/backup/www/ /tmp/restore-test/
ls -lh /tmp/restore-test/ | head

只备份、从不验证恢复的备份，等于没有备份。

九、常见问题速查

• 同步后目标多了一层目录：检查源目录末尾的斜杠是否写对。
• 权限变了：确认用了 -a，并检查两端用户、属主是否一致。
• 每次都全量重传：检查时间戳是否被改动过，或者目标文件系统不支持保留时间戳。
• 同步很慢：先看是不是大文件多、是否开了不必要的 -z，再考虑 --bwlimit 与分批同步。
• 定时任务没跑：先查 cron 日志和脚本里的日志文件，确认脚本有执行权限、SSH 免密配置对 cron 环境同样生效。

总结

rsync 的用法并不复杂，关键是把四个习惯固定下来：先演练再执行、源目录斜杠写清楚、不需要的文件排除掉、备份后验证恢复。把这套流程做成定时任务后，日常的文件同步和备份基本可以做到无人值守，出问题时也有日志可查。