Guia de migração do Borg Backup para mover um repositório para um novo armazenamento

A abordagem segura consiste em tratar a pausa dos processos de escrita, a cópia ou transferência pelo método adequado à versão, a verificação do destino e a mudança com possibilidade de reversão como uma sequência de etapas observáveis, e não como um único comando.

Num repositório BorgBackup em armazenamento local, NAS ou acessível por SSH, o risco prático é ter de mover um repositório Borg sem criar uma cópia dividida ou silenciosamente incompleta. Registe a identidade atual e o ponto de recuperação, comece pelo indicador menos invasivo, interprete os resultados aprovados e reprovados antes de alterar outra variável e pare quando o armazenamento se tornar instável ou quando a única cópia recuperável ficar exposta. O fluxo de trabalho abaixo só termina depois de a carga de trabalho original funcionar ou de as evidências atingirem um limite de escalada.

Registe o contrato do repositório antes de copiar

Guarde a versão do Borg, o URL do repositório, o ID do repositório, o modo de encriptação, a localização da chave, o processo de recuperação da frase-passe, a lista de arquivos, o tamanho, o espaço livre, as definições de apenas acrescentar e todos os clientes ou trabalhos de automatização que possam escrever. O repositório não pode ser recuperado apenas a partir de uma cache local e os repositórios encriptados podem depender de material de chave armazenado fora do destino.

O artigo da ZimaSpace sobre um guia de recuperação de uma cache Borg perdida separa o estado da cache, que pode ser reconstruído, de chaves em falta ou danos no repositório. Faça essa verificação antes da migração para que um problema de chave não seja descoberto apenas depois de o armazenamento antigo desaparecer.

Decida se se trata da relocalização, byte a byte, do mesmo repositório ou de uma transferência para um repositório recém-inicializado. A versão e o formato do Borg determinam quais os métodos disponíveis; não misture exemplos de comandos do Borg 1 e do Borg 2 nem parta do princípio de que a identidade do repositório deve mudar.

Pause os processos de escrita e crie um ponto de origem consistente

Desative temporizadores, trabalhos cron, contentores e clientes remotos e confirme que não existe nenhum processo Borg ou bloqueio do repositório ativo. Execute borg list e um borg check adequado antes de copiar. Se a origem falhar a verificação, preserve-a e diagnostique essa condição, em vez de clonar a incerteza para o destino.

Uma discussão no Super User salienta o risco de copiar um repositório ativo com rsync enquanto um repositório Borg desduplicado sofre alterações. A regra segura é copiar um repositório em pausa ou utilizar um snapshot do sistema de ficheiros criado depois de todos os processos de escrita do Borg pararem, para que índices, segmentos, estado de nonce e dados pertençam ao mesmo ponto.

Mantenha os agendamentos de cópias de segurança desativados até a validação do destino terminar. Se o tempo de inatividade for demasiado longo, faça uma cópia inicial enquanto o repositório estiver inativo, pare os processos de escrita e execute uma sincronização final; nunca permita que a origem e o destino aceitem cópias de segurança independentes durante a mudança.

Copie utilizando o método suportado pela sua versão do Borg

Para uma relocalização do mesmo repositório, preserve todos os ficheiros, permissões, comportamento de ficheiros esparsos e propriedade com uma ferramenta de cópia local ou remota adequada e analise o respetivo registo de erros. Copie a raiz do repositório como uma unidade, e não arquivos selecionados ou diretórios de dados aparentemente grandes. Mantenha a origem intacta depois da sincronização final.

Para um repositório novo ou uma migração de formato, utilize a capacidade de transferência apenas quando for suportada pelas versões instaladas do Borg e pelo plano de encriptação. Uma resposta no Server Fault descreve a transferência de repositórios Borg como a direção de repositório para repositório associada ao Borg 2, que não é intercambiável com uma cópia do sistema de ficheiros do Borg 1.

Depois de copiar, monte ou disponibilize inicialmente o destino aos clientes em modo apenas de leitura. Se o ID do repositório, o acesso à chave, as permissões ou o formato forem inesperados, pare e corrija o destino; não “inicialize” sobre dados copiados nem execute uma reparação para forçar o reconhecimento.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Verifique os arquivos, mude os clientes e mantenha a reversão

Execute borg list, borg info e as verificações adequadas do repositório e dos arquivos no destino. Extraia ficheiros de teste de um arquivo recente e de um arquivo mais antigo para um diretório separado e compare o conteúdo, os metadados e as permissões. Teste com o mesmo binário do Borg e o mesmo caminho remoto que a automatização utilizará.

Atualize um cliente para o novo URL, limpe ou reconstrua apenas o estado da cache que o Borg identifique como necessário e crie um pequeno arquivo de teste. Restaure a partir desse arquivo e confirme que o agendamento de limpeza ou compactação continua desativado até todos os clientes utilizarem a nova localização.

A mudança é bem-sucedida quando o inventário de arquivos coincide, as verificações são aprovadas, duas restaurações são utilizáveis e uma nova cópia de segurança é concluída depois de reiniciar ou reiniciar o agendador. Mantenha a origem em modo apenas de leitura durante pelo menos um ciclo normal; elimine-a apenas depois de expirar o período de reversão ou escale o problema se as verificações divergirem entre a origem e o destino.