rsync断点续传需组合--partial、--timeout、--contimeout等参数并封装重试脚本，通过检测.rsync-partial文件和错误码判断续传状态，辅以mtr链路评估与SHA256校验确保跨国专线抖动下的准确、可审计同步。
直接用 rsync -avP 就能实现断点续传，但要真正扛住跨国专线的物理抖动（比如光缆微弯、设备瞬时过热、BGP路由闪断），必须组合关键参数、规避默认陷阱，并建立可验证的重试闭环。核心不是“能不能续”，而是“续得准、判得清、不误删、可审计”。
必备参数：让rsync感知抖动并安全挂起
默认 rsync 在 SSH 层超时后会静默退出，无法区分“传输完成”和“连接中断”。需显式启用以下机制：
-
--partial：强制保留已接收的不完整文件（生成
.rsync-partial后缀），这是断点识别的唯一依据；不加此参数，中断后目标端文件会被自动删除 - --timeout=60：设置单次数据块传输超时（单位秒），避免卡在坏块上；跨国链路建议设为 45–90 秒
- --contimeout=30：控制 SSH 连接建立阶段超时，防止因 DNS 解析慢或防火墙策略导致假死
- --compress-level=3：压缩等级设为 3（非最高），平衡 CPU 占用与带宽节省；等级过高易在弱网下引发缓冲区堆积和重传放大
路径与权限：避免因元数据冲突导致续传失败
跨国同步中，时区差异、NTP 不准、远程服务器 umask 设置异常，都可能让 rsync 误判文件已变更而重传整块：
- 源和目标路径末尾统一加
/（如/data/backup/），确保 rsync 操作的是目录内容而非目录本身，防止因目录时间戳漂移触发全量扫描 - 远程目标目录需确保写权限稳定，禁用 NFSv4 的 delegation 或 CIFS 的 oplock，否则内核级锁争用会导致
.rsync-partial文件被意外截断 - 若目标是 ext4/xfs 文件系统，建议挂载时启用
noatime，避免访问时间更新干扰增量判断
重试逻辑：用 shell 封装实现“可验证续传”
单纯重复执行 rsync 命令不可靠——它不会告诉你上次卡在哪、是否真续上了。推荐如下轻量封装：
#!/bin/bash
SRC="/mnt/backup/db-dump-20260523.sql"
DST="user@tokyo:/backup/"
CMD="rsync -avz --partial --timeout=60 --contimeout=30 --compress-level=3 --progress $SRC $DST"
<h1>检查目标端是否存在对应 .rsync-partial 文件</h1><p>if ssh "$DST" "ls -l ${SRC##*/}.rsync-partial 2>/dev/null" >/dev/null; then
echo "[INFO] Partial file detected → resuming..."
else
echo "[INFO] No partial file → fresh transfer"
fi</p><p>$CMD
RET=$?
if [ $RET -eq 0 ]; then
echo "[OK] Sync completed successfully"
elif [ $RET -eq 12 ] || [ $RET -eq 23 ]; then
echo "[WARN] Network error (12=timeout, 23=partial transfer) → safe to retry"
exit 1
else
echo "[ERROR] rsync failed with code $RET → check permissions or disk space"
exit $RET
fi
该脚本将错误码 12（超时）和 23（部分传输）明确标记为可重试状态，并通过检查 .rsync-partial 存在性确认续传上下文，避免“以为续了，其实重头来”。
监控与兜底：物理抖动后的快速归位
专线抖动常伴随短暂丢包（ping 可达但 TCP 重传率突增），建议部署两级兜底：
- 在传输前运行
mtr --report-cycles 10 tokyo-dc.example.com快速评估当前路径质量；若平均丢包率＞0.5%，暂缓启动大文件同步 - 对超过 50GB 的备份，在目标端添加校验钩子：
ssh user@tokyo "sha256sum /backup/db-dump-20260523.sql | cut -d' ' -f1" > local.sha256
与本地原始文件 sha256 对比，确认最终一致性，不依赖 rsync 自身校验
