PDF de programación - bacula, el vampiro

Por amphora

departamento ¿Eso que tienes ahí es un chupetón? , Sección Software Libre
Puesto a las Thu May 6th, 2004 at 03:24:41 PM CET
Bacula, el vampiro

Trás un tiempo probando amanda, como sistema de backups en cinta y a raíz de una entrada en el
diario de Iñaki Arenaza decidí darle un tiento a bacula.

Si alguno ha probado amanda es posible que se haya sentido bastante perdido en su
configuración, la documentación es muy escasa (o al menos a mi me lo parece) y no dá la
sensación de que se esté desarrollando activamente. Nunca lo he llegado a poner en producción,
tan solo he estado haciendo pruebas y aunque funciona perfectamente, me quedaba ese regustín a
que no era todo lo bueno que debiera ser. Como no conocía otras alternativas libres, terminé su
configuración y pruebas y no volví a tocar el tema, hasta el momento en que tuviera que ponerse
en marcha.

Como ya he dicho, gracias a la entrada de Iñaki en su diario, puse Galeón apuntando a su url, y me
he encontrado con un sistema de backup que colma todas mis necesidades (salvo diferentes
cuestiones que ya trataré). La documentación es extensa y muy bien estructurada, de hecho se
escribe antes que el código y es posible encontrar características que todavía no se han
implementado. Todas las tareas que realiza bacula se han modularizado y repartido las tareas
entre varios demonios y servicios y además para los que lo necesiten hay un cliente para win32.
Comprendiendo a bacula

Cuesta cinco minutos comprender el funcionamiento del sistema, gracias a la documentación y a la
separación lógica de las tareas a realizar. La configuración es algo más compleja, pero en realidad
no mucho más, y para eso ya estoy yo escribiendo este artículo. De nada.

Quiero hacer una aclaración, aunque hablo de un sistema de backup en cinta, no quiere decir que
unicamente se pueda volcar en ese tipo de dispositivos, se puede utilizar perfectamente en una red
doméstica, o en una sola máquina y grabar los respaldos en un CD, pero obviamente bacula está
orientado a una red más grande y con uno o varios dispositivos de cinta.

Bacula guarda todas sus operaciones,trabajos,listas de volúmenes, etc en una base de datos estilo
SQL. Toda la instalación la he realizado en sistemas debian, salvo algunos clientes, que utilizan
otra serie de distribuciones (Red Hat y Mandrake), así que la instalación de bacula se redujo a un
apt- get y el solito me creo las bases de datos necesarias. ¿Como se hace en otras distribuciones?
Ni idea, en las otras me he limitado a configurar los clientes

Bueno, que me enrollo mucho. El sistema se divide en:

• Bacula director El demonio encargado de gestionar todas las operaciones de backup. El

director sabe los trabajos que se van a realizar, cuando , donde y como. Y además se
encarga de restaurar los ficheros que le pidamos y su verificación (una especie de suma de
comprobación de integridad). Se puede instalar en cualquier máquina de la red.

• Bacula File El cliente. Es necesario instalarlo en todas las máquinas de las que queramos

hacer respaldo. Su función es leer y transmitir los ficheros que el director le pida, o
restaurarlos.

• Bacula Storage Este demonio se encarga de la lectura/escritura física en los volúmenes que

estén definidos (cintas, ficheros)

Además tenemos la consola, con la cual nos conectaremos al director, y desde donde podremos
dar ordenes, hacer consultas, etc. Y el catálogo, donde el director guarda y registra todas sus

operaciones.

Aclarado esto, conviene también explicar que son los volúmenes y los "pools":

Bacula se refiere a los volúmenes como los dispositivos físicos donde se guardan los volcados
(ficheros o cintas) y a los "pools" como el conjunto de uno o varios volúmenes. Para que quede más
claro, nosotros definimos por ejemplo un "pool" que va a servir para hacer copias diarias de
diferentes máquinas, y en ese "pool" añadimos diferentes volúmenes y bacula sabe cuales
volúmenes pertenecen a cada "pool". De esta manera, bacula conoce donde está cada cosa, y de
donde sacarla, o bien donde será necesario escribir cuando el volumen actual esté lleno.

El funcionamiento viene a ser algo así:

El director, que tiene definidos una serie de trabajos y a una determinada fecha y hora se pone en
marcha, contacta con el primer cliente que tiene definido, el cliente de esa máquina comprueba los
ficheros o directorios que le pide el director y le devuelve los que hayan cambiado (si es una copia
diferencial o incremental) al director, este se pone en contacto con el demonio "storage" que
almacena en el volumen los ficheros que le mandan, y vuelta a empezar por cada uno de los
clientes. Para un trabajo de verificación viene a ser lo mismo, solo que no se guardan los ficheros,
sino solo las sumas de comprobación en la base de datos SQL que usemos (a día de hoy SQLite,
MySQL o PostgreSQL)
Instalación

Aunque ya he comentado, que la instalación a partir de binarios es sumamente fácil, hay que
comentar algunas cosas:

• El kernel Si no viene configurado por defecto (como mi caso) es necesario recompilar el

kernel de la máquina que tenga conectado el dispositivo de cinta con soporte para scsi y
cintas:

<*> SCSI support
- - - SCSI support type (disk, tape, CD- ROM)
<*> SCSI disk support
(40) Maximum number of SCSI disks that can be loaded as modules
<M> SCSI tape support

• Los demonios: Al trabajar en red, la base datos puede estar en cualquier parte, el director

también, los clientes cada uno en su máquina y el demonio que trata con la cintas en la
máquina que tiene las cintas. Mi opinión es no complicarse la vida e instalar el director, la
base de datos y el demonio encargado de grabar datos en la máquina con el scsi de cintas.
Y la consola en el ordenador normal de trabajo (aunque al instalar el cliente en debian, se te
instala también la consola)

Entonces tenemos que:

maquina@directora:~#apt- get install bacula- director- mysql bacula- sd

maquina@cliente:~#apt- get install bacula- fd

Una vez que está instalado y configurado, nos ponemos a retocar los ficheros de configuración.
Todos los ficheros de configuración son bastante simples y apenas requieren modificación alguna,
salvo el del demonio director que es bastante extenso y complicadillo. En realidad, en las últimas
versiones de bacula se ha simplificado bastante este fichero ya que se ha implementado un recurso
que permite tener definidos una serie de trabajos modelo, que despues se pueden modificar
puntualmente para cada cliente/trabajo. Viene a ser algo parecido a las clases de la programación
orientada a objetos. La pena es que en debian unstable van por la versión 1.32 y la versión
upstream es la 1.34, no pudiendose hacer uso de esa característica. A mi me queda un fichero tal
que así:

maquina@directora:~# wc - l /etc/bacula/bacula- dir.conf
1099 /etc/bacula/bacula- dir.conf

Dejamos para la segunda parte la configuración de los ficheros

Continuamos con la serie. Esta vez hablamos como prometí de los diferentes ficheros de
configuración de este estupendo vampiro

Los ficheros de configuración de bacula

Continuamos con la serie. Esta vez hablamos como prometí de los diferentes ficheros de
configuración de este estupendo vampiro.

Vamos a ir de los más fáciles a los más dificiles:

•

/etc/console.conf
La consola de bacula es el medio por el cual nos vamos a comunicar con el sistema director.
Su fichero de configuración es este:

gandalf:/etc /bacula# cat console.conf
#
# Bacula User Agent (or Console) Configuration File
#

Director {
Name = maquinadirectora- dir
DIRport = 9101
address = maquinadirectora.x.com
Password = "clave"
}

El nombre ha de ser el mismo que más tarde definiremos en el fichero de configuración del
director. Lo siguiente es el puerto donde escucha el director. El FQDN o bien su dirección IP.
Y finalmente la password que se necesita para conectar al director.
/etc/bacula- fd.conf
El fichero de configuración de los clientes

•

gandalf:/etc /bacula# cat bacula- fd.conf
#
# List Directors who are permitted to contact this File daemon
#
Director {
Name = maquinadirectora- dir
Password = "clave"
}

#
# "Global" File daemon configuration specifications
#
FileDaemon { # this is me
Name = gandalf- fd
FDport = 9102 # where we listen for the director
WorkingDirectory = /var/lib /bacula
Pid Directory = /var/run /bacula
}

# Send all messages except skipped files back to Director
Messages {
Name = Standard
director = maquinadirectora- dir = all, !skipped
}

Los comentarios del fichero aunque estén en ingles, son bastante aclaratorios, así que no
voy a entrar en detalles. Basicamente, se autoriza al director a conectar con nosotros por el

puerto 9102.Definimos el nombre de nuestro cliente, y se definen el tipo de mensajes que
queremos hacer llegar al director.

•

/etc/bacula- sd.conf
El demonio encargado de escribir en los dispositivos de cinta tiene su propio fichero:

maquinadirectora:/etc/bacula# cat bacula- sd.conf
# You may need to change the name of your tape drive
# on the "Archive Device" directive in the Device
# resource. If you change the Name and/or the
# "Media Type" in the Device resource, please ensure
# that dird.conf has corresponding changes.
#

Storage { # definition of myself
Name = maquinadirectora- sd
SDPort = 9103 # Director's port
WorkingDirectory = "/var/lib/bacula"
Pid Directory = "/var/run/bacula"
}

#
# List Directors who are permitted to contact Storage daemon
#
Director {
Name = ma