scp 大文件中断后 rsync –partial –inplace 断点续传写法

scp中断后不能直接用rsync –partial –inplace续传，因为scp生成的残缺文件前半部分可能与源文件不一致，导致rsync误判差异而重复传输或损坏文件；必须先验证目标文件已写入部分字节完全匹配源文件，再使用–append-verify等安全参数。

scp 中断后为什么不能直接用 rsync –partial –inplace 续传 scp 和 rsync 的传输机制完全不同：scp 是纯流式拷贝，不校验、不分块、不记录偏移；而 rsync 的断点续传依赖本地文件的「已存在内容」作为基础，通过滚动校验（rolling checksum）比对差异。如果目标端文件是 scp 中断写了一半的残缺文件，且你直接用 rsync --partial --inplace 覆盖重试，它会误判「前面部分」和源文件不一致（因为 scp 写到一半时末尾是脏数据或零填充），导致重复传输甚至损坏。

所以关键不是加什么参数，而是先确认目标文件是否可被 rsync 安全复用。

如何判断中断的 scp 目标文件能否用于 rsync 断点续传 rsync 能复用的前提是：目标文件已写入的部分，字节内容与源文件**完全一致**，且长度 ≤ 源文件大小。常见场景中只有两种情况满足：

• 源文件未改动（如只读静态大包），且 scp 是因网络闪断中断，目标端磁盘写入未被截断或覆盖（即没有 dd 式覆写、没被其他进程 truncate）
• 你手动用 head -c N source > target 截出前 N 字节验证过一致性（例如 sha256sum source target | head -2 对比前若干 MB）

否则一律视为不可复用——宁可删掉目标文件重来，也不要赌 --inplace 不出错。

正确的 rsync 断点续传命令写法（含安全防护） 默认不加 --inplace 更安全：rsync 会先写临时文件再原子重命名，即使中断也不会污染原目标。但若明确要续传（且已确认目标文件可用），必须组合使用以下三个参数：

• --partial：允许保留传输中断时的临时文件（实际作用是不让 rsync 删除 .rsync-tmp 文件）
• --inplace：直接修改目标文件（跳过临时文件），这是实现「真正覆盖续写」的必要开关
• --append 或 --append-verify：强制从目标文件当前长度处继续追加（--append-verify 还会在追加前校验已有部分）

推荐写法：

rsync -P --partial --inplace --append-verify user@host:/path/to/src/file /local/dest/file

其中 -P = --progress --partial，--append-verify 是关键——它比单纯 --inplace 多一步校验，避免因目标文件被意外修改导致后续错位。

容易被忽略的权限与挂载限制 rsync --inplace 要求目标文件可写，且所在文件系统支持「覆盖写入」。某些场景下会静默失败或退化为全量重传：

• NFS/CIFS 挂载点可能禁用 inplace 写入（尤其 windows 共享），此时 --inplace 会被忽略，rsync 自动回退到临时文件模式
• 目标文件被 chattr +a（仅追加）锁定时，--append 会失败，报错 Operation not permitted
• 源端文件在传输中被修改（如日志滚动），--append-verify 会检测到哈希不匹配并中止，而不是强行续传

最稳妥的做法永远是：中断后先 ls -l 看目标文件大小，再 stat 看 ctime/mtime 是否异常，最后决定是删掉重来，还是谨慎启用 --append-verify。