☰

源和目标之间的 Rsync 大小不同

tag-icon • tag-icon rsync ext4 xfs
源和目标之间的 Rsync 大小不同

我正在使用 rsync 及其选项

-r for recursive
-l copy symlinks as symlinks
-t preserve modification time
-D preserve devices and specials
-v verbose
--prune-empty-dirs

源文件系统是 ext4，而目标文件系统是 XFS。我复制了几百个文件夹，大小从几百 GB 到几 TB 不等，它们的大小差异都在 1GB 以内。但是，这个特定的文件夹在源文件系统上是 264GB，而我将其 rsync 到目标文件系统上后，大小就变成了 286GB。差异非常大，我不知道这到底是哪里出了问题。

如果源 ext4 FS 存在损坏，是否有可能无法报告正确的磁盘使用情况？我正在使用“du -skh”。

我已删除所有内容并重新启动了 3 次，但结果还是一样。

答案1

最可能的原因是硬链接。默认情况下，Rsync 将 2 个硬链接文件转换为目标上的重复文件，占用两倍的磁盘空间。如果您想保留硬链接，请添加该-H/--hard-links选项。

下一个最有可能的问题是稀疏文件。默认情况下，Rsync 不会将任何文件写入稀疏文件，即使它们位于源上（它实际上无法分辨）。如果您有稀疏文件（最常用作虚拟机映像和不完整的 p2p 下载），那么您将需要使用--sparse option。

答案2

当我使用“du -b -d0 源目标”时遇到了这个“问题”，
因为我深入研究后发现有大量不匹配的内容。

问题似乎是 du 坚持报告目录和文件的磁盘使用情况，而我只想要文件的大小。

因此，由于创建一些目录会在某些文件系统上使用较多字节，而在其他文件系统上使用较少字节，因此会有所不同。

解决方案只是比较实际文件的大小，而不是目录。

以下命令行使用 find 仅输出音乐目录中的文件，然后使用 du 计算字节数

find music -type f -print0 |du --files0-from=- -cb

如果有人能发布一个 sed 脚本来做同样的事情，请这样做

答案3

rsync 常见问题解答页面列出了以下原因：https://sanitarium.net/rsyncfaq/#differentsizes

然而，唯一知道的方法就是比较文件。

对于少量文件，您可以这样做diff -r /mnt/data /mnt/data-BACKUP。但是，如果中途停止，则无法从中断处重新启动。较旧的 diff 程序不能很好地处理二进制文件。

对于大量文件，我建议计算所有文件的哈希值并查找差异。这样，如果进程停止或中断，您可以轻松继续。

请参阅此脚本作为示例：

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

答案4

两个文件系统使用的块大小是否相同？

如果您真的怀疑文件已损坏，请考虑使用 rsync 的（慢！）-c 选项。

相关内容