☰

更新，附加信息

tag-icon • tag-icon ubuntu filesystems rsync backup tar
更新，附加信息

我目前正在寻找一种提高系统备份性能的方法，并在一些测试中实现了以下目标：

使用不压缩的 TAR 将我的 Ubuntu 系统从 SSD 备份到 HDD（均为 ext4）比将相同内容从 SSD 同步到 HDD 快得多。

详细地：

  • TAR获取1h 15min并生成一个429G的大文件
  • rsync拍摄5h并制作一个406G的大文件夹

两者都应该复制相同的数据，因为它们使用的忽略文件具有相同的内容，稍微调整为这两种工具。

我不确定为什么最终的 TAR 实际上比 rsynced 文件夹大，但我并不真正关心那个 ATM。

我真正感兴趣的是为什么 TAR 速度这么快＆ 如果我能以某种方式改进 rsync（或其他一些文件复制工具）以获得类似的性能？

我真的不想使用 TAR 作为我的备份策略，因为解压缩如此大的档案或仅提取单个文件需要“很长时间”，当我真正需要访问它们时，这会出现问题。

我意识到，通过始终复制到同一目标文件夹，我可以极大地提高 rsync 性能，因此得到增量副本但这是明确的不是我要找的因为我希望始终拥有不同日期的多个备份。

更新，附加信息

测试替代方案“通过 TAR 复制”

我还尝试过“通过 TAR 复制”（如所述这里或者这里）比rsync慢一点，所以瓶颈似乎是写入速度。

使用的命令

我使用了以下命令得到了上面的结果：

  • tar -X "tar-excludes.txt" -cvf "/media/backup/full" "/"
  • rsync -aAXWvh --stats --info=progress2 --exclude-from "rsync-excludes.txt" --log-file="log.txt" "/" "/media/backup/full"

文件

我正在备份整个操作系统（有一些例外），因此备份包括所有类型的文件。一些大文件以及许多小文件。

设备详细信息

主机是一台 ~ 8 年的 Intel NUC D34010WYKH

源驱动器是内部 SSD，目标驱动器是通过 USB 3.0 连接的外部 HDD。两个驱动器均采用ext4.

答案1

各种 cpio 和 tar 文件格式都是简单的文件头序列，后跟文件数据。写出新的文件头只是将记录附加到输出文件。写出文件数据只是将更多记录附加到输出文件中。

这是唯一发生过的事情：记录被附加到输出文件中。通常这些记录也被批量分成 10KiB 或 5KiB（有时甚至 1MiB）的块。

这是一件非常高效的事情。如果输出文件是实际的磁带设备这只是将写入（顺序输出）附加到磁带上的当前位置。这并不奇怪。这些实用程序旨在将文件归档到磁带，具有良好的顺序 I/O 特性和糟糕的随机访问 I/O 特性。

（添加压缩也不会改变这一点。压缩实用程序也被设计为使用顺序 I/O。）

即使这是磁盘卷上的文件，每附加一批记录基本上都是三个操作：调整磁盘卷的可用空间映射以获取另一个块，调整文件 i 节点以在文件末尾包含该新块（通过使用范围和合适的分配策略，哪些文件系统可以降低成本），并写出块。通过常见的文件系统驱动程序优化，当检测到顺序追加写入模式时，推测性地预分配连续数据块的运行，这确实可以非常便宜地完成。

而rsync式备份是在磁盘卷中创建整个树，其中涉及创建目录条目、更新 B 树等、分配 i 节点、创建硬链接以及更新任何日志，此外在单个文件级别执行 cpio/tar 存档的操作：调整磁盘卷的可用空间映射、调整 i 节点的块分配以及写出文件数据块。

仅使用顺序附加操作写出存档对于磁带来说非常有效，并且对于存储在磁盘卷上的单个存档文件来说也可以相当高效。写出大量单独的文件本质上需要做更多的事情。

当然，为了这种效率，您所付出的代价是易于对存档进行内联修改、良好的存档随机访问读取以及智能增量备份设施。

在 20 世纪 80 年代，Rahul Dhesi 创建了一种存档格式大多串行，这使得能够使用少量随机访问 I/O 对现有档案进行内联更新，以返回并覆盖被取代文件的标头。它的权衡是，必须经常通过重写整个存档来清除被取代文件的文件头和数据，当然，保存旧的尚未清除的文件版本需要更大的空间。

答案2

TAR耗时1小时15分钟，生成429G大文件

rsync耗时5h，产生406G大文件夹

凝视我的水晶球，我可以从中做出一些推论 - 源设备和目标设备之间存在大量小文件和显着的延迟。如果您查看了这些因素并将您在问题中发现的内容以及您正在运行的用于创建备份的实际命令包含在内，将会很有帮助。

Tar 速度快得多，因为：

  • 数据流量仅朝一个方向流动，它可能（可能）使连接饱和 - OTOH rsync 需要从两端同步检索数据
  • tar 写入单个流，因此文件创建不会产生影响

我意识到，通过始终复制到同一目标文件夹并因此获得增量副本，我可以极大地提高 rsync 性能，但这显然不是我想要的，因为我希望始终拥有不同日期的多个备份

假设源和目标是连接到同一主机的块设备（agan，未指定），也许您应该尝试覆盖文件系统。

答案3

这是centos的/目录（这里无关紧要）

bin  boot  dev  etc  home  lib  lost+found  media  mnt  opt  proc  root  sbin  selinux  srv  sys  tmp  usr  var

您很可能不想复制 /dev、/proc 和 /sys，根据您的需要，您也不想复制 /media。

所以而不是使用rsync / $DEST（我假设 $DEST 在另一台主机上）。

你可以跑

rsync /bin /boot /etc /lib /root /sbin /selinux $DEST &
sleep 300
rsync /home $DEST &
sleep 300
rsync /opt $DEST &
...
wait

如果你的所有数据都在 /home 中，你可以继续往下看

rsync /home/dir1 $DEST &
sleep 300
rsync /home/dir2 $DEST &
...

您将必须调整 $DEST，或使用排除选项rsync

假设您有 1 000 000 个文件，rsync（一个或多个）仍然需要检查 1M 文件统计信息（在源部分）和 1M 文件统计信息（在目标部分），进行一些压缩等...

正如评论中提到的，我必须每天两次同步包含 100 M 文件的目录，rsync 将持续 14 小时到 16 小时，采用上述策略（以及一些试验和错误），我设法将时间减少到 4 小时到 5 小时，使用20 个 rsync（其中 15 个是短暂的）

相关内容