Mes: octubre 2016

Compresión en LTO

jmartin

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

jmartin Deja un comentario

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

jmartin 2 comentarios

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';

 

Monitorizar cambios en Galera Cluster

jmartin Deja un comentario

Para chequear el estado de un cluster Galera se puede inspeccionar cada uno de los nodos que lo componen y comprobar que se hayan en funcionamiento y sincronizados. Pero hay una alternativa que el propio Galera implementa. Está muy bien documentado en los siguientes enlaces:

  • http://galeracluster.com/documentation-webpages/monitoringthecluster.html
  • http://galeracluster.com/documentation-webpages/notificationcmd.html

Como se explica ahí, Galera permite enviar notificaciones cuando detecta algún cambio en el estado del cluster, a través de la llamada a un script o programa con los argumentos que ahí se comentan (--status, --uuid, --members, --index). El script que viene como ejemplo puede ser suficiente para la mayoría de los casos. Cada vez que Galera detecta un cambio, invoca al script pasándole los respectivos argumentos. Éste crea un schema dentro de la propia base de datos, desactivando para ello la replicación en esta sesión, de modo que cada uno de los nodos tienen información propia en los registros que crean. Al script por defecto yo simplemente he añadido una línea para que, además de actualizar las tablas con los cambios, envíe un mail al administrador para que pueda actuar si es necesario.

LVM en rbd Ceph

jmartin Deja un comentario

Queremos usar LVM sobre un dispositivo de bloques Ceph. Por defecto, LVM ignora este tipo de dispositivos (lo primero que hemos hecho ha sido mapear la imagen a dispositivo del sistema con rbd map obteniendo el dispositivo /dev/rbd0).

Para permitirlo, hay que editar el fichero de configuración de LVM (/etc/lvm/lvm.conf)y añadir/editar estas líneas:

preferred_names = [ "^/dev/mpath/", "^/dev/mapper/mpath", "^/dev/[hs]d" , "^/dev/rbd" ]
types = ["rbd", 1024]