Linux rsync --checksum 何时值得付出额外扫描成本

Linux 上用 rsync 做备份时，--checksum 不是“更安全的默认开关”，而是用额外磁盘读取换取更可靠的内容判断。常规同步可以信任文件大小和修改时间时，保持默认 quick check 通常更快；如果时间戳可能被重置、文件被同大小内容覆盖，或者需要先校准一份不可信副本，才值得让两端读取文件并计算预传输校验。

默认判断与 --checksum 判断的边界

rsync 默认先做 quick check：比较对应文件的大小和最后修改时间。两者一致时，文件通常会被视为无需更新；大小变化或时间不匹配，才会进入后续传输判断。--checksum（短选项 -c）会把“同大小文件是否相同”的依据改成文件内容校验，因此能够发现“内容变了但大小和时间看起来没变”的情况。

这里有一个容易混淆的边界：rsync 在传输文件时本来就会做重建结果的校验，那是传输过程中的验证；--checksum 负责的是传输前决定文件是否需要更新。开启它不会让已经传输的数据再自动获得一种完全不同的安全等级，却会让未变化文件也先被读取一遍。

先算扫描成本，再决定是否开启

判断重点不是“checksum 是否准确”，而是这份准确性是否值得付出读取成本。以下三类场景通常值得考虑：旧备份经过其他工具复制，修改时间不再可信；构建或解包过程可能保留原时间但替换了同大小内容；首次接管一份来源不明的镜像，需要先做一次内容校准。相反，持续同步本地代码、日志归档或明确由同一程序维护的目录，元数据稳定时不必每轮都扫描全部文件。

尤其要注意“网络慢”这个直觉陷阱：--checksum 需要发送端和接收端参与预检查，真正的耗时可能出现在两台机器的磁盘，而不是链路。把源端、目标端的读 I/O 和同步窗口一起看，结论才可靠。

用 dry-run 把判断变成可复查结果

不要一上来就正式覆盖目标目录。先用 dry-run 查看 rsync 认为哪些文件需要变化，--itemize-changes 让输出带上变化类型；下面的命令只是可复用示例，路径和主机名应换成自己的环境。

# 先只比对，不写入目标；-c 读取同大小文件做内容预检查
rsync -aivn --checksum --itemize-changes /srv/data/ backup:/srv/data/

# 确认变更集合后再执行同步；保留 -i 方便记录变化类型
rsync -aiv --checksum --itemize-changes /srv/data/ backup:/srv/data/

输出中可以重点看三件事：同大小但内容不同的文件是否从“无需更新”变成需要传输；属性变化是否只是权限或时间更新；文件数量很多时，预检查阶段是否已经超过同步窗口。新版本 rsync 还可能在跳过提示中区分 sum change、file change、attr change 和 uptodate，这些信号比单看“命令成功退出”更有解释力。

生产环境的选择清单与回退方式

可以把策略固定成“默认关闭、异常开启、结果留痕”。日常任务使用默认 quick check；迁移验收、时间戳被批量改写、备份恢复后的第一次校准使用 --checksum；完成一次校准后，若元数据由稳定流程维护，再回到默认模式。若扫描已经挤占业务窗口，先缩小 --files-from 范围或拆分目录，而不是盲目提高并发。

还要单独检查 rsync 两端版本和 checksum 协商能力。可以用下面的命令记录可用能力，但不要把输出中的算法名称直接当成业务一致性证明：

# 记录两端版本和编译能力，用于排查协商差异
rsync --version

# 只查看帮助中的 checksum 选项，不执行文件变更
rsync --help | grep -E -- '--checksum|checksum-choice'

最后保留 dry-run 输出、实际变更数量和任务耗时。这样下一次遇到“为什么这轮突然很慢”时，可以区分是 checksum 带来的全量读取、真实文件变化增多，还是目标端属性更新，而不是简单删掉参数。

常见问题

只想验证文件是否相同，必须正式同步吗？

不必。使用 -n 做 dry-run，配合 --checksum 和 --itemize-changes 可以先得到待变更集合；确认范围、成本和输出后，再决定是否执行写入。

开启 --checksum 后为什么仍然看到属性变化？

因为 checksum 主要影响内容是否需要更新，权限、属主、时间等属性仍由归档参数和目标文件状态决定。看到属性变化不等于内容校验失效，应结合 itemized changes 的类型判断。