Linux rsync --delete 怎样避免目标目录误删

我第一次把 rsync --delete 放进定时同步脚本时，真正担心的不是“它会不会删文件”，而是“它认定的目标范围是不是我以为的那个目录”。稳妥的做法是：固定源、目标和尾斜杠，先用 --dry-run 配合 --max-delete=0 看清删除清单，再决定是否启用正式删除；需要回退时，再加独立的 --backup-dir。

官方手册：https://download.samba.org/pub/rsync/rsync.1

结论：--delete 只处理正在同步的目录中“目标端有、源端没有”的项目。误删通常来自同步范围写错、源目录不完整，或把排除项也纳入了删除范围。

先弄清 --delete 的删除范围

--delete 的对象是接收端多余项，但前提是 rsync 正在同步整个目录。比如源路径写成 /srv/app/current/ 时，尾斜杠表达的是“同步这个目录的内容”；源路径写成 /srv/app/current 时，目录本身也参与目标路径拼接。正式任务里，源和目标最好都用绝对路径，并把尾斜杠写成团队约定。

不要把 /srv/app/current/* 当作目录同步的替代写法。星号先由 shell 展开，rsync 收到的是一组文件项，不是完整的父目录，因此 --delete 的删除边界也会不同。目标目录里临时文件、人工放入的配置和旧日志，只有在它们落入本次同步范围且没有被保护时，才可能成为多余项。

先用预演确认哪些项目会被删除

我会把预演命令单独保存，不直接把正式命令复制到定时任务里。--dry-run 不改动文件，--itemize-changes 让新增、更新和删除项更容易区分；--max-delete=0 可以在发现目标端有多余项时只给出警告而不执行删除。

#!/usr/bin/env bash
# 先固定同步边界，避免定时任务从错误的当前目录启动
SRC="/srv/app/current/"
DST="/srv/app-mirror/"

# 只做预演：列出变化，并把删除上限设为 0，不改动目标目录
rsync -aivn --delete --max-delete=0 "$SRC" "$DST"

预演时重点看三件事：源目录是否真的挂载完整、目标路径是否指向预期卷、删除项数量是否符合这次发布的变化。如果一次发布只改了几个文件，却出现大量删除项，先停在预演阶段；不要用 --ignore-errors 把异常强行推进，因为官方手册说明发送端出现 I/O 错误时，rsync 默认会自动禁用目标端删除，这是避免源端暂时不可读造成大面积清理的保护。

把排除规则和删除策略分开

默认情况下，--exclude 或过滤规则既影响发送端文件列表，也会在接收端删除阶段保护匹配项。因此像 .env、runtime/ 这类由目标机自己维护的内容，可以先用排除规则保护，而不是把它们同步后再人工抢救。

#!/usr/bin/env bash
# 目标机自己维护的配置和运行目录不参与本次镜像
rsync -aivn --delete --max-delete=0 \
  --exclude='.env' \
  --exclude='runtime/' \
  "/srv/app/current/" "/srv/app-mirror/"

# 只有明确要求连排除项也清理时，才使用这个开关
# rsync -aiv --delete --delete-excluded \
#   --exclude='.env' \
#   "/srv/app/current/" "/srv/app-mirror/"

--delete-excluded 不是“更彻底的同步”按钮，而是改变保护边界的危险选项。尤其要注意 per-directory 规则：如果删除阶段读不到同一套规则，接收端可能无法按预期保护文件；生产脚本应把全局排除规则写清楚，并把规则文件本身的传输方式一起设计。

正式同步怎样保留回退空间

确认预演结果后，我更倾向于用 --delete-delay，让删除名单在传输过程中计算、在更新完成后再删除；再用 --backup 和绝对路径的 --backup-dir 把被替换或删除的旧内容放到独立位置。备份目录不要放在本次同步目标内部，否则下一轮可能又把它当成目标多余项处理。

#!/usr/bin/env bash
# 正式同步前仍固定源和目标，备份目录放在目标树之外
SRC="/srv/app/current/"
DST="/srv/app-mirror/"
TRASH="/srv/rsync-trash/$(date +%F)"

# 删除延后到传输收尾，并把旧内容转移到独立回退目录
rsync -aiv --delete-delay --backup --backup-dir="$TRASH" \
  "$SRC" "$DST"

这套写法解决的是“误删后还有回退材料”，不是替代备份系统。应给 /srv/rsync-trash/ 配置容量和保留周期，并确认执行账号有写入权限。若只是想观察会删除多少文件，可以保留预演命令；如果需要限制一次最多删除的数量，可设置一个业务上合理的 --max-delete=N，超过上限时让任务报错并进入人工处理。

常见边界问题

目标目录里的文件为什么没有被删？先确认它是否被 --exclude 或过滤规则保护，再确认命令是否同步了父目录而不是通配符文件列表；还要检查是否启用了 --max-delete 上限。

源目录临时挂载失败会怎样？不要把空目录当成正常源目录继续执行。先检查挂载和读取权限；rsync 对发送端 I/O 错误默认会停用目标端删除，脚本也不应使用 --ignore-errors 把这个保护关掉。

什么时候可以使用 --delete-excluded？只有当排除项本来就应该由镜像任务清理，并且已经为配置、日志、规则文件和回退方案做出明确约定时才考虑；对生产目标的自维护目录，通常应保持默认保护。

把 --delete 当成“让目标严格贴合源目录”的策略，而不是普通复制参数。真正安全的组合是：范围可读、预演可审、排除可解释、异常会停删、旧内容有独立回退位置。