Como agendar tarefas do Restic para criar cópias de segurança, esquecer e eliminar sem conflitos de bloqueio

Programe as cópias de segurança com frequência, aplique o forget através de um único controlador do repositório e execute o prune com menos frequência dentro de uma janela de manutenção exclusiva. Não permita que cada anfitrião seja responsável pelas três tarefas.

Um repositório partilhado num servidor doméstico precisa de dois tipos de agendamento: pontos de recuperação por anfitrião e manutenção ao nível de todo o repositório. Crie o agendamento com base em durações medidas e objetivos de recuperação, não em exemplos fixos da Internet. Centralize a retenção e o prune, agrupe corretamente os snapshots, ordene explicitamente as unidades e defina uma nova tentativa e um alerta para cada tarefa ignorada. O agendamento só fica concluído depois de dois ciclos e de um restauro de exemplo demonstrarem que a retenção e o bloqueio funcionam como previsto.

Faça o inventário de todas as tarefas, responsáveis e durações normais máximas

Crie uma tabela para cada operação que interage com o repositório: backup, forget, prune, check, unlock, listagem de snapshots e teste de restauro. Registe o anfitrião que inicia a operação, o comando ou wrapper, a credencial, a duração normal e a maior duração recente, o tempo limite, a regra de novas tentativas e o destino do alerta. Inclua as tarefas ocultas em aplicações de backup ou interfaces NAS.

Um repositório partilhado precisa de manutenção ao nível do repositório, e não de uma cópia por cliente. As boas práticas do Restic para vários anfitriões atribuem forget, prune e check uma única vez por repositório, agrupando a retenção para os anfitriões e caminhos relevantes.

Consolide as tarefas de manutenção duplicadas num único controlador. Mantenha a responsabilidade pelas cópias de segurança por anfitrião quando isso facilitar o acesso às origens, mas faça com que cada anfitrião comunique ao controlador o estado de início e de conclusão. Se uma tarefa não tiver uma duração medida ou um responsável, observe-a antes de definir uma janela de manutenção à sua volta.

Defina primeiro a cadência das cópias de segurança e depois delimite o forget

Escolha a cadência de backup de cada anfitrião com base na quantidade de alterações que pode aceitar perder e no tempo que uma cópia de segurança demora normalmente. Distribua os grandes scans das origens se estes competirem pela rede ou pelo armazenamento, mas não distribua tarefas apenas para tornar um gráfico mais organizado. Deixe que a cópia de segurança normal mais longa determine o início mais cedo da manutenção.

Execute o forget a partir do controlador do repositório e pré-visualize a sua seleção utilizando o agrupamento pretendido de anfitrião, caminho e etiqueta. Um agrupamento inesperado por calendário pode fazer com que a retenção elimine mais pontos de restauro do que uma simples leitura da quantidade a manter faria supor.

Mantenha o forget logicamente separado do prune físico durante a conceção do agendamento. A política de retenção pré-visualizada pode ser executada após uma cópia de segurança bem-sucedida ou numa fase própria do controlador, enquanto o prune dispõe de uma janela exclusiva mais longa. Não associe o prune à cópia de segurança de cada anfitrião apenas porque é possível combinar os dois comandos.

Coloque o prune e o check em janelas ao nível de todo o repositório

Execute o prune com menos frequência do que o backup e, normalmente, também com menos frequência do que o forget, porque a limpeza física do repositório pode demorar muito mais tempo e bloquear outro trabalho. Coloque-o depois de todas as cópias de segurança previstas e de concluída a seleção de retenção. Dê ao check uma fase ou janela própria, com base no tamanho do repositório e na velocidade do backend.

Uma configuração do Restic com systemd pode manter o backup e o pruning em serviços separados, permitindo que o agendador observe os respetivos estados de saída em vez de iniciar um único comando opaco.

Se o prune ultrapassar regularmente a janela, não permita que as cópias de segurança se acumulem silenciosamente. Reduza a frequência do prune, alargue a janela, investigue o débito do backend ou divida os repositórios quando as suas necessidades operacionais já não forem compatíveis. A entrada exige que não exista nenhuma cópia de segurança ativa; a saída exige um estado de manutenção limpo e a libertação do bloqueio do repositório.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

Defina dependências, novas tentativas e alertas

Defina a ordem pretendida em vez de depender de intervalos entre horas: as unidades de backup comunicam a conclusão, o forget só é executado depois das cópias de segurança necessárias, o prune só é executado depois de o repositório entrar na sua janela exclusiva e o check segue a política de manutenção escolhida. Utilize uma barreira externa partilhada que todas as unidades relevantes respeitem.

Os targets do systemd podem expressar que as dependências entre o backup e a manutenção têm de ser concluídas por ordem, em vez de simplesmente começarem a horas diferentes.

Defina novas tentativas limitadas para conflitos de bloqueio e falhas de rede e envie um alerta quando o prazo não for cumprido. Uma cópia de segurança atrasada deve adiar o prune; um prune que ultrapasse o tempo deve adiar a cópia de segurança seguinte e notificar o operador. O desbloqueio forçado e as opções sem bloqueio não são políticas de novas tentativas.

Verifique dois ciclos completos e um restauro

Observe dois ciclos completos em vez de declarar sucesso assim que os ficheiros dos temporizadores forem carregados. Confirme que cada origem produz o snapshot esperado, que o forget mantém os grupos pretendidos, que o prune só é executado na sua janela, que os bloqueios são eliminados após saídas limpas e que os alertas registam qualquer atraso.

Restaure ficheiros a partir de um snapshot que tenha sobrevivido à sequência de retenção e prune, e não apenas a partir do backup mais recente. Isto prova que o agendamento completo preserva um ponto de recuperação utilizável, em vez de apenas produzir estados de tarefa positivos.

O agendamento é aprovado quando dois ciclos são concluídos pela ordem correta, nenhuma tarefa desaparece silenciosamente, os snapshots mantidos correspondem à pré-visualização e o restauro de exemplo está correto. Reverta a automatização da manutenção, mantendo os backups normais, se a retenção eliminar o grupo errado, se o prune não conseguir terminar de forma fiável ou se os conflitos de bloqueio se repetirem. Ajuste a cadência com base nos resultados medidos, não desativando a proteção do repositório.