我通过点对点的T1线路发送增量式ZFS快照，我们希望在下一次备份开始之前，一天的快照几乎不能通过networking。 我们的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周期来备用。 有没有更好的压缩algorithm或替代方法，我可以用来推送更less的数据在线？
这听起来像你已经尝试了所有最好的压缩机制，并仍然受到线速度的限制。 假设运行更快的线路是不可能的，你是否考虑过less运行备份，以便有更多的时间运行？
简而言之，是否有某种方法来降低正在写入的数据量？ 不知道你的应用程序堆栈很难说如何，但只是做一些事情，如确保应用程序覆盖现有的文件，而不是创build新的可能会有所帮助。 并确保你没有保存你不需要的临时/caching文件的备份。
这是我所学到的，正在做同样的事情。 我build议使用mbuffer。 在我的环境中进行testing时，它只能在接收端得到帮助，如果没有这个function，发送速度就会减慢，而接收端就会收到。
一些例子： 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作为caching，所以即使是1g到mbuffer也需要我减less一些caching大小。
另外，这不是我真正的专业领域，我认为最好是让ssh进行压缩。 在你的例子中，我认为你使用的是bzip，然后使用默认使用压缩的ssh。 所以SSH正试图压缩一个压缩的stream。 我最终使用arcfour作为密码，因为它是最小的cpu密集，这对我很重要。 你可能有更好的结果与另一个密码，但我肯定会build议让SSH做压缩（或closuresssh压缩，如果你真的想使用它不支持的东西）
真正有趣的是，在localhost上发送和接收时使用mbuffer也可以加快速度：zfs send tank / pool @ snapshot | mbuffer -s 128k -m 4G -o – | zfs接收-F tank2 / pool
我发现本地主机传输4g似乎是我的甜点。 它只是表明zfs发送/接收并不真正喜欢延迟或任何其他暂停在stream中最好的工作。
只是我的经验，希望这有助于。 我花了一段时间才弄明白这一切。
这是你的具体问题的答案：
您可以尝试使用rzip ，但是它的工作方式与compress / bzip / gzip有些不同：
rzip希望能够读取整个文件，所以它不能在pipe道中运行。 这将大大增加您的本地存储需求，您将无法运行备份并通过一根pipe道的线路发送备份。 也就是说，所得到的文件，至less根据这个testing，是相当小的。
如果你的资源约束是你的pipe道，那么你将会无论如何全天候运行备份，所以你需要不断地复制快照，并希望你保持不变。
你的新命令是：
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的东西来传输压缩的文件，所以如果传输失败的中间，你可以拿起你离开的地方。
我假设你根本不能增加你的网站的原始带宽…
您可能会看到不在主机上使用压缩的好处。
如果你使用了像优化器这样的东西，那么如果你在发送文件之前没有压缩文件的话，它将能够更好地优化传输，也就是说，你只是在做你正在做的事情，但是从pipe道中删除bzip2。 经过一段时间的备份后，wan优化器将caching大部分在传输中看到的内容，并且您将看到传输速度的巨大提升。
如果您处于有限的预算范围内， 则可以使用rsync和rsyncing 解压缩的快照来看到类似的改进，即：
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只会传输昨天快照和今天之间的差异。 根据快照过程的工作原理，即使两者不是完全相同的文件，两者之间仍然会有很多冗余。
万优化器是解决这个问题的更可能的方式（好吧，以太网是解决这个问题的最可能的方法，但是我们将把它从表中解决）。 在写入光纤或河床安装的大检查之前，rsync只是在黑暗中进行testing（本地; rsync会告诉你在本地数据上节省了多less时间）。
物有所值。 我不会直接发送| 压缩| 解压缩| 如果接收方收到此消息，可能会导致传输线路故障，并且在接收期间池会长时间处于脱机状态。 我们发送到本地文件然后gzip快照和传输使用rsync（与河床），然后我们从文件接收。 河床没有优化交通，但是如果交通出现问题，需要重新启动，河床加速重新启动。
我们考虑过不使用Rsync压缩来压缩增量快照，也不使用河床以外的压缩。 很难说什么是最好的，但是当我们使用rsync压缩从oracle传输归档日志时，传输速率大约是普通文件和河床（RSync）的两倍。
如果你有一个河床，那么使用rsync而不是ssh，因为河床了解rsync，并会尝试优化它，并将数据添加到caching（见上面，重新启动传输）。
我的经验是，尽pipe比以下压缩步骤快得多（平均）， zfs send仍然非常突然。 我的备份在zfs send之后插入了相当多的缓冲区，在gzip之后更多：
zfs send $SNAP | mbuffer $QUIET -m 100M | gzip | mbuffer -q -m 20M | gpg ... > file
在我的情况下，输出设备是USB（不是networking）连接，但缓冲也很重要，原因相似：当USB驱动器保持100％忙时，整体备份时间更快。 你可能不会发送更less的字节（按你的要求），但你仍然可以更快完成。 缓冲保持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"
主要关键是要频繁地创build快照（~10分钟），以使您的快照尺寸更小，然后发送每个快照。 ssh不会从一个损坏的快照stream中恢复，所以如果你有一个巨大的快照发送，pipestream到pbzip2，然后拆分成可pipe理的大小的块，然后rsync拆分文件到接收主机，然后pipe到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发送完成之前rsync，或者一旦你看到一个完整的500MB块），按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
用户freind提到：什么是值得的。 我不会直接发送| 压缩| 解压缩| 如果接收方收到此消息，可能会导致传输线路故障，并且在接收期间池会长时间处于脱机状态。 – 如果正在进行的发送/接收被networking丢弃中断，但是没有超出池的范围，我在接收主机中遇到了以前的zfs版本<28的问题。 那很有意思。 只有在接收端退出“zfs recv”时才重新发送快照。 如果需要，手动杀死“zfs recv”。 现在在FreeBSD或Linux中zfs send / recv已经有了很大改进。
你可以select一个更快的密码ssh，也许blowfish-cbc，也可以尝试-123456789开关
-1 (or --fast) to -9 (or -best)
“最好的”压缩algorithm取决于你有什么types的数据 – 如果你推MP3收集压缩可能会减缓进程，而文本/日志文件可以显着压缩与gzip -9 。
你每天要推送多less数据？
你将需要testing你的数据。 只要将它发送到一个文件，并用每种方法压缩它。
对我们来说，gzip做出了巨大的改变，我们通过这一切来运行所有的东西，但gzip和bzip或7z之间甚至没有1％的差异。
如果你使用的是较慢的T1，则需要将其存储到一个文件中，并将其同步到rsync上。
对于那些受限于CPU而不是带宽的人（不是你）来说，就像lstvan所说的那样，arcfour128这种不同的encryption技术可以加快速度。 我们在内部移动时使用它。
尝试打开与-D发送的zfs的重复数据删除。 当然，节省取决于您的数据有多less重复。
你有没有考虑调整你的TCP / IP协议栈，这样你的TCP缓冲区和窗口大小有点大？ 您可以在Solaris上使用此ndd工具或Linux / BSD / Mac OSX上的sysctl工具。 在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做同样的事情。