ZFS发送/接收的最佳压缩

我正在通过点对点T1线发送增量ZFS快照，而到了这样的地步，在下一次备份开始之前，一天的快照价值几乎无法通过网络传输。我们的send / 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周期可以节省。是否可以使用更好的压缩算法或替代方法将更少的数据推入生产线上？

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

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

这是我学到的与所做的完全相同的事情。我建议使用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

我的复制脚本中的send命令：

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用作缓存，因此即使给1g的mbuffer也需要我减小一些缓存大小。

另外，这并不是我真正的专长，我认为最好让ssh进行压缩。在您的示例中，我认为您正在使用bzip，然后使用ssh，默认情况下使用ssh进行压缩，因此SSH尝试压缩压缩流。我最终使用arcfour作为密码，因为它是CPU占用最少的，这对我很重要。使用其他密码可能会得到更好的结果，但是我绝对建议让SSH进行压缩（如果您确实想使用它不支持的功能，请关闭ssh压缩）。

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

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

我发现用于localhost传输的4g似乎是我的最佳选择。它只是表明zfs发送/接收并不太喜欢延迟或流中的任何其他暂停才能最好地工作。

只是我的经验，希望对您有所帮助。我花了一些时间才弄清楚这一切。

这是对您的特定问题的解答：

您可以尝试rzip，但是它的工作方式与compress / bzip / gzip略有不同：

rzip希望能够读取整个文件，因此无法在管道中运行。这将大大增加您的本地存储需求，并且您将无法运行备份并将备份通过有线方式发送到单个管道中。也就是说，至少根据此测试，生成的文件要小得多。

如果您的资源限制是管道，那么您将始终以24x7全天候运行备份，因此您只需要不断地复制快照并希望无论如何都可以继续运行。

您的新命令将是：

remotedir=/big/filesystem/on/remote/machine/
while 
  snaploc=/some/big/filesystem/
  now=$(date +%s)
  snap=snapshot.$now.zfssnap
  test -f $snaploc/$snap
do
  sleep 1
done

zfs send -i tank/vm@2009-10-10 tank/vm@2009-10-12 > $snaploc/$snap &&
rzip $snaploc/$snap &&
ssh offsite-backup "
        cat > $remotedir/$snap.rzip && 
        rzip -d $remotedir/$snap.rzip && 
        zfs recv -F tank/vm < $remotedir/$snap &&
        rm $remotedir/$snap " < $snaploc/$snap &&
rm $snaploc/$snap

您将需要进行更好的错误纠正，并且将考虑使用rsync之类的工具来传输压缩文件，因此，如果在中间传输失败，则可以从上次中断的地方继续。

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

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

2：在这种情况下，最好使用的压缩器是zstd（ZStandard），它现在具有“自适应”模式，该模式将根据以下情况更改压缩级别（在支持的19+级别之间加上新的更高速度的zstd-fast级别）。 zfs send和zfs recv之间的链接速度。它尽可能压缩，同时将等待流出管道的数据队列减至最少。如果您的链接速度很快，则不会浪费更多的时间来压缩数据；如果您的链接速度很慢，它将继续进行更多的数据压缩，最终可以节省时间。它还支持线程压缩，因此在Pigzip之类的特殊版本之外，我可以利用gzip和bzip不支持的多个内核。

我假设您根本无法增加网站的原始带宽...

您可能会看到在主机上不使用压缩的好处。

如果使用wan优化器之类的工具，则在不发送文件之前不对其进行压缩的情况下，它将可以更好地优化传输，即，您可以按照自己的意愿进行操作，但可以从管道中删除bzip2。在运行了几次备份之后，wan优化器将缓存传输中看到的大部分内容，并且您会看到传输速度有了巨大的提高。

如果您的预算有限，则可以通过使用rsync和rsync 未压缩的快照来看到类似的改进，即：

zfs send -i tank/vm@2009-10-10 tank/vm@2009-10-12 > /path/to/snapshotdir/snapshotfile
rsync /path/to/snapshotdir/snapshotfile offsite-backup:/remote/path/to/snapshotfile
ssh offsite-backup 'zfs recv -F tank/vm < /remote/path/to/snapshotfile'

这样会更快，因为rsync只会转移昨天快照和今天快照之间的差异。根据快照过程的工作方式，即使两者根本不是同一文件，两者之间仍然可能有很多冗余。

wan优化器到目前为止是解决此问题的一种更可能的方法（嗯，城域以太网是解决此问题的最可能方法，但我们将其保留在表外）。rsync只是一个黑暗的快照，值得测试（本地； rsync会告诉您它在一个直接副本上节省了多少时间），然后再为光纤或河床安装编写大笔支票。

物有所值。我不会直接发送| 压缩| 解压缩 如果传输线断裂，并且接收期间您的池长时间处于脱机状态，则在接收端会导致问题。我们发送到本地文件，然后将快照gzip压缩并使用rsync（带有riverbed）进行传输，然后从文件中接收。如果传输存在问题，则河床不会优化流量BUT，因此需要重新启动，以重新发送河床的速度。

我们已经研究过不使用Rsync压缩而不使用除河床以外的任何压缩方法来压缩增量快照。很难说哪个是最好的，但是当我们使用rsync压缩从oracle传输存档日志时，传输速率大约是普通文件和河床（使用RSync）的两倍。

如果您有河床，请使用rsync而不是ssh，因为河床了解rsync并将尝试对其进行优化，并将数据添加到缓存中（请参见上文，重新启动传输）。

我的经验是，zfs send尽管比随后的压缩步骤要快（平均而言），但还是很突发的。我的备用刀片相当的缓冲之后zfs send，更后gzip：

zfs send $SNAP | mbuffer $QUIET -m 100M | gzip | mbuffer -q -m 20M | gpg ... > file

在我的情况下，输出设备是通过USB（不是网络）连接的，但是由于类似的原因，缓冲很重要：当USB驱动器保持100％繁忙时，总体备份时间会更快。您可能不会（根据您的请求）整体发送较少的字节，但仍可以更快地完成。缓冲可防止CPU约束的压缩步骤变为IO约束。

通过WAN发送时，我一直都使用pbzip2（并行bzip2）。由于它是线程化的，因此您可以使用-p选项指定要使用的线程数。首先在发送和接收主机上安装pbzip2，安装说明位于http://compression.ca/pbzip2/。

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

主键是频繁创建快照（约10分钟），以减小快照大小，然后发送每个快照。ssh不会从损坏的快照流中恢复，因此，如果要发送的快照很大，请将流通过管道传输到pbzip2，然后拆分为可管理的大小块，然后将rsync拆分文件传输到接收主机，然后通过管道传输到zfs recv接收串联的pbzip2文件。

zfs send -i tank/vm@2009-10-10 tank/vm@2009-10-12 | pbzip2 -c | \
split -b 500M - /somedir/snap-inc-10-to-12.pbzip2--

这将产生以500MB块命名的文件：

/somedir/snap-inc-10-to-12.pbzip2--aa
/somedir/snap-inc-10-to-12.pbzip2--ab
/somedir/snap-inc-10-to-12.pbzip2--ac
...

rsync多次接收主机（您甚至可以在zfs发送完成之前或看到完整的500MB块时进行rsync），随时按ctrl + c可以取消：

while [[ true ]]; do rsync -avP /somedir/snap-inc-10-to-12.pbzip2--* offsite-backup:/somedir ; sleep 1; done;

zfs接收：

cat /somedir/snap-inc-10-to-12.pbzip2--* | pbzip2 -dc | zfs recv -Fv tank/vm

用户朋友提到：物有所值。我不会直接发送| 压缩| 解压缩 如果传输线断裂，并且接收期间您的池长时间处于脱机状态，则在接收端会导致问题。-如果正在进行的发送/接收被网络中断中断，但接收池中的<28较早的zfs版本以前遇到过问题，但没有使池脱机。那很有意思。仅在接收端退出“ zfs recv”时，才重新发送快照。如果需要，请手动终止“ zfs recv”。在FreeBSD或Linux中，zfs send / recv现在有了很大的改进。

您可以为ssh或blowfish-cbc选择更快的密码，也可以尝试-123456789开关

-1 (or --fast) to -9 (or -best)

您将需要测试您的数据。只需将其发送到文件并使用每种方法对其进行压缩即可。

对于我们来说，gzip产生了巨大的变化，我们通过它运行了所有内容，但是gzip和bzip或7z之间甚至没有1％的差异。

如果您的T1速度较慢，则需要将其存储到文件中并重新同步。

对于那些受CPU限制比带宽更多限制的人（不是您），如lstvan所说，arcfour128这样的不同密码可以加快处理速度。我们在移动事物时在内部使用它。

尝试使用-D打开zfs发送的dedup。当然，节省的费用取决于您的数据中有多少重复。

“最佳”压缩算法取决于您拥有的数据类型-如果您要推送MP3集合压缩，则可能会减慢该过程，而使用可以显着压缩文本/日志文件gzip -9。

您每天要推送多少数据？

您是否考虑过调整TCP / IP堆栈，以便使TCP缓冲区和窗口大小更大一些？您可以ndd为此使用Solaris上的sysctl工具或Linux / BSD / Mac OSX上的工具。在Solaris上，你要寻找的/dev/tcp tcp_max_buf和/dev/tcp tcp_cwnd_max值，并在Linux上的sysctl，你正在寻找net.ipv4.tcp_mem，net.ipv4.tcp_rmem和net.ipv4.tcp.wmem值。

此外，这些链接可能还有一些其他帮助：

Solaris TCP性能调优

该页面底部有一组链接，这些链接还将说明如何针对Linux / BSD / OSX执行相同的操作。