带有–hard-links的rsync冻结

我从辛苦的经验中得出的答案是：不要这样做。 不要尝试复制大量使用硬链接的目录层次结构，例如使用rsnapshot或rsync --link-dest或类似rsync --link-dest创build的目录层次结构。 除了小数据集之外，它不能工作。 至less，不可靠。 （当然，你的里程可能会有所不同;也许你的备份数据集比我的小得多）。

使用rsync --hard-links重新创build目标端文件的硬链接结构的问题在于发现源端的硬链接是困难的 。 rsync必须在内存中build立inode映射来查找硬链接，除非你的源文件相对较less，否则这种情况可能会爆炸。 就我而言，当我了解到这个问题并且正在四处寻找替代解决scheme时，我尝试了cp -a ，它也应该保留目标文件的硬链接结构。 它搅拌了很长时间，然后终于死了（段错误，或类似的东西）。

我的build议是为你的rsnapshot备份留出整个分区。 当它填满时，把另一个分区联机。 将硬链接重的数据集作为整个分区移动，而不是单独的文件要容易得多。

在rsync似乎挂起点，它挂起或只是忙？ 使用iotop -o检查top和磁盘活动的cpu活动。

它可能正忙于复制一个大文件。 你会看到这在iotop或类似的，或在rsync的显示，如果你用--progress选项运行它。

它也可能正忙于扫描inodes列表来检查链接的文件。 如果正在使用增量recursion，在大多数情况下，如果客户端和服务器都具有rsync v3.0.0或更高版本，则这是recursion传输的默认值，它可能刚刚打到一个包含许多文件的目录，并且正在运行所有文件之间的链接检查在它和以前发现的所有。 --hard-links选项对于大型文件集可能非常耗费CPU资源（这就是为什么它不包含在一般的--archive选项所暗示的选项列表中）。 这将在rsync似乎暂停/挂起时performance为CPU使用率高。

我有同样的问题。 我的问题是通过添加--no-inc-recursive选项解决的。