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)
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 还会在追加前校验已有部分)
--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 会检测到哈希不匹配并中止,而不是强行续传
inplace 写入(尤其 Windows 共享),此时 --inplace 会被忽略,rsync 自动回退到临时文件模式chattr +a(仅追加)锁定时,--append 会失败,报错 Operation not permitted
--append-verify 会检测到哈希不匹配并中止,而不是强行续传最稳妥的做法永远是:中断后先 ls -l 看目标文件大小,再 stat 看 ctime/mtime 是否异常,最后决定是删掉重来,还是谨慎启用 --append-verify。










