Como verificar se a replicação ZFS pode ser retomada após uma transferência interrompida

Sim, quando o lado de receção preserva um token de retoma válido e os instantâneos de origem necessários para esse token ainda existem.

A decisão é importante quando um envio zfs bruto ou incremental é interrompido por uma falha de rede ou do destino. Os dois estados concorrentes são um token de retoma de receção válido e um token em falta ou um instantâneo de origem destruído. Comece com uma configuração guardada e dados descartáveis, observe um ramo de cada vez e pare se o teste aumentar o risco de perda de dados, permissões ou disponibilidade.

Defina as condições subjacentes à decisão de replicação zfs retomável

Registe o ambiente antes de alterar qualquer coisa: versões de software e firmware, identidades dos dispositivos, caminho de montagem ou de rede, espaço livre, permissões e o sintoma observável. A linha de base deve preservar detalhes suficientes para reproduzir a interrupção de um envio zfs bruto ou incremental por uma falha de rede ou do destino.

O primeiro candidato é um token de retoma de receção válido. O segundo é um token em falta ou um instantâneo de origem destruído. O atual envio zfs retomável define o mecanismo ou limite do comando utilizado no teste; não substitui a observação deste servidor doméstico específico.

Escreva a condição de aceitação e a condição de paragem antes de executar o discriminador. Um resultado aprovado deve alterar as evidências previstas por um ramo, mantendo inalterados os serviços não relacionados; um resultado reprovado deve devolver o sistema ao estado guardado, em vez de desencadear uma cadeia de correções especulativas.

Teste a afirmação sem reduzir o requisito original

Use este discriminador: interrompa uma replicação descartável, leia o token, gere um fluxo de envio retomado e compare o instantâneo final do destino. Mantenha constantes a carga de trabalho, o cliente, o caminho, o conjunto de ficheiros e o tempo, para que o resultado seja atribuível à variável alterada.

Use envio e receção ZFS para selecionar o campo que pode realmente separar os ramos e, em seguida, capture o respetivo carimbo de data e hora, estado de saída, texto do erro, identidade do dispositivo ou instantâneo, latência, bytes transferidos, permissões e estado de recuperação. Uma saída limpa do comando não é suficiente quando a identidade, a durabilidade ou o estado da aplicação são a afirmação em teste.

Repita o teste uma vez após um reinício, uma nova ligação, uma remontagem ou uma cache fria, quando esse evento fizer parte da condição original. Se a primeira execução for destrutiva ou se o ambiente não puder ser restaurado, pare e reproduza-a numa cópia descartável.

token=$(zfs get -H -o value receive_resume_token pool/dst)
zfs send -t "$token" | ssh nas zfs receive pool/dst

Interprete resultados aprovados, reprovados e excecionais

APROVADO: o fluxo de retoma é concluído e os instantâneos de origem e destino partilham a linhagem GUID esperada. Registe a versão exata, a identidade e a carga de trabalho que foram aprovadas, para que a conclusão permaneça condicional em vez de se tornar uma afirmação universal.

REPROVADO: não existe qualquer token, o destino foi revertido ou os instantâneos de origem necessários foram removidos. Um resultado reprovado não prova automaticamente o ramo oposto quando a rede, a memória, as permissões ou a consistência da origem podem influenciar ambos; isole essas dependências partilhadas antes de escalar.

EXCEÇÃO OU RESULTADO AMBÍGUO: aborte a receção parcial apenas depois de decidir que o custo do reinício é aceitável. Preserve os registos e não execute comandos de reparação, limpeza, destruição, reparticionamento ou alteração recursiva de propriedade até existir uma cópia recuperável.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Confirme a decisão com a carga de trabalho original

Aplique a ação correspondente ao ramo observado e, em seguida, repita a condição original em vez de um substituto reduzido. A decisão só é válida quando o fluxo de retoma é concluído e os instantâneos de origem e destino partilham a linhagem GUID esperada ao longo de dois ciclos ou do reinício, suspensão, interrupção ou transição de carga relevante.

Use as janelas de cópia de segurança imutáveis para verificar o fluxo de trabalho dependente mais próximo, mas mantenha o acionador original inalterado. Os conjuntos de dados, partilhas, contentores, utilizadores e pontos de recuperação não relacionados devem manter o acesso e o tempo de resposta anteriores.

O limite de paragem é explícito: se não existir qualquer token, se o destino tiver sido revertido ou se os instantâneos de origem necessários tiverem sido removidos, regresse à última configuração verificada, conserve as evidências e escale para um teste mais aprofundado da plataforma ou do hardware apenas quando o ramo for reproduzível.

Depois de obter o resultado pretendido, compare-o com a estrutura do repositório local, para garantir que a correção não transfere o risco para um serviço vizinho. Um teste do objetivo bem-sucedido com uma nova falha de cópia de segurança, identidade, tempo limite ou disponibilidade continua a ser uma alteração malsucedida.

FAQ

Na replicação ZFS retomável, as pesquisas restantes normalmente dizem respeito a saber se todas as receções interrompidas criam um token, se os instantâneos de origem antigos podem ser eliminados após uma interrupção e como verificar a réplica final. As respostas abaixo mantêm esses casos extremos separados da decisão principal.

O limite de aceitação não muda: o fluxo de retoma é concluído e os instantâneos de origem e destino partilham a linhagem GUID esperada. Se uma condição subsequente alterar o sistema de ficheiros, a identidade, o caminho de rede ou a versão da aplicação, repita apenas o discriminador afetado por essa alteração.

Pare de alargar a experiência quando não existir qualquer token, quando o destino tiver sido revertido ou quando os instantâneos de origem necessários tiverem sido removidos. Nesse momento, aborte a receção parcial apenas depois de decidir que o custo do reinício é aceitável; preserve as evidências antes de escalar para o responsável pela plataforma, pelo armazenamento ou pelo hardware.

Todas as receções interrompidas criam um token?

Não. A receção tem de utilizar um comportamento retomável e falhar num estado que preserve um token.

Os instantâneos de origem antigos podem ser eliminados após uma interrupção?

Não, até que o fluxo retomado deixe de depender deles e o destino tenha sido verificado.

Como verificar a réplica final?

Compare a linhagem GUID dos instantâneos, as propriedades, os ficheiros esperados e uma amostra de restauro - não apenas o estado de saída do comando.

Na replicação ZFS retomável, a resposta prática continua a ser condicional: o fluxo de retoma é concluído e os instantâneos de origem e destino partilham a linhagem GUID esperada. Quando não existe qualquer token, o destino foi revertido ou os instantâneos de origem necessários foram removidos, aborte a receção parcial apenas depois de decidir que o custo do reinício é aceitável; um sucesso parcial que não consegue sobreviver à carga de trabalho original não é compatibilidade.