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
...
