scp中断后不能直接用rsync --partial --inplace续传，因为scp覆盖写入产生截断脏数据，rsync --inplace会基于错误内容比对，导致跳过应重传块、文件损坏；续传前须删除/重命名坏目标文件、确认源未修改、用--dry-run --debug=all验证增量逻辑是否触发。
scp 中断后为什么不能直接用 rsync --partial --inplace 续传
因为 scp 和 rsync 的文件写入机制完全不同：scp 是覆盖式写入（先清空目标再写），而 rsync --inplace 是原地修改，依赖源文件与目标文件的块级差异。如果 scp 中断在中间，目标文件是截断的、内容错位的脏数据，rsync 会把它当“已存在部分”去比对，结果可能跳过大量本该重传的块，甚至传完仍是损坏文件。
rsync 续传前必须做的三件事
不是加个 --partial 就能续——得让 rsync 看到“可比对的真实起点”：
- 删掉被
scp中断写坏的目标文件（或重命名备份），避免rsync基于错误内容做校验 - 确保源文件自
scp启动后没被修改过（否则rsync的校验和比对会失效） - 用
rsync --dry-run --debug=ALL先跑一次，看输出里是否出现recv_generator或match_sums—— 如果没看到，说明 rsync 没触发增量逻辑，大概率是目标文件残留导致的误判
--partial --inplace 的真实作用和陷阱
--partial 只保证传输中断时保留已收到的部分；--inplace 让 rsync 直接修改目标文件而非先写临时文件再重命名。两者合用看似“最省事”，但实际有硬伤：
-
--inplace会破坏文件的原子性：传输中文件始终处于可读但不一致的状态，如果其他进程同时读取，可能拿到半截数据 - 若目标文件系统不支持 sparse file（比如某些 NFS 或 FAT32 挂载），
--inplace可能引发写入失败或静默损坏 - 真正稳妥的组合其实是
--partial --append-verify（适用于大文件追加场景）或默认行为（即不用--inplace），让 rsync 自己管理临时文件和原子替换
推荐命令与关键参数解释
假设你要续传 /data/large.tar 到远程 user@host:/backup/：
rsync -avz --partial --progress --checksum /data/large.tar user@host:/backup/
这里不加 --inplace，理由很实在：
-
--checksum强制基于内容比对（而非时间戳+大小），避免因scp中断导致的时间戳混乱引发误判 - 默认行为会在目标侧生成
.large.tar.045f2a这样的临时文件，传完再rename()，安全 -
--progress能实时看到已传多少、剩多少，比靠日志猜更可靠
真正麻烦的从来不是命令怎么写，而是你不知道目标文件到底坏成什么样了——只要残留一个字节的截断文件，rsync 就可能默默传错。动手前多看一眼 ls -l 和 sha256sum 输出，比背参数有用得多。
