减少异地备份的 ZFS 流大小

减少异地备份的 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输出中)?

答案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

什么类型的电子邮件系统和什么类型的“存储”技术?如果邮件存储已经以任何方式压缩,那么每个增量实际上可能都是完整的,因为其压缩数据流可能会由于压缩而动态变化。

另外,重复数据删除是否在两个系统上都起作用?听起来它可能在源系统上的可能性很小。这可能是大小差异的原因。

相关内容