rsync的--backup仅覆盖时移动旧文件，不触发于首次同步；--backup-dir须存在且不重建目录结构，仅存最后一次被覆盖文件，非可靠备份方案。
rsync --backup 和 --backup-dir 实际备份行为
rsync 的 --backup 不是“自动保留所有历史版本”，它只在覆盖文件时，把**被覆盖的旧文件**挪走——前提是目标路径里原本就存在同名文件。如果目标路径是空的、或文件是首次同步，--backup 完全不触发，也不会生成任何备份。
--backup-dir 必须配合 --backup 使用，且该目录必须已存在（rsync 不会自动创建）。它只接收被覆盖的旧文件，**不递归重建目录结构**：比如源是 docs/report.txt，目标已有同名文件，rsync 会把旧 report.txt 移到 --backup-dir 根目录下，而不是 --backup-dir/docs/report.txt。
- 备份文件名默认不变（除非加
--suffix，如--suffix=.20240501） - 如果多次覆盖同一文件，只有最后一次被覆盖的旧版本会被移到
--backup-dir，之前的备份会被新备份覆盖（除非用--suffix避免重名） -
--backup-dir路径必须是绝对路径，或相对于 rsync 当前工作目录的相对路径（不是相对于目标目录）
误删后能否靠 --backup-dir 恢复？
不能直接依赖。因为 --backup-dir 只存“被覆盖时淘汰下来的旧文件”，不是“删除时保留的快照”。如果你执行的是 rsync --delete 同步，被删掉的文件根本不会经过“覆盖”流程，也就不会进入 --backup-dir —— 它们直接被 unlink，无痕消失。
真正能恢复的，仅限于以下情况：
- 你没用
--delete，只是增量同步，且某些文件在目标端被源端新版覆盖了 → 对应旧版在--backup-dir中 - 你手动删了目标文件，但之前恰好执行过一次带
--backup的同步，且该文件当时被覆盖过 → 它可能还在--backup-dir里
换句话说：--backup-dir 是副作用产物，不是备份方案。把它当恢复依据，等于赌自己过去某次同步刚好“撞上”了要恢复的文件被覆盖的时机。
用 rsync --dry-run 提前识别风险操作
--dry-run 的核心价值不是“看会不会报错”，而是观察 rsync **打算删什么、覆盖什么、跳过什么**。但它有严重盲区：默认不显示将被 --delete 删除的文件，除非加上 --itemize-changes（简写 -i）。
安全验证必须组合使用：
-
rsync -avn --delete --itemize-changes src/ dst/：a表示 archive 模式（隐含-r -l -p -t -g -o -D），v输出详情，n即--dry-run；-i会在每行开头标出变更类型，其中*deleting行明确列出将被删除的文件 - 注意
--delete的作用域：默认只删目标端比源端多出的文件；加--delete-before或--delete-after会影响顺序，但不改变删除列表 - 如果源路径末尾有
/（如src/），rsync 同步的是目录内容；没有/（如src）则同步整个目录本身——这直接影响--delete的范围，--dry-run结果也完全不同
真正可靠的恢复前提是你自己留了底
--backup-dir 目录本身没有版本管理、没有时间戳记录、不校验完整性。它只是一个临时中转站。如果你没定期归档它，或没监控它的磁盘占用，里面可能早已被覆盖、清空、或权限异常导致不可读。
更现实的做法是：把 --backup-dir 当作“辅助线索”，而非“恢复来源”。真正要恢复，得靠外部快照（如 btrfs/zfs snapshot）、定时归档（tar + date 命名）、或专用备份工具（restic、borg）。rsync 自身不提供回滚能力，它的设计哲学就是“单向确定性同步”，不是“双向可逆操作”。
