Linux 远程备份与安全传输方法

rsync + ssh 是最稳妥的远程备份组合，加密且支持增量同步，无需远程 rsync 服务；需显式指定 -e 参数、注意路径结尾斜杠、限制 ssh 密钥权限、加锁防重入、校验与还原测试不可少。

rsync + SSH 是当前最稳妥的远程备份组合

直接用 rsync 走 SSH 通道，既加密又保持增量同步能力，比单纯 scp 或 tar + ssh 更省带宽、更可控。它不依赖远程主机装额外服务（比如 rsync daemon），只要能 SSH 登录就能跑。

常见错误是漏掉 -e 参数或写错 SSH 选项，导致走默认未加密的 rsync 协议（端口 873），或者连接被拒绝却误以为是路径问题。

• 必须显式指定 -e "ssh -p 2222"（如果 SSH 端口不是 22）
• 避免用 rsync user@host::module 这种 daemon 模式——它默认不加密，且需要远程开 rsyncd 服务，多一层暴露面
• 加 --delete 前先试运行加 --dry-run，否则删错本地或远端文件没回滚
• 路径结尾是否加 / 影响极大：/data/ 同步内容，/data 同步目录本身

SSH 密钥免密登录必须限制命令和权限

备份脚本常配 SSH 免密登录，但直接用无限制的密钥等于给攻击者开了后门。不能只靠“密码不用输”就认为安全。

典型风险是：一旦私钥泄露，攻击者可完整登录目标机，而不仅限于备份操作。

• 生成密钥时用 ssh-keygen -t ed25519 -C "backup@web01"，优先选 ed25519
• 在远程 ~/.ssh/authorized_keys 中，把公钥行开头加上强制指令：command="rsync --server --sender -vlogDtpre.iLs . /backup/",no-port-forwarding,no-X11-forwarding,no-agent-forwarding ssh-ed25519 AAAA...
• 确保远程 /backup/ 目录属主为备份用户，且权限 ≤ 750，禁止组外写入

备份失败时常见报错与定位路径

备份中断不报错、或只输出一堆 @Error，往往是因为没看清实际卡在哪一环。SSH 连接失败、磁盘满、权限不足、路径不存在，都可能表现为相似的静默退出或 rsync error: unexplained error (code 255)。

• 先手动执行一次带 -v --progress 的命令，观察卡在 “sending incremental file list” 还是 “building file list” —— 前者大概率是远程权限或路径问题，后者可能是本地扫描慢或符号链接循环
• 检查远程 df -h 和 ls -ld /backup，尤其注意 SElinux 是否启用（getenforce 返回 Enforcing 时需 chcon -t rsync_etc_t /backup 或临时设为 permissive）
• 如果报 protocol version mismatch，说明本地和远程 rsync 版本差太多（如 macos 自带 rsync 2.6.9 vs ubuntu 3.2+），建议远程也用 rsync --version 对齐

定时任务里别裸写 rsync，要加日志和锁机制

crontab 直接调 rsync 很容易撞上上次还没跑完，尤其大目录首次同步可能持续数小时。两个实例同时写同一目标，轻则覆盖，重则损坏 hard link 备份结构。

• 用 flock -n /tmp/backup.lock -c "rsync ..." 防重入，-n 表示获取不到锁立即退出，不阻塞
• 所有输出重定向到日志：> /var/log/backup.log 2>&1，但别用 >> 追加——日志会无限膨胀，改用 logger -t backup 推系统日志更稳妥
• 避免在 crontab 里写长命令，封装成脚本，开头加 #!/bin/bash -e，出错立刻终止，不继续执行后续步骤

真正难的不是传过去，而是确认传得全、没被篡改、还能按时恢复。校验和、保留多个时间点、定期抽样还原测试，这些动作不会自动发生，得在脚本里一条条写死。