Fluxo de manutenção do repositório Restic: verificar, podar, compactar e testar o restauro

A abordagem segura consiste em tratar os agendamentos de tarefas, a verificação de integridade, a pré-visualização da retenção, a limpeza para recompactação, a nova verificação e um restauro isolado como uma sequência de etapas observáveis, e não como um único comando.

Num repositório Restic utilizado por um ou mais hosts de servidor doméstico, o risco prático consiste em ter de manter um repositório Restic sem bloquear as cópias de segurança nem confundir a recuperação de espaço com a capacidade de recuperação. Registe a identidade atual e o ponto de recuperação, comece pelo fator de distinção menos invasivo, interprete os resultados positivos e negativos antes de alterar outra variável e pare quando o armazenamento ficar instável ou quando a única cópia recuperável ficar exposta. O fluxo de trabalho abaixo só termina depois de a carga de trabalho original ser concluída com êxito ou de as evidências atingirem um limite de escalamento.

Abra uma janela de manutenção em todo o repositório

Pause os agendamentos de cópia de segurança, esquecimento, verificação, cópia e limpeza em todos os hosts que conseguem aceder ao repositório. Confirme que não existe nenhum proprietário ativo de bloqueio, guarde a versão do Restic e o ID do repositório e teste as credenciais sem as expor no histórico da shell ou nos registos. A manutenção do repositório é uma alteração de estado partilhada, não uma tarefa por contentor.

Se uma falha anterior tiver deixado um bloqueio, siga o fluxo de trabalho da ZimaSpace para repositório Restic bloqueado após uma falha antes de desbloquear. Um bloqueio é uma evidência de propriedade; remova-o apenas depois de o processo identificado, o host, os carimbos de data/hora e a atividade do backend mostrarem que a operação terminou.

Verifique o espaço livre no backend, os inodes ou limites de objetos, as permissões de escrita e o espaço local de cache ou temporário. Pare se o caminho de armazenamento estiver instável, se a retenção imutável impedir a eliminação necessária ou se não for possível pausar outro escritor.

Verifique a estrutura e dados de amostra do repositório

Execute restic snapshots e uma operação normal de restic check, guardando o resultado e o código de saída. Em seguida, agende --read-data ou subconjuntos de leitura de dados suportados, de acordo com o tamanho e a largura de banda do repositório. O sucesso de uma verificação apenas estrutural não prova que todos os pacotes são legíveis.

Uma discussão da comunidade Restic distingue as funções de rotina de check, prune e rebuild-index e explica que a reconstrução do índice não é uma manutenção preventiva normal. Não execute rebuild-index nem elimine ficheiros de pacotes porque uma verificação está a demorar; reserve os comandos de recuperação para uma inconsistência diagnosticada.

Se a verificação indicar pacotes em falta, incompatibilidade de hash, falha de leitura do backend ou inconsistência do índice, pare antes de executar prune. Proteja o repositório, repita apenas a leitura que falhou através de um caminho estável e recorra à recuperação documentada numa cópia.

Pré-visualize a retenção e, em seguida, execute prune e recompactação

Execute a política pretendida de restic forget com --dry-run e reveja os snapshots mantidos e removidos por host, caminho e etiquetas. Só confirme o forget quando a lista preservar os pontos de recuperação necessários. Quando possível, mantenha um snapshot recente verificado fora de uma alteração experimental da política.

No Restic, “compact” não é um comando separado: prune remove dados não referenciados e recompacta os ficheiros do repositório conforme necessário. Um guia de resolução de problemas atual descreve falhas do Restic prune, incluindo falhas de espaço livre e de bloqueios que devem ser resolvidas antes de outra tentativa destrutiva.

Execute prune uma vez, sem concorrência de cópias de segurança, e guarde o registo completo. Se falhar, não o execute novamente às cegas nem elimine objetos que pareçam temporários. Verifique novamente os bloqueios, o espaço de trabalho livre, as permissões do backend e a última fase concluída; preserve o estado do repositório para diagnóstico.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

Volte a verificar e execute um restauro isolado

Após um prune concluído com êxito, execute novamente restic check e conclua a cobertura planeada de leitura de dados. Compare a contagem de snapshots, o tamanho do repositório e os erros com a referência anterior à manutenção. A ausência de uma redução do espaço equivalente à estimativa não é uma falha se os snapshots retidos continuarem a referenciar os dados.

Restaure um snapshot recente e um subconjunto representativo mais antigo para um diretório vazio. Verifique o conteúdo dos ficheiros, as permissões, os carimbos de data/hora, as ligações simbólicas e um artefacto ao nível da aplicação. Uma operação de montagem ou listagem, por si só, não constitui um teste de restauro.

Retome os agendamentos apenas quando a verificação após prune for bem-sucedida, os dados restaurados forem utilizáveis e for possível criar e restaurar uma nova cópia de segurança pequena. Escale qualquer corrupção nova, erro repetido do backend ou prune incompleto antes de permitir novamente que vários hosts escrevam.