在法国用二手 NAS 跑 rsync 备份，别把 --delete 当同步

先交代场景：DS218j 两块 4T 红盘做 SHR，DSM 7.1，数据盘约 2.8T，主要是照片和几份工程项目的归档。另一头是同一局域网里的一台 OVH 独立服务器（法国本地机房），走 WireGuard 隧道连回来，每晚 3 点用 rsync 把 NAS 上的 /volume1/archive 拉到服务器上做异地副本。带宽是 Freebox 的千兆下行、700M 上行，实测 rsync 稳定在 40–60MB/s，一次全量跑了差不多 13 小时，之后增量每晚 10 分钟以内。

一开始我图省事，直接抄了网上最常见的命令：

rsync -avz --delete /volume1/archive/ user@server:/srv/backup/archive/

前两周没事。第三周 NAS 上有个目录名被我不小心改错，源路径空了一天，rsync 很勤快地把服务器上那份也删了。还好服务器上还有一份更早的 tar，不然就是双份丢。这件事之后我把命令改成了两段式：

# 先 dry-run，把删除项单独记下来
rsync -avn --delete /volume1/archive/ user@server:/srv/backup/archive/ \
  | grep '^deleting' > /var/log/rsync-delete.log

# 再正式跑，但删除项限制在 30 天前的日志里人工确认过的路径
rsync -av --delete --exclude='*.tmp' \
  --backup --backup-dir=/srv/backup/trash/$(date +%F) \
  /volume1/archive/ user@server:/srv/backup/archive/

关键是 --backup --backup-dir：被删除或被覆盖的文件不会直接消失，而是进当天的 trash 目录，保留 14 天再由 cron 清。代价是服务器上多占一份空间，我按 2.8T 的 8% 预留，实际一周下来大概 60–90G，可以接受。

为什么不用 DSM 自带的 Hyper Backup 直接推？试过，走 rsync 协议时它对符号链接和部分中文文件名的处理不稳，日志也不够细。用裸 rsync 至少每一步都能在 -i 的输出里看到。另外 -z 在千兆局域网里其实是负收益，压缩吃掉 CPU，传输反而慢，我后来去掉了。

会失效的地方说几个我踩过的：一是源目录末尾的斜杠，/volume1/archive 和 /volume1/archive/ 结果完全不同，前者会在目标下多套一层目录；二是 NAS 上如果有正在写入的大文件，rsync 会传一个不完整版本，我后来在 cron 里加了一句 find /volume1/archive -mmin -5 判断有没有活跃写入，有就跳过当晚；三是 WireGuard 隧道 MTU 没调时，大文件偶尔卡在 99%，这个之前社区里有人写过，不再展开。

现在的问题是：服务器端那份 trash 目录我按日期分，但清理脚本只会删整目录，遇到跨天还在被引用的文件就没法处理。你们在类似的两段式 rsync 里，是怎么做保留策略的？