Porque é que um token de retoma do ZFS Send deixa de funcionar depois de o destino reiniciar?

Um reinício do destino não deverá normalmente invalidar um token de retoma do ZFS, a menos que o estado de receção guardado, o conjunto de dados ou o histórico de origem necessário tenham sido alterados.

O token é uma descrição opaca de uma receção específica interrompida, não um marcador reutilizável para qualquer tentativa de replicação posterior. Pertence ao sistema de ficheiros ou volume de destino que preservou o estado parcial com uma receção retomável. Após um reinício, uma tarefa pode ler o conjunto de dados errado, importar o agrupamento de armazenamento de forma diferente, limpar o estado parcial, modificar o destino, perder um instantâneo de origem necessário ou gerar um fluxo incompatível. Verifique o token em ambas as extremidades antes de reiniciar uma transferência completa.

Confirme que o estado de receção parcial sobreviveu ao reinício

No destino, leia a propriedade receive_resume_token do sistema de ficheiros ou volume exato utilizado pela receção interrompida. Registe o nome do agrupamento de armazenamento, o caminho do conjunto de dados, o valor do token e a utilização de espaço do estado parcial.

O manual do FreeBSD explica que as receções retomáveis preservam o estado parcial e mantêm um token opaco no conjunto de dados de receção até a transferência ser concluída ou o estado ser explicitamente abandonado.

Se a propriedade estiver vazia após o reinício, a receção não foi guardada com a opção de retoma, o estado parcial foi concluído ou abortado, o conjunto de dados consultado é o errado ou uma limpeza automática o removeu. Não reutilize um token copiado de uma transferência anterior.

Verifique se o token pertence ao conjunto de dados de destino exato

Verifique se o agrupamento de armazenamento de destino foi importado com o nome esperado e se a replicação continua a visar o mesmo caminho do conjunto de dados. Preste atenção a raízes alternativas, agrupamentos de armazenamento renomeados, alterações no caminho principal e opções de tarefas que adicionem ou removam componentes do caminho.

A referência de propriedades do ZFS do Ubuntu define receive_resume_token como uma propriedade do conjunto de dados, o que significa que o token tem de ser lido no sistema de ficheiros ou volume que contém esse estado guardado específico.

Não se pode presumir com segurança que um token obtido de backup/pool/data retome uma receção que visa agora backup/data. Corrija o caminho da tarefa antes de alterar instantâneos ou destruir a receção parcial.

Verifique se o destino foi modificado ou revertido

Inspecione comandos, tarefas agendadas, software de replicação, retenção de instantâneos e atividade do administrador desde a interrupção. Procure reversões, promoções de clones, renomeações de conjuntos de dados, abortos de receções ou uma nova receção no mesmo destino.

A Klara Systems salienta que as ferramentas de replicação gerem o estado do destino em torno de zfs send e receive, pelo que uma tarefa de orquestração pode invalidar o caminho de recuperação original ao limpar ou substituir o estado guardado.

Não grave ficheiros comuns num destino de replicação enquanto investiga. Mesmo quando o token ainda existe, alterações no destino podem bloquear o fluxo ou forçar uma reversão que destrua dados mais recentes do destino.

-15% OFF

ZimaBoard 2 - Mini Servidor Doméstico para a Sua Grande Ideia

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Verifique se a origem ainda possui a cadeia de instantâneos ou marcadores

Identifique o conjunto de dados de origem e os instantâneos ou marcadores codificados pela transferência interrompida. Compare-os com a retenção atual e com quaisquer renomeações ou eliminações de instantâneos ocorridas desde a paragem da transferência.

O manual zfs-send do FreeBSD especifica que zfs send -t gera um fluxo a partir do token de retoma da receção, associando o novo fluxo à receção interrompida e não a um instantâneo atual arbitrário.

Se a retenção tiver eliminado o histórico de origem necessário, o token não poderá reconstruir dados que já não existem. Preserve o estado parcial restante no destino até decidir se é necessária outra cópia da origem ou um novo envio completo.

Verifique as funcionalidades do agrupamento de armazenamento e as opções do fluxo em ambos os sistemas

Registe as versões do ZFS, as funcionalidades ativadas do agrupamento de armazenamento, o estado da encriptação e as opções originais do fluxo, como envios em bruto, comprimidos, incorporados ou de blocos grandes. Compare-as após qualquer atualização de software ou do agrupamento de armazenamento.

A documentação da Oracle sobre replicação retomável descreve a retoma de uma transferência interrompida como uma operação coordenada de envio e receção, pelo que a compatibilidade e o contexto da transferência original continuam a ser importantes após um reinício.

Um reinício, por si só, não altera os sinalizadores de funcionalidades, mas uma atualização realizada durante a indisponibilidade pode fazê-lo. Reproduza manualmente o comando de retoma com saída detalhada antes de presumir que o próprio token está corrompido.

Verifique os serviços de replicação e o SSH após o arranque do destino

Confirme que o agrupamento de armazenamento de destino foi importado, que os conjuntos de dados encriptados necessários estão desbloqueados, que o SSH está em execução, que o utilizador de replicação pode executar comandos ZFS e que a tarefa só é iniciada depois de o armazenamento estar disponível.

As orientações de replicação remota do TrueNAS exigem que os pré-requisitos de SSH e do conjunto de dados de destino estejam disponíveis após o reinício; caso contrário, a automatização pode falhar antes sequer de tentar utilizar o token guardado.

Teste a autenticação e uma consulta de propriedades só de leitura antes de iniciar o fluxo retomado. Uma falha de rede ou de permissões pode parecer uma falha do token no registo de uma tarefa de nível superior.

Retome uma vez ou aborte deliberadamente a receção parcial

Gere um fluxo de envio retomado utilizando o token atual e encaminhe-o para uma receção retomável no mesmo destino. Guarde toda a saída de erro e evite iniciar tarefas de replicação em paralelo.

O guia de migração de dados NAS da ZimaSpace apresenta a regra de segurança complementar: preserve a origem e o caminho de reversão até o destino ter sido verificado.

Se o token não puder ser utilizado e o estado parcial já não tiver valor, aborte-o com o comando de aborto de receção suportado, mas apenas depois de confirmar que é possível gerar uma transferência completa ou incremental nova. Abortar liberta o estado parcial guardado e não pode ser desfeito.

Perguntas frequentes

Um reinício do destino invalida sempre um token de retoma do ZFS?

Não. Uma receção parcial guardada foi concebida para sobreviver a interrupções, incluindo um encerramento inesperado. Uma falha após o reinício geralmente significa que a tarefa está a ler um conjunto de dados diferente, que o estado parcial foi limpo, que o histórico de origem necessário foi alterado ou que faltam dependências de arranque.

É possível gerar um novo token de retoma apenas a partir da origem?

Não. O token opaco provém do estado de receção parcial guardado no conjunto de dados de destino. A origem utiliza esse token para gerar um fluxo de continuação, mas não consegue recriar sozinha um estado de destino eliminado.

Quando deverá a receção parcial ser abortada?

Aborte apenas quando o caminho de retoma tiver sido comprovadamente inutilizado, a origem puder gerar uma transferência de substituição e o estado parcial do destino já não for necessário para a recuperação. Preserve os registos e os instantâneos disponíveis antes de o remover.