Linux rsync 部分传输后的断点续传参数

Linux 上用 rsync 传输大文件时，连接中断并不等于必须从零开始。普通的稳定文件，优先用 --partial-dir 把未完成内容留在专用暂存目录；只有确认目标端已有前缀与源端完全一致、文件还会继续变长时，才考虑 --append 或 --append-verify。如果只是想让目标文件始终直接被写入，才选择 --inplace，但它会改变目标文件的可见性和参数组合。

最稳的判断顺序是：先确认文件是否会增长，再决定部分文件放在哪里，最后才选择是否信任已有前缀。普通文件不要因为“想续传”就直接套用 --append。

rsync 官方手册地址：https://rsync.samba.org/ftp/rsync/rsync.html

下面只讨论 rsync 的部分传输保留、后续复用和参数边界。示例展示命令结构与判断方式，不把命令输出描述成当前机器已经执行过的结果。

先按文件状态选续传路线

把文件分成三类，参数选择就不会混乱：

• 普通稳定文件：文件内容可能在传输前后发生修改，或者只能确认“这是同一个文件”，使用 --partial-dir 保留中断数据，让 rsync 继续做增量匹配。
• 持续增长文件：明确知道目标端已有内容就是源端的相同前缀，且源文件只会在末尾追加，才可以评估 --append 或 --append-verify。
• 需要直接写目标文件：目标文件不能额外占用一份临时副本时才考虑 --inplace，并接受读者可能看到未完成内容的风险。

这三个选择解决的是不同问题：--partial-dir管理“中断数据放在哪里”，--append管理“已有前缀是否可信”，--inplace管理“更新是否直接发生在目标文件上”。

普通稳定文件优先放进 partial-dir

--partial会保留被中断的部分文件；--partial-dir=DIR则把这部分内容放进指定目录，并让后续传输把它作为恢复依据。相对于把半成品直接留在最终文件名下，独立目录更容易和业务读取路径隔离。

一个适合普通大文件的最小写法如下。这里使用相对目录名，让 rsync 在目标文件所在目录附近管理暂存数据。

# 保留中断数据，并让下一次传输复用目标目录下的暂存文件。
rsync -a --info=progress2 \
  --partial-dir=.rsync-partial \
  /srv/releases/app.tar \
  deploy@example.com:/srv/releases/

--partial-dir会启用部分文件保留逻辑，但目录本身不能让不可信用户随意写入；官方手册特别提醒，不能把它当成公共临时目录。若只需要临时保留而不想让它长期存在，应在确认完整文件已经落位后清理该目录，并把清理动作放在明确的维护流程里。

下一次传输怎样判断会复用中断数据

恢复的关键不是记住某个“断点字节数”，而是让 rsync 找到匹配的部分文件，并重新比较源端和目标端的文件信息。相对的 --partial-dir=.rsync-partial通常会在目标目录旁保存部分文件；传输完成后，部分文件不再承担恢复职责。

可以先用 dry-run 观察计划，而不真正传输：

# 只查看同步计划；-n 不写入目标，-i 让文件变化原因更容易阅读。
rsync -ani \
  --partial-dir=.rsync-partial \
  /srv/releases/app.tar \
  deploy@example.com:/srv/releases/

如果源文件在两次传输之间被替换、缩短或发生中间位置修改，不能把旧的部分文件当作可信断点。此时应让普通增量传输重新比较；不要仅凭文件名相同就改用 --append。

append 和 append-verify 只处理增长文件

--append适用于“目标端已有内容就是源端前缀，源文件只在尾部继续增长”的场景。它不会重新验证已有前缀，只校验本次追加的数据，因此效率较高，但前提也更严格。只要已有前缀可能损坏、源文件可能被重写，或者目标文件不是同一条增长链，就不应该使用它。

--append-verify仍然采用追加模型，但会把文件中的旧数据也纳入校验，通常更稳妥而且代价更高。它不是“普通文件续传的加强版”，而是“确认增长模型后，对已有前缀再多做一次确认”。

# 只有确认日志只会追加、目标端前缀可信时，才使用 append。
rsync -av --append --info=progress2 \
  /var/log/app.log \
  archive@example.com:/srv/log-archive/

# 需要把已有前缀也纳入校验时，改用 append-verify，代价是更低的传输效率。
rsync -av --append-verify --info=progress2 \
  /var/log/app.log \
  archive@example.com:/srv/log-archive/

这类参数不适合数据库文件、会被覆盖写入的镜像文件或内容可能回写的业务文件。文件在协商期间变短时，rsync 也会把它视为不满足追加条件；这正是应该回到普通增量传输判断的信号。

--inplace 是空间取舍，不是通用续传开关

--inplace会直接更新目标文件，适合磁盘空间紧张、目标文件本来就允许被原地修改，或者希望减少临时副本的场景。它隐含 --partial，但与 --partial-dir、--delay-updates冲突，因此不能把三者拼成“更强的续传组合”。

# 目标文件会被原地改写；调用方必须接受中断时可见的半成品状态。
rsync -av --inplace --info=progress2 \
  /srv/images/disk-image.raw \
  storage@example.com:/srv/images/

原地更新的代价是：其他进程可能在传输未完成时读到不完整内容；对已有数据频繁改写时，增量算法效率也可能下降。若目标文件需要“要么旧版本、要么新版本”的更强可见性，应优先保留临时文件并在完整后再替换，而不是强行使用 --inplace。

一套可复用的参数决策流程

1. 确认文件生命周期：询问它是否只会追加，还是可能被覆盖、截断、重写。
2. 先选暂存位置：普通稳定文件使用专用 --partial-dir，并确认目录权限和剩余空间。
3. 再判断前缀可信度：只有共享增长文件才进入 --append 家族。
4. 决定校验代价：前缀绝对可信且更重视效率时选 --append；仍需检查旧数据时选 --append-verify。
5. 最后检查读者可见性：只有允许目标文件出现半成品时才用 --inplace。

最容易踩到的几个边界

不要把 -P 当成万能断点续传。-P只是 --partial 与 --progress 的组合，适合快速打开“保留部分文件和显示进度”；需要固定暂存位置时，仍应明确写出 --partial-dir。

不要把 --append 用在普通大文件上。它信任已有前缀，文件中间任何变化都会让这个假设失效。

不要把 /tmp 当成共享 partial-dir。部分文件可能包含敏感数据，目录还可能被其他用户写入或清理；应使用归属明确、权限受控的目录。

不要同时期待“原地写入”和“独立暂存”。--inplace与 --partial-dir表达的是相反的文件落点策略，选项冲突时应回到业务可见性和磁盘空间约束重新做决定。

常见问题

rsync 断了以后，下一次一定从上次字节位置继续吗？

不应把它理解为固定字节指针。rsync 会根据目标端可用的部分文件和文件比较结果重新组织传输；能否复用以及复用多少，取决于两端文件状态和所选模式。

普通文件可以直接使用 --append-verify 吗？

不建议。即使它会校验已有数据，参数本身仍然假设文件是共享前缀并继续增长的对象；普通文件应优先使用默认增量逻辑配合 --partial-dir。

--partial-dir 传输成功后要不要手动删除？

先确认完整目标文件已经落位，再按项目约定清理残留目录。不要在下一次恢复前提前清理，也不要用无权限边界的公共目录承载部分文件。