rsync 与 --hard-links 冻结

Question

我有一个名为 的大目录servers，其中包含许多由rsnapshot. 这意味着结构或多或少类似于：

./servers
./servers/daily.0
./servers/daily.0/file1
./servers/daily.0/file2
./servers/daily.0/file3
./servers/daily.1
./servers/daily.1/file1
./servers/daily.1/file2
./servers/daily.1/file3
...

快照是以rsnapshot节省空间的方式创建的：如果/servers/daily.0/file1与 相同/servers/daily.1/file1，它们都使用硬链接指向同一个 inode，而不是每个周期都复制一个完整的快照。/servers/daily.0/file1/servers /daily.0/file1

我尝试使用硬链接结构复制它，以节省目标驱动器上的空间，使用：

nohup time rsync -avr --remove-source-files --hard-links servers /old_backups

一段时间后，rsync 冻结 - 没有新行添加到nohup.out文件中，并且似乎没有文件从一个驱动器移动到另一个驱动器。删除nohup并没有解决问题。

知道出了什么问题吗？

亚当

Answer 1

我根据来之不易的经验给出的答案是：不要这样做。不要试图复制目录层次结构中大量使用的硬链接，例如使用创建rsnapshot或rsync --link-dest或相似。除了小数据集，它对任何东西都不起作用。至少，不可靠。（当然，您的里程可能会有所不同；也许您的备份数据集比我的要小得多。）

使用的问题rsync --hard-links重新文件的目的地侧的硬链接结构是发现在源端的硬链接是很难。rsync必须在内存中构建 inode 映射以找到硬链接，除非您的源文件相对较少，否则这可能并且会爆炸。就我而言，当我了解到这个问题并四处寻找替代解决方案时，我尝试了cp -a，这也应该保留目标中文件的硬链接结构。它搅动了很长时间，然后终于死了（出现了段错误或类似的问题）。

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

Answer 2

此时 rsync 似乎挂了，是挂了还是只是忙？检查 cpu 活动top和磁盘活动iotop -o。

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

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