Vida útil e eficiência de backup completo da Duplicity

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

É razoável querer um backup completo de vez em quando? Como a duplicidade aumenta, cada backup incremental depende do incremento anterior e todos dependem muito do último backup completo. Caso isso se torne corrupto, coisas ruins acontecem. Uma pergunta relacionada: o Duplicity testa os backups incrementais quanto à consistência?

Supondo que eu não quero um backup completo a cada tantas vezes, a eficiência com que a duplicidade criar esse backup completo? Ele pode / verifica assinaturas de arquivos e copia dados inalterados de backups / incrementos completos anteriores? Criando basicamente um novo arquivo 'completo', transferindo dados novos / alterados e mesclando os dados inalterados existentes?

No momento, minha preocupação é que seja necessário executar um backup completo, mas o uso consistente e amplo de largura de banda dos backups completos tornará isso irracional para alguns clientes.

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

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

Não acho que a duplicidade tenha especificamente um comando "check" http://pad.lv/660895 , mas seria bom se tivesse. É muito prudente fazer uma restauração de teste de vez em quando.

Uma questão relacionada é se você deve manter mais de uma cadeia de backup. Novamente, isso depende do custo. Um motivo para manter um é que você pode restaurá-lo se a cadeia atual estiver corrompida, devido a uma falha de hardware, falha do SO ou um erro de duplicidade. Obviamente, se a cadeia antiga for muito antiga, a restauração a partir dela poderá ser de valor limitado.

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

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

O que você está pedindo é chamado de backup completo sintético , que se refere ao 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).

Não conheço o Duplicity, mas, no site deles , parece não fazer backups sintéticos completos. Você deve manter todos os incrementais de volta ao máximo em que se baseiam. Se esse é o caso, você provavelmente vai querer forçar um backup completo a cada tantas vezes, porque:

• Passar por um milhão de incrementos provavelmente tornará as restaurações lentas
• Você provavelmente não deseja manter os incrementais voltando ao início dos tempos

Uma maneira interessante de obter totais sintéticos é usar o rsync com a opção --link-dest = DIR ou usar o rsnapshot . Ele armazenará apenas as diferenças entre cada backup incremental, mas cada um parecerá estar cheio. Quando você exclui qualquer um deles, ele mescla automaticamente os incrementais adequadamente. Isso é feito através da magia de links físicos, de modo que os diffs sejam baseados em arquivos (o arquivo foi alterado e está incluído no diff, ou não).