Backups automatizados en red: Bacula

Bacula es una solución open source de backups, que permite realizar copias de seguridad de forma automatizada y programada, y su principal característica a destacar es que permite hacerlo a través de la red. Esto es, aunque se puede utilizar en entornos domésticos (aunque quizás ésta no sea la mejor solución, sino ésta otra), donde mejor se desenvuelve Bácula es en un entorno empresarial, donde hay máquinas y servidores virtuales, servidores dedicados, equipos de usuario, etc...

Aquí tenéis la web del proyecto: http://www.bacula.org

Supongamos el siguiente escenario: Estamos en una red donde tenemos un dispositivo de almacenamiento tipo NAS o similar, de varios chorrocientos de gigas. También tenemos en la misma red varios equipos de usuario y algún que otro servidor. Pues bien, lo que queremos hacer es que todos los sábados (por ejemplo) se haga una copia de seguridad completa de ciertos directorios y archivos de interés de todos nuestros equipos, y que todos los días se haga una copia incremental de los mismos. Aquí es donde entra en juego Bacula.

Cabe decir que Bacula no es apropiado para backup de bases de datos, sino de archivos.

Bacula se compone de varias partes, las explicaré de forma resumida, y luego veremos más en detalle cómo se configura todo ello (supondremos que todos los equipos corren Linux Debian o similar, para simplificar un poco).

• Por un lado tenemos el Storage Daemon, o Bacula-sd, es el demonio de almacenamiento, el que va a almacenar las copias.
• Tenemos también los clientes, o Bacula-client, que son los demonios instalados en los equipos de los cuales queremos hacer backup.
• Disponemos también de una consola llamada bacula-console, que nos servirá de utilidad a la hora de hacer backups manuales, restaurar un backup antiguo, simular una operación de backup (a modo de "a ver cómo quedaría"), crear/modificar/eliminar dispositivos de almacenamiento, etc.
• Y por último tenemos el Director de la orquesta, o Bacula-director, es el componente que va a dirigir el cotarro, por así decirlo, es el que dice quién hace qué en cada momento.

Debo decir que Bacula permite trabajar con las llamadas "tapes", pero aquí veremos almacenamiento digital, sobre un disco duro (ya sea cifrado o no).

En primer lugar instalamos el Director en el servidor principal desde el cual controlaremos el proceso de copias (luego veremos cómo configurarlo):

aptitude install bacula-director-common bacula-director-mysql

Instalamos también todas las dependencias requeridas, claro.

Después instalamos el Storage Daemon en el servidor que hará el almacenamiento de las copias (puede ser el mismo servidor en el que instalamos el director):

aptitude install bacula-sd

Por último, instalamos el cliente en cada equipo del que queremos realizar un backup:

aptitude install bacula-client

Con las herramientas instaladas, vamos a ver cómo configurarlo.

Como cada "demonio" puede ser nombrado de una forma determinada, nosotros les llamaremos debian-dir al Director, debian-sd al Storage Daemon, y debian-fd1/2/3... a cada cliente (ya que, por defecto, Bacula coge el hostname para nombrar cada componente). Aún así, la mayor parte de la configuración por defecto está bien, pero modificaremos algunas cosas.

En el bacula-sd (/etc/bacula/bacula-sd.conf) debemos configurar los parámetros de la unidad de almacenamiento (puede ser un volumen local, remoto, o puede estar sobre un sistema de ficheros cifrado). Empezamos por el Storage, que es la definición del propio módulo en sí:

Importante: Bacula no trabaja bien con nombres de hosts, por lo que siempre que haya que configurar una ip, así lo haremos (aunque sea una dirección de localhost, definiremos la ip que utiliza en la red).

A continuación le decimos a bacula-sd quién es el Director:

Aquí figuran 2 directores, el principal por así decirlo (debian-dir) y el monitor (debian-mon). El monitor es el que va a consultar el estado en el que se encuentra bacula-sd. Como véis, tenemos que decirle con qué pass se va a conectar cada uno (ojo, no son pass de usuario, ni mucho menos, son contraseñas que sólo usará Bacula). Sí, ya sé que es una barbaridad enviar contraseñas sin cifrar por la red, pero es así como funciona (también las enviábamos en conexiones http y nadie se echaba las manos a la cabeza... :-) ).

A continuación definimos el tipo de almacenamiento que utilizaremos:

También tenemos la opción de definir un  cargador de cintas, pero en este caso no lo vamos a utilizar.
Por último, permitiremos que bacula-sd envíe mensajes al Director:

Pasemos ahora a los clientes. En cada uno de ellos configuraremos los siguientes parámetros:

Tenemos el Director y el monitor, con sus respectivas contraseñas. También definimos el propio demonio cliente y el envío de mensajes.

Finalmente, definiremos el bacula-dir (este tiene un poco más de chicha). Principalmente se basa en definiciones de trabajos y entidades, ahora lo veremos.

En primer lugar definimos como siempre al propio Director:

Seguidamente definimos un trabajo de backup:

Definimos también el trabajo que engloba a esta definición de trabajo (es un poco lioso, pero al final es una jerarquía de Trabajo -> Definición de Trabajo -> Definición de elementos que lo componen).

Definimos un trabajo de Restore, para poder restaurar las copias que hagamos (los parámetros son casi autoexplicativos):

Definiremos un File Set, es decir, los archivos de los que queremos hacer backup, y los que queremos excluir, si los hubiera. También podemos definir una firma de tipo MD5, que utilizará Bacula para determinar si ha habido cambios o no.

Definimos ahora la programación horaria, para decir cuándo se ha de hacer un backup completo, cuándo un icremental, etc. En este caso haremos un backup completo todos los domingos a las 23:05, y un incremental todos los días a las 23:05:

Definimos también el catálogo, donde Bacula hará su inventario de archivos de los que ha hecho backup, diferencias, etc...

Ahora definiremos los clientes de los cuales hay que hacer backup:

Le decimos el dispositivo de almacenamiento:

En caso de tener un cargador de cintas, lo definiríamos aquí. En la configuración por defecto hay unos cuantos ejemplos.

Especificamos los datos de conexión a la base de datos:

Y habilitamos el envío de mensajes estándar y, opcionalmente, por email, en cuyo caso debemos especificar la dirección en el parámetro %r:

Definimos los Pool que servirán de almacenamiento, el tiempo durante el cual se guardarán los volúmenes y el tamaño máximo y número de volúmenes.

Definimos la consola:

Antes de arrancar la consola, nos aseguramos de que tiene puesta la ip correcta del Director al que tiene que conectar (/etc/bacula/bconsole.conf):

También debemos definir todos los componentes (director, sd y fd) en el archivo /etc/bacula/tray-monitor.conf.

Tras comprobar que todo está correcto, vamos a testear el sistema a mano para asegurarnos de que todo funciona correctamente. Para ello, iniciamos todos los servicios:

/etc/init.d/bacula-sd start

/etc/init.d/bacula-fd start

/etc/init.d/baclua-dir start

Y comprobamos las configuraciones de todos los ficheros:

/usr/sbin/bacula-sd -t -c /etc/bacula/bacula-sd.conf

/usr/sbin/bacula-fd -t -c /etc/bacula/bacula-fd.conf

/usr/sbin/bacula-director -t -c /etc/bacula/bacula-dir.conf

En mi caso, el Director me dio un error de autorización del usuario bacula en la base de datos. Esto lo solucioné dando permisos a dicho usuario y estableciendo el parámetro DB Address del bacula-dir.conf a localhost.

Arrancamos la consola de Bacula para administrar el sistema de backups de forma manual:

bconsole

Primero tecleamos help para ver una lista de los comandos disponibles, y tras ello creamos un volumen de almacenamiento:

Ahora vamos a crear un backup:

A partir de aquí, si tecleamos "yes", ejecutará el backup. En este caso, detecta que es un backup incremental. Sin embargo, si no hay ningún Full Backup que le sirva de base para hacer el incremental, hará un Full. Con un status dir obtenemos el estado del Director, así como un listado de los útlimos jobs:

En este caso, hemos hecho un Full, y después hemos hecho un Incremental (jobs 7 y 8), mostrando en cada caso los bytes copiados:

El comando restore es muy parecido, sólo hay que seguir las opciones disponibles para ejecutar un trabajo de restauración de archivos. Pongamos que ahora borramos todos los archivos de los que hemos hecho backup. Vamos a hacer un restore para comprobar (con archivos dummy por supuesto) que funciona bien.

Listamos los últimos 20 Jobs, y elegimos el último de ellos:

A partir de aquí podemos explorar el backup para ir seleccionando los archivos que queremos restaurar mediante el comando mark [nombre de archivo] o mark all para seleccionar todos los archivos:

En este caso sólo podemos seleccionar un archivo porque hemos seleccionado restaurar un backup Incremental, y es ese archivo el que habíamos modificado después de hacer el Full Backup. Tecleamos done para terminar, seleccionamos un cliente donde restaurar, y aceptamos:

Nos mostrará un mensaje del trabajo que se ha añadido a la cola para procesar y, si no hay trabajos pendientes, lo hará inmediatamente.

No obstante, aquí tenéis una completa guía de la consola de bácula donde se detallan todas las opciones disponibles y su funcionalidad.

Podemos comprobar que se ha restaurado correctamente el Full Backup, con los incrementales correspondientes hasta llegar al que habíamos seleccionado para restaurar:

Y ya está, tenemos un sistemas de backups completos e incrementales automatizados y, si quisiéramos, sobre un sistema de ficheros cifrado.

Seguramente hay soluciones mucho mejores, pero en cuanto a open source no está nada mal. Es fácil de montar y de gestionar, y lo que es más importante, la restauración de archivos funciona exactamente igual que los backups, evitando así la tediosa labor de rescatar un backup y devolver los archivos a sus sitios originales.

También podríamos comprimir los volúmenes llenos, bien mediante un cron o un script por ejemplo, pero eso ya lo dejamos a elección del lector.

--EOF--