Quando deve recriar uma cadeia de replicação ZFS interrompida?

Faça uma nova semente quando não conseguir provar a existência de uma base comum válida ou quando reparar a cadeia exigir um rollback não verificado do destino. Preserve primeiro a última réplica legível.

Num NAS doméstico, o atalho tentador é forçar o próximo envio incremental até funcionar. Isso pode ocultar um instantâneo-pai em falta, um destino divergente ou um destino de receção que já não é o conjunto de dados que pensa ser. Comece por fazer um inventário de ambos os lados sem alterar nenhum deles, prove se ainda existe uma base partilhada e use uma nova semente completa faseada quando as evidências não sustentarem uma continuação incremental segura.

Prove Que Ambos os Lados Ainda Partilham a Mesma Base

Comece por fazer um inventário apenas de leitura do conjunto de dados de origem, do conjunto de dados de destino, dos instantâneos, dos marcadores e de qualquer estado de retoma da receção. Compare mais do que um nome de instantâneo conveniente: confirme que a base candidata pertence aos conjuntos de dados pretendidos e representa o mesmo histórico de replicação. Guarde as listagens antes da limpeza para poder explicar por que motivo escolheu a ação seguinte.

A replicação incremental ZFS depende de uma base já presente no recetor. Por isso, uma sequência de replicação de instantâneos prática preserva deliberadamente o histórico partilhado, em vez de assumir que etiquetas idênticas provam continuidade.

Se existir uma base verificada em ambos os lados, avance para um teste incremental não destrutivo. Se o nome existir, mas a identidade ou o caminho do conjunto de dados forem diferentes, trate a cadeia como não comprovada. Se já não existir uma base comum, não elimine mais instantâneos nem force o destino para trás; a decisão já passou a ser uma nova semente faseada.

Teste o Plano Incremental Sem Alterar a Réplica

Construa o envio proposto com a base verificada e o destino mais recente, mas não o encaminhe ainda para o destino ativo. Utilize uma execução simulada, uma estimativa detalhada ou o modo de pré-visualização da ferramenta de replicação. Confirme o caminho de origem, o caminho de destino, o instantâneo de base, o instantâneo de destino, as opções de recursividade e o tamanho esperado do fluxo antes de qualquer receção poder modificar os dados.

Um agendador que indica nenhum instantâneo de base comum está a recusar uma suposição insegura, não está simplesmente a pedir uma nova tentativa. As tentativas repetidas não recriam o histórico partilhado eliminado.

Um fluxo com tamanho correspondente às diferenças entre a base e o destino exatos permite reparar a cadeia. Um fluxo próximo do tamanho total do conjunto de dados, um conjunto de dados inesperado ou qualquer requisito de rollback forçado significa que a pré-visualização falhou. Pare nesse ponto e preserve a réplica atual; alterar opções até o comando funcionar não é verificação.

Escolha a Reparação Apenas Quando o Histórico e o Estado do Destino Forem Concordantes

Repare o caminho incremental apenas quando a base comum estiver verificada, o destino não se tiver tornado numa cópia de trabalho independente e a pré-visualização propuser a diferença esperada. Mantenha o destino apenas de leitura durante a janela de reparação. Envie primeiro para um conjunto de dados-filho novo ou para um destino de preparação, quando a ferramenta o permitir, e compare antes de o promover.

Faça uma nova semente quando não existir uma base válida, o destino tiver divergido, o rollback necessário eliminar instantâneos de que ainda precisa ou o tempo gasto a provar a cadeia exceder o custo controlado de uma nova transferência completa. As discussões sobre ancestralidade de instantâneos incrementais reforçam que os nomes intermédios são menos importantes do que manter um ponto comum utilizável.

Não apague o destino antigo para libertar espaço, a menos que exista outra cópia verificada. Uma nova semente mais segura escreve para um conjunto de dados ou agrupamento separado, verifica a nova cópia e só depois desativa a cadeia danificada. Se não houver capacidade suficiente para manter ambos, pare e obtenha espaço temporário em vez de transformar a última réplica legível numa experiência.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

Valide a Nova Cadeia ao Longo de Dois Ciclos de Replicação

Uma receção completa bem-sucedida prova apenas que chegou um fluxo. Crie um pequeno ficheiro de teste ou altere uma propriedade na origem, faça o instantâneo agendado seguinte e execute um segundo ciclo incremental utilizando a nova base comum. Compare as propriedades do conjunto de dados, as listas de instantâneos, uma amostra de ficheiros e o registo de replicação após ambas as execuções.

Se o comportamento de retoma tiver feito parte da falha original, mantenha o anterior caminho de falha do token de retoma separado da ancestralidade em falta, para que o mesmo sintoma não o encaminhe novamente para a reparação errada.

A recuperação é bem-sucedida quando a nova semente é legível, a segunda transferência incremental tem o tamanho correspondente às diferenças e é concluída com êxito, e os instantâneos e ficheiros esperados aparecem após um reinício ou uma execução agendada. Mantenha a réplica anterior até essas verificações serem concluídas. Escale o problema se as identidades mudarem novamente, se o destino não puder permanecer apenas de leitura ou se a ferramenta selecionar repetidamente uma base inesperada.