Linux 数据备份策略设计

rsync适合轻量日常增量备份，borgbackup更安全但需注意仓库完整性；推荐组合使用，配合flock防冲突、ssh优化和定期恢复验证。

备份方案选 rsync 还是 borgbackup？

普通服务器日常增量备份，rsync 足够轻量、可控且兼容性好；但若需加密、去重、版本快照和跨设备恢复能力，borgbackup 是更安全的选择。两者不互斥——常见做法是用 rsync 做本地快速同步，再用 borgbackup 对同步后的目录做压缩加密归档。

注意：rsync 默认不校验文件内容一致性（仅靠 mtime/size），加 --checksum 会显著拖慢速度；borgbackup 默认启用内容定义块去重，首次备份慢，后续极快，但需要保留完整的 repo 目录，删错一个文件可能损坏整个仓库。

crontab 定时任务里怎么避免备份冲突？

多个备份任务并行运行容易导致源文件被修改、目标目录被覆盖或锁文件争用。关键做法是加锁 + 状态检查：

• 用 flock 包裹整个备份命令，例如：flock -n /tmp/backup.lock -c "rsync -a /data/ /backup/"
• 在脚本开头检查上一次 rsync 进程是否还在：pgrep -f "rsync.*data" > /dev/NULL && exit 1
• 每次备份前写入时间戳文件：date +%s > /backup/.last_run，便于监控任务是否“假死”

备份到远程 nas 时，ssh 连接失败的典型原因

多数“备份中断”实际是 ssh 层面的问题，而非 rsync 或 borg 本身。常见触发点：

• 远程 sshd 配置了 MaxStartups 限制，突发连接被拒绝，错误类似：ssh: connect to host x.x.x.x port 22: Connection refused
• 客户端未配置密钥自动登录，rsync 在后台执行时无法交互输入密码
• 远程路径使用绝对路径但权限不足，例如 borg repo 放在 /mnt/nas/backup，而挂载用户无写权限
• 网络波动导致长连接超时，建议在 ~/.ssh/config 中为该主机添加：ServerAliveInterval 60 和 ServerAliveCountMax 3

如何验证一次备份真的可用？

90% 的备份故障暴露在恢复环节。不能只看日志里有没有 “success”，必须定期抽检：

• 对 rsync 备份，用 rsync --dry-run --delete 反向比对，确认差异项为 0
• 对 borgbackup，至少每月执行一次：borg check --verify-data repo::archive-name（注意：耗 I/O，避开业务高峰）
• 挑一个非关键目录，用 borg extract 解出文件后，sha256sum 校验原始与恢复后的内容是否一致
• 真正致命的是元数据损坏——比如 borg repo 的 config 文件被静默破坏，此时 borg list 都会失败，所以建议把 repo 的 config 和 hints.0 文件单独同步一份到其他位置

备份不是“设完 crontab 就结束”的事，最常被跳过的其实是恢复演练和元数据保护。只要 repo 目录或 rsync 目标盘的 inode 信息异常，表面成功的备份可能根本无法还原。