ZFS 同步通过不可靠的慢速 WAN。ZFS 复制还是 rsync？

Question

我的任务是通过 WAN 进行异地备份工作。两个存储盒都是基于 FreeBSD 的运行 ZFS 的 NAS 盒。

每周一次或两次，15-60 演出的摄影数据被转储到办公室 NAS。我的工作是找出如何使用非常慢的 DSL 连接（约 700Kb/s 上传）尽可能可靠地在场外获取这些数据。接收盒的形状要好得多，下行速度为 30Mb/s，上行速度为 5Mb/s。

我知道，在异地携带硬盘驱动器可以更快地移动数据，但在这种情况下它不是一种选择。

我的选择似乎是：

rsync 是一个久经考验的解决方案，并且具有在某些事情中断时恢复发送的非常重要的能力。它的缺点是迭代许多文件并且不知道重复数据删除。

ZFS 快照发送可能会传输更少的数据（它对文件系统了解更多，可以执行重复数据删除，可以比 rsync 更有效地打包元数据更改）并且具有正确复制文件系统状态的优点，而不是简单地复制单独的文件（这更占用磁盘空间）。

我很担心 ZFS 复制性能 [1]（尽管那篇文章已经发布了一年）。我还担心如果出现问题，能否重新开始传输——快照功能似乎不包括这一点。整个系统需要完全不干涉。

使用任一选项，我应该能够通过将流量路由到指定端口，然后在路由器上使用 QOS 来降低流量的优先级。我需要避免在每次传输期间对两个站点的用户产生重大负面影响，因为这需要几天时间。

所以……这就是我对这个问题的看法。我错过了任何好的选择吗？有没有其他人设置过类似的东西？

Answer 1

经过一些研究，我相信您发送快照是正确的。ZFSSEND和RECEIVE命令可以通过管道传输到 bzip2，然后可以将该文件 rsync 同步到另一台机器。

以下是我使用的一些来源：

我没有找到任何发布复制脚本的帖子，但我确实找到了发布备份脚本的人。也就是说，我不明白它，所以它可能是垃圾。

许多网站都谈到经常设置 cron 作业来执行此操作。如果是这种情况，您可以在对带宽和用户影响较小的情况下进行复制/备份，并成为一个很好的灾难恢复功能，因为异地数据是最新的。（也就是说，在开始时的初始数据块之后。）

同样，我认为您发送快照的想法是正确的，使用SEND/似乎有很多优点RECEIVE。

编辑：刚才看了一个视频1 视频2，可能有助于suports使用SEND/RECEIVE约rsync的会谈（在3分49秒开始）。Ben Rockwood 是演讲者，这里是他博客的链接。

Answer 2

如果您每天最多可以传输 6GB（假设零开销和零竞争流量），并且您需要以“每周一次或两次”的频率移动“15-60 个演出”，则可以达到 15-120每周 GB，或每天 2-17 GB。因为需要规划高峰需求，17GB甚至远远超过你的理论最大值6GB，很可能你有一个非常严重的带宽问题。升级连接需要什么？如果无法升级连接，请考虑定期（例如每周）邮寄物理媒体的选项。
假设您可以让带宽数学更有意义，rsync可能是最好的选择。在复制高度冗余的数据（例如虚拟机映像）时，重复数据删除意识将非常有价值，但在涉及独特的数字内容（音频、视频、照片）时，它应该几乎没有或没有任何好处......当然，除非用户是无意中存储了相同文件的重复副本。