Linux rsync 增量同步如何避免临时文件覆盖目标

Linux 上用 rsync 做发布或备份时，最稳妥的思路不是让它直接改写目标文件，而是让未完成的数据先落到临时位置，文件完整后再替换目标。通常应优先使用默认的临时文件机制；需要断点续传时加 --partial-dir=.rsync-partial，一次更新多个文件时再考虑 --delay-updates。临时目录必须和目标文件位于同一文件系统，否则重命名可能退化为复制，短暂暴露半成品的风险仍在。

rsync 为什么不会直接把半成品写进目标文件

默认更新一个已有文件时，rsync 会在接收端创建临时文件，数据和属性准备完成后再把它移动到正式路径。这个设计让中断通常只留下临时对象，读者看到的目标文件仍是旧版本；真正接近原子替换的前提是临时文件和目标在同一文件系统内。

不要把“增量同步”理解成“目标文件每收到一个块就被改写”。增量算法减少的是网络传输，是否直接修改目标则由传输模式决定。--inplace 明确要求就地更新，硬链接和节省额外空间是它的使用理由，但中断会留下被改过的目标文件。

单次同步怎么用 partial-dir 保留可恢复状态

对大文件、网络不稳定或不希望正式目录出现半成品的任务，可以把临时部分文件集中到目标目录下的隐藏目录：

# 把未完成传输放到目标目录的受控暂存目录
rsync -a --partial-dir=.rsync-partial ./build/ user@example:/srv/app/

# 用演练模式先确认将更新哪些文件，不会写入目标
rsync -an --itemize-changes --partial-dir=.rsync-partial ./build/ /srv/app/

--partial-dir 同时启用保留部分文件的行为；下一次同步可以利用暂存文件继续传输，完成后再放入正式路径。相对路径的 .rsync-partial 会跟随目标目录，权限应限制为同步进程可写，不能随手指定所有用户可写的 /tmp。

如果任务中使用了自定义 exclude 规则，要确认暂存目录不会被发送，也不会被清理规则误删。删除策略尤其要谨慎：它应服务于清理过期暂存文件，不能在同步尚未完成时把可恢复数据删掉。

多文件发布时怎么减少混合版本

网页静态资源或一组配置文件一起更新时，即使每个文件都是完成后替换，读请求仍可能在短时间内读到新旧混合版本。此时可使用：

# 将多个更新文件暂存在目标层级，结束时集中放入正式位置
rsync -a --partial-dir=.rsync-partial --delay-updates ./release/ user@example:/srv/app/

# 先检查删除和更新范围；确认无误后再去掉 -n 执行
rsync -an --delete --partial-dir=.rsync-partial --delay-updates ./release/ /srv/app/

--delay-updates 会把更新文件放入等待目录，在传输结束时快速移动到目标位置。它需要完整文件列表，可能增加接收端内存和磁盘占用；如果接收端无法容纳一份额外的更新文件副本，就不要为了“看起来原子”强行打开它。

上线前检查哪些文件系统和恢复边界

先确认目标挂载点和暂存目录属于同一文件系统，再检查空间、权限和清理策略。可以用下面的命令查看设备边界：

# 分别查看目标目录和暂存目录所在的文件系统
df -P /srv/app /srv/app/.rsync-partial

# 检查暂存目录权限，避免被其他用户写入
stat -c '%A %U:%G %n' /srv/app/.rsync-partial

如果必须使用独立挂载点的 --temp-dir，不能再把它当作“完成后原子替换”的保证：官方说明中，跨文件系统的 rename 无法直接完成，rsync 只能复制到目标。生产发布还应把目标目录的读取方、磁盘水位和失败后的重试动作写进运维流程。

常见问题

只加 --partial 就能避免覆盖目标吗？

不能把它当作完整隔离方案。--partial 主要是保留中断文件；需要把半成品放在独立目录时，应明确使用 --partial-dir。

为什么 --inplace 和 --delay-updates 不能一起用？

前者要求直接写目标，后者要求先暂存再集中放置，二者对文件落点的要求相反，所以 rsync 将它们视为冲突选项。

把暂存目录放到 /tmp 是否更安全？

不一定。除了可能跨文件系统，所有用户可写的临时目录还会扩大篡改和撞名风险。优先使用目标目录下权限受控的相对 --partial-dir。