笔记：自从我第一次提出这个问题以来，我对这个问题的理解发生了很大的变化（见下面的编辑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输出中）？
答案1
我知道这是一个非常老的问题，但我在几个地方看到过不同之处。在使用 zfs send|recv 时，zfs list 中表示的值总是存在一些混淆。问题是，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
哎呀！这比 USED 值多了很多。但是，如果您不需要目标中的所有中间快照，则可以使用合并选项（-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 基于提取逻辑来自源的数据，因此如果您在源文件系统上激活了压缩，则估算值将基于需要发送的未压缩数据。例如，获取一个增量快照并将其写入磁盘，您将获得接近 dry-run 命令的估算值：
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 更紧凑），但对于此版本，我没有观察到对使用我的数据集生成的流的大小有任何影响。
答案2
什么类型的电子邮件系统和什么类型的“存储”技术？如果邮件存储已经以任何方式压缩，那么每个增量实际上可能都是完整的，因为其压缩数据流可能会由于压缩而动态变化。
另外，重复数据删除是否在两个系统上都起作用？听起来它可能在源系统上的可能性很小。这可能是大小差异的原因。