rsync支持断点续传，核心是--partial保留中断文件、双端块级校验比对差异、配合SSH健壮参数（如ServerAliveInterval）及超时控制，实现真正可恢复传输。
在跨国高丢包、高延迟、连接不稳定的网络环境下，普通 rsync 或 wget 拉取备份容易因超时或中断失败，且重试成本高。关键不是“重试”，而是“可恢复”——即每次传输中断后，能从断点继续，不重复下载已成功接收的数据块。
用 rsync + SSH 配置断点续传拉取（推荐首选）
rsync 本身支持增量同步和部分传输恢复，配合合理参数可在丢包环境中稳定工作：
- 使用
--partial：保留传输中断时的不完整文件，下次继续写入而非重下 - 启用
--progress和--stats方便监控；加--timeout=60避免单次卡死过久 - 通过
-e "ssh -o ConnectTimeout=15 -o ServerAliveInterval=30 -o ServerAliveCountMax=3"强化 SSH 层健壮性 - 务必加
--delete-after（慎用--delete），避免误删本地已有但远程暂未同步完的文件 - 示例命令：
rsync -avz --partial --timeout=60 -e "ssh -o ConnectTimeout=15 -o ServerAliveInterval=30" user@remote:/backup/20240601/ /local/backup/
对大文件用 wget 或 curl 分块+校验续传
当目标是单个超大备份文件（如数据库 dump），rsync 可能受限于远程文件系统不支持硬链接或无 rsync daemon。此时用 wget 或 curl 更直接：
-
wget -c -t 0 --retry-connrefused --wait=2 --random-wait URL-c启用断点续传，-t 0无限重试，--retry-connrefused对连接拒绝也重试 -
curl -C - --retry 10 --retry-delay 3 --max-time 600 -o file.zip URL-C -表示从本地文件当前大小处继续，需确保文件名不变且未被其他进程修改 - 建议搭配 SHA256 校验：先拉取
file.zip.sha256，下载完成后sha256sum -c file.zip.sha256验证完整性，失败则自动清理重试
封装为带状态跟踪与自动重试的 shell 脚本
单纯命令不够，需记录进度、控制并发、避免雪崩重试：
- 用临时标记文件（如
.fetching.lock和.fetched.sha256）标识当前任务状态 - 每次运行前检查本地文件是否存在且校验通过，跳过已完成项
- 设置指数退避重试：第1次等5秒，第2次等15秒，第3次等45秒……避免密集刷请求加重网络负担
- 日志中记录每次 start/end 时间、传输字节数、退出码，便于事后分析丢包时段规律
- 可加入简单熔断逻辑：连续3次超时后暂停1小时，防止无效轮询耗尽资源
补充增强策略（非必须但强烈建议）
物理层不可控，但可优化协议层和调度层应对：
- 让远端开启 rsync daemon（非 SSH 模式），使用
--port指定非标准端口，减少被中间防火墙 reset 的概率 - 在远端压缩备份（如
tar -czf），拉取后再解压，降低传输量和失败窗口 - 若允许，将备份推送到近地 CDN 或对象存储（如 AWS S3 / 阿里 OSS），再从就近节点拉取，绕过直连跨国链路
- 定期用
mtr或ping -R抓取路由路径变化，发现劣化节点后协调 ISP 或切换隧道出口
