scp传输中断后如何续传？

Question

**问题：SCP传输中断后无法续传，如何避免重复传输大量已成功发送的数据？** SCP协议本身不支持断点续传——一旦连接中断（如网络抖动、SSH超时或客户端意外退出），已传部分无法被识别和复用，重试时将从头开始，造成带宽浪费与时间损耗。尤其在传输GB级大文件或弱网环境下，该问题尤为突出。用户常误以为`scp -C -r`或添加`-o ConnectTimeout=30`等参数可实现续传，实则无效；也有尝试用`rsync over SSH`替代却未正确启用`--partial --progress --append-verify`选项，导致校验失败或覆盖不完整文件。此外，目标端残留的不完整文件若未清理，还可能引发后续同步冲突。根本症结在于SCP设计定位为“简单安全复制”，而非可靠增量传输工具。因此，亟需明确：什么场景下必须弃用SCP？有哪些轻量、兼容现有SSH基础设施且真正支持断点续传的替代方案？

Answer 1

```html

一、认知层：为什么 SCP 天然不支持断点续传？

SCP（Secure Copy Protocol）本质是 SSH-1/2 协议之上的一个无状态封装层，它将文件流通过 ssh 的标准输入/输出管道直接转发，不维护任何传输元数据（如已传字节数、校验块偏移、分块哈希等）。其设计哲学是“一次成功、失败重来”，符合 POSIX 简单复制语义。即使目标端写入了 9.8GB 的临时文件，SCP 客户端也无从感知——因为协议未定义 RESUME 命令、无文件长度协商阶段、无服务端状态回传机制。这也是为何 scp -o ConnectTimeout=30 或 -C（压缩）完全无法改变续传能力的根本原因。

二、诊断层：如何快速识别是否已落入“伪续传陷阱”？

• 现象误判：执行 scp file user@host:/path 中断后重试，看似“接着传”，实为覆盖写入（目标端残留的不完整文件未被校验或跳过）；
• 日志盲区：SCP 默认无进度回调接口，scp -v 仅显示连接建立与通道打开过程，不输出字节级传输快照；
• 时间戳误导：目标端文件 mtime 可能更新，但大小仍为 0 或远小于源文件 → 表明写入异常中断且未清理；
• rsync 配置失效：仅用 rsync -avz -e "ssh -o ConnectTimeout=15" src/ user@host:dst/ 而未加 --partial --append-verify --inplace，则默认行为仍是全量重传+临时文件覆盖。

三、决策层：必须弃用 SCP 的五大典型场景

场景编号	典型环境	风险等级	替代必要性
S1	跨国跨运营商大文件（≥2GB）批量同步	★★★★★	网络抖动率＞3% 时，平均重传成本＞单次耗时 × 2.7
S2	IoT 边缘设备回传日志（4G/卫星链路）	★★★★☆	TCP 重传窗口与 SSH KeepAlive 不匹配，极易触发半开连接
S3	CI/CD 流水线中制品上传（如 Docker image layer）	★★★★★	重复传输导致构建超时、缓存失效、计费激增
S4	数据库备份文件（.sql.gz, .tar.zst）迁移	★★★★☆	中断后无法验证完整性，人工介入成本高
S5	审计合规要求“可验证增量交付”的金融/政务系统	★★★★★	SCP 无传输摘要、无块级校验、无会话恢复凭证

四、实践层：三大轻量级、SSH 兼容型断点续传方案对比

以下方案均复用现有 SSH 密钥体系与防火墙策略（仅需开放 22 端口），无需部署额外服务端组件：

# ✅ 推荐首选：rsync over SSH（生产级成熟方案）
rsync -avzP \
  --partial \
  --append-verify \
  --inplace \
  --timeout=60 \
  --retries=3 \
  -e "ssh -o ServerAliveInterval=30 -o ServerAliveCountMax=3" \
  /data/largefile.bin user@host:/backup/

# ✅ 进阶选择：rclone + SFTP backend（支持加密、分块、带宽限速）
rclone copy /data/largefile.bin remote:sftp-backup/ \
  --sftp-host host.example.com \
  --sftp-user user \
  --sftp-key-file ~/.ssh/id_rsa \
  --transfers=2 \
  --checkers=4 \
  --progress \
  --ignore-checksum \
  --use-server-modtime

# ⚠️ 实验性方案：lftp sftp://（脚本化强，适合定时任务）
lftp -c "
set sftp:connect-program 'ssh -a -x -o \"StrictHostKeyChecking no\"';
mirror -c -P10 --parallel=3 --loop --on-error=continue /local/ sftp://user@host//remote/
"

五、架构层：自动化断点续传工作流（Mermaid 流程图）

flowchart TD
    A[启动传输任务] --> B{目标路径是否存在同名文件？}
    B -->|否| C[执行全量 rsync --partial]
    B -->|是| D[获取目标文件 size & mtime]
    D --> E{size > 0 且 mtime 在 10min 内？}
    E -->|否| C
    E -->|是| F[rsync --append-verify --inplace]
    F --> G{传输成功？}
    G -->|是| H[rm -f *.part; exit 0]
    G -->|否| I[记录 offset & retry count]
    I --> J{retry count < 5？}
    J -->|是| K[wait 30s; goto F]
    J -->|否| L[alert via webhook; exit 1]

六、加固层：防御性操作清单（DevOps 团队必检项）

1. 在所有 rsync 脚本开头添加 set -o pipefail -e 防止静默失败；
2. 目标端配置 umask 002 并启用 StrictModes yes SSH 选项保障权限安全；
3. 对大于 1GB 的文件，强制启用 --checksum（非默认的修改时间+大小判断）；
4. 使用 rsync --dry-run 预演首次同步，确认 .~tmp~ 临时文件策略；
5. 在 crontab 中调用前，增加 ssh -o ConnectTimeout=5 -o BatchMode=yes user@host exit 健康探活；
6. 所有传输日志统一接入 ELK/Splunk，字段包含：file_size, transferred_bytes, duration_ms, exit_code, resume_offset；
7. 定期运行 find /backup -name '*~' -mmin +1440 -delete 清理陈旧临时文件。

```