ZFS 发送/接收的最佳压缩

Question

我正在通过点对点 T1 线路发送增量 ZFS 快照，我们已经到了在下一次备份开始之前一天的快照几乎无法通过网络传输的地步。我们的发送/接收命令是：

zfs send -i tank/vm@2009-10-10 tank/vm@2009-10-12 | bzip2 -c | \
ssh offsite-backup "bzcat | zfs recv -F tank/vm"

我有足够的 CPU 周期可用。是否有更好的压缩算法或替代方法可以用来将更少的数据推送到线路上？

Answer 1

这是我在做与您正在做的完全相同的事情时学到的东西。我建议使用 mbuffer。在我的环境中进行测试时，它只对接收端有所帮助，如果没有它，发送会在接收跟上时变慢。

一些例子：http : //everycity.co.uk/alasdair/2010/07/using-mbuffer-to-speed-up-slow-zfs-send-zfs-receive/

带有选项和语法的主页 http://www.maier-komor.de/mbuffer.html

来自我的复制脚本的发送命令：

zfs send -i tank/pool@oldsnap tank/pool@newsnap | ssh -c arcfour remotehostip "mbuffer -s 128k -m 1G | zfs receive -F tank/pool"

这将在远程主机上运行 mbuffer 作为接收缓冲区，以便发送尽可能快地运行。我运行了一条 20mbit 的线路，发现在发送端也有 mbuffer 也没有帮助，而且我的主 zfs 盒子正在使用它的所有 ram 作为缓存，所以即使给 mbuffer 1g 也需要我减少一些缓存大小。

此外，这并不是我真正的专业领域，我认为最好让 ssh 进行压缩。在您的示例中，我认为您正在使用 bzip，然后使用默认使用压缩的 ssh，因此 SSH 正在尝试压缩压缩流。我最终使用 arcfour 作为密码，因为它对 CPU 的占用最少，这对我来说很重要。使用另一种密码可能会有更好的结果，但我绝对建议让 SSH 进行压缩（或者如果您真的想使用它不支持的东西，请关闭 ssh 压缩）。

真正有趣的是，在本地主机上发送和接收时使用 mbuffer 也会加快速度：

zfs send tank/pool@snapshot | mbuffer -s 128k -m 4G -o - | zfs receive -F tank2/pool

我发现用于本地主机传输的 4g 似乎是我的最佳选择。它只是表明 zfs 发送/接收并不真正喜欢流中的延迟或任何其他暂停以达到最佳效果。

只是我的经验，希望能帮到你。我花了一段时间才弄清楚这一切。

Answer 2

自从发布这个问题以来，情况已经发生了变化：

1：ZFS 现在支持压缩复制，只需在 zfs send 命令中添加 -c 标志，并且在磁盘上压缩的块在通过管道到达另一端时将保持压缩状态。可能还有更多的压缩要获得，因为 ZFS 中的默认压缩是 lz4

2：在这种情况下使用的最佳压缩器是 zstd (ZStandard)，它现在有一个“自适应”模式，可以改变压缩级别（在支持的 19+ 级别之间，加上新的更高速度的 zstd-fast 级别）基于zfs send 和 zfs recv 之间的链接速度。它尽可能多地压缩，同时将等待离开管道的数据队列降至最低。如果您的链接速度很快，它不会浪费更多时间压缩数据，如果您的链接速度较慢，它会继续工作以更多地压缩数据并最终节省您的时间。它还支持线程压缩，因此除了像 pigzip 这样的特殊版本之外，我还可以利用 gzip 和 bzip 不具备的多核。

Answer 3

听起来您已经尝试了所有最好的压缩机制，但仍然受到线路速度的限制。假设运行更快的生产线是不可能的，您是否考虑过降低运行备份的频率，以便它们有更多的时间运行？

除此之外，是否有某种方法可以减少写入的数据量？在不知道您的应用程序堆栈的情况下，很难说如何做到这一点，但只要做一些事情，例如确保应用程序覆盖现有文件而不是创建新文件，可能会有所帮助。并确保您没有保存不需要的临时/缓存文件的备份。