ZFS发送/recv的最佳压缩

Question

我正在通过点对点的T1行发送增量的ZFS快照，我们到了一个点，在下一个备份开始之前，一天的快照几乎无法在线路上完成。我们的发送/recv命令是：

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

听起来你已经尝试了所有最好的压缩机制，并且仍然受到线路速度的限制。假设运行一条更快的线路是不可能的，您是否考虑过只需要减少备份的频率，以便它们有更多的时间运行？

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

Answer 2

这个问题发布以来的几年里，情况发生了变化：

1: ZFS现在支持压缩复制，只需将-c标志添加到zfs发送命令中，在磁盘上压缩的块将在通过管道传递到另一端时保持压缩。还可以获得更多的压缩，因为ZFS中的默认压缩是lz4。

2:在本例中使用的最佳压缩器是zstd (ZStandard)，它现在具有一种“自适应”模式，它将根据zfs发送和zfs之间的链接速度改变压缩级别(所支持的19+级别之间的压缩级别，以及新的更高速度的zstd快速级别)。它可以压缩尽可能多的数据，同时将等待输出管道的数据队列降到最低。如果您的链接是快速的，它将不会浪费时间压缩数据更多，如果您的链接是缓慢的，它将继续工作，以压缩更多的数据，并节省你的时间。它还支持线程压缩，所以我可以利用多个核心，而gzip和bzip不这样做，除了特殊的版本，如素食者。

Answer 3

这是我学到的，做和你做的一模一样的事情。我建议使用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，因此发送将尽可能快地运行。我运行了20 main行，发现在发送端设置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发送/接收并不真正喜欢延迟或流中的任何其他暂停来最佳工作。

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