Repositório Restic Bloqueado Após uma Falha: Causas, Verificações e Soluções

Um repositório Restic pode permanecer bloqueado porque outro processo ainda está ativo, uma falha deixou um estado obsoleto, o backend atrasou as atualizações ou uma tarefa de manutenção ainda mantém um bloqueio exclusivo.

Num servidor doméstico com vários anfitriões, é perigoso presumir que a última falha visível criou o único bloqueio. Pode ainda estar a decorrer uma tarefa de limpeza noutro local, um contentor pode ter reiniciado com a mesma agenda ou o armazenamento de objetos pode não apresentar imediatamente o estado mais recente. Comece por suspender novas agendas e ler a identidade do bloqueio; remova um bloqueio apenas depois de o anfitrião, o processo, a hora e a atividade do repositório indicarem que a operação terminou.

Leia a identidade do bloqueio antes de agir

Pause as agendas de cópia de segurança, esquecimento, verificação e limpeza em todas as máquinas que conseguem aceder ao repositório. Liste os bloqueios e guarde o anfitrião, o ID do processo, o utilizador, a hora de criação, a hora de atualização e a função exclusiva ou não exclusiva. Em seguida, inspecione o processo correspondente e os registos do serviço no anfitrião indicado, em vez de fazer suposições apenas com base na idade.

Os bloqueios obsoletos surgem frequentemente após um processo Restic interrompido, mas uma pipeline interrompida é apenas uma das causas possíveis. Um processo que recebe um sinal não tratado pode deixar um estado semelhante ao de uma tarefa remota que ainda está em execução.

Se o PID estiver ativo e os registos continuarem a avançar, aguarde ou pare a tarefa através do respetivo gestor de serviços; não desbloqueie enquanto ela estiver a decorrer. Se o processo estiver ausente e o anfitrião não tiver reiniciado a mesma tarefa, o bloqueio passa a ser um candidato a obsoleto. Se o anfitrião estiver inacessível ou a vista do backend for inconsistente, o estado permanece por confirmar e não há justificação para uma ação destrutiva.

Distinguir as quatro assinaturas de bloqueio

Um escritor ativo tem um processo correspondente, atividade atual nos registos e um bloqueio que é atualizado. Uma saída não tratada não tem um processo ativo e apresenta um carimbo de data/hora fixo depois de o anfitrião ou o contentor parar. O atraso do backend manifesta-se quando os clientes discordam sobre a lista de bloqueios ou quando os carimbos de data/hora ficam atrasados em relação à atividade conhecida do repositório. Uma tarefa de manutenção inacabada apresenta um bloqueio exclusivo e um registo de verificação ou limpeza que continua a ser alterado.

Uma ordem abrangente de resolução de problemas do Restic mantém os bloqueios do repositório, as falhas de limpeza e a possível corrupção como linhas de investigação separadas, para que uma correção de bloqueio obsoleto não seja aplicada a uma falha de armazenamento.

Teste uma assinatura de cada vez. Confirme primeiro se há atividade, compare depois os carimbos de data/hora e os registos, verifique em seguida a acessibilidade do backend e o relógio e, por fim, inspecione a manutenção. Se continuarem a ser plausíveis duas assinaturas, mantenha o bloqueio e investigue a opção mais segura; desbloquear não é um teste de diagnóstico, porque altera a proteção que está a tentar compreender.

Limpar apenas um bloqueio comprovadamente obsoleto

Antes de desbloquear, verifique novamente todos os clientes, controladores de automatização, anfitriões de contentores e serviços do lado do repositório. Guarde a lista atual de bloqueios e os registos recentes. Utilize o comando normal de remoção de bloqueios obsoletos, não uma opção de remoção total nem uma opção sem bloqueios, porque o procedimento normal foi concebido para manter os bloqueios ativos.

Uma falha real causada por um bloqueio obsoleto pode interromper uma agenda de cópias de segurança que funcionava corretamente, mas a antiguidade de um caso não define um limiar universalmente seguro para a eliminação.

Se o comando normal remover o registo obsoleto e nenhum bloqueio regressar imediatamente, avance para uma listagem do repositório em modo só de leitura. Se recusar porque o bloqueio está ativo, pare e descubra quem o detém. Se surgir imediatamente um novo bloqueio, uma agenda ou um contentor reiniciado continua em execução; desative essa origem antes de tentar outra reparação.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Volte a testar a operação original e procure recorrências

Execute a mesma operação que falhou, registando o progresso e o estado de saída. Observe o bloqueio a surgir, a ser atualizado enquanto a tarefa está ativa e a desaparecer após uma saída normal. Em seguida, permita que um ciclo agendado normal seja executado. Isto reproduz o acionador original e comprova mais do que uma listagem bem-sucedida do repositório.

Se o repositório passar a só de leitura ou a manutenção falhar depois de o bloqueio ser limpo, siga o procedimento separado de recuperação após uma limpeza interrompida, em vez de desbloquear repetidamente.

A recuperação é considerada bem-sucedida quando dois ciclos com a carga original são concluídos, cada bloqueio é atualizado enquanto está ativo e removido à saída, e uma verificação do repositório ou uma restauração de amostra funciona normalmente. Escale o problema se os bloqueios voltarem a surgir após saídas normais, se os clientes discordarem sobre o estado do backend ou se a verificação indicar objetos do repositório em falta ou danificados. Mantenha o bloqueio ativado durante toda a investigação.