能恢复，但仅当同步时启用了--backup与--backup-dir；否则rsync直接unlink文件，无回收站，依赖文件系统恢复工具成功率极低且不推荐。
rsync --delete 误删后还能恢复吗
能，但前提是当初同步时用了 --backup 或 --backup-dir；没开备份选项的，rsync 不留痕，删了就是真没了。它不像 rm 有回收站，也不像某些 GUI 工具会自动存副本——删操作是直接 unlink 文件，靠文件系统层面的恢复工具（如 extundelete）成功率极低，且不推荐在生产环境试。
怎么用 --backup-dir 预防误删
核心是让 rsync 在覆盖或删除前，把旧文件挪进指定目录而不是直接丢弃。关键不在“删”，而在“删之前先存一份”。
-
--backup必须和--backup-dir配合使用，单独用--backup只会在目标目录加波浪号后缀（比如file.txt~），不集中管理，容易漏看 -
--backup-dir路径必须存在，且对运行用户有写权限；建议用绝对路径，避免相对路径在不同工作目录下行为不一致 - 必须搭配
--delete或--delete-before才会触发备份逻辑——如果只是新增/更新文件，--backup-dir不起作用 - 示例命令：
rsync -av --delete --backup --backup-dir=/backup/rsync-20240510 /src/ /dst/
--dry-run 看不出 --backup-dir 实际效果
rsync --dry-run 会跳过所有真实 I/O 操作，包括备份动作。它只模拟“哪些文件会被删/传/覆盖”，但不会告诉你“旧文件将被移到哪个 --backup-dir 下”。所以光靠 --dry-run 无法验证备份是否生效。
- 真正验证方式：先小范围实操一次（比如同步一个子目录），然后检查
--backup-dir下是否有对应文件结构 -
--dry-run的价值是确认--delete是否会误伤——比如发现它打算删掉你本想保留的某个子目录，就该立刻加--exclude或调整源路径 - 注意：
--dry-run输出里出现deleting xxx行，不代表这些文件真会被删；但如果同时开了--backup-dir，那些行对应的文件在真实运行时才会被移走
误删后从 --backup-dir 恢复的实操要点
恢复不是一键回滚，得手动把备份目录里的文件拷回去，而且要注意时间戳、权限、软链接等细节是否匹配原始需求。
- 别直接
cp -r /backup/rsync-20240510/* /dst/——这会覆盖当前还在用的新文件，甚至可能把已删除目录下的残留文件也一并“复活” - 优先用
rsync反向同步：rsync -av --ignore-existing /backup/rsync-20240510/ /dst/，--ignore-existing防止覆盖现有新版本 - 如果备份目录里有嵌套层级（比如
/backup/rsync-20240510/path/to/file），确保目标路径/dst/是完整根路径，否则可能错位还原 - 恢复后务必校验几个关键文件的
md5sum或stat时间戳，确认没被意外截断或权限错乱
最麻烦的其实是备份目录本身没做定期清理，或者多个 --backup-dir 时间戳命名不规范，导致你根本不确定该从哪天的备份里找文件。这事一旦发生，就得翻日志、对时间、比路径——没有捷径。
