Compresión en LTO

A la hora de hacer backups es muy útil usar compresión para ahorrar espacio, sobre todo si se tratan de datos que no se van a usar como los archives o históricos.

Los sistemas de copias de seguridad como Bacula permiten indicar el tipo y nivel de compresión que se desea utilizar en cada copia. No obstante, si se trata de backup a cintas es muy posible que la unidad de cintas ya tenga su propio sistema de compresión; esto es, se puede hacer la compresión por hardware (unidad de cintas) en lugar de por software (Bacula). De hecho, todas las unidades de cinta LTO tienen soporte para compresión. Cuando se indica la capacidad de una cinta LTO dan 2 números, la capacidad nativa, sin comprimir y la capacidad con datos comprimidos. Aunque este valor depende de los datos que almacenará puesto que algunos tipos de datos tienen mayor tasa de compresión que otros, suelen mostrar un valor de compresión de 2:1, es decir, el doble de capacidad con datos comprimidos.

Usar ambos tipos de compresión a la vez (hardware+software) no solo consume más tiempo, sino que puede llegar a consumir más espacio que los datos originales. Comprimir algo que ya está comprimido no mejora, incluso empeora el ratio. Por esto, se recomienda usar únicamente la compresión hardware ya que es bastante buena y no supone ninguna sobrecarga.

Para comprobar si la unidad tiene la compresión activada podemos usar la utilidad tapeinfo.

# tapeinfo -f /dev/sg0 
Product Type: Tape Drive
Vendor ID: 'HP      '
Product ID: 'Ultrium 5-SCSI  '
Revision: 'Z6FS'
Attached Changer API: No
SerialNumber: 'HU1246T73R'
MinBlock: 1
MaxBlock: 16777215
SCSI ID: 3
SCSI LUN: 0
Ready: yes
BufferedMode: yes
Medium Type: Not Loaded
Density Code: 0x58
BlockSize: 0
DataCompEnabled: yes
DataCompCapable: yes
DataDeCompEnabled: yes
CompType: 0x1
DeCompType: 0x1
Block Position: 430690
Partition 0 Remaining Kbytes: 1470031
Partition 0 Size in Kbytes: 1470031
ActivePartition: 0
EarlyWarningSize: 0
NumPartitions: 0
MaxPartitions: 1

Si no estuviera activado, lo podemos activar con

# mt -f /dev/st0 compression 1

Cómo mantener un conjunto de volúmenes disponibles para cualquier pool en Bacula

En Bacula, cada volume ha de pertenecer a una determinada pool para que un trabajo la utilice. Siguiendo las reglas de Bacula y las especificaciones que indiquemos, un volume se puede reciclar, pero siempre pertenecerá a la misma pool. Se puede dar el caso de que una pool se quede sin volumes para usar, habiendo disponibles en otras pools. Hay una manera de corregir este comportamiento mediante el uso de la pool Scratch: por defecto, Bacula usa los volúmenes de la pool Scratch cuando alguna de las pools necesita un nuevo volumen. Esto es, si una pool necesita un nuevo volumen para escribir y no puede encontrar ninguno, los coge de la pool Scratch, pero no los devuelve a la pool Scratch por defecto. Para ello, tenemos que indicar la pool a la que va el volumen cuando es reciclado.

Sabiendo esto, la solución que he adoptado es asignar un par de volúmenes a cada uno de mis pools, los cuales no cambiaran de pool al reciclarse, y crear la pool Scratch a la que le he asignado los volúmenes restantes configurando la pool para que una vez sean reciclados, estos volúmenes vuelvan a esta pool y puedan ser usados por otras pools.

La configuración sería la siguiente:

Pool {
   Name = Scratch
   Pool Type = Backup
   RecyclePool = Scratch
}

Copia de seguridad de bases de datos MariaDB consistentes

El objetivo es hacer copias de seguridad de un servidor de bases de datos MariaDB de manera que sean consistentes y minimizando el efecto de hacer los backups sobre el funcionamiento normal del servidor.

Como solución inicial, vamos a utilizar mysqldump que vuelca la estructura y datos de los esquemas en sentencias sql. Como ventaja tiene que es muy fácil de usar y que se pueden editar las setencias resultantes, por ejemplo, antes de exportarlas a otra base de datos. Como desventaja es que el recrear una base de datos de esta forma lleva mucho tiempo.

mysqldump se conecta como cliente al servidor para hacer el volcado de los datos. Para evitar problemas de seguridad, vamos a crear un nuevo usuario con los privilegios mínimos para que mysqldump pueda funcionar. Dependiendo del tipo de motor, necesitaremos unos privilegios u otros. Por ejemplo, estos son los privilegios que se necesitan para los motoros InnoDB y MyISAM:

InnoDB

CREATE USER ‘backup’@’localhost’ IDENTIFIED BY ‘secret’; GRANT SELECT, SHOW VIEW, RELOAD, REPLICATION CLIENT, EVENT, TRIGGER ON *.* TO ‘backup’@’localhost’;

MyISAM

GRANT LOCK TABLES ON *.* TO 'backup'@'localhost';