Estou usando o syncoid do projeto sanoid para criar cópias dos sistemas de arquivos ZFS em uma máquina diferente no meu ambiente de teste (alguns Framboesa Pi)
Eu baguncei um instantâneo na máquina de origem: um servidor entrou em pane durante uma transferência de instantâneo e depois eu excluí o instantâneo que estava sendo transferido.
Eu criei manualmente um novo instantâneo e o restaurei com sucesso no destino.
Agora, quando executo o syncoid no servidor de destino usando:
${SYNCOID} --sshkey="${SSH_KEY}" root@${REMOTE_SERVER}:${SRC_POOL}/${SAMPLE_FILESYSTEM} ${DEST_POOL}
ele reclama que não pode retomar uma transação de envio / recebimento
Durante operações normais, o syncoid recupera o receive_resume_token na máquina de destino:
/usr/local/sbin/zfs get -H receive_resume_token 'destpool/samplefs'
Se encontrar um, ele tentará recuperar o instantâneo correspondente a esse token na máquina de origem:
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
A única maneira de fazê-lo funcionar é adicionar o sinalizador "--no-resume" ao comando syncoid. Isso não é o que eu quero, já que alguns sistemas de arquivos são muito grandes e travamentos de sistemas são prováveis nesse ambiente.
Eu tentei limpar esse token executando:
zfs recv -A 'srcpool/samplefs'
na máquina de origem e:
zfs recv -A 'destpool/samplefs'
na máquina alvo, eu recebo:
srcpool/samplefs does not have any resumable receive state to abort
(na máquina de destino é destpool / samplefs)
A pergunta é: existe uma maneira de limpar o atributo receive_resume_token no sistema de arquivos de destino?
Por favor, note que este problema está presente apenas com um sistema de arquivos. Existem muitas outras transferências de trabalho em ambas as máquinas em ambas as direções usando o mesmo conjunto de comandos.