我正在使用 syncoidsanoid 项目在我的测试环境中的另一台机器上创建 ZFS 文件系统的副本（几台 Raspberry Pi）
我搞乱了原始机器上的快照：一台服务器在快照传输期间出现故障，后来我删除了正在传输的快照。
我手动创建了一个新的快照并成功将其恢复到目标上。
现在，当我使用以下命令在目标服务器上运行 syncoid 时：
${SYNCOID} --sshkey="${SSH_KEY}" root@${REMOTE_SERVER}:${SRC_POOL}/${SAMPLE_FILESYSTEM} ${DEST_POOL}
它抱怨无法恢复发送/接收交易
在正常操作期间，syncoid 会在目标机器上检索 accept_resume_token：
/usr/local/sbin/zfs get -H receive_resume_token 'destpool/samplefs'
如果找到，它会尝试在源机器上检索与该令牌相对应的快照：
ssh sourceserver zfs send -t (token stored in receive_resume_token retrieved above) | (network stuff...) | zfs receive -s -F 'destpool/samplefs'
cannot resume send: 'sourcepool/samplefs@samplesnap' used in the initial send no longer exists
让它工作的唯一方法是将“--no-resume”标志添加到 syncoid 命令。这不是我想要的，因为有些文件系统非常大，系统在这种环境下很容易崩溃。
我尝试通过运行以下命令来清除该令牌：
zfs recv -A 'srcpool/samplefs'
在源机器上，并且：
zfs recv -A 'destpool/samplefs'
在目标机器上，我得到：
srcpool/samplefs does not have any resumable receive state to abort
（在目标机器上它是 destpool/samplefs）
问题是：有没有办法清除目标文件系统上的receive_resume_token属性？
请注意，此问题仅存在于一个文件系统中。两台机器上还有许多其他正在双向使用相同命令集的工作传输。
答案1
如果zfs recv -A没有帮助，您可以尝试销毁（或重命名）目标数据集并重新同步。
还请注意，使用syncoid该--no-resume选项应该不会有问题：即使在大型数据集上，增量更新通常也很小，并且不会受益于恢复支持（相反，这对于第一次完全同步很有用）。