我正在使用rsync的选项
-r for recursive -l copy symlinks as symlinks -t preserve modification time -D preserve devices and specials -v verbose --prune-empty-dirs 源FS是ext4，目标是XFS。 我已经复制了几百个范围在几百到几个TB之间的文件夹，它们都在小于1GB的大小差异之内。 但是，这个特定的文件夹在源上是264GB，一旦我rsync它是286GB。 这是一个巨大的差异，我不知道什么是错的。
如果源ext4 FS有一些损坏，是否有可能不报告正确的磁盘使用情况？ 我正在使用'du-skh'。
我已经删除了整个事情，并重新启动它3次，并产生相同的结果。
rsync FAQ页面列出了这些原因： https : //sanitarium.net/rsyncfaq/#differentsizes
但是唯一的方法就是比较文件。
对于less量的文件，你可以做diff -r /mnt/data /mnt/data-BACKUP 。 但是，如果中途停止，则不能从停止的地方重新启动。 旧版diff程序不能很好地处理二进制文件。
对于大量的文件，我build议计算所有文件的哈希值并寻找差异。 这样，如果进程停止或中断，你可以继续没有太大的困难。
以此脚本为例：
https://github.com/TomOnTime/tomutils/blob/master/bin/md5tree
md5tree /mnt/data >/var/tmp/list.orig md5tree /mnt/data-BACKUP >/var/tmp/list.backup # NOTE: For these next 2 lines TAB means press the TAB key. sort -t'TAB' -k6 </var/tmp/list.backup >/var/tmp/list.backup.sorted sort -t'TAB' -k6 </var/tmp/list.orig >/var/tmp/list.orig.sorted diff /var/tmp/list.orig.sorted /var/tmp/list.backup.sorted
最可能的原因是硬链接 。 默认情况下，Rsync将2个硬链接文件转换成占用两倍磁盘空间的目标文件。 如果要保留硬链接，请添加-H/--hard-links选项。
下一个最可能的问题是稀疏文件 。 Rsync在默认情况下不会将任何文件写入稀疏文件，即使它们在源文件上（它实际上不能说明）。 如果您有稀疏文件（最常用作虚拟机映像和不完整的p2p下载），那么您将需要使用--sparse option 。
两个文件系统上使用的块大小是否相同？
如果您对文件被损坏有怀疑，请考虑使用（slow！）-c选项进行rsync。