rsync断点续传必须显式加--partial（-p不够可靠），配合--timeout、--contimeout、--bwlimit防中断，--size-only适合日志场景，且需自行封装重试逻辑。
rsync断点续传必须加 --partial 和 -P
不加这两个参数，rsync 会把中断的临时文件直接删掉，下次启动等于重头来过。其中 -P 是 --progress 和 --partial 的组合简写，但实际生产中建议显式写出 --partial，避免因 shell 别名或旧版本（如 rsync -P 解析不一致导致失效。
常见错误现象：传输中断后，目标端完全没留下任何文件；或者只留一个 0 字节空文件 —— 这说明 --partial 没生效，rsync 默认把未完成的临时文件清理掉了。
-
--partial让 rsync 保留传输到一半的文件（存为原名，非隐藏临时文件） -
--partial-dir=.rsync-partial可选：把未完成文件暂存在独立目录，避免和已完成文件混在一起（需确保目标端该目录可写） - 不要依赖
--inplace实现断点续传 —— 它是覆盖写模式，不校验偏移，断点续传时可能损坏文件
远程同步必须走 SSH，且避免用 rsync:// 协议
rsync 断点续传在远程场景下本质是基于 SSH 的可靠管道 + 本地文件状态比对，不是协议层原生支持。用 rsync://（守护进程模式）反而无法利用 SSH 的连接恢复能力，且默认不启用 --partial，极易失败。
正确写法必须带 -e "ssh -o ConnectTimeout=10" 显式指定 SSH 参数：
-
-e "ssh -o StrictHostKeyChecking=no -o ConnectTimeout=15"：跳过首次密钥确认，缩短连接失败等待时间 - 别用
rsync -avz user@host:/src /dst这种裸写法 —— 如果 SSH 连接中途断开，rsync 无法判断是网络抖动还是服务端挂了，大概率直接退出 - 跨国传输时，在
-e中追加-o TCPKeepAlive=yes -o ServerAliveInterval=30，防止中间 NAT 超时断连
--checksum 和默认校验策略影响断点续传可靠性
rsync 默认只对比文件大小 + 修改时间戳来决定是否跳过传输。如果目标端文件被意外截断（比如上次中断后残留了 80%），而时间戳没变、大小又恰好“对得上”，rsync 就会跳过它 —— 表面看是续传，实际是漏传。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
这时候必须加 --checksum 强制全量内容比对：
- 代价是每次都要读取整个文件计算校验和（CPU 和 I/O 开销上升）
- 对大文件（>1GB）或慢盘（NAS、USB），建议配合
--ignore-times一起用，彻底禁用时间戳判断 - 如果只是担心传输中断导致的不完整，
--size-only更轻量：只比大小，不比时间戳，适合日志类追加写场景
限速与超时参数不配好，断点续传形同虚设
很多用户加了 --partial 还是续传失败，根本原因是网络波动时 rsync 被主动 kill 或超时退出，根本没机会触发续传逻辑。
关键参数要成对出现：
-
--timeout=300：单次数据块传输超过 5 分钟就报错（不是整个任务） -
--contimeout=60：SSH 连接建立阶段，60 秒内连不上就放弃，避免卡死 -
--bwlimit=5000：限制为 5000 KB/s（注意单位是 KB/s，不是 Kbit/s），比-l（scp 专用）更精准 - 别用
--compress处理已压缩文件（如.zip、.tar.gz）—— CPU 白耗，还可能因压缩率低拖慢整体吞吐
真正容易被忽略的是：断点续传不是“自动重试”，它只保证“再次运行相同命令时能接着传”。你得自己封装一层重试逻辑（比如用 until rsync ...; do sleep 10; done），否则一次失败就停在那里。
