Deduplicação em Nível de Arquivos

A principal razão para usar a deduplicação em nível de arquivos (Community e Enterprise) seria se você tivesse exatamente os mesmos arquivos entre várias máquinas diferentes. Este pode ser o caso se seus sistemas operacionais e aplicações são exatamente os mesmos e atualizados para a mesma versão. Também é apenas recomendável se você não pode usar outro tipo de deduplicação de blocos por qualquer motivo (por exemplo: Deduplicação Global, para fitas magnéticas ou armazenamento em nuvem do Bacula Enterprise).

Essa deduplicação funciona da seguinte maneira: você deve executar um backup marco (especial) que tenha um nível específico dentro do Bacula: Base Job (sempre uma espécie de Full), que deve ser executado também em uma Pool diferente. Todas as cópias de segurança do cliente do Bacula que estão configuradas para comparar o seu conteúdo com as do trabalho base não repetem a cópia dos mesmos arquivos que já foram copiados pelo trabalho de Base.

Se a deduplicação estiver configurada corretamente, você poderá ver no registro do log dos jobs a proporção de arquivos que não foram backupeados porque foram copiados no Base Job correspondente.

Em teoria, você poderia configurar um backup de Base de uma máquina e comparar apenas seus backups futuros com sua Base. O efeito prático disso é que, mesmo que você envie um trabalho de backup Full, o Bacula somente copiará os arquivos que foram alterados desde a última terminação do trabalho nível Base. Seria basicamente o mesmo comportamento de executar um backup Full e, em seguida, um diferencial/incremental. Portanto, não há uma vantagem clara de usar a deduplicação para uma única máquina específica.

Configurando a Deduplicação do Bacula:

a) Adicione no bacula-dir.conf as seguintes diretivas aos trabalhos que podem ter os arquivos similares ao Base Job e que por isso serão deduplicados:

Job {
  Name = BackupHeitor
  Base = BackupHeitor
  Accurate = yes 
  Schedule = base_schedule
  FileSet = debian_7_set
  ...
}

A diretiva Base diz ao Bacula o universo de tarefas de backup regulares e base que serão comparados e não repetir a cópia de arquivos semelhantes. No exemplo correto, o trabalho do BackupHeitor está se comparando com as ocorrências dele mesmo que serão executadas utilizando o level Base. A diretiva Accurate = yes também é obrigatória.

b) Não deixe o bacula-dir.conf ainda. Você também deve fazer algumas alterações em seu FileSet do backup regular original:

FileSet { 
  Name = debian_7_set
  Include {
    Options {
     	  BaseJob = pmugcs5 
     	  Accurate = mcs5 
     	  Verify = pin5
    }
    File = /etc
    File = /var
    File = /opt
  }
  ...

Cada uma dessas opções necessárias estabelece comportamentos diferentes para a forma como o Bacula procura e compara arquivos entre Jobs de backup Base e regulares. Eles são os mesmos suportados para o Verify Job (job de verificação) do Bacula.

c) Adicione ao menos uma nova Pool e Schedule para as tarefas de backup base. Considere usar um valor para VolumeRetention significativo que não seja menor do que os backups regulares; caso contrário, você poderia perder a capacidade de executar a restauração completa de alguns Jobs Full se o trabalho Base a que eles se referem já estiver reciclado.

Pool {
  Name = Base-Pool
  Pool Type = Backup
  Volume Use Duration = 18 hours
  Volume Retention = 364 days
  ...
}
Schedule {
  Name = base_schedule
  Run = Base Pool=Base-Pool 1st sunday at 12:00
}

d) Realize um Job no nível Base e, em seguida, a tarefa de backup regular (ex. Full), que já deverá ser deduplicado. Você pode notar que informações semelhantes aparecerão no resumo do log do Job:

...
Rate: 2425.4 KB/s 
Software Compression: 39.7 % 
Base files/Used files: 39336/39114 (99.44%) 
VSS: yes 
Encryption: no
...

Disponível em: PortuguêsEnglish (Inglês)Español (Espanhol)