Deduplicación a Nivel de Archivos

La razón principal para usar la deduplicación a nivel de archivos (Community y Enterprise) sería si tuviera exactamente los mismos archivos entre varias máquinas diferentes. Este puede ser el caso si sus sistemas operativos o aplicaiones son exactamente iguales y están actualizados a la misma versión. También se recomienda si no puede utilizar otro tipo de deduplicación de bloques por algún motivo (por ejemplo, Deduplicación Global de Bacula Enterpise, incluyendo cintas magnéticas o almacenamiento en nube).

Esta deduplicación funciona de la siguiente manera: debe realizar un backup histórico (especial) que tenga un nivel específico dentro de Bacula: Base Job (siempre una especie de Full), que también debe realizarse en un Pool diferente. Todas las copias de seguridad del cliente Bacula que están configuradas para comparar su contenido con las del trabajo base no repiten la copia de los mismos archivos que ya fueron copiados por el trabajo Base.

Si la deduplicación está configurada correctamente, puede ver en el registro del log de jobs la proporción de archivos que no se hice backup porque se copiaron en el Base Job correspondiente.

En teoría, podría configurar un backup de Base de una máquina y comparar solo sus backups futuros con su Base. El efecto práctico de esto es que, incluso si envía un trabajo de backup Full, Bacula solo copiará los archivos que se hayan modificado desde que finalizó el último trabajo de nivel Base. Sería básicamente el mismo comportamiento que realizar un backup Full y luego un diferencial/ incremental. Por lo tanto, no existe una clara ventaja de utilizar la deduplicación para una sola máquina específica.

1. 1. 1. Configurando la Deduplicación de Bacula:

a) Agregue en bacula-dir.conf las siguientes directivas a los trabajos que pueden tener los archivos similares a Base Job y que, por lo tanto, se deduplicarán:

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

La directiva Base le dice a Bacula el universo de tareas de backup regulares y base que se compararán y no repetirán la copia de archivos similares. En el ejemplo correcto, el trabajo BackupHeitor se compara con las ocurrencias de sí mismo que se ejecutarán utilizando el nivel Base. La directiva Accurate = yes también es obligatoria.

b) No abandones bacula-dir.conf todavía. También debe realizar algunos cambios en su FileSet del backup regular original:

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

Cada una de estas opciones necesarias establece diferentes comportamientos para la forma en que Bacula busca y compara archivos entre Jobs de backup Base y regulares. Son los mismos soportados para Verify Job (job de verificación) de Bacula.

c) Agregue al menos un nuevo Pool y Schedule para tareas de backup base. Considere usar un valor significativo de VolumeRetention que no sea menor que los backups regulares; de lo contrario, podría perder la capacidad de realizar una restauración completa de algunos Jobs Full si el trabajo Base al que hacen referencia ya está 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) Realice un Job Base y mas tarde el Job de backup regular (por ejemplo, Full), que debe ser ahora deduplicado. Puede notar que aparecerá información similar en el resumen de log del 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ês (Portugués, Brasil)English (Inglés)Español