印度机房用 rsync 增量备份，删掉的文件在目标端活了三个月

印度机房一台备份机，Debian 11，源目录 1.8TB 左右，约 42 万个文件，主要是应用日志和上传件。目标是一块 4TB 的外挂盘，xfs。每天凌晨跑一次同步，跑完我只看 rsync 的退出码和尾部几行，一直是 0，就默认没事。

三个月后要回收一块盘，去目标端核对，发现源端早删掉的东西还在，占了 600 多 GB。命令本身没报错，问题在参数：

rsync -avz --partial --progress /data/upload/ /mnt/backup/upload/

没有 --delete，增量同步就只做加法。源端删文件，目标端永远不知道。更麻烦的是目录改名：源端把 2024-03 改成 2024-03-archive，目标端会当成一个新目录整个拷一遍，旧目录原样留着，数据翻倍。

改成的样子：

rsync -a --delete --delete-excluded \
  --exclude='*.tmp' --exclude='cache/' \
  /data/upload/ /mnt/backup/upload/

注意 --delete 和 --exclude 的顺序关系：被 exclude 掉的东西不会因为 --delete 被删，这一点是安全的；但如果你加了 --delete-excluded，目标端的这些文件也会一起清掉，要确认目标端确实不需要留。我一开始两个都加，结果目标端原本留着的 .tmp 恢复副本被清空，好在那些是垃圾。

代价说清楚：--delete 意味着源端误删会立刻传导到备份端，没有缓冲。我的做法是先跑一遍 dry-run，把删除清单落到日志里：

rsync -a --delete --dry-run /data/upload/ /mnt/backup/upload/ \
  | grep '^deleting' > /var/log/rsync-delete-$(date +%F).log

第二天早上看这个文件，条数异常就先不动。另外 -z 我在内网直连时去掉了，42 万个小文件压缩收益不大，CPU 反而先到瓶颈，单次跑从 50 分钟降到 35 分钟左右。

哪里会失效：源端和目标端文件系统不同、大小写敏感性不同时，--delete 会按目标端的规则判断，可能出现删了又拷的循环；跨机走 ssh 时如果中途断连，目标端可能停在半删状态，得配合 --partial-dir 和重跑。还有一次目标盘写满，rsync 报错退出，但前面的删除已经生效，等于备份被削掉一块——所以我现在跑之前先 df 卡一道阈值。