笔记:自从我第一次提出这个问题以来,我对这个问题的理解发生了很大的变化(见下面的编辑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
什么类型的电子邮件系统和什么类型的“存储”技术?如果邮件存储已经以任何方式压缩,那么每个增量实际上可能都是完整的,因为其压缩数据流可能会由于压缩而动态变化。
另外,重复数据删除是否在两个系统上都起作用?听起来它可能在源系统上的可能性很小。这可能是大小差异的原因。