远程备份加密应避免rsync+gpg管道方式，因其破坏增量同步并阻塞I/O；推荐restic/borgbackup原生加密去重，或rsync前本地加密；SSH需调优ServerAliveInterval、TCPKeepAlive、IPQoS；密钥须离线保管，禁用硬编码；UDP加速工具对备份有害。
远程备份加密用 rsync + gpg 组合太慢？别硬套管道
直接在 rsync 命令里用 | gpg --cipher-algo aes256 -c 管道加密，看着简洁，实际会卡住：rsync 的增量同步逻辑被破坏，每次都要重传整个文件，加密还串行阻塞 i/o。真正可行的是「先本地加密再同步」或「用支持加密传输的替代方案」。
- 优先走
restic或borgbackup：它们原生支持去重 + 加密 + 增量，传输前就完成分块加密，不依赖管道，延迟敏感场景更稳 - 如果必须用
rsync，加密放在源端完成，生成.gpg文件后同步，且加--compress（对未压缩文件有效）和-z（ssh 层压缩）双压 - 禁用
rsync --partial配合加密文件——部分写入的.gpg无法解密，会丢数据
scp 和 rsync 走 SSH 丢包率高？换 ssh 配置比换工具更立竿见影
不是协议本身问题，是默认 SSH 参数对高延迟、弱网络太保守。重点调三个配置项，不用动服务端，客户端 ~/.ssh/config 加几行就行：
-
ServerAliveInterval 30：每 30 秒发心跳，防中间设备断连清空连接 -
TCPKeepAlive no：关掉底层 TCP keepalive，避免被某些防火墙误杀 -
IPQoS lowdelay：告诉内核这条路由优先走低延迟队列（Linux 有效，macOS 需配dscp）
实测在 100ms+ RTT、丢包 1% 的跨境链路上，rsync 断连重试次数下降 70% 以上。
备份加密密钥管理不当，反而让「安全」变成单点故障
把 gpg 私钥存在备份服务器上？等于把锁和钥匙放同一个保险箱。更糟的是用密码短语硬编码在脚本里——ps aux 就能看见。
- 私钥只存本地运维机，用
gpg --export-secret-keys导出后离线保管，服务器上只留公钥（gpg --export -a KEYID > backup.pub） - 加密时用
gpg --encrypt --recipient KEYID --armor，不加--sign（签名会暴露公钥指纹） - 密钥过期时间设为 2 年，用
gpg --edit-key KEYID提前续期，避免某天备份突然失败
UDP 加速工具如 udptunnel 或 kcptun 对备份加密无效甚至有害
这类工具本质是把 TCP 流量套进 UDP 再做重传/纠删，但备份场景中：rsync 和 restic 本身已基于 TCP 实现可靠传输，再套一层 UDP 只会增加 jitter 和乱序概率，加密后的二进制流对丢包更敏感。
- 实测开启
kcptun后，restic backup失败率从 0.2% 升到 8%，错误多为connection reset by peer或unexpected EOF - 真要降低延迟，优先优化路由（
mtr定位瓶颈跳点）、换云厂商 BGP 线路，或改用zstd级别 3 压缩（比默认gzip快 3 倍，压缩率只差 5%） - 别碰
net.ipv4.tcp_congestion_control = bbr这种内核参数——BBR 在长肥管道（long-fat pipe）有效，但小带宽高丢包环境反而更激进丢包
加密和传输优化是两层事：加密决定「谁看得懂」，传输参数决定「能不能稳送到」。混在一起调，容易两边都丢。
