Cambiar disco fallido en RAID software (mdadm)

mdadm es un método de implementar a nivel software las facilidades del RAID a nivel hardware. Aunque en la actualidad, especialmente los servidores de producción, suelen traer todos consigo la posibilidad de crear diferentes tipos de RAID hardware, es cierto que pueden no traerlo. En ese caso y como proteger nuestros datos (y por lo tanto la disponibilidad de los mismos) debería de estar por encima de todo, la opción de tener disponible una solución de RAID puede resultar francamente útil y para hacerlo está mdadm.

mdadm crea el RAID, pero no evita que un disco pueda fallar. Sí tenéis una salida similar a la siguiente,

shell> mdadm -D /dev/md0
/dev/md0:
        Version : 00.90.00
  Creation Time : Thu Ene  2 12:27:05 2014
     Raid Level : raid1
     Array Size : 64128 (62.63 MiB 65.67 MB)
    Device Size : 64128 (62.63 MiB 65.67 MB)
   Raid Devices : 2
  Total Devices : 1
Preferred Minor : 0
    Persistence : Superblock is persistent

    Update Time : Tue Ene  2 18:54:59 2014
          State : active, degraded
 Active Devices : 1
Working Devices : 1
 Failed Devices : 0
  Spare Devices : 0

           UUID : 40e3ae0f:fd3ef12a...
         Events : 0.91

Number  Major  Minor  RaidDevice  State
0       0      0      0           faulty removed
1       8      1      1           active sync   /dev/sda1

querrá decir que uno de los discos que compone el RAID ha fallado. Como se puede observar, hay dos discos en el RAID y uno de ellos ya no está presente (/dev/sdb1).

La solución ahora pasa por marcar el RAID como fallido, cambiar el disco y volver a reconstruir el RAID nuevamente. Para hacerlo, os dejo aquí los pasos.

• Indicamos al RAID que la partición ha fallado

  shell> mdadm --manage /dev/md0 --fail /dev/sdb1
  

• Eliminamos la partición de RAID

  shell> mdadm --manage /dev/md0 --remove /dev/sdb1
  

• Apagamos el equipo y cambiamos el disco
• Replicamos estructura del disco sda al nuevo disco sdb

  shell> sfdisk -d /dev/sda | sfdisk /dev/sdb
  

• Incluimos en nuevo disco en el RAID

  shell> mdadm --manage /dev/md0 --add /dev/sdb1
  

• Esperamos a que sincronicen los datos (según el tipo de RAID)
  
  Durante este tiempo se puede trabajar perfectamente con el equipo, aunque irá un poco más lento, probablemente.

Si algún día lo tenéis que usar, espero que os sea de ayuda y sino, mejor que mejor.

Leer más

Optimizar base de datos MySQL

MySQL es el motor de base de datos por defecto de numerosas aplicaciones, entre ellas Bacula. Y como otros muchos motores de bases de datos, tiene su parte buena y su parte mala. La parte buena es la flexibilidad y potencia que nos ofrece. La parte mala es que en aplicaciones muy dinámicas, hablando de datos, MySQL tiende a fragmentar las tablas y por lo tanto, espacio en disco ocupado y rapidez de acceso a datos aumentan. Aunque este post lo relacionamos directamente con Bacula, este pequeño truco sirve para cualquier otras aplicación que emplee MySQL. Lo que vamos a explicar aquí, es como optimizar un poco las tablas, es decir, que tras realizar muchas escrituras y borrados y también updates, hacer que la estructura de la tabla vuelva a ser la óptima. Existen dos formas, la primera es la clausulo OPTIMIZE de mysql, y la segunda, un pequeño script, que aparece en la documentación de bacula. Ambas estrategias van a realizar algo parecido, desfragmentar la tabla, repararla y ordenar los índices. Vamos a ver cómo funcionan.

• OPTIMIZE
  
  Es una clausula de MySQL y sobre tablas MyISAM da muy buenos resultados. Por lo tanto, para aplicarlo a bacula, simplemente tendremos que ejecutar dicha clausula sobre todas las tablas, una a una. 

  mysql> OPTIMIZE LOCAL TABLE bacula.BaseFiles;
  +------------------+----------+----------+----------+
  | Table            | Op       | Msg_type | Msg_text |
  +------------------+----------+----------+----------+
  | bacula.BaseFiles | optimize | status   | OK       |
  +------------------+----------+----------+----------+
  1 row in set (0.00 sec)
  
  mysql> OPTIMIZE LOCAL TABLE bacula.CDImages;
  +-----------------+----------+----------+----------+
  | Table           | Op       | Msg_type | Msg_text |
  +-----------------+----------+----------+----------+
  | bacula.CDImages | optimize | status   | OK       |
  +-----------------+----------+----------+----------+
  1 row in set (0.00 sec)
  

  Según el grado de fragmentación que presente, el proceso puede llevar más o menos tiempo.
• script
  
  Esta forma es algo más elaborada y requiere escribir un poco de código, pero el resultado es mucho más óptimo y queda más logrado. Realizamos el siguiente script,

  #!/bin/bash
  
  inMB=$(du -ms $DIR | awk '{print $1}')
  echo "DB Bacula size: $inMB MB"
  echo "Optimize MySQL Database (I): dump"
  mysqldump -f -uroot -p --opt bacula > /tmp/bacula.sql
  echo "Optimize MySQL Database (II): write"
  mysql -u root -p bacula < /tmp/bacula.sql
  echo "Delete security copy"
  rm -f /tmp/bacula.sql
  newInMB=$(du -ms $DIR | awk '{print $1}')
  echo "New DB Bacula size: $newInMB MB"
  RATIO=`echo "scale=2; ($inMB-$newInMB)/$inMB*100" | bc`
  echo "$RATIO % compress ratio"
  

  Antes de ejecutarlo, intentamos comprender un poco lo que hace, que no es más que realizar un dump de la base de datos bacula para luego volver a insertarla. Al insertarla, genera el schema y borra los datos actuales para volver a meterlos, sacando toda fragmentación y ordenando los índices.
  Un ejemplo de ejecución sería,
  

  DB Bacula size: 1577 MB
  Optimize MySQL Database (I): dump
  Optimize MySQL Database (II): write
  Delete security copy
  New DB Bacula size: 897 MB
  43.00% compress ratio
  

Cualquier de las dos opciones es buena, y es aconsejable según el uso que se haga de bacula ejecutarla cada 3 o 6 meses. Si el equipo realiza muchas copias de seguridad, ejecutarlo una vez al mes, tampoco sobra. Realmente, lo importante es el porcentaje de espacio que se le gana. En esta ejecución, fue de un 43%, efectivamente lo necesitaba. Si la mejora es de un 3%, obviamente, no ;-)

Leer más

Backup incremental vía ftp

Si bien es cierto que uno de los programas más usados para hacer copias incrementales de directorios es rsync, también hay que saber sacar todo el provecho a ftp. Desde el principio de los tiempos, el sistema ftp fue usado para albergar copias de archivos y servir de backup de los mismos en numerosas ocasiones, pero el principal problema que tenía era la sincronización. Si un archivo existía podía sobre-escribirlo  pero si dentro de una carpeta un fichero se ha modificado, realmente había que subir todo el contenido de la carpeta, lo que hace que se consuma mucho ancho de banda. Para solucionarlo, investigando un poco descubrí el proyecto lftp (Sophisticated command-line FTP/HTTP client programs), que permite crear un pequeño script que sólo suba aquellos archivos que se han modificado en un directorio ftp.

A continuación os dejo un ejemplo de cómo emplearlo.

shell> lftp -c "set ftp:list-options -a;
       open ftp://usuarioftp:passwordftp@hostftp;
       lcd /directorio/donde/copiar;
       cd /directorio/local/a/copiar;
       mirror --reverse --delete;
       close -a;"

Leer más

Enterasys, backup automático

Todos sabemos la importancia de tener backup's de nuestros sistemas y de la importancia de que los mismos sean constantes. De nada nos sirve un backup del mes pasado si las cosas están cambiando muy a menudo. Para solucionar estes problemas ya hablamos en este blog de bacula, un potente software cliente-servidor para la realización automática de backups.

Sin embargo, qué pasa si tenemos que hacer backup's de otros elementos de la red, como pueden ser switch's o router's. Estos elementos son tanto o más importantes que los propios equipos, ya que si tenemos la información, pero no tenemos forma de compartirla, de nada nos sirve. Es muy raro encontrar un equipo de estos que permita automatizar el backup y Enterasys no lo hace. Por norma general, hay siempre que ejecutar una serie de comandos que no se pueden encadenar, lo que complica su automatización. Al final cuando hay un problema, siempre se obtiene la misma frase "sí, había que hacerlo, pero no lo hice". Y ahí empiezan todos los problemas.

Así que ya sabes, si tienes equipos Enterasys en tu oficina, usando expect puedes automatizar la creación de backup's de los sistemas.

#!/usr/bin/expect -f

set router [lindex $argv 0]

spawn telnet "$router"
match_max 100000
expect "Username:"
send -- "admin\n"
expect -exact "Password:"
send -- "mi_passwd\n"
expect -- "->"
send "delete configs/$router.cfg\r"
expect -- "->"
send "show config outfile configs/$router.cfg\r"
expect -- "->"
send "copy configs/$router.cfg tftp://server.local/$router.cfg\r"
expect -- "->"
send "exit\r"

Su empleo es sencillo, se pasa como argumento la IP o nombre del router con lo que él accede y deja una copia de la configuración en nuestro servido tftp preferido. Como sabéis, Enterasys realizar las copias a/desde un servidor tftp y necesitan estar en la misma red que los propios equipos, en caso de que empleéis VLAN's.

Leer más

status bacula en zabbix

De bacula ya hemos hablado alguna vez en este blog y de zabbix, creo que también, así que ahora estaría bien unir ambos en un mismo post y hacer que los mensajes de estado de los trabajos de bacula vayan a un monitor zabbix, para así saber si el proceso de backup se realizó o no correctamente. Saber que el backup está OK es muy importante y zabbix nos permite sacar alertas de cambios de estado de forma muy simple, por lo que se acabó leer los informes que bacula envía por mail! En los foros de zabbix hay un ejemplo de cómo unir zabbix + bacula, pero la verdad es que no me pareció un poco consufa y complicada de montar, así que me puse a investigar un poco las posibilidades de bacula de enviar informes y cómo poder obtener el estado para enviárselo a zabbix. Tras leer un poco de documentación, simplemente me di cuenta de que era más efectivo emplear la directiva RunScript dentro de Jobs que editar y capturar todo el mensaje. Así que... manos a la obra! Primero comenzamos editando los ficheros de trabajos de cada cliente, ya que el envío del estado del backup lo realizará el propio cliente y no el servidor. Esto tiene sus pros y sus contras. Por el momento he decidido dejarlo así. Un ejemplo de trabajo sería el siguiente,

Job {
  Name = "backup-equipo23"
  JobDefs = "DefaultJob"
  Client = equipo23-fd
  FileSet = "equipo23-fs"
  Write Bootstrap = "/var/lib/bacula/backup-equipo23.bsr"
  RunScript {
    RunsWhen = After
    Command = "/usr/local/bin/bacula %l %e"
    RunsOnClient = yes
    RunsOnFailure = yes
    RunsOnSuccess = yes
  }
  Enabled = yes
}

La única diferencia respecto de lo que ya había, fue agregarle las líneas que están en negrita y que hacen justamente lo que nos interesa, ejecutar un pequeño script que envía el estado del backup según el tipo (Full, Incremental, etc). En la documentación oficial de bacula está descrito, pero el tipo de variables que se le pueden pasar son:

• %c -- Client's name
• %d -- Director's name
• %e -- Job Exit Status
• %i -- JobId
• %j -- Unique Job id
• %l -- Job Level
• %n -- Job name
• %s -- Since time
• %t -- Job type (Backup, ...)
• %v -- Volume name

Y en nuestro caso pasamos un %l, para que nos indique el nivel de trabajo y %e, el estado de finalización del mismo.

Ahora hay que hacer el pequeño script que se ejecutará cuando el trabajo finalice. Éste es,

#!/bin/bash

case "$1" in
 Incremental)
  zabbix_sender -c zabbix_agentd.conf -k bacula.inc.verify.result -o $2
  ;;
 Full)
  zabbix_sender -c zabbix_agentd.conf -k bacula.full.verify.result -o $2
  ;;
 *)
  zabbix_sender -c zabbix_agentd.conf -k bacula.other.verify.result -o $2
  ;;
esac

Ya que como $1 recibimos el tipo de nivel de backup y sólo realizamos backup's Full o Incremental y como $2 recibimos el estado, por lo tanto, es lo que directamente enviamos a zabbix. El estado enviado puede ser OK, Error, Fatal Error, Canceled, Differences o Unknown term code. Aquí podemos optar por pasarlo a número o no, yo prefiero dejarlo como tipo texto, ya que zabbix también permite sacar alertas de campos de tipo texto.

Llegados a este punto ya sólo queda crear una pequeña plantilla de zabbix que permita obtener los datos enviados como Trapper y un trigger que reaccione ante cambios. Los 3 items a los que hace referencia el script tienen estas propiedades:

Nombre descriptivo: Full backup
Tipo: Trapper ZABBIX
Monitor: bacula.full.verify.result
Tipo de información: Texto
Conservar el histórico durante (en días): 60
Estado: Activo
Aplicaciones: bacula

Y por su parte, los triggers asociados,

Nombre: {HOSTNAME} Full backup fail!
Expresión: {Template_bacula:bacula.full.verify.result.regexp(OK)}#1
Gravedad: Alta

Leer más

Clonar particiones en red

Aunque este es un tema bastante recurrido en la red, tuve que emplearlo hace poco para rescatar un disco y me parece interesante ponerlo, para que quede constancia y así la próxima vez que lo tenga que emplear, simplemente lo veo y listo.

SI tenéis la necesidad de clonar un disco en red, la forma más simple de hacerlo es empleando netcat y dd. Del lado del cliente, es decir, del lado del equipo que tiene el disco a clonar, tenemos que ejecutar lo siguiente,

shell> dd if=/dev/vg0/home bs=1M | nc 192.168.1.33

Mientras que del lado del servidor, es decir, el equipo que va a recibir los datos de la clonación, tenemos que ejecutar,

shell> nc -l 9999 | dd of=/dev/vg0/home_ext bs=1M

Una breve explicación de lo que se va a realizar es la siguiente. Primero se ejecuta el segundo comando, para abrir el puerto 9999 y dejar que el flujo de datos que llegue se escriban en la partición home_ext. Ésta debe de existir. A continuación, se ejecuta el primer comando, para enviar todos los datos vía netcat al equipo que está a la escucha. Como se puede observar, dd nos da la clave, if es el origen de datos y of es el destino de los mismos.

Leer más

Backup de ACL's

Si estás trabajando en un servidor GNU/Linux que maneja ACL's, especialmente complejas para usuarios y grupos, lo mejor que puedes hacer es realizar un backup de las mismas diariamente, por que si un día necesitas restaurar algo, lo más probable es que también tengas que reestablecer la larga cadena de ACL's que conlleva y eso, según qué casos puede no ser 100% simple. Para poder hacer lo comentado, existe el comando getfacl que no es más que un pequeño programa que consultas las ACL's del directorio pasado como parámetro y permite volcar la salida a un fichero de texto. A continuación, os dejo un ejemplo de cómo quedaría el script que realizar el backup de las ACL's.

#!/bin/bash

BACKUP_DIRS="/data"
STORE_ACL="/var/backups"
umask 077
for i in $BACKUP_DIRS
do
 cd $i; /usr/bin/getfacl -R . > $STORE_ACL/$i.acl
done

Y puesto que todos nuestros sistemas está automatizados y manejados con puppet, creamos una pequeña clase que permite instalar este script y ejecutarlo diariamente sin esfuerzo alguno.

class configuracion::acl {
 file { "/usr/local/sbin/backup-acl":
   owner => root,
   group => root,
   mode => 0500,
   source => "puppet://$master/files/backup-acl",
   ensure => present;
 }

 cron { "domain-acl":
   command => "/usr/local/sbin/backup-acl",
   user => root,
   hour => 1,
   minute => 15,
   require => File [ "/usr/local/sbin/backup-acl" ],
   ensure => present;
 }
}

Así que para poder usarla, únicamente hay que agregar la clase creada en los equipos que se desee.

include configuracion::acl

Leer más

Manejo de cintas de backup en GNU/Linux

Hace tiempo que tenía planeado escribir este post y con ello espero que ayudar algún día a alguien que necesite manejar una librería o unidad de cintas. Actualmente están perfectamente soportadas en sistemas GNU/Linux y en uno de los próximos post espero comenzar a mostrar cómo conseguir que bacula funcione perfectamente contra la librería. Pero antes de nada... hay que saber manejar la librería y las cintas. Bacula, o cualquier otro cliente de backups, lo único que hace es manejar de forma automática estos comandos según lo necesite.

Por lo tanto, vamos a ello. Primero hay que tener claro un par de conceptos. En prácticamente todos los sistemas GNU/Linux, el cargador de cinta está identificado como un dispositivo /dev/sgX (en mi caso será /dev/sg0) y la cinta, una vez cargada como /dev/nstX (en mi caso /dev/nst0). Existen comandos perfectamente pensados para manejar ambos dispositivos. Para el primero emplearemos mtx y para el segundo, el comando mt.

Hay que recordar que la cintas de backup son secuenciales y por lo tanto, al cargarlas, leer o escribir en ellas primero hay que posicionarse en donde corresponda. Una vez aclarado esto, vamos a ver las principales opciones para manejar la unidad de cintas.

• Consultar el estado de la librería

  shell> mtx -f /dev/sg0 status
  

• Cargar una cinta

  shell> mtx -f /dev/sg0 load numero_de_cinta
  

• Descargar una cinta

  shell> mtx -f /dev/sg0 unload
  

Y una vez que tenemos una cinta cargada, también podemos hacer cosas con ella, para comprobar que realmente funciona correctamente. Para ello,

• Consultar el estado de una cinta

  shell> mt -f /dev/nst0 status
  

• Rebobinar la cinta cargada

  shell> mt -f /dev/nst0 rewind
  

• Expulsar la cinta, después de rebobinarla

  shell> mt -f /dev/nst0 eject
  

• Escribir directamente en la cinta

  shell> tar -cvf /dev/nst0 fichero/directorio
  

• Escribir un eof después de escribir algo
  
  Permite luego poder ir saltando de fichero en fichero.

  shell> mt -f /dev/nst0 eof
  

• Salta de fichero en fichero por la cinta
  
  Es necesario escribir un eof entre ficheros.

  shell> mt -f /dev/nst0 fsf
  

• Sacar un fichero de la cinta estando al principio del mismo
  
  Recordar, la cinta es secuencial. Primero nos posicionamos y luego leemos.
  El fichero o directorio leído quedará almacenado en el directorio actual.

  shell> tar -xvf /dev/nst0
  

• Borrar una cinta

  shell> mt -f /dev/nst0 erase
  

Leer más