eaj*_*eaj 6 freebsd backup zfs
注意：自从我第一次问这个问题以来，我对这个问题的理解发生了重大变化（请参阅下面的编辑 2），但我保留了原始版本。
我们已经建立了一个异地备份系统（仍在内部测试），通过 ZFS 发送/接收进行数据传输。两端的机器都是 FreeBSD 8.2。总体而言，该设置运行良好。
但是，对于 ZFS 快照流大小，我显然有一些不了解的地方。我很难找到这方面的信息，所以我希望有更多经验的人可以启发我。
在源机器上，我有一个大约 47GB 的文件系统，我需要为其传输快照：
# zfs list -t snapshot -r -s creation stg/serverx
NAME USED AVAIL REFER MOUNTPOINT
(.......)
stg/serverx@20110620 2.88M - 47.1G -
stg/serverx@20110621 2.89M - 47.1G -
stg/serverx@20110622 2.88M - 47.1G -
stg/serverx@20110623 5.44M - 46.6G -
我在远程服务器上已经有了 6/22 的快照，所以我将生成的流发送给它
zfs send -i stg/serverx@20110622 stg/serverx@20110623
这是在另一端毫无问题地接收到的；然而，生成的流超过 80 GB — 几乎是整个源文件系统大小的两倍。
我是否误解了由生成的“USED”列的含义zfs list？我原以为这个快照流是 5.44M 加上一定量的开销。似乎我不太明白什么是开销。
可能有用的信息：我们将每个服务器备份（通过 rsync）到它自己的文件系统。这个特定的流似乎生成了最大的流（相对于文件系统和快照大小）。我怀疑这可能与它是一个邮件服务器有关，所以它的一些内容是非常动态的。但是，我希望这也会显示在“已使用”大小的快照中。
显然，我们可以通过压缩流来节省很多（它可能会减少到原始大小的 12-20%）。即便如此，带宽仍将是我们的限制因素，因此我们想了解是什么让这些流如此庞大，以及我们是否可以采取任何措施来缓解它。
编辑：我忘记了我们在源文件系统上启用了 zfs 压缩。因此，所使用的 47 GB 确实转换为近 80 GB 的“真实”文件系统数据。我想这是一个部分的解释，但我仍然不明白为什么增量流zfs send会如此之大。
编辑2：
对该备份和其他一些备份的进一步调查得出的结论是，实际上可以预期大量传输（由于已经进行了一些升级）。但是，我在zfs list.
我已经阅读了文档，并且我知道计算快照使用的空间有很多复杂性。该zfs手册页说，在的描述如下used特性：
当快照。. . 创建后，它们的空间最初在快照和文件系统之间共享，并且可能与以前的快照共享。随着文件系统的变化，之前共享的空间成为快照独有的空间，并计入快照的已用空间。
这对我来说很有意义。但是，我希望看到在服务器升级当天结束时创建的更大的快照。事实上，它只有几兆字节。这里没有重复数据删除（zpool 版本 15）。但是生成的增量流zfs send -i比较大，包含了所有的升级信息。
有人可以解释这种明显的不一致吗？那么，相关的问题是：如何合理估计增量流的大小（例如，从zfs list输出）？
我知道这是一个非常古老的问题，但我在一些不同的地方看到过它。对于 zfs list 中表达的值总是存在一些混淆，因为它涉及使用 zfs send|recv。问题在于，USED 列中表示的值实际上是对删除单个快照时将释放的空间量的估计，请记住可能存在引用相同数据块的较早和较晚的快照。
例子：
zfs list -t snapshot -r montreve/cev-prod | grep 02-21
NAME USED AVAIL REFER MOUNTPOINT
montreve/cev-prod@2018-02-21_00-00-01 878K - 514G -
montreve/cev-prod@2018-02-21_sc-daily 907K - 514G -
montreve/cev-prod@2018-02-21_01-00-01 96.3M - 514G -
montreve/cev-prod@2018-02-21_02-00-01 78.5M - 514G -
montreve/cev-prod@2018-02-21_03-00-01 80.3M - 514G -
montreve/cev-prod@2018-02-21_04-00-01 84.0M - 514G -
montreve/cev-prod@2018-02-21_05-00-01 84.2M - 514G -
montreve/cev-prod@2018-02-21_06-00-01 86.7M - 514G -
montreve/cev-prod@2018-02-21_07-00-01 94.3M - 514G -
montreve/cev-prod@2018-02-21_08-00-01 101M - 514G -
montreve/cev-prod@2018-02-21_09-00-01 124M - 514G -
为了找出通过 zfs send|recv 重建快照需要传输多少数据，您需要对这些值使用试运行功能 (-n)。拍摄上面列出的快照尝试：
zfs send -nv -I montreve/cev-prod@2018-02-21_00-00-01 montreve/cev-prod@2018-02-21_09-00-01
send from @2018-02-21_00-00-01 to montreve/cev-prod@2018-02-21_sc-daily estimated size is 1.99M
send from @2018-02-21_sc-daily to montreve/cev-prod@2018-02-21_01-00-01 estimated size is 624M
send from @2018-02-21_01-00-01 to montreve/cev-prod@2018-02-21_02-00-01 estimated size is 662M
send from @2018-02-21_02-00-01 to montreve/cev-prod@2018-02-21_03-00-01 estimated size is 860M
send from @2018-02-21_03-00-01 to montreve/cev-prod@2018-02-21_04-00-01 estimated size is 615M
send from @2018-02-21_04-00-01 to montreve/cev-prod@2018-02-21_05-00-01 estimated size is 821M
send from @2018-02-21_05-00-01 to montreve/cev-prod@2018-02-21_06-00-01 estimated size is 515M
send from @2018-02-21_06-00-01 to montreve/cev-prod@2018-02-21_07-00-01 estimated size is 755M
send from @2018-02-21_07-00-01 to montreve/cev-prod@2018-02-21_08-00-01 estimated size is 567M
send from @2018-02-21_08-00-01 to montreve/cev-prod@2018-02-21_09-00-01 estimated size is 687M
total estimated size is 5.96G
哎呀！这比使用的值要多得多。但是，如果您不需要目标处的所有中间快照，则可以使用合并选项（-i 而不是 -I），该选项将计算任意两个快照之间的必要差异，即使中间还有其他快照也是如此。
zfs send -nv -i montreve/cev-prod@2018-02-21_00-00-01 montreve/cev-prod@2018-02-21_09-00-01
send from @2018-02-21_00-00-01 to montreve/cev-prod@2018-02-21_09-00-01 estimated size is 3.29G
total estimated size is 3.29G
这样就隔离了快照之间重写的各个块，因此我们只获取它们的最终状态。
但这还不是故事的全部！zfs send 基于从源中提取逻辑数据，因此，如果您在源文件系统上激活了压缩，则估计值基于需要发送的未压缩数据。例如，拍摄一个增量快照并将其写入磁盘，您将获得接近试运行命令估计值的值：
zfs send -i montreve/cev-prod@2018-02-21_08-00-01 montreve/cev-prod@2018-02-21_09-00-01 > /montreve/temp/cp08-09.snap
-rw-r--r-- 1 root root 682M Feb 22 10:07 cp08-09.snap
但如果你通过 gzip 传递它，我们会看到数据被显着压缩：
zfs send -i montreve/cev-prod@2018-02-21_08-00-01 montreve/cev-prod@2018-02-21_09-00-01 | gzip > /montreve/temp/cp08-09.gz
-rw-r--r-- 1 root root 201M Feb 22 10:08 cp08-09.gz
旁注 - 这是基于 Linux 上的 OpenZFS，版本： - ZFS：加载模块 v0.6.5.6-0ubuntu16
您会发现一些可应用于发送流的优化参考（-D 重复数据删除流，-e 更紧凑），但在这个版本中，我没有观察到对我的数据集生成的流的大小有任何影响。