O Restic ou o Borg podem parecer esquecer um repositório quando o caminho configurado aponta agora para um diretório vazio, outro sistema de ficheiros ou uma identidade de repositório transferida.
Os dados do repositório podem continuar intactos no disco de cópias de segurança, mas a tarefa pode abrir o diretório de montagem vazio antes de o disco estar disponível, utilizar um caminho de contentor alterado, ler uma variável de ambiente desatualizada ou recusar um repositório Borg cujo ID aparece numa nova localização. Diagnostique a origem montada e a identidade do repositório antes de inicializar qualquer coisa. Executar um comando de inicialização no caminho vazio errado pode criar um segundo repositório e ocultar a falha original.
Confirme o que está montado no caminho configurado do repositório
Registe o caminho do repositório utilizado pela tarefa agendada e compare o caminho antes e depois de o disco de cópias de segurança ser montado. Registe a origem do sistema de ficheiros, o UUID, o ponto de montagem e a capacidade disponível.
O utilitário findmnt do Linux resolve a montagem ativa por trás de um caminho de destino, sendo por isso a primeira verificação correta quando um diretório familiar pode ser, na realidade, a pasta anfitriã não montada.
Se o caminho pertencer ao sistema de ficheiros raiz em vez do disco de cópias de segurança, pare o serviço de cópias de segurança antes de este gravar um novo repositório ou conjunto de cópias nesse diretório vazio.
Verifique a localização exata do repositório Restic
Compare o caminho indicado com -r, --repository-file ou RESTIC_REPOSITORY com o ponto de montagem atual. Verifique os scripts de encapsulamento, os campos do NAS, os ficheiros de credenciais e os ambientes das tarefas agendadas.
O Restic define um repositório local como um diretório específico que contém a configuração, os dados, o índice, as chaves, os bloqueios e os instantâneos. Por isso, alterar o ponto de montagem altera a localização que o comando tenta abrir.
Não execute restic init apenas porque o novo caminho indica que não existe nenhum repositório. Primeiro, localize os diretórios de configuração e de dados do repositório original no disco montado.
Trate deliberadamente o aviso de repositório transferido do Borg
Registe o URL do repositório Borg, o ID do repositório, a localização anterior, a localização atual, o caminho da cache e o diretório de segurança. Confirme que o mesmo repositório foi transferido intencionalmente.
A FAQ do Borg explica que este solicita aprovação após a transferência de um repositório, porque o mesmo ID de repositório num novo caminho também pode indicar uma substituição insegura.
Aprove a transferência apenas depois de comparar o ID do repositório e o conteúdo do armazenamento. Não suprima o aviso globalmente quando vários repositórios amovíveis podem estar ligados através de caminhos variáveis.
Substitua caminhos dependentes da ordem dos dispositivos pela identidade persistente do armazenamento
Verifique se a configuração da montagem faz referência a /dev/sdX, a uma etiqueta duplicada, ao UUID do sistema de ficheiros, ao UUID da partição ou a um ID de dispositivo. Compare todos os discos alternados para detetar identificadores duplicados.
A ArchWiki salienta que os UUID reduzem as colisões de nomes em comparação com etiquetas e nomes de dispositivos atribuídos pelo kernel, que podem mudar consoante a ordem de deteção.
Um identificador estável tem de continuar a apontar para o diretório de montagem fixo pretendido. O UUID impede alterações causadas pela ordem dos discos, mas não atualiza uma tarefa de cópia de segurança que ainda contenha o caminho anterior.
Verifique a tradução dos caminhos dos contentores e das montagens bind
Num Restic, Borg ou interface de cópias de segurança executado num contentor, compare o ponto de montagem do anfitrião com a origem da montagem bind e com o caminho do repositório dentro do contentor. Inspecione o contentor em execução, em vez de consultar apenas o ficheiro compose guardado.
A documentação do Docker explica que as montagens bind dependem do caminho exato do anfitrião. Assim, mover um disco de /mnt/backup-a para /media/backup-a pode deixar o contentor associado a um diretório vazio.
Mantenha o caminho de hardware estável no anfitrião e disponibilize um único caminho estável no contentor. Não guarde diretamente na configuração do repositório caminhos de suportes amovíveis específicos do anfitrião quando estiver disponível uma associação fixa.
Faça o serviço de cópias de segurança aguardar pela montagem
Compare os carimbos temporais do arranque e do serviço. Confirme que a montagem terminou antes de o agendador de cópias de segurança, o contentor, a interface do repositório ou a tarefa de manutenção tentar aceder ao sistema.
As orientações da Red Hat para montagens persistentes recomendam definir uma montagem fixa no fstab, que pode depois ser associada a dependências do serviço e a uma validação antes do arranque.
Uma opção de arranque nofail pode ser adequada para um disco de cópias de segurança amovível, mas o serviço de cópias de segurança deve continuar a recusar o arranque quando o sistema de ficheiros necessário não estiver disponível.
Volte a ligar o repositório existente antes de executar uma cópia de segurança
Pare as tarefas agendadas, monte o sistema de ficheiros pretendido no caminho fixo, verifique a estrutura do repositório, abra-o em modo só de leitura ou liste os instantâneos e execute uma pequena verificação do repositório antes de ativar as gravações.
O artigo da ZimaSpace sobre caminhos de aplicações estáveis baseados em UUID aborda a cadeia geral de montagem; este artigo centra-se na identidade do repositório e na segurança das ferramentas de cópias de segurança depois de os caminhos serem alterados.
O problema está resolvido quando o mesmo ID do repositório e o histórico de instantâneos são abertos no caminho pretendido após testes repetidos de reinício e rotação de discos, sem criar um novo repositório no diretório de montagem vazio.
Perguntas frequentes
É possível mover um repositório Restic para outro ponto de montagem?
Sim, desde que o repositório completo seja movido intacto e todas as tarefas passem a referenciar a nova localização. O Restic identifica o repositório através do caminho ou do backend fornecido ao comando.
Porque é que o Borg avisa quando os dados do repositório não foram alterados?
O Borg regista a identidade e a localização anterior do repositório como medida de segurança. A apresentação do mesmo ID noutro caminho requer aprovação deliberada.
Devo inicializar um repositório no novo caminho?
Não, até provar que o repositório antigo não está disponível. Inicializar um ponto de montagem vazio cria um repositório separado, em vez de voltar a ligar o original.
Suporte e Dicas
Mais para Ler

Por que motivo o restauro de um volume Docker recria o conteúdo dos ficheiros, mas elimina os atributos estendidos?
Um diagnóstico da restauração de volumes que abrange o inventário de xattr, as opções do tar e do Rsync, os namespaces, o suporte do...

Porque é que um contentor em execução mantém o limite de memória antigo depois de o ficheiro Compose ser alterado?
Um diagnóstico dos limites de memória que abrange cgroups ativos, reinício versus recriação, campos do Compose, limites rígidos e flexíveis, âmbitos superiores, swap e...

Porque é que reiniciar um proxy reverso invalida todas as sessões de uma aplicação auto-hospedada?
Um diagnóstico da perda de sessão que abrange o âmbito do reinício, a propriedade dos cookies, a rotação de segredos, as sessões suportadas por...

