Linux rsync --delete 使用前怎么做干运行和排除

在 Linux 上用 rsync --delete 做目录镜像，最容易出问题的不是参数不会写，而是把“源端没有的文件”误认为“目标端也应该删除”。稳妥的做法是：先固定源目录和目标目录，使用同一组参数运行 --dry-run，逐条看删除候选，再确认排除规则，最后去掉 --dry-run 执行正式同步。

为什么 --delete 之前必须先看干运行结果

--delete 的含义是让目标目录尽量贴近源目录：目标端存在、源端不存在的项目会成为删除候选。它不是“删除旧文件”的模糊清理命令，真正的边界来自源路径、目标路径和过滤规则。把源目录写成空目录，或者误把目标写在前面，都可能造成完全不同的结果。

第一次执行应先加 --dry-run（简写为 -n），并配合 -v 或 --itemize-changes 查看变化。干运行不会修改目标文件，但也不代表可以跳过人工核对；重点看输出中的删除候选是否都属于本次镜像范围。

# 先预览，不修改目标目录；源路径末尾斜杠表示同步目录内容
rsync -av --dry-run --delete --itemize-changes \
  /srv/site/ deploy@example.com:/srv/site/

# 只在确认删除候选后，执行与预览完全相同的参数
rsync -av --delete --itemize-changes \
  /srv/site/ deploy@example.com:/srv/site/

这里把预览命令和正式命令并排保存，是为了避免“预览时没带排除条件，正式执行时临时改参数”。如果输出里出现不该动的目录，先停在预览阶段，不要靠恢复备份来赌命令正确。

目标目录和排除规则要先定边界

排除规则解决的是“哪些项目不参与这次同步”。例如应用缓存、运行日志和目标端独立维护的备份目录，可以先用 --exclude 标记为保护对象：

# 排除目录和日志文件；规则要与实际相对路径一致
rsync -av --dry-run --delete \
  --exclude='cache/' \
  --exclude='logs/*.log' \
  --exclude='backup/' \
  /srv/site/ /data/site-mirror/

默认情况下，被排除的对象不会因为 --delete 一起消失。如果明确要让目标端连排除项也清理，才考虑 --delete-excluded；这会把“保护规则”变成“同步删除规则”，通常只适合目标目录完全由源端管理的场景。

排除模式要按源目录的相对路径理解。cache/ 与 /cache/ 的匹配范围不同，logs/*.log 也不等于所有层级的日志文件。先在干运行中观察具体路径，再调整模式，比凭感觉添加多个通配符更安全。

把命令拆成预览、确认和正式同步

在生产目录或远端主机上，建议把检查分成三个固定动作。第一，确认源目录确实有内容，并记录源、目标的绝对路径；第二，用最终参数执行干运行，重点检查删除候选、排除目录和目录层级；第三，只在清单符合预期时去掉 --dry-run。

可以把命令写进脚本，但不要把危险的删除动作藏在没有日志的定时任务里。至少保留执行时间、源目标路径和 --itemize-changes 输出。远端同步还应确认 SSH 用户拥有目标目录权限，避免因权限错误产生“看起来同步完成、实际只更新了一部分”的误判。

常见问题

干运行没有删除输出，是否说明 --delete 失效？

不一定。可能是目标端没有多余项目，也可能是排除规则保护了它们。先去掉复杂规则做一次只读预览，再逐条加回排除项定位。

为什么排除的文件还留在目标目录？

这是默认行为：排除项不会参与删除。只有明确使用 --delete-excluded，才会把排除对象也纳入目标端清理范围。

远端同步时最容易写错什么？

最常见是 SSH 主机、用户和目标路径写错，或把没有斜杠的源目录理解成了目录内容。正式执行前，把远端目标路径单独复制出来核对一次。

这类命令真正可靠的标志，不是参数越多，而是删除范围能够被预览、解释和复查。先把边界固定，再让 --delete 做镜像收敛，风险会比直接执行一条“看起来完整”的命令低得多。