Esta Guía Rápida proporciona los pasos necesarios para implementar la Dededución global y de Almacenamiento con Bacula Enterprise.
Como organizaciones de TI están constantemente siendo desafiadas a proporcionar soluciones de alta calidad con un costo total de propiedad reducido. Uno de estos desafíos es la cantidad creciente de datos de copia de seguridad, junto con el tiempo limitado para realizar tareas de copia de seguridad (ventana de copia de seguridad). Bacula Enterprise ofrece varias maneras de enfrentar estos desafíos, siendo uno de ellos la deduplicación global Endpoint, que minimiza una transferencia de red y el tamaño del volumen Bacula usando tecnología de deduplicación.
Una deduplicación puede reducir significativamente el espacio en disco necesario para almacenar sus datos. En los mejores casos, dependiendo de la deduplicabilidad de los datos de respaldo, esto puede reducir el espacio en disco necesario en un 99%.
El Plugin Bacula ya compacta los datos después de la deduplicación, por lo que debe evitar la copia de seguridad de datos comprimidos, lo que generalmente rinde una baja tasa de deduplicación.
La deduplicación puede reducir significativamente el ancho de banda de red necesario, ya que ambos extremos pueden intercambiar referencias en lugar de los datos reales en sí. Funciona cuando el destino ya tiene una copia de los bloques originales. La deduplicación funciona para copias de seguridad, pero también al realizar una restauración.
Manipular referencias en lugar de datos puede acelerar la mayor parte del procesamiento dentro del Daemon de Almacenamiento. Por ejemplo, los recursos de Bacula como Copia/Migración y Virtual Full pueden ser hasta 1.000 veces más rápidos.
Recomendaciones
Para realizar una deduplicación eficiente y rápida, el Storage Daemon necesitará de energía adicional de la CPU (para computar códigos hash y compactación), además de RAM adicional (para consultas rápidas de código hash).
Para un rendimiento eficaz, el índice de deduplicación se debe almacenar en SSD, ya que el índice tendrá muchos accesos aleatorios y muchas actualizaciones. Normalmente, se necesitan 10 GB de 1 TB de copias de seguridad.
Para el almacenamiento con deduplicación, prefiera sistemas de archivos que comprueban bloques como ZFS y utilizando la tecnología RAID de hardware. Si no es capaz de usar ZFS, se recomienda usar XFS. La razón de esto es que si su disco desarrolla un bloque defectuoso, en lugar de dañar un archivo (que se puede almacenar varias veces), puede dañar todos los archivos (docena y cientos) que contengan el mismo bloque de datos.
La deduplicación no se implementa para dispositivos de cinta. Funciona sólo con copias de seguridad basadas en disco.
La deduplicación global es realizada por el software Bacula. Si desea utilizar la deduplicación suministrada por el hardware o el sistema de archivos, consulte el documento técnico del producto del controlador de volúmenes alineados del bacula.
Instalación
El paquete de instalación de Dedup Driver está disponible para RHEL, CentOS, Debian, Ubuntu, SUSE y para la mayoría de las demás distribuciones de Bacula Enterprise Linux soportadas. Debe instalarse en la misma máquina Bacula Storage Daemon. Por ejemplo:
rpm -ivh bacula-enterprise-dedup-plugin-8.10.1-1.el7.x86_64.rpm
Reinicie el bacula-sd y compruebe que el conductor está cargado con un mando de status storage.
Configuración del Storage Daemon (bacula-sd.conf)
Conforme a la Figura 1, las directivas Dedup Directory y Dedup Index Directory deben configurarse para el uso del Dedup Global. Por el bconsole, vaya al Módulo de Configuración, botón de almacenamiento Daemon (medio de la pantalla) y edite el Recurso de almacenamiento Daemon:
Figura 1. Configuração do Recurso Storage Daemon do bacula-sd.conf pelo BWeb
Por el texto, su bacula-sd.conf debe ser editado para incluir las directivas:
Storage {
Name = my-sd
Working Directory = /opt/bacula/working
Pid Directory = /opt/bacula/working
Subsys Directory = /opt/bacula/working
Plugin Directory = /opt/bacula/plugins
Dedup Directory = /mnt/bacula/dedup/containers
Dedup Index Directory = /mnt/SSD/dedup/index
}
Dedup Directory = <ruta de directorio>. Los datos de copia de seguridad de los contenedores se almacenan en el directorio Dedup. Este directorio es común para todos los dispositivos Dedup configurados en un demonio de almacenamiento y envete una gran cantidad de espacio libre para alojar datos deducidos de copias de seguridad. Le aconsejamos que utilice LVM en sistemas Linux para garantizar que pueda extender el espacio en este directorio. Si cambia la directiva de Dedup Directory, los archivos se deben mover al nuevo directorio.
Dedup Index Directory = <directorio-ruta>. Los índices están armados sin dirección de índice Dedup. Los indicadores se cambian a los procesos aleatorios de adaptación y al beneficio de las unidades rápidas, como unidades SSD.
Por defecto, Bacula Storage Daemon se ejecuta con el usuario del sistema operativo bacula. Asegúrese de tener permiso al montar estos directorios, o si son discos locales:
chown bacula /mnt/bacula/dedup/containers chown bacula /mnt/SSD/dedup/index
En el bacula-sd.conf, también es necesario crear un nuevo Autochanger especial y Dispositivos que usan el controlador de deduplicación:
Autochanger {
Name = "Dedup"
ChangerCommand = "/dev/null"
ChangerDevice = "/dev/null"
Device = "DedupDisk1","DedupDisk2"
}
Device {
Name = "DedupDisk1"
Archive Device = /mnt/bacula/dedup/volumes
Media Type = DedupVolume1
Device Type = Dedup
LabelMedia = yes
Random Access = Yes
AutomaticMount = yes
RemovableMedia = no
AlwaysOpen = no
Maximum Concurrent Job = 5
}
Device {
Name = "DedupDisk2"
Archive Device = /mnt/bacula/dedup/volumes
Media Type = DedupVolume1
Device Type = Dedup
LabelMedia = yes
Random Access = Yes
AutomaticMount = yes
RemovableMedia = no
AlwaysOpen = no
Maximum Concurrent Job = 5
}
Un Autochanger y varios Devices son sugeridos para evitar cuellos de botella de tareas de copia de seguridad simultáneas y saturar la capacidad de grabación del Daemon de Almacenamiento. Más de 5 trabajos simultáneos del Director van al siguiente Dispositivo disponible (DedupDisk2).
El Archive Device contiene la carpeta en el formato de volúmenes tradicionales del Bacula, por lo que todavía es posible usar bscan, bextract y otras herramientas de emergencia de Bacula. Usando Dedup, los volúmenes realmente no contienen los datos de copia de seguridad, pero los contenedores escribieron en el directorio Dedup.
El Midia Type debe ser un nombre exclusivo para todos los Dispositivos y Daemon de Almacenamiento adjuntos al mismo Director. Los diferentes cambiadores deben tener un Midia Tipos diferentes.
Reinicie el almacén de demonios para aplicar los cambios.
Configuración del Director (bacula-dir.conf)
Cree una nueva directiva Autochanger para conectar el Bacula SD:
Storage {
Name = Dedup
Allow Compression = No
Address = 192.168.0.85
Password = xxx
Device = Dedup
Media Type = DedupVolume1
...
}
Permitir la compresión debe ser no para deshabilitar la compresión del software Bacula, ya que el Mecanismo Global de Dedup ya lo ejecuta después de la deduplicación.
Los nombres de dispositivo y el tipo de medio deben coincidir con los definidos en la configuración de los recursos Autochanger y Device del bacula-sd.conf.
En cada uno de los FileSets del Bacula, puede decidir entre Global (cliente de copia de seguridad) o Deduplicación de almacenamiento. La deduplicación global (ambas caras) tiene la ventaja de minimizar el tráfico de la red La opción de almacenamiento sólo ejecuta la deduplicación de datos en la máquina del demonio de almacenamiento.
Include {
Options {
Dedup = bothsides # or storage
}
File = /etc
}
Configuración Opcional de File Daemon (bacula-fd.conf)
Los File Daemons Bacula pueden ser configurados para mantener cierta información de deduplicación para acelerar las restauraciones, especialmente usando anchos de banda menores. Esto se puede activar con la directiva Enable Client Rehydration (predeterminada = no).
FileDaemon {
...
Enable Client Rehydration = yes
}
Nuevas Pools del Bacula Director
Una vez que se adjunta un nuevo almacenamiento, es una buena idea crear nuevos Pools de copia de seguridad asociados, para no obtener los Dedup Volúmenes mezclados con otros. Por ejemplo:
Pool {
Name = Daily-Dedup
Type = Backup
Storage = Dedup
...
}
Configuración del trabajo de copia de seguridad
No hay configuración especial en los trabajos de copia de seguridad que utilizan la deduplicación. Basta con programar tareas de copia de seguridad periódicas para los grupos de copia de seguridad recién creados mediante los archivos de archivos con la deduplicación de las ventanas o el almacenamiento activo.
Prueba y estado de Deduplicación
Aquí hay un ejemplo de salida de la salida del comando dedup usage:
* dedup storage=Dedup usage
Dedupengine status:
DDE: hash_count=1275 ref_count=1276 ref_size=78.09 MB
ref_ratio=1.00 size_ratio=1.13 dde_errors=0
Config: bnum=1179641 bmin=33554393 bmax=335544320 mlock_strategy=1
mlocked=9MB mlock_max=0MB
Containers: chunk_allocated=3469 chunk_used=1275
disk_space_allocated=101.2 MB disk_space_used=68.87 MB
containers_errors=0
Vacuum: last_run="06-Nov-14 13:28" duration=1s ref_count=1276
ref_size=78.09 MB vacuum_errors=0 orphan_addr=16
Stats: read_chunk=4285 query_hash=7591 new_hash=3469 calc_hash=3470
[1] filesize=40.88KB/499.6KB usage=36/484/524288 7% ***...............
[2] filesize=40.13KB/589.0KB usage=18/286/524288 6% **5...............
[3] filesize=25.47KB/655.2KB usage=7/212/524288 3% *4................
El size_ratio es la ganancia general de deduplicación para todos los trabajos de copia de seguridad. Cuanto más copias de seguridad se realicen y se mantengan, esta proporción debe mejorarse.
El ref_size es el tamaño de los trabajos de copia de seguridad antes de la deduplicación y el disk_space_used es el tamaño real de los contenedores de deduplicación.
Es una buena idea habilitar la funcionalidad hole_punching, lo que puede ahorrar más espacio en disco a largo plazo, aprovechando los bloques de datos expirados en el mecanismo de deduplicación. Por ejemplo:
* dedup vacuum holepunching storage=<DeviceName>
Lea el white paper referenciado de Bacula Systems para obtener más información sobre la salida del uso de dedup y para más opciones de comando, como el proceso de vacuum y scrub (verificación) del motor de deduplicación.
Como se muestra en la Figura 2, también es posible obtener información similar por Bweb, a ejemplo del consumo de los datos de bakup deduplicado en disco, y el tamaño si estos datos no se reducen por el Dedup (Equivalente Standard File o Tape Storage Space). Versión del motor de Dedup, tamaño de los Holes y muchas otras informaciones. El uso de los contenedores y la disposición de los bloques ocupados se muestra gráficamente en el widget más abajo en esta pantalla.
Figura 2. Menú Estadísticas, Uso Deduplicación Global EBacula por BWeb
Ejecución de un trabajo de copia de seguridad
El registro regular de Jobs de Bacula debe imprimir cierta información sobre la deduplicación. Por ejemplo:
... FD Bytes Written: 137,402,873,108 (137.4 GB) SD Bytes Written: 258,766,712 (258.7 MB) Rate: 28330.5 KB/s Software Compression: 99.8% 531.0:1 ...
El FD Bytes Written son los datos de copia de seguridad no deduplicados obtenidos del cliente.
El SD Bytes Written es la cantidad de datos duplicados grabados en el Bacula Storage.
Si el formato de compresión FileSet está establecido (por ejemplo, LZO, aunque no es utilizado por Bacula al escribir en el controlador Dedup), el campo de Software Compression debe informar de la tasa de deduplicación.
Referencia
Global Endpoint Deduplication – Bacula Enterprise Edition. http://baculasystems.com
Disponível em: 
Español
