Linux rsync --delete 为什么会删错文件：源目录边界、试运行与恢复检查

备份目录里突然少了一批文件，命令却显示同步成功，最先要查的通常不是磁盘故障，而是 rsync --delete 两端目录边界有没有写错。这个参数的含义是让目标端删除源端不存在的多余文件；源路径多一个斜杠、把目录写成通配符，都会改变它看到的同步范围。

误删现场：命令成功不代表结果符合预期

假设发布机把 /srv/release/ 同步到备份机的 /data/release/。某次整理发布目录后，值班同事执行了：

rsync -a --delete /srv/release/ backup:/data/release/

返回码是 0，但备份端多出来的旧文件消失了。这里的“成功”只说明 rsync 完成了它收到的同步规则：目标目录中凡是源端没有的内容，都属于可删除对象。它不会替你判断那些文件是不是人工保留的归档。

先看时间线：哪一步把删除范围放大了

排查时把命令拆成三个时刻，通常比盯着一行日志更快：

1. 同步前：源端只有当前发布树，目标端还保留上次发布的旧文件。
2. 生成命令：脚本拼接了源目录和目标目录，并自动加上 --delete。
3. 目标端变化：rsync 比较两边的相对路径，把目标端独有项列为删除。

如果目标目录本来还承担归档用途，问题不是 rsync 的比较算法失效，而是“镜像同步”和“历史保留”被放进了同一个目录。命令越稳定，错误的边界反而越稳定地重复发生。

根因一：源路径尾斜杠改变了目录树

rsync 官方文档把尾斜杠解释得很明确：源路径带尾斜杠时，传输的是目录内容；不带尾斜杠时，目录本身会成为目标下的一层。先在临时目录做一个最小验证：

mkdir -p /tmp/rsync-demo/src /tmp/rsync-demo/dest
touch /tmp/rsync-demo/src/app.conf
rsync -ain /tmp/rsync-demo/src /tmp/rsync-demo/dest
rsync -ain /tmp/rsync-demo/src/ /tmp/rsync-demo/dest

两条命令的相对路径不同：第一条倾向于出现 dest/src/app.conf，第二条倾向于出现 dest/app.conf。生产命令不要凭记忆补斜杠，先用 -n 看目标端会生成哪一层。

根因二：通配符让 --delete 失去父目录语义

下面两种写法看起来只差一个星号，rsync 收到的对象却不一样：

# 同步整个目录，--delete 才能作用于被同步的目录
rsync -a --delete /srv/release/ backup:/data/release/

# shell 先展开 *.conf，rsync 收到的是若干文件参数
rsync -a --delete /srv/release/*.conf backup:/data/release/

第二种写法不能表达“把 release 目录中不再存在的所有内容清掉”，因为父目录并没有作为完整同步对象传入。更危险的是，脚本改动通配符后，操作人员仍按第一种命令的效果去理解输出。目录镜像用目录路径，筛选需求用 rsync 的包含和排除规则，并且要把结果写入 dry-run 日志。

修复动作：把一次真实同步拆成三次核对

第一步，固定源端和目标端的最终目录

先用文字写出目标端期望的相对路径。例如希望文件落在 /data/release/app.conf，就把源端写成 /srv/release/，目标端写成 backup:/data/release/。不要同时让脚本根据变量有时补斜杠、有时不补。

第二步，只做试运行并保存删除清单

rsync -ain --delete --itemize-changes \
  /srv/release/ backup:/data/release/ \
  | tee /var/log/rsync-release-dry-run.log

-n 表示不实际改动，-i 列出变化类型。看到以 *deleting 开头的行时，逐条确认它确实是源端已经删除的发布文件，而不是备份端特意留下的归档。清单范围不对就停在这里，别用真实同步去“试试看”。

第三步，真实同步后再次复查

确认清单后再执行同一组参数，避免人工复制时换了路径：

rsync -a --delete --itemize-changes \
  /srv/release/ backup:/data/release/ \
  | tee /var/log/rsync-release-apply.log

随后重新运行一次不带删除的检查或对比文件清单，确认目标端仍有必要文件。实时发布目录与历史归档目录最好分开；必须保留历史版本时，使用带版本号的独立目录或快照，不要指望 --delete 同时完成镜像和保留。

发现误删后怎么止损

看到删除数量异常，先停止定时任务和人工重试，保留源端状态、目标端日志与两次 dry-run 输出。不要立即向同一个目标目录再跑一次同步，因为新的写入可能覆盖恢复时需要的时间点。

1. 确认源端当前版本没有继续清理，并复制一份只读清单。
2. 从快照、独立备份或回收站恢复被删目录，恢复前先列出文件数量和校验值。
3. 恢复后重新执行 rsync -ain，先确认只剩预期的新增、更新或删除。

如果没有独立备份，rsync 本身不能把目标端已经删除的文件变回来；它是同步工具，不是回收站。这个结果要如实记录，后续再补快照或版本化备份。

防复发检查清单

• 脚本把源端目录和目标端目录打印到日志，且尾斜杠规则固定。
• 正式任务前自动保留 --dry-run --itemize-changes 输出。
• 生产目录和归档目录不是同一个目标路径。
• 删除数量超过阈值时让任务停在核对阶段，不直接继续。
• 恢复演练能拿到快照、独立备份或可验证的历史副本。

相关问题

--delete 会删除源端文件吗？

不会。它针对接收端目录中源端不存在的多余项。源端文件删除后，下一次镜像同步可能让接收端对应文件也被删除。

为什么一定要先用 --dry-run？

因为删除范围取决于实际路径、过滤规则和两端当前状态。试运行可以在不改文件的情况下看到变化清单，尤其适合发现尾斜杠和变量拼接错误。

历史文件应该怎样保留？

把历史版本放在独立目录、快照或备份系统中。镜像目录适合表达“目标跟源端一致”，不适合同时承担长期归档。

总结：先确认它要不要成为镜像

rsync --delete 并不神秘，它只是严格执行“目标端跟随源端”的规则。真正容易出错的是把路径边界、过滤方式和归档意图混在一起。固定源目录写法，先看 dry-run 删除清单，再做真实同步；如果目标还要保留历史，就把历史放到镜像目录之外。