Como saber se uma falha de cópia de segurança provém do repositório ou dos ficheiros de origem

Teste as leituras do repositório de forma independente a partir de uma fonte pequena e estável e, em seguida, teste os caminhos de origem suspeitos num repositório novo e descartável.

A decisão é importante quando uma cópia de segurança termina com erros de leitura, checksum, permissões, pacotes ou índices. Os dois estados em competição são danos no repositório ou no destino e erros de leitura, permissões ou alterações nos ficheiros de origem. 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.

Separe os danos no repositório ou no destino dos erros de leitura, permissões ou alterações nos ficheiros de origem

Registe o ambiente antes de alterar qualquer coisa: versões do software e do firmware, identidades dos dispositivos, caminho de montagem ou de rede, espaço livre, permissões e o sintoma observável. A referência inicial deve preservar detalhes suficientes para reproduzir uma cópia de segurança que termina com erros de leitura, checksum, permissões, pacotes ou índices.

O primeiro candidato é um dano no repositório ou no destino. O segundo são erros de leitura, permissões ou alterações nos ficheiros de origem. A atual sequência de resolução de problemas do Restic define o mecanismo ou limite de comando utilizado no teste; não substitui a observação deste servidor doméstico específico.

Defina 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 dos ramos, mantendo os serviços não relacionados inalterados; um resultado reprovado deve devolver o sistema ao estado guardado, em vez de desencadear uma cadeia de correções especulativas.

Execute um único discriminador controlado

Utilize este discriminador: execute uma verificação do repositório e uma restauração de teste, depois faça uma cópia de segurança de um conjunto de teste fixo e legível e inspecione separadamente os erros de origem. Mantenha constantes a carga de trabalho, o cliente, o caminho, o conjunto de ficheiros e o momento, para que o resultado possa ser atribuído à variável alterada.

Utilize um fluxo de trabalho independente do Restic para selecionar o campo que pode efetivamente separar os ramos e, em seguida, registe o respetivo carimbo de data/hora, estado de saída, texto do erro, identidade do dispositivo ou do 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 alegação em teste.

Repita o teste uma vez depois de um reinício, de uma religação, de voltar a montar ou de uma cache fria, quando esse evento fizer parte da condição original. Se a primeira execução for destrutiva ou se não for possível restaurar o ambiente, pare e reproduza o teste numa cópia descartável.

restic check
restic restore latest --include /canary --target /tmp/restore-test

Interprete qual o ramo apoiado pelas evidências

APROVADO: as verificações ou restaurações do repositório falham em várias origens, ou apenas caminhos de origem específicos falham enquanto o repositório permanece saudável. Registe a versão, a identidade e a carga de trabalho exatas que passaram, para que a conclusão permaneça condicional, em vez de se tornar uma afirmação universal.

REPROVADO: as falhas de rede e de memória afetam ambos os testes; por isso, reproduza localmente antes de declarar que algum dos lados está danificado. 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: suspenda a manutenção destrutiva, copie os registos e proteja o último estado válido do repositório. Preserve os registos e não execute comandos de reparação, limpeza, destruição, reparticionamento ou alteração recursiva de proprietários 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

Aplique a ação correspondente e reproduza a falha 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 as verificações ou restaurações do repositório falham em várias origens, ou apenas caminhos de origem específicos falham enquanto o repositório permanece saudável durante dois ciclos ou na reinicialização, suspensão, interrupção ou transição de carga relevante.

Utilize o dimensionamento de pacotes do Restic 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 os tempos de resposta anteriores.

O limite de paragem é explícito: se as falhas de rede e de memória afetarem ambos os testes, reproduza localmente antes de declarar que algum dos lados está danificado; volte à última configuração verificada, conserve as evidências e escale para um teste mais profundo da plataforma ou do hardware apenas quando o ramo for reproduzível.

Depois de o resultado pretendido se confirmar, compare-o com a frequência de verificação, para garantir que a correção não transfere o risco para um serviço vizinho. Um teste pretendido bem-sucedido com uma nova falha de cópia de segurança, identidade, tempo limite ou disponibilidade continua a ser uma alteração falhada.

Perguntas frequentes

Para isolar falhas de cópia de segurança, as pesquisas restantes geralmente dizem respeito a saber se uma verificação do repositório bem-sucedida prova a cobertura da origem, se o repositório deve ser reparado imediatamente e quais os erros de origem fáceis de ignorar. As respostas abaixo mantêm esses casos-limite separados da decisão principal.

O limite de aceitação não muda: as verificações ou restaurações do repositório falham em várias origens, ou apenas caminhos de origem específicos falham enquanto o repositório permanece saudável. Se uma condição posterior 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 as falhas de rede e de memória afetarem ambos os testes e reproduza localmente antes de declarar que algum dos lados está danificado. Nesse momento, suspenda a manutenção destrutiva, copie os registos e proteja o último estado válido do repositório; preserve as evidências antes de escalar para o responsável pela plataforma, pelo armazenamento ou pelo hardware.

Uma verificação do repositório bem-sucedida pode provar a cobertura da origem?

Não. Prova as propriedades do repositório, mas não que todos os ficheiros de origem pretendidos estavam legíveis ou foram incluídos.

O repositório deve ser reparado imediatamente?

Não, não antes de criar uma cópia de segurança, quando for viável, e confirmar a classe da falha.

Que erros de origem são fáceis de ignorar?

Recusas de permissão, ficheiros que desaparecem, setores ilegíveis, ficheiros esparsos e problemas de consistência da aplicação podem ficar ocultos nos resumos.

O diagnóstico está concluído quando a mesma carga de trabalho faz com que as evidências correspondam a danos no repositório ou no destino ou a erros de leitura, permissões ou alterações nos ficheiros de origem, e a ação correspondente elimina o sintoma original sem criar um segundo. Se nenhum dos ramos continuar reproduzível, mantenha os registos e o estado guardado intactos; a incerteza é motivo para escalar, não para acumular mais correções.