rsync 增量同步与断点续传实战：exclude、--delete 与限速

发布时间：2026-09-16 04:31 更新时间：2026-09-16 04:31 阅读量：0

给服务器做备份，绕不开一个问题：目录里动辄几十万个文件、几百 GB 数据，如果每次全量拷贝，既慢又浪费带宽。rsync 的价值就在这里——它只传输「有差异的部分」，配合断点续传和限速参数，可以在生产环境里稳定跑完一次大目录同步。这篇文章从实际备份任务出发，把增量同步原理、exclude 规则、--delete 的风险和 --bwlimit 限速讲清楚，命令都可以直接改成自己的路径来用。

增量同步与断点续传：rsync 到底比 scp 强在哪

scp 的思路是「整文件搬运」，文件改了一个字节也要重传整个文件。rsync 默认采用 quick check 算法：先比较文件大小和修改时间（mtime），两者一致就认为文件没变，直接跳过。这一步不需要读文件内容，几万个文件的目录也能很快扫完，这是它做增量同步的基础。如果加上 --checksum，rsync 会改用校验和比较，结果更可靠，但需要读取每个文件计算哈希，大目录下会明显变慢，一般只在怀疑 mtime 不准时才用。

断点续传靠的是 --partial 和 --append-verify 这类参数。默认情况下，传输中断后 rsync 会把没传完的临时文件删掉，下次重头再来；加上 --partial 后它会保留部分文件，下次同步时从已传部分继续。要注意的是，--append-verify 只适合「只在文件尾部追加内容」的场景（比如持续写入的日志），如果文件中间被修改过，用追加模式反而会导致两端不一致，这种情况应让 rsync 重新校验整个文件。

# 基础增量同步：保留权限、属主、时间戳，显示进度
rsync -avz --partial --progress /data/www/ backup@10.0.0.8:/backup/www/

大文件续传场景：只追加且校验，适合日志类文件
rsync -avz --append-verify /data/logs/app.log backup@10.0.0.8:/backup/logs/

本地目录之间同步，相当于带增量能力的 cp
rsync -a --delete /data/www/ /mnt/backup/www/

路径末尾的斜杠是新手最容易踩的坑：源路径带斜杠表示「同步目录里的内容」，不带斜杠表示「同步这个目录本身」。比如 /data/www/ 会把 www 里的文件铺到目标目录，而 /data/www 会在目标下再建一层 www。写命令前先确认这一层，能避免备份目录结构错位。

exclude 规则怎么写，别把缓存和临时文件也备份了

真实备份任务里，缓存目录、session 文件、日志、.git 目录通常没必要同步，它们体积大、变化频繁，会拖慢每次增量。rsync 提供 --exclude（排除）和 --include（包含）两个参数，规则按顺序匹配，先匹配到的先生效。规则里如果包含斜杠，会按「相对传输根目录的路径」匹配；不带斜杠则匹配任意层级下的同名文件或目录。

# 排除缓存、日志、.git，并排除所有 .tmp 结尾文件
rsync -avz --partial \
  --exclude='cache/' \
  --exclude='runtime/log/' \
  --exclude='.git/' \
  --exclude='*.tmp' \
  /data/www/ backup@10.0.0.8:/backup/www/

规则较多时，写进文件更清晰，用 --exclude-from 引用
rsync -avz --partial --exclude-from=/etc/rsync-exclude.txt \
  /data/www/ backup@10.0.0.8:/backup/www/

写规则时有一个容易忽略的顺序问题：include 必须放在对应的 exclude 之前，否则文件会先被 exclude 拦掉。比如想保留 config 目录但排除其余子目录，就要先 --include='config/' 再 --exclude='*'，具体行为以 rsync 官方手册的 FILTER RULES 章节为准。规则调试阶段可以加 -n（dry run）先跑一遍，只看会传哪些文件，不真正写入。

--delete 的风险与 --bwlimit 限速：生产备份必须把关的两处

--delete 的作用是让目标端与源端保持一致：源端删掉的文件，目标端也删掉。用在「镜像备份」场景很方便，但风险也最大——一旦源路径写错、挂载点没挂上、或者手滑把源目录指到了空目录，rsync 会忠实地把目标端清空。这不是 rsync 的 bug，而是它按你的指令执行了同步。降低风险有几个实用做法：先加 -n --delete 演练，确认删除清单再执行；给删除动作加保险参数 --delete-after（传输完成后再删），避免中途失败留下半截状态；条件允许时用 --backup --backup-dir，把被覆盖或删除的文件挪到备份目录，而不是直接消失。

# 演练：只显示将被删除的文件，不真正删除
rsync -avn --delete /data/www/ /mnt/backup/www/

带回收目录的镜像同步：被删文件挪到 .rsync-trash，保留 7 天由外部脚本清理
rsync -avz --delete --backup --backup-dir=/mnt/backup/.rsync-trash/$(date +%F) \
  /data/www/ /mnt/backup/www/

限速 2MB/s，避免备份把业务带宽跑满
rsync -avz --partial --bwlimit=2048 \
  /data/www/ backup@10.0.0.8:/backup/www/

--bwlimit 的单位是 KB/s，写 2048 就是约 2MB/s。它限制的是 rsync 自身的平均传输速率，适合备份任务与业务共用同一块网卡的情况。如果是跨机房同步，同时给 rsync 加上 --timeout 防止长时间卡死，再把整个任务放进 crontab 或 systemd timer 里定时执行，配合日志文件记录每次结果，出问题才好回溯。另外，同步大量小文件时可以考虑 -z 压缩，但它消耗 CPU，内网高带宽环境下不一定划算，实际效果以自己环境的测试为准。

小结一下：用 rsync 做备份，核心是三件事——靠 quick check 实现增量、用 --partial 系列参数应对中断、用 exclude 规则减少无效传输；而 --delete 和 --bwlimit 则是「安全」与「带宽」两个开关，前者务必先 dry run 再加回收目录，后者按业务可承受的带宽来定数值。建议你先在测试目录跑通一遍完整命令，确认删除清单和限速效果符合预期，再写进定时任务，把 rsync 的输出重定向到日志文件长期留存。

继续阅读