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

Question 1

如果您每天最多可以传输 6GB（假设零开销和零竞争流量），并且需要以“每周一到两次”的频率移动“15-60 GB”，那么每周就相当于 15-120 GB，或者每天 2-17 GB。因为需要为高峰需求做好计划，而 17 GB 甚至远远超过了您的理论最大 6 GB，则很可能存在非常严重的带宽问题。升级连接需要什么？如果无法升级连接，请考虑按计划（例如每周）邮寄物理媒体。
假设你可以让带宽计算变得更有意义一点，同步可能是最佳选择。在复制高度冗余的数据（例如虚拟机映像）时，重复数据删除意识将发挥巨大作用，但对于独特的数字内容（音频、视频、照片）来说，它应该没有什么好处……当然，除非用户无意中存储了相同文件的重复副本。

Answer

如果您每天最多可以传输 6GB（假设零开销和零竞争流量），并且需要以“每周一到两次”的频率移动“15-60 GB”，那么每周就相当于 15-120 GB，或者每天 2-17 GB。因为需要为高峰需求做好计划，而 17 GB 甚至远远超过了您的理论最大 6 GB，则很可能存在非常严重的带宽问题。升级连接需要什么？如果无法升级连接，请考虑按计划（例如每周）邮寄物理媒体。
假设你可以让带宽计算变得更有意义一点，同步可能是最佳选择。在复制高度冗余的数据（例如虚拟机映像）时，重复数据删除意识将发挥巨大作用，但对于独特的数字内容（音频、视频、照片）来说，它应该没有什么好处……当然，除非用户无意中存储了相同文件的重复副本。

Question 2

经过一番研究，我认为您关于发送快照的说法是正确的。ZFSSEND和RECEIVE命令可以通过管道传输到 bzip2，然后该文件可以通过 rsync 传输到另一台机器。

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

我没有找到任何发布复制脚本的帖子，但我确实找到了发布其复制脚本的人备份脚本。话虽如此，但我没看懂，所以它可能是垃圾。

许多网站都谈到了设置一个 cron 作业来频繁执行此操作。如果是这样，您可以复制/备份，对带宽和用户的影响较小，并且具有良好的灾难恢复功能，因为异地数据更为最新。（即，在开始时的初始数据块之后。）

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

编辑：刚刚看了一个视频1 视频2SEND这可能有助于支持/的使用RECEIVE并讨论 rsync（从 3 分 49 秒开始）。Ben Rockwood 是演讲者，以下是他的链接博客。

Answer

经过一番研究，我认为您关于发送快照的说法是正确的。ZFSSEND和RECEIVE命令可以通过管道传输到 bzip2，然后该文件可以通过 rsync 传输到另一台机器。

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

我没有找到任何发布复制脚本的帖子，但我确实找到了发布其复制脚本的人备份脚本。话虽如此，但我没看懂，所以它可能是垃圾。

许多网站都谈到了设置一个 cron 作业来频繁执行此操作。如果是这样，您可以复制/备份，对带宽和用户的影响较小，并且具有良好的灾难恢复功能，因为异地数据更为最新。（即，在开始时的初始数据块之后。）

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

编辑：刚刚看了一个视频1 视频2SEND这可能有助于支持/的使用RECEIVE并讨论 rsync（从 3 分 49 秒开始）。Ben Rockwood 是演讲者，以下是他的链接博客。

Question 3

备份的目的是什么以及如何访问它们？

如果您的备份主要用于灾难恢复，那么 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 在数据中心之间备份大量数据，对设置非常满意。

Answer