Como impedir que as tarefas de limpeza do Restic bloqueiem as cópias de segurança agendadas

Evite conflitos do prune ao atribuir um único responsável pela manutenção a cada repositório e ao reservar um período durante o qual nenhum cliente de cópia de segurança possa iniciar novos trabalhos.

Num repositório partilhado de um servidor doméstico, a falha costuma começar antes do erro de bloqueio: vários anfitriões são responsáveis por agendas de manutenção, uma cópia de segurança demora mais do que o esperado e o prune começa sem uma barreira aplicável a todo o repositório. Inverta essa sequência. Centralize o prune, reserve tempo suficiente, serialize os trabalhos fora do Restic e crie alertas para execuções ignoradas ou atrasadas. Se já existir um conflito, impeça novos trabalhos e use o procedimento mínimo de recuperação em vez de enfraquecer o bloqueio.

Atribua um Único Responsável pela Manutenção a Cada Repositório

Procure em todos os clientes e serviços do lado do repositório comandos de manutenção do Restic. Registe quem é responsável por forget, prune, check, unlock e pelos alertas. Desative agendas de prune duplicadas e mantenha um único controlador com as credenciais do repositório e a visibilidade necessárias para ver todos os clientes.

É possível coordenar várias cópias de segurança em torno de um único repositório, mas remover todos os bloqueios antes do prune elimina a barreira de segurança e pode criar a sobreposição insegura que a agenda pretendia evitar.

A verificação de responsabilidade é bem-sucedida quando apenas um anfitrião pode iniciar a manutenção de todo o repositório e todos os clientes de cópia de segurança sabem onde são comunicadas as falhas. Se um dispositivo ou wrapper de cópia de segurança puder iniciar manutenção oculta, desative essa opção automática ou inclua-a no mesmo controlador antes de prosseguir.

Reserve um Período de Prune Superior à Execução Normal Mais Longa

Use os registos recentes para encontrar a cópia de segurança normal mais longa, o prune recente mais longo, os atrasos na ativação dos clientes e a fila de novas tentativas. Agende o prune depois da conclusão esperada da cópia de segurança mais tardia e deixe tempo para a sua própria duração normal máxima. Não escolha a meia-noite apenas porque parece tranquila num anfitrião.

Um plano de retenção também deve limitar os instantâneos por anfitrião ou etiqueta, para que a retenção em vários anfitriões não selecione os instantâneos errados enquanto o repositório está sob a responsabilidade de um único responsável pela manutenção.

Se as cópias de segurança ultrapassarem frequentemente o limite proposto, altere o horário do prune em vez de encurtar o período da cópia de segurança. Se a duração do prune crescer para além do intervalo disponível, reduza a frequência da recuperação física de espaço, investigue o débito do backend ou use um período maior. A prevenção falha quando a agenda depende de todos os trabalhos terminarem sempre no seu tempo médio.

Imponha Exclusão Mútua e uma Política de Novas Tentativas Visível

Use um único método externo de serialização que todos os trabalhos locais respeitem: ordenação de unidades systemd, um wrapper de bloqueio partilhado ou uma fila controlada pelo anfitrião de manutenção. O wrapper deve recusar ou atrasar o trabalho posterior, preservar o bloqueio do próprio Restic e escrever um estado claro que permita ao sistema de monitorização gerar alertas.

Uma agenda do Restic baseada em systemd pode separar os serviços recorrentes de cópia de segurança e de prune, mantendo visíveis a ordenação, o estado de saída e os registos.

Defina um intervalo limitado para novas tentativas e um atraso máximo. Uma cópia de segurança bloqueada pela manutenção deve tentar novamente depois do período, não desaparecer até ao dia seguinte; um prune bloqueado por uma cópia de segurança atrasada deve gerar um alerta e passar para o próximo período aprovado. Nunca transforme o desbloqueio automático forçado na ação de nova tentativa.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

Teste a Política de Prevenção e Mantenha uma Reversão Mínima

Teste ambas as ordens num repositório descartável ou num conjunto de dados de exemplo: inicie primeiro a cópia de segurança e solicite o prune; depois, inicie primeiro o prune e solicite a cópia de segurança. Em cada caso, um dos trabalhos deve aguardar ou terminar de forma visível, o controlador deve tentar novamente de acordo com a política configurada e nenhum bloqueio deve ser removido enquanto houver um processo ativo.

Após a implementação, analise os registos da próxima cópia de segurança, operação forget e prune normais. Se o repositório ficar apenas de leitura após a manutenção, use o procedimento separado de recuperação após um prune interrompido em vez de flexibilizar a barreira de prevenção.

A política é validada quando dois ciclos terminam sem sobreposição, os trabalhos atrasados tentam novamente de forma visível, os alertas são acionados para períodos falhados e uma restauração de teste continua válida. Se falhar, desative primeiro a automatização do prune e mantenha as cópias de segurança normais a funcionar com o bloqueio habitual. Escale o problema quando não existir nenhum período de manutenção compatível com a carga de trabalho medida ou quando o backend não conseguir concluir o prune de forma fiável.