meta 目录同步前，我先用 rsync 的 -n 把差异数对齐了

之前同步 meta 目录到备用机，用的是 rsync -a --delete，看着一切正常，但每次跑完 --stats 里的文件数都对不上。目录不大，1.4 万个文件、约 6.3 GB，源端和目的端差了 37 个文件，不多，却查了很久。

后来改成先干跑，把差异数固定下来再动手：

rsync -an --delete --itemize-changes \
  /data/meta/ backup@10.0.3.21:/data/meta/ \
  > /tmp/meta-dryrun.$(date +%F-%H%M).log

# 每类变更各多少条
grep -c '^>f' /tmp/meta-dryrun.*.log   # 传文件
grep -c '^\*deleting' /tmp/meta-dryrun.*.log  # 要删的

关键在 -n 加上 --itemize-changes，输出里每条变更前面有标记，>f 是往目的端传文件，*deleting 是要删的。跑两遍干跑，差异数必须一样，否则说明源端还在动，先别同步。我第一遍 37 条，第二遍 41 条，多了 4 条，查下去是 meta 里一个脚本在定时写临时文件。

为什么坚持这个顺序：--delete 是真删，没有回收站，干跑是唯一能在删之前看见删除清单的手段。代价是每次多跑一遍全量扫描，6.3 GB 大概 40 秒，对凌晨的定时任务不算什么，但白天临时同步会嫌慢。

失效的地方我也踩过。干跑和真跑之间有时间窗，这期间新写的文件不会出现在清单里，所以我在真跑时加了 --delay-updates，把文件先写到临时名再统一改名，避免目的端读到半截文件。另一个坑是软链：-a 会保留软链，但如果目的端那个位置原来是个真目录，--delete 会先删目录再建软链，干跑日志里看着是两条独立记录，很容易看漏。我现在的做法是同步前单独跑一次 find /data/meta -type l，把软链清单留一份，真跑后对一遍。

还有一点，--itemize-changes 的输出量在首次全量同步时非常大，我一般只在增量场景用它，首次同步直接看 --stats 的 transferred 数。

你们那边 meta 目录同步前会固定差异数吗，还是直接跑完看 stats？如果源端有常驻写入，这个时间窗你们是怎么处理的？