Linux rsync 大目录同步慢怎么优化：用文件清单和分批校验把 18MB/s 拉回 92MB/s

一台归档机每天要把 /data/source 的素材同步到备机，文件夹总大小只有86GB，进度前十分钟几乎完全不动。查了网卡监控曲线很平稳，磁盘也没报故障告警，rsync 只是反复停在 sending incremental file list 不动。遇到这类场景先别急着升级带宽：十几万小文件带来的目录遍历和元数据比对开销，往往比文件传输本身耗的时间多得多。

先测出 rsync 大目录同步真正卡在哪里

这类问题最容易出现误判。传输慢不一定是网络带宽不够；如果文件数量特别多，源端要先挨个读取目录项、比对修改时间和文件大小，目标端还要逐层创建目录、写入inode记录。先在业务低峰时段跑一轮基准测试，把输出单独重定向落到日志文件里：

/usr/bin/time -f 'elapsed=%E cpu=%P' \
rsync -aHAX --info=progress2,stats \
  /data/source/ backup@10.20.0.18:/data/backup/ \
  2>&1 | tee /var/log/rsync-baseline.log

观察日志的时候别只看最后输出的平均速度。如果日志长时间停在 sending incremental file list、CPU只有单个核心占满、网络速率还不到链路上限的10%，优先排查是不是卡在目录扫描阶段。如果已经在持续传输数据但目标盘的 iowait 持续攀升，再去排查落盘和文件系统的性能压力。

三组数字足够定位瓶颈方向

之前实际跑的基准测试里，源目录有12万个文件、平均单文件大小700KB。前7分钟程序几乎都在列目录，网络速率不到3MB/s；等进入文件传输阶段之后，速度才能稳定到18MB/s。这里的数字不是通用阈值，但足以说明瓶颈根本不在网卡带宽上。

别让每一轮同步都从根目录重新扫一遍

如果上游业务系统能给出本轮所有发生变更的文件列表，最有效的优化改动往往不是堆一堆奇怪的rsync参数，而是直接让rsync只处理这份清单里的文件。清单里的路径必须是相对于源目录的相对路径，且用空字符做分隔，哪怕文件名里带空格也不会被误拆分。

cd /data/source || exit 1
find project-a project-b -type f -mmin -90 -print0 > /tmp/changed-files.list

rsync -aHAX --from0 --files-from=/tmp/changed-files.list \
  --delete-delay --info=progress2,stats \
  /data/source/ backup@10.20.0.18:/data/backup/

--files-from 更适合「变更范围预先可知」的同步场景，比如构建产物同步、按日期分区的归档文件、上游已经记录过变更路径的素材库。它不适合第一次全量数据迁移，也不适合没法预判删改范围的目录；这类场景还是得先跑一轮完整同步作为基准基线。

文件删除操作别和数据写入抢同一部分IO资源。--delete-delay 会把清理旧文件的动作推迟到所有新数据传输完成之后再执行，任务中途出错的话更容易保留现场排查问题。如果同步的是备份类目录，可以先在非生产副本上比对确认待删除的文件列表没问题，再把这个参数加到正式同步任务里。

把分批同步改动变成可复查的结果

调整完配置之后别直接就认定速度变快了。同一份测试数据、同一时段、同一个目标存储盘，至少对比三个指标：从扫描开始到第一个文件字节发出去的等待时长、稳定传输阶段的平均速率、同步结束之后两端的差异文件数。别上来就把并发任务数拉满；目标盘一旦被多个并发任务同时打满，单任务的速度提升反而会换来更长的整体同步耗时窗口。

# 比较目录中的普通文件数
ssh backup@10.20.0.18 'find /data/backup -type f | wc -l'
find /data/source -type f | wc -l

# 对一个小范围做校验试跑，输出差异而不写入
rsync -aHAXnc --from0 --files-from=/tmp/changed-files.list \
  /data/source/ backup@10.20.0.18:/data/backup/

之前的测试样本里，用预先生成的文件清单把扫描等待时间从7分钟压缩到了54秒；连续四个批次传输的稳定速率从原本的18MB/s提升到了约92MB/s。这个性能结果只在「本轮变更的文件集合远小于全量目录」的条件下成立。如果每轮同步几乎所有文件都发生了改动，生成清单本身也会消耗大量时间，直接跑全量同步反而更简单高效。

一份够用的上线检查清单

• 源端和目标端的rsync主版本互相兼容，两边对扩展属性的同步需求已经提前确认对齐。
• 清单里的所有路径都是相对于 /data/source 的相对路径，不存在以 / 开头的非法路径。
• 执行删除操作之前先用校验模式试跑一遍确认差异，出现异常时保留完整的 /tmp/changed-files.list 供后续排查。
• 任务日志里要记录本轮同步的文件总数、总耗时、平均速率和进程退出码，方便下一轮任务做效果对比。

几个容易把 rsync 调得更慢的细节

默认开启压缩参数。 内网环境下同步大量已经压缩过的图片、压缩包或者视频文件时，-z 只会额外占用CPU资源。只有链路带宽很窄、待传输内容是文本类数据的时候，再单独测试压缩功能的实际收益。

为了提速直接跳过所有属性比对。 -aHAX 里的属主属组判断、硬链接保留和扩展属性同步，并不是每一类目录都需要，但删掉这些参数之前要先确认业务侧的数据恢复要求。备份数据的可用性比单次同步快几十秒重要得多。

多个全量同步任务同时跑在同一块存储盘上。 这会把性能瓶颈从网络侧转移到inode操作和磁盘写入队列里。更稳妥的方式是按一级目录拆分错峰执行，给每个批次的任务单独保留日志。

相关问题

rsync 什么时候更适合用全量扫描？

第一次跨机迁移、没法可靠识别所有变更文件、或者需要清理大量历史遗留文件的时候，全量扫描的结果更可靠。可以把这类任务安排在业务低峰时段跑，不用硬套文件清单的优化方案。

用文件清单同步会不会漏文件？

会出现遗漏，前提是上游的变更记录本身不完整。所以清单的生成来源要可追溯，刚切换到方案的初期建议先做一次校验试跑，之后定期安排全量核对窗口兜底。

目标端磁盘慢的时候先调整哪些项？

先确认 iostat 的IO等待和资源利用率，再适当减少并发批次、避开高峰写入时段。别上来就乱改rsync的各项参数，不然很难区分性能变化是配置调整带来的，还是存储侧压力变化导致的。

能不能只靠修改时间判断文件要不要同步？

大部分日常同步场景都可以这么用，但跨不同操作系统复制、时间戳不可信或者数据价值很高的场景，建议额外加抽样校验或者单独的全量核对任务做兜底。

把「同步很慢」拆成一条可测的链路

rsync同步大目录的问题，核心从来不是要记住一长串冷门参数，而是要搞清楚程序运行的每一分钟都耗在了哪个环节。先统计拆分扫描、传输、落盘三个阶段的耗时，再把已知的变更集合整理成预先生成的文件清单，最后用分批策略和校验机制保证结果可靠。这么处理之后，速度提升有明确的统计依据，出问题要回退的时候也有清单和日志可以追溯。