☰

rsync 与 --hard-links 选项一起冻结

tag-icon • tag-icon rsync hardlink rsnapshot
rsync 与 --hard-links 选项一起冻结

我有一个名为 的大目录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并没有解决问题。

知道什么地方出了问题吗？

亚当

答案1

我的答案是：不要这样做，这是我根据自己来之不易的经验得出的。不要尝试复制大量使用硬链接的目录层次结构，例如使用rsnapshot或rsync --link-dest类似命令创建的目录层次结构。除了小型数据集外，它不会对任何其他数据集起作用。至少，不可靠。（当然，您的情况可能会有所不同；也许您的备份数据集比我的小得多。）

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

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

答案2

此时 rsync 似乎挂起了，它是挂起了还是只是忙？使用 检查 CPU 活动top并使用 检查磁盘活动iotop -o。

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

它还可能忙于扫描 inode 列表以检查链接文件。如果使用增量递归（如果客户端和服务器都使用 rsync v3.0.0 或更高版本，则在大多数情况下这是递归传输的默认设置），它可能只是访问了一个包含许多文件的目录，并在其中的所有文件和之前找到的所有文件之间运行链接检查。该--hard-links选项可以是非常处理大量文件时 CPU 占用大（这就是为什么它不包含在常规选项所隐含的选项列表中--archive）。当 rsync 似乎暂停/挂起时，这将表现为高 CPU 使用率。

答案3

很可能rsync仍在运行，但速度太慢，您认为它已冻结。尝试运行sudo iotop -od5并iostat -tmxyz 5显示系统中发生的 5 秒平均值。

您还可以使用它top来验证 rsync 是否仍在使用 CPU 能力以及它已获取了多少 RAM。还要检查“进程状态”列。如果它显示D，则该进程正在等待 IO（“等待磁盘访问”中的“D”）。

根据我的经验，通过网络同步大型目录总是很痛苦。如果你需要重建硬链接，那就更痛苦了。如果你已经有了旧的同步结果并试图更新它，硬链接会特别痛苦。对于这种情况，我建议--delete-before尽可能使用标志（先阅读副作用man rsync：）。它会在移动任何数据之前计算所有要同步的数据，这会延迟数据传输的开始，但可以有效地处理硬链接。因此，它应该能够更好地处理大量硬链接。

rsync如果您使用并且拥有大量文件（这里的大量文件是指 1000 多万个文件，大小超过 10 TB），并且 RAM 使用量至少为几 GB（如果您拥有大量硬链接文件，则需要创建具有多个链接--delete-before的 inode 列表），则在计算要传输的数据时，预计至少需要等待几个小时。在计算过程中，使用的网络流量非常少，如果本地和远程系统的性能差异很大，则较快的系统将处于空闲状态，直到较慢的系统计算出所需的更改。

就像是

rsync -avH --delete-before myremoteserver.example.com@/data/. /data/.

应该没问题。

请注意，如果本地或远程系统的 RAM 不足，系统可能会在尝试处理同步的同时进行交换，这可能会导致进程实际上rsync冻结，因为整个系统运行速度太慢。在这种情况下，添加足够的交换空间可能会有所帮助。

如果接收端有足够的可用空间，您可以直接跳过使用-H选项，rsync并在以后重建硬链接以节省存储空间。在这种情况下，您可能想要使用名为的程序hardlinks。

答案4

我也遇到了同样的问题。通过添加--no-inc-recursive选项解决了我的问题。

从https://download.samba.org/pub/rsync/rsync.html：

如果增量递归处于活动状态（请参阅--recursive），rsync 可能会在层次结构中的其他地方找到该内容的另一个链接之前传输丢失的硬链接文件。

这不会影响传输的准确性（即哪些文件是硬链接在一起的），只会影响其效率（即复制硬链接文件的新早期副本的数据，该文件可以在稍后的传输中在硬链接文件集的另一个成员中找到）。

避免这种低效率的一种方法是使用--no-inc-recursive选项禁用增量递归。

相关内容