tldr; 我正在尝试接收ZFS流，该流已从克隆的文件系统中作为复制（-R）创建。使用zfs recv -o origin=[clone-origin]只会得到cannot receive: local origin for clone [...] does not exist。
前提条件
我有一个SmartOS区域ZFS文件系统，该文件系统是从特定映像克隆的。 （（IMAGE-uuid和ZONE-uuid已被替换，以提高可读性）
$ zfs list -r -o name,origin zones/[ZONE]
NAME ORIGIN
zones/[ZONE] zones/[IMAGE]@[ZONE]
区域文件系统具有服务器快照：
$ zfs list -r -t all -o name, origin zones/[ZONE]
NAME ORIGIN
zones/[ZONE] zones/[IMAGE]@[ZONE]
zones/[ZONE]@[SNAP0] -
zones/[ZONE]@[SNAP1] -
zones/[ZONE]@[SNAP2] -
[...]
关于基本映像，SmartOS（更好的vmadm）为新创建的区域创建映像的快照。区域根基于此快照（此处为guid 11194422825011190557）创建为克隆。
$ zfs list -r -o name,origin,guid zones/[IMAGE]
NAME ORIGIN GUID
zones/[IMAGE] - 5616748063181666458
zones/[IMAGE]@[OTHER-ZONE] - 11174377117517693115
zones/[IMAGE]@[OTHER-ZONE] - 5587104570997150836
zones/[IMAGE]@[OTHER-ZONE] - 535244446308996462
zones/[IMAGE]@[OTHER-ZONE] - 12527420623439849960
zones/[IMAGE]@[ZONE] - 11194422825011190557
zones/[IMAGE]@[OTHER-ZONE] - 18143527942366063753
zones/[IMAGE]@[OTHER-ZONE] - 15066902894708043304
zones/[IMAGE]@[OTHER-ZONE] - 16574922393629090803
zones/[IMAGE]@[OTHER-ZONE] - 818178725388359655
zones/[IMAGE]@[OTHER-ZONE] - 11867824093224114226
zones/[IMAGE]@[OTHER-ZONE] - 9357513766021831186
备份
要创建区域根的备份，我创建了快照和复制流。
zfs snapshot zones/[ZONE]@[DATE]
zfs send -R zones/[ZONE]@[DATE] > [ZONE]_[DATE].zfs
使用zstreamdump检查它会显示预期的来源。它以十六进制表示，但是0x9b5a943fae511b1d是11194422825011190557：
$ zstreamdump < [ZONE]_[DATE].zfs
BEGIN record
hdrtype = 2
features = 4
magic = 2f5bacbac
creation_time = 0
type = 0
flags = 0x0
toguid = 0
fromguid = 0
toname = zones/[ZONE]@[DATE]
nvlist version: 0
tosnap = [DATE]
fss = (embedded nvlist)
nvlist version: 0
0xf19ec8c66f3ca037 = (embedded nvlist)
nvlist version: 0
name = zones/[ZONE]
parentfromsnap = 0x0
origin = 0x9b5a943fae511b1d
props = (embedded nvlist)
nvlist version: 0
devices = 0x0
compression = 0x2
quota = 0x500000000
(end props)
[...]
还原
要恢复灾难，我使用vmadm create和vm描述的备份来重新创建区域（保留ZONE-uuid）。 vmadm拉取图像并创建带有快照的相应zfs文件系统zones/[IMAGE]，作为重新创建的区域文件系统zones/[ZONE]的克隆源。
因此结构与崩溃前相同：
$ zfs list -r -o name,origin zones/[ZONE]
NAME ORIGIN
zones/[ZONE] zones/[IMAGE]@[ZONE]
但是，图像快照的向导（由vmadm创建）与预期不同。流期望0x9b5a943fae511b1d（或11194422825011190557），但实际上是12464070312561851369：
: zfs list -r -o name,guid zones/[IMAGE]
NAME GUID
zones/[IMAGE] 5616748063181666458
[...]
zones/[IMAGE]@[ZONE] 12464070312561851369
[...]
-我以为--o origin=的{{1}}参数进来了。
问题
通过接收zfs流恢复实际数据，最终会出现错误：
zfs recv （其中$ zfs recv -vF zones/[ZONE] < [ZONE]_[DATE].zfs
cannot receive: local origin for clone zones/[ZONE]@[SNAP0] does not exist
是备份文件系统的第一个快照，请参见上面的“前提条件”）
这是预料之中的，因为GUID已更改。因此，我使用新的guid（SNAP0）将原点强制为图像快照，但是错误仍然相同：
12464070312561851369问题
我对$ zfs recv -vF -o origin=zones/[IMAGE]@[ZONE] zones/[ZONE] < [ZONE]_[DATE].zfs
cannot receive: local origin for clone zones/[ZONE]@[SNAP0] does not exist
参数的解释正确吗？
为什么不能按预期工作？
如果这是错误的方法，如何创建备份并还原克隆的zfs文件系统？
非常感谢您的阅读和帮助！
答案 0 :(得分：0)
您似乎偶然发现了一个 ZFS 错误，该错误现在才引起了一些关注。
-R 标志试图保留通常可能不相关的所有类型的关系，例如父克隆等。没有方便的替代方案，只能“发送所有增量直到这个”。相反，您必须进行两次传递。这不是特定于 vdadm 的，所以对于一般的 ZFS，逻辑如下：
zfs send zones/[ZONE]@[EARLIESTDATE] > [ZONE]_[EARLIESTDATE].zfs
zfs send -I zones/[ZONE]@[EARLIESTDATE] zones/[ZONE]@[DATE] > [ZONE]_[EARLIESTDATE]-[DATE].zfs
zfs recv -vF zones/[ZONE] < [ZONE]_[EARLIESTDATE].zfs
zfs recv -vF zones/[ZONE] < [ZONE]_[EARLIESTDATE]-[DATE].zfs
此后，在最新备份的快照和源的最新快照之间只需要 -I 传递。
一个提议的解决方案是使用此处描述的 zfs 的修改变体：
https://github.com/openzfs/zfs/issues/10135
不过，请确保您知道这如何影响您的数据集。那么你的命令是
FQ_OVERRIDE_GTND=1 .zfs recv vF -o origin=zones/[IMAGE]@[ZONE] zones/[ZONE] < [ZONE]_[DATE].zfs
另一个相同的错误报告在这里：