Linux rsync 高效备份实践

rsync增量同步变慢主因是–delete触发全量扫描，尤其小文件多时io暴增；应改用–delete-delay、避免nfs/cifs上使用，并用–dry-run预估行为。

rsync 增量同步为什么有时反而变慢？

根本原因常是 --delete 或 --delete-after 触发全量扫描，尤其在大量小文件场景下，rsync 会先遍历目标端确认哪些要删，IO 和 stat 调用暴增。不是算法问题，是操作语义代价被低估。

• 加 --delete-delay 把删除动作延后到传输完成再批量执行，减少中途中断导致的不一致
• 避免在 NFS 或 CIFS 挂载点上用 --delete，远程文件系统 stat 性能差，容易卡在“building file list”阶段
• 用 rsync --dry-run --stats 先看预估行为：重点关注 number of files 和 Number of created directories 是否异常高

如何让 rsync 跳过已校验一致的文件？

默认只比对修改时间 + 大小，但 NFS、容器卷或某些备份存储会丢失 mtime 精度，导致反复传输。必须显式启用内容校验，但别无脑加 --checksum。

• --size-only 最快，适合确定文件只增不改的归档场景（如日志轮转）
• --checksum 强制逐块计算 MD5，CPU 和 IO 开销大，仅在 mtime 不可信且文件变更极小时启用
• 更平衡的选择是 --modify-window=1，把 mtime 比较容差从 0 秒放宽到 1 秒，能兼容大部分 FAT/NFS 时间戳截断问题

rsync over ssh 的连接复用怎么配才不翻车？

每次 rsync 都新建 SSH 连接，密钥解析、TCP 握手、加密协商叠加起来，小文件多时耗时可能超过传输本身。OpenSSH 的 ControlMaster 是解法，但配置错会导致锁死或权限错误。

• 在 ~/.ssh/config 里配：

  Host backup-server     HostName 192.168.1.100     User backupuser     ControlMaster auto     ControlPath ~/.ssh/cm-%r@%h:%p     ControlPersist 300

• 确保 ControlPath 目录可写且权限为 700，否则 rsync 会静默回退到直连
• 不要在脚本里混用 -e "ssh -o ControlMaster=no"，它会覆盖 config，复用失效

备份失败后如何安全续传？

rsync 本身不支持断点续传大文件（除非用 --partial），但常见误操作是直接重跑命令，结果触发大量重复校验甚至误删。

• 必加 --partial：传输中断时保留已下载部分，下次自动基于相同路径继续
• 慎用 --append：只适用于纯追加场景（如日志），对随机写入的数据库文件会损坏数据
• 真正可靠的续传依赖外部机制：用 find /src -newer /tmp/last_backup.marker -print0 | rsync --files-from=- ...，靠时间戳标记边界，避开 rsync 自身状态管理

最麻烦的从来不是命令写不对，而是没想清楚“这次备份到底要保证什么”——是强一致性？还是最终一致性？是单次快照，还是持续流式？选错前提，参数调得再细也救不回来。