meta 目录同步到备用机，我漏了 inode 这一层

两台机器之间同步 meta 目录，我之前的做法是 rsync -a 一把梭，看起来文件数、大小、mtime 都对得上，就默认两边一致了。直到上次做回滚演练才发现，备用机上有一批文件内容是对的，但校验脚本跑出来的结果和主库不一样。版本是 meta 0.9.x，目录里大概 1.2 万个文件、三层子目录，主备都是 ext4，量不算大，问题反而更容易被忽略。

我先做的不是改同步命令，而是把两边的差异定位出来：

# 在主备各跑一遍，输出 路径 inode 硬链接数
find /data/meta -type f -printf '%p %i %n\n' | sort > /tmp/$(hostname).inode

对比后发现，备用机上有几十个文件的硬链接数是 1，主库是 2。也就是说 rsync 复制的是“文件内容”，没有保留硬链接关系，原本共享同一份数据的两个路径，在备用机上变成了两份独立副本。meta 的校验逻辑里有一步是按 inode 去重统计的，副本一拆开，统计口径就变了，看起来像数据损坏，其实只是链接关系丢了。

改法很简单，加 -H：

rsync -aH --delete /data/meta/ backup:/data/meta/

代价是 -H 需要在两端都维护一份 inode 映射，文件多的时候内存会涨，1.2 万个文件感觉不到，但我之前在另一个 8 万文件的目录上试过，rsync 进程 RSS 会到几百 MB，同步时间也长了大概三成。所以我的取舍是：meta 目录这种带硬链接的小目录必须开 -H，普通日志目录不开。

哪里会失效：-H 只保证“这次同步时”的链接关系，如果主库新增了硬链接，而备用机上对应文件已经存在且 inode 不同，rsync 会先删再建，中间有一小段窗口两边不一致；另外跨文件系统同步时，硬链接本身就不保证能落成同一个 inode，-H 只能尽力。我自己踩过的坑是先用 –dry-run 看输出，看到大量 deleting 才意识到 -H 触发了重建，别在业务高峰期跑。

你们同步 meta 目录时，是直接 -aH，还是先做一次 inode 快照对比再决定？