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