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

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

每周一次或两次，将15-60克摄影数据转储到办公室NAS。我的工作是弄清楚如何使用非常慢的DSL连接（〜700Kb / s上载）尽可能可靠地将这些数据移到异地。接收盒的形状要好得多，下降速率为30Mb / s，上升速率为5Mb / s。

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

我的选择似乎是：

• ZFS增量式通过SSH发送
• 同步

rsync是一个久负盛名的解决方案，并且具有在中断某些事件时恢复发送的最重要的功能。它具有迭代许多文件而又不了解dedup的缺点。

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

我担心ZFS复制性能[1]（尽管该文章已有一年历史了）。我还担心如果出现故障，是否能够重新启动传输-快照功能似乎不包含该功能。整个系统需要完全放手。

[1] http://wikitech-static.wikimedia.org/articles/z/f/s/Zfs_replication.html

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

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

1. 如果您每天最多可以传输6GB（假设零开销和零竞争流量），并且您需要以“每周一次或两次”的频率移动“ 15-60演出”，那么计算结果为15-120每周GB，或每天2-17 GB。因为有必要计划峰值需求，并且17 GB甚至远远超过理论上的最大6 GB，所以您可能会遇到非常严重的带宽问题。升级连接需要什么？如果无法升级连接，请考虑选择按计划（例如每周一次）邮寄物理媒体。

2. 假设您可以获得带宽数学知识，那么rsync可能是最佳选择。在复制高度冗余的数据（例如，虚拟机映像）时，重复数据删除意识将具有巨大的价值，但对于独特的数字内容（音频，视频，照片），它应该几乎没有好处或没有好处。无意间存储了相同文件的重复副本。

经过一些研究，我相信您发送快照是正确的。ZFS SEND和RECEIVE命令可以通过管道传递到bzip2中，然后可以将该文件重新同步到另一台计算机上。

这是我使用的一些资源：

• 《Oracle Solaris ZFS管理员指南》第211页（或此处的 Web版本）开始讨论此问题。

• 我还找到了一个博客文章，给出了一个简单的例子。 该博客还展示了通过bzip2传输位流并将其发送的过程。

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

许多网站都谈论建立一个cron作业来经常这样做。在这种情况下，您可以进行复制/备份，而对带宽和用户的影响较小，并且由于场外数据是最新的，因此它是一种很好的灾难恢复功能。（也就是说，开始时是在初始数据块之后。）

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

编辑：刚刚看了一个video1 video2，它可能有助于支持SEND/ 的使用，RECEIVE并谈论rsync（开始于3m49s）。本·洛克伍德（Ben Rockwood）是发言人，这是他博客的链接。

备份的目的是什么？需要如何访问它们？

如果备份主要用于灾难恢复，则ZFS快照可能更可取，因为您将能够使文件系统恢复到上一次增量备份时的确切状态。

但是，如果您的备份还可以使用户访问可能被意外删除，损坏等的文件，那么rsync可能是一个更好的选择。最终用户可能不了解快照的概念，或者您的NAS无法为最终用户提供对以前快照的访问权限。无论哪种情况，都可以使用rsync提供备份，用户可以通过文件系统轻松访问该备份。

使用rsync，您可以使用--backup标志来保留已更改文件的备份，并且使用--suffix标志可以控制重命名文件的旧版本。这样可以轻松创建备份，在该备份中您可能已将旧版本的文件标为日期

file_1.jpg
file_1.jpg.20101012
file_1.jpg.20101008
etc.

您可以轻松地将其与包含find命令的cronjob结合使用，以根据需要清除任何旧文件。

两种解决方案都应该能够保留有关文件的足够元信息以用作备份（rsync提供--perms，-owner等标志）。我使用rsync在数据中心之间备份大量数据，对此设置感到非常满意。

ZFS应该具有“可恢复发送”功能，该功能将允许在今年3月左右的某个时间继续中断的复制。该功能已由Matt Ahrens和其他一些人完成，应该很快就可以使用。

也许WAN压缩设备将是一个解决方案...？我们使用Riverbed，我们对此感到非常满意（例如NetApp SnapMirror的压缩率非常高，高达80-90％）