Vida útil e eficiência de backup total de duplicidade

Question

Estou tentando desenvolver uma estratégia de backup para alguns clientes e estou inclinado à duplicidade para backup remoto (já uso o rdiff-backup para backups internos / no local).

É razoável querer um backup completo de tempos em tempos? Como os incrementos de duplicidade são encaminhados, cada backup incremental está contando com o incremento anterior e todos dependem muito do último backup completo. Se isso se tornar corrupto, coisas ruins acontecem. Uma questão relacionada: O Duplicity testa os backups incrementais para consistência?

Assumindo que eu faça deseja um backup completo de vez em quando, a eficiência da duplicidade cria esse backup completo? Pode verificar assinaturas de arquivos e copiar dados inalterados de anteriores backups / incrementos completos? Basicamente, criar um novo arquivo 'completo' transferindo dados novos / alterados e mesclando dados inalterados existentes?

Neste momento, minha preocupação é que a execução de um backup completo seja necessária, mas o uso consistente de largura de banda grande de backups completos tornará isso irracional para alguns clientes.

    

Answer 1

Eu acho razoável querer um backup completo de vez em quando: a maioria das minhas máquinas está configurada para fazer uma a cada poucos meses. Não há nada de mágico nesse número: o valor correto dependerá da quantidade de dados que você tem, da velocidade de alteração, da probabilidade de restaurar de outra forma que não seja o instantâneo mais recente, quanto tráfego e armazenamento custa e como você é paranóico. Outras pessoas podem querer um backup completo toda semana.

A menos que você faça um backup completo de tempos em tempos, o tamanho do arquivo e o tempo de recuperação continuarão aumentando.

Eu não acho que a duplicidade tenha especificamente um link no comando "verificar", mas seria bom se o fizesse. É muito prudente fazer um teste de restauração de vez em quando.

Uma questão relacionada é se você deve manter mais de uma cadeia de backup. Mais uma vez, depende do custo. Um motivo para manter um é que você pode restaurar a partir dele se a corrente atual estiver corrompida, seja por causa de falha de hardware, falha do sistema operacional ou um erro de duplicidade. É claro que se a cadeia antiga é muito antiga, a restauração dela pode ter valor limitado.

Fazer um backup completo sempre carrega uma cópia completa dos dados.

Se a preocupação do cliente for a fração de largura de banda usada, em vez de cobranças de tráfego, convém executá-la, por exemplo, em trickle .

    

Answer 2

O que você está pedindo é chamado de backup completo sintético , que se refere à processo de obter um backup completo mesclando um backup incremental com um backup completo anterior no lado do destino (ou seja, o servidor de backup).

Eu não estou familiarizado com o Duplicity, mas pelo site ele parece não fazer backups completos sintéticos. Você deve manter todos os incrementais de volta ao total em que eles estão baseados. Se esse for o caso, você provavelmente desejará forçar um backup completo de vez em quando, porque:

• Passar por um milhão de incrementos provavelmente fará com que as restaurações sejam lentas
• Você provavelmente não quer manter os incrementais voltando para o começo do tempo

Uma maneira interessante de obter anúncios sintéticos é usar o rsync com a opção --link-dest = DIR , ou use rsnapshot . Ele armazenará apenas as diferenças entre cada backup incremental, mas cada um parecerá cheio. Quando você exclui qualquer deles, ele automaticamente mesclará os incrementos apropriadamente. Ele faz isso através da magia dos hard links, então os diffs serão baseados em arquivos (ou o arquivo foi alterado e está incluído no diff, ou não).