Porque é que uma cópia de segurança do Restic fica bloqueada quando outro anfitrião começa a eliminar cópias antigas?

A cópia de segurança costuma ficar bloqueada porque a limpeza necessita de controlo exclusivo sobre o repositório partilhado, pelo que o segundo anfitrião não pode continuar a utilizar o mesmo estado do repositório nesse momento.

Numa configuração doméstica com vários anfitriões, a sequência temporal é o melhor primeiro indicador: a cópia de segurança avança normalmente, outra máquina inicia a limpeza e, de seguida, a cópia de segurança fica à espera ou comunica um bloqueio. Confirme o proprietário do bloqueio e o registo de manutenção ativo antes de alterar qualquer coisa. Deixe a limpeza terminar ou pare-a corretamente a partir do anfitrião proprietário; nunca remova o bloqueio a partir do cliente de cópia de segurança que está à espera.

Confirme que a limpeza é exatamente o fator desencadeante

Guarde o registo da cópia de segurança em espera e o registo de manutenção do anfitrião que executa a limpeza, com marcas temporais. Liste os bloqueios do repositório e associe o anfitrião, o processo e o estado exclusivo ao trabalho de limpeza. A causa é sustentada quando o progresso da cópia de segurança para depois de a limpeza adquirir o repositório e retoma depois de o bloqueio ser libertado.

Os operadores que utilizam um único repositório a partir de vários anfitriões referem contenção de bloqueios durante a limpeza, porque a operação de manutenção entra em conflito com agendamentos de cópias de segurança que, de outro modo, seriam independentes.

Se a cópia de segurança já estava lenta, se o anfitrião da limpeza nunca obteve um bloqueio ou se ambos os registos param devido a um erro de armazenamento, não force este diagnóstico. Verifique a disponibilidade e a latência do backend, bem como o próprio processo de cópia de segurança. A explicação baseada no bloqueio da limpeza só se aplica quando o fator desencadeante, o proprietário do bloqueio e o momento da libertação são coerentes.

Trate o bloqueio exclusivo como uma fronteira de segurança

A limpeza altera o armazenamento do repositório e, por isso, necessita de uma visão consistente enquanto decorre. A cópia de segurança em espera não está necessariamente bloqueada no sentido habitual do processo; pode estar a respeitar o bloqueio de manutenção. A primeira pergunta é se a limpeza está a progredir, não como fazer com que a cópia de segurança ignore o bloqueio.

Um repositório partilhado necessita de um único responsável pela manutenção, porque a manutenção de todo o repositório afeta todos os clientes, mesmo quando os dados de origem pertencem a anfitriões diferentes.

Se os registos da limpeza avançarem e as operações de E/S do repositório continuarem, mantenha o bloqueio e deixe o trabalho terminar. Se o trabalho estiver realmente bloqueado, pare-o de forma correta a partir do anfitrião que o possui e aguarde uma saída limpa. Remover o bloqueio a partir de outro cliente enquanto a limpeza continua a escrever transforma uma espera controlada numa sobreposição insegura.

Recupere a cópia de segurança em espera sem contornar o bloqueio

A correção menos invasiva é aguardar a conclusão da limpeza. Se a cópia de segurança tiver uma política de novas tentativas limitada, deixe-a tentar novamente depois de o bloqueio exclusivo desaparecer. Quando for necessário parar a limpeza, utilize o gestor de serviços ou o supervisor de processos no anfitrião proprietário, aguarde o encerramento e confirme que a lista de bloqueios foi alterada antes de reiniciar a cópia de segurança.

A retenção pode ter um âmbito por anfitrião, mas a recuperação física de espaço continua a ser uma operação do repositório. Uma política de retenção com âmbito por anfitrião impede que sejam selecionados os instantâneos errados; não torna segura a execução simultânea da limpeza para clientes de cópia de segurança não relacionados.

Repita a cópia de segurança em espera com o bloqueio normal. Se for concluída, a correção corresponde à causa confirmada. Se outra limpeza começar imediatamente, desative o agendamento de manutenção duplicado. Se a cópia de segurança continuar bloqueada sem um bloqueio exclusivo, deixe de aumentar o número de tentativas e retome o diagnóstico do backend, da rede, da análise da origem ou do processo.

-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 sobreposição original e defina o limite

Utilize uma janela controlada com registos completos. Inicie uma cópia de segurança normal, invoque depois o controlador de manutenção planeado e confirme que este não cria uma sobreposição insegura. Repita pela ordem prevista, começando pela limpeza, e verifique se a cópia de segurança aguarda ou termina de acordo com a política configurada; em seguida, confirme que é concluída depois de o bloqueio ser libertado.

Se uma limpeza interrompida deixar o repositório num estado operacional diferente, siga o diagnóstico de limpeza interrompida, em vez de tratar todas as falhas posteriores como simples contenção.

A recuperação é bem-sucedida quando a sobreposição original é tratada de forma previsível, a cópia de segurança é posteriormente concluída, a limpeza termina corretamente e um instantâneo de amostra continua a ser restaurável. Escale o problema se o bloqueio nunca for atualizado ou libertado, se vários anfitriões continuarem a iniciar a manutenção ou se uma verificação do repositório comunicar danos. Esses resultados ultrapassam a causa única de uma limpeza em execução.