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
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-mysqlInstalamos 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-clientCon 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í:
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:
Por último, permitiremos que bacula-sd envíe mensajes al Director:
En primer lugar definimos como siempre al propio Director:
Definimos un trabajo de Restore, para poder restaurar las copias que hagamos (los parámetros son casi autoexplicativos):
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):
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:
Y comprobamos las configuraciones de todos los ficheros:/etc/init.d/bacula-sd start/etc/init.d/bacula-fd start/etc/init.d/baclua-dir start
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./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
Arrancamos la consola de Bacula para administrar el sistema de backups de forma manual:
bconsolePrimero 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:
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:
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--
No hay comentarios:
Publicar un comentario