ZFS备份占用空间远小于原池的原因及备份完整性确认

嘿，很高兴你自己已经做了不少排查工作，还准备自答，我来帮你把这些细节理清楚，搞明白空间差异的原因，同时确认备份是不是真的完整~

一、为什么备份占用空间比原池小？ #

这里有几个核心原因，咱们一一拆解：

• 你备份的只是原池的部分数据集：看你的备份命令，你发送的是tank/ds1@backup2302062136的递归快照，而原池tank显示的457G used是整个池的总占用，包含了tank/ds1之外的其他数据（比如池里可能还有其他独立数据集）。而备份池indoorpool里只有tank/ds1及其子数据集的完整备份，它的261G used就是这部分数据的实际大小，两者的差值刚好对应原池里其他数据的占用量，这是最主要的原因。

• 压缩比的差异是统计范围不同导致的：你查的是池级别的压缩比，原池tank的1.32x是整个池所有数据集的平均压缩比；而备份池indoorpool里只有tank/ds1系列的数据集，这部分数据本身的压缩比更高（1.53x），所以整体压缩比就比原池高。另外，你看到备份池的compression是off，这只是池级别的默认设置——你接收的数据集indoorpool/ds1会继承源数据集的压缩设置（也就是lz4），因为zfs send -R会同步数据集的所有属性，池级别的默认值不会覆盖已创建的数据集设置。你可以用这条命令验证：

  zfs get compression indoorpool/ds1
  

  大概率会看到它的压缩是lz4，这就解释了为什么备份数据依然是压缩状态，占用空间更小。

• ZFS Send/Receive的天然高效性：zfs send只会发送快照中实际存在的唯一数据块，不会发送已经删除的块或者重复冗余的数据（原池可能有一些历史快照的冗余，但备份只包含你指定的快照链），这也会让备份的占用空间比原池的实时占用更紧凑。

二、如何确认备份是完整且成功的？ #

你已经做了最关键的一步——对比源和备份的快照数量，完全一致，这是个非常好的迹象。再补充几个验证方法，彻底打消顾虑：

1. 检查数据集属性同步情况：用以下两条命令对比，确认除了挂载点这类和池相关的属性，其他关键属性（加密、压缩、记录大小等）都一致：

   zfs get all tank/ds1 | grep -v default
   zfs get all indoorpool/ds1 | grep -v default
   

2. 用zfs compare验证数据一致性：这条命令会直接对比两个快照的差异，如果没有任何输出，说明数据完全一致：

   zfs compare -r tank/ds1@backup2302062136 indoorpool/ds1@backup2302062136
   

3. 验证备份的可恢复性：如果条件允许，可以尝试挂载备份的数据集，随机检查一些文件的内容和大小，确认和原数据完全匹配：

   zfs mount indoorpool/ds1
   # 之后去挂载目录检查文件，比如用md5sum对比原文件和备份文件
   

从你描述的情况来看，备份命令没有报错，快照数量完全匹配，这些都说明备份大概率是完整成功的。

总结 #

空间差异主要是因为你备份的只是原池的部分数据集，加上备份数据本身的压缩比更高，再结合ZFS发送接收的高效性。只要通过上述方法验证了数据一致性，就可以放心使用这个备份啦~

备注：内容来源于stack exchange，提问作者lucidbrot