Bacula es probablemente, la solución OpenSource más conocida para la realización de copias de seguridad a nivel empresarial. Bacula se compone de varios elementos:
- Director: dice cuando hacer backups/restores a los clientes de bacula (FD). Los backups que realizan los clientes de bacula se envían directamente al storage, sin pasar por el director.
- Storage: recibe los datos de los clientes de bacula y los envía al lugar donde se almacenarán (disco, cinta, etc.). El demonio bacula-sd se configurará en un servidor que tenga montados los recursos de almacenamiento (se suele usar el propio servidor de bácula).
- Catalog: base de datos (MySQL, PostgreSQL o SQLlite) con la información de los jobs. Además, guarda los nombres de todos los archivos de los backups realizados, lo cual servirá para hacer restores selectivos.
- Cliente bácula (FD): agente que corre en las máquinas clientes que se quieren backupear.
- Bconsole: programa que interactua con el director, por línea de comandos y permite administrar bacula. Por ejemplo, permite lanzar backups a mano, ver el estado de los jobs o listar los dispositivos de almacenamiento configurados.
1. Instalación de Bacula con MySQL
Desde un entorno basado en Red Hat, Fedora, CentOS, o similar, bastará con usar yum:
- yum install mysql-devel mysql-server
- yum install bacula-storage-mysql bacula-director-mysql bacula-console bacula-client
Con el último comando, se instalarán, además, las siguientes dependencias de bacula:
- bacula-common
- bacula-director-common
- bacula-storage-common
Una vez instalados los paquetes, se iniciará MySQL para inicializar el entorno, y posteriormente se podrá ejecutar /usr/bin/mysql_secure_installation para acabar de securizar la instalación (bacula requiere no eliminar el login remoto):
- /etc/init.d/mysqld start
- /usr/bin/mysql_secure_installation
- Set root password? [Y/n] Y
- Remove anonymous users? [Y/n] Y
- Disallow root login remotely? [Y/n] n
- Remove test database and access to it? [Y/n] Y
- Reload privilege tables now? [Y/n] Y
Tras la inicialización de MySQL, se podrán usar los scripts que vienen con la instalación de bacula, para crear la base de datos MySQL de bacula y darle los permisos necesarios. Bastará con ejecutar, en orden, los siguientes scripts:
- /usr/libexec/bacula/grant_mysql_privileges -u root -p
- /usr/libexec/bacula/create_mysql_database -u root -p
- /usr/libexec/bacula/make_mysql_tables -u root -p
- /usr/libexec/bacula/grant_bacula_privileges -u root -p
NOTA: El acceso a mysql se configura por defecto con el usuario «bacula» sin password. Ésto se puede cambiar ejecutando mysql_setpermissions y adaptando la sección «Catalog» del fichero de configuración bacula-dir.conf, a las nuevas credenciales.
Fuente: http://wiki.bacula.org/
2. Configuración de bacula
Los ficheros de configuración de bacula, se encuentran en /etc/bacula, y serán necesarios una serie de cambios antes de poder iniciar los servicios de bacula. Puedes consultar aquí los cambios mínimos, en la sección «Edit config files and change the default passwords or the services will not start». Para testear bácula, bastará con realizar estos cambios mínimos.
Paciencia con la configuración y cuidado con los passwords introducidos, ya que es fácil equivocarse al asociar passwords entre ficheros.
Si se desea, se puede profundizar algo más en la configuración de cada elemento, destacando:
Director
En la configuración del director se definen, entre otros, los clientes (servidores que queremos incluir en el plan de backups). Para cada cliente, se definirá, en el fichero de configuración del director, las siguientes secciones:
- Client: entre otros parámetros, la sección contiene el nombre del cliente y dirección IP.
- FileSet: contiene el nombre del cliente definido en la sección «Client» así como los directorios a incluir en el backup. Se puede crear un fichero con el listado completo de directorios a incluir, y hacer referencia a este fichero con el carácter «<«, tal y como sigue:
- Job: definición del tipo de job (backup, restore, etc.), nombre del cliente al que hace referencia, nivel del job (incremental, full) y nombre del Storage, del Pool y del Schedule que usará, entre otros. En efecto, cada job define, qué, dónde, cómo y cuando (FileSet, Storage, Backup/Restore/Level y Schedule respectivamente).
File = </etc/bacula/clientes/clienteA/directory_list
Se pueden hacer «includes» en los ficheros de configuración, en cualquier parte del archivo, indicando la ruta del fichero a incluir con un @ delante. Ésto es una buena idea para por ejemplo, tener un include de cada cliente con sus correspondientes secciones, en lugar de tener un fichero bacula-dir.conf demasiado grande.
@/etc/bacula/clientes/clienteA.conf
Otros conceptos interesantes, que se definen en el fichero de configuración del Director, son el Storage, el Pool y el Schedule, los tres muy relacionados entre sí, y usados, como se ha comentado, en la defición de los Jobs:
- Storage: define donde está el componente storage instalado (bacula-sd). El bacula-sd ya tendrá la configuración del Storage, pero en esta sección de configuración dentro del Director, se deberán indicar algunos elementos que ya estarán definidos en el bacula-sd.conf, como son el nombre del dispositivo y el tipo de media:
- Device: debe coincidir con el nombre del Device o del Autochanger usado en el bacula-sd.
- Media Type: cadena de carácteres arbitraria que debe coincidir con el Media Type definido en la sección Device del bacula-sd.
- Schedule: define la política de backups (tipo de backup, y periodicidad). Ej:
- Pool: un pool es una agrupación lógica de volúmenes de almacenamiento (cintas o discos), que Bacula usará para almacenar los backups. Se puede especificar en el pool, el nombre del Storage usado, pero no hace falta, puesto que también se especificará en el Job. Con los pools, podemos por ejemplo dejar todos los full backups en un pool y los incrementales en otro (almacenando al final, los full en un conjunto de cintas/discos y los incrementales en otro diferente). También se podrían especificar diferentes pools para que cada cliente guarde los backups en su propio pool.
Run = Incremental mon-sat at 01:00
Run = Full 1st-5th sun at 00:30
Cliente (FD)
Como se ha visto, la configuración de los backups de cada cliente no se especifica en el bacula-fd.conf local de los clientes, si no que se centraliza desde el director. El bacula-fd.conf local de los clientes, únicamente especificará el nombre del cliente local, los mensajes, y qué directores podrán conectar con ese cliente.
Cuando se ejecuta un Job, se contactará con el cliente definido en el Job (recordemos que los Jobs se definen en la configuración del Director). Si se trata de un Job del tipo «backup», el cliente especificado en el Job hará el backup y se lo pasará directamente al Storage. Si se trata de un Job «restore», se le pasará el restore al cliente especificado en el Job, y se le restaurará allí donde se haya especificado en el Job.
3. BConsole
Si hemos seguido los pasos hasta ahora, tendremos el BConsole instalado en el server. Podremos entrar ejecutando, símplemente:
bconsole
Desde la consola tendremos varios comandos a ejecutar, de entre los que destacan:
- «help» para obtener el listado de comandos.
- «help comando» mostrará el detalle del comando, incuyendo los argumentos que espera. Muy, muy útil.
- «status» listará el estado de los diferentes componentes de bacula.
- Ejecutando «status 1» se mostrará el estado del director, listando los jobs programados y terminados. Con «status 2» se verá el estado del storage.
- «list volumes» mostrará los volumenes disponibles. Si no aparece ninguno o al empezar a hacer tests aparece un volumen con estado «BLOCKED» quizá debamos ejecutar «label» para darle una etiqueta al volumen.
- «list jobs» mostrará los últimos jobs.
- «run» lanzará un asistente que nos guiará para ejecutar un backup, de entre los definidos en el bacula-dir.conf. Mediante el asistente podremos modificar (mod) cualquier parámetro del job a lanzar, para escoger por ejemplo entre un backup incremental o un full, o la prioridad del mismo.
- «restore» igual pero para restaurar backups (run 3 no funcionará para restaurar).
4. Comunicaciones y firewalls
Al hacer un backup, si no se han cambiado los puertos por defecto, se seguirá la siguiente secuencia de comunicaciones:
- Console -> DIR:9101
- DIR -> SD:9103
- DIR -> FD:9102
- FD -> SD:9103
Como se puede observar en el punto 3, los clientes (FD) escuchan por el puerto 9102, y éstos conectan directamente contra el storage (SD) en el punto 4. Es importante asegurarse de que los diferentes componentes de bácula aceptan peticiones a su correspondiente puerto, con tal de asegurar el correcto funcionamiento de la solución de backups.
5. Webacula
Webacula es un proyecto que nos permite gestionar Bacula desde una cómoda interfaz web. Su instalación no es difícil, pero tiene una serie de requisitos que podrían resultar algo confusos. Aquí explican de forma detallada cómo instalarlo en Ubuntu, pero servirá de guia para otras distribuciones.
Fuentes:
- Instalar bacula en Fedora
- Guía práctica de Bácula por Matias Banchoff (pdf) (Enlace original aquí)
- Bacula main reference