rsync -P --append-verify 比 scp 更适合断点续传，因 rsync 基于块校验实现增量同步，--append-verify 在追加前校验已有数据完整性，避免损坏文件继续写入，而 scp 完全不支持断点续传。
rsync -P --append-verify 为什么比 scp 更适合断点续传
scp 本身不支持断点续传，中断后重跑就是从头开始；而 rsync 基于块校验和增量同步机制，只要目标文件已存在且部分写入，--append-verify 就能跳过已确认正确的头部数据，只传输剩余部分并最终校验完整性。-P 是 --partial --progress 的简写，既保留传输中断时的临时文件，又实时显示进度——这两者配合才是可靠断点续传的关键。
常见错误现象：rsync: failed to set times on "/path/to/file": Operation not permitted (1) 或传输完成后文件内容错乱，往往是因为没加 --append-verify 却误以为启用了续传逻辑。
必须加 --append-verify，不能只用 --append
--append 只追加字节，不校验已有内容是否正确；网络抖动或磁盘缓存异常可能导致目标文件前半段已损坏，继续追加只会让问题更隐蔽。--append-verify 会在追加前对已有部分做校验和比对（类似 md5sum 检查），不一致就报错退出，强制你处理源头问题。
- 使用场景：大文件（>1GB）在不稳定链路（如4G/弱WiFi）上传输
- 参数差异：
--append 忽略一致性，--append-verify 多一次本地读取+校验开销，但换来可靠性
- 性能影响：校验会多一次顺序读，对 SSD 影响小，HDD 上延迟略增，但远小于重传整文件的代价
实际命令写法与路径注意事项
最简可用命令是：
rsync -P --append-verify -e "ssh -p 22" /local/file user@host:/remote/path/
--append 忽略一致性，--append-verify 多一次本地读取+校验开销，但换来可靠性rsync -P --append-verify -e "ssh -p 22" /local/file user@host:/remote/path/
关键点：
-
-e "ssh -p 22"显式指定 ssh 参数，避免因 ssh 配置缺失导致连接失败（比如非标准端口、自定义密钥路径） - 源路径结尾不加
/，否则 rsync 会把整个目录当成要同步的对象；目标路径结尾加/表示“放入该目录”，不加则表示“重命名为该文件名” - 目标路径必须有写权限，且所在文件系统需支持修改 mtime（某些挂载的 NAS 或容器卷可能禁用）
- 如果提示
protocol version mismatch，说明两端rsync版本差太多，老版本不支持--append-verify（要求 ≥ 3.1.0）
容易被忽略的权限与状态检查点
rsync 断点续传依赖目标文件的完整性和可修改性。中断后别急着重跑，先检查三件事：
- 目标文件大小是否大于 0？为 0 说明上次根本没写进去，直接删掉再跑
- 用
ls -l 看目标文件 mtime 是否更新过，没更新可能是 ssh 连接成功但 rsync 进程被 kill 了
- 确认目标磁盘还有足够空间：
df -h /remote/path，rsync 不会在写满时优雅退出，而是报 I/O 错误并中断
断点续传真正卡住的地方，往往不是命令写得对不对，而是目标端的状态没人去核对。
ls -l 看目标文件 mtime 是否更新过，没更新可能是 ssh 连接成功但 rsync 进程被 kill 了df -h /remote/path，rsync 不会在写满时优雅退出，而是报 I/O 错误并中断
