cafe con bacula

Café con Bacula OSLUGR / canonigos / 28.01.2015

Café con Bacula / OSLUGR / canonigos / 28.01.2015

Bacula es una solución de Backup en red diseñado para funcionar en distintos sistemas operativos.

¿QUÉ ES BACULA?

Y… ¿QUIÉN HA CREADO BACULA? Bacula es un proyecto Open Source creado por Kern Sibbald en el año 2000 y que actualmente se distribuye bajo licencia AGPL v3.

UN PROYECTO OPEN SOURCE, BIEN. Bacula dispone también de una versión comercial llamada ‘Bacula Enterprise’ cuyas características más avanzadas van descendiendo a la versión ‘Community’ y que está desarrollada por Bacula Systems. También cuenta con una comunidad muy activa que incluso ha realizado un fork del proyecto, pero eso ya es otro cantar.

¿Y HACE FALTA TANTO PARA UN SIMPLE BACKUP? Bacula es una herramienta centralizada que funciona en múltiples plataformas, capaz de hacer su trabajo en distintos tipos de medios (cintas, discos externos o internos), confiable, segura y con características empresariales que la hacen una buena elección como sistema de Backup. Y además es Open Source. ¿ Qué mas quieres ?.

VALE, ME HAS CONVENCIDO. Lo sabía.

¿ME ENSEÑAS COMO FUNCIONA? Vamos a ello.


COMPONENTES DE BACULA File Daemon (FD)

Console Director (DIR)

Storage Daemon

(SD)

Catalog Database

Comandos de Usuario

Autorización

Atributos de Fichero Localización Almacenamiento

Atributos de Fichero Localización Almacenamiento

Comandos

PostgreSQL MySQL SQLite

Medios físicos

DIRECTOR


STORAGE DAEMON

FILE DAEMON

CONSOLE

CATALOG

DIRECTOR o DIR es un demonio de Bacula que se encarga de gestionar, autorizar, planificar y ejecutar todos los trabajos de copia que programemos dentro del sistema. La configuración de este demonio reside en el fichero bacula-dir.conf.

STORAGE DAEMON o SD es el demonio de Bacula encargado de guardar el backup en el medio físico seleccionado. Su fichero de configuración es el bacula-sd.conf. Puede contener la definición de distintos medios físicos y puede estar localizado en el mismo servidor que el demonio DIR o no.

FILE DAEMON o FD es el demonio cliente encargado de enviar la copia de seguridad según las directrices del DIR al SD en la planificación elegida. Un FD puede responder a varios DIR al mismo tiempo siempre que los tenga listados en su fichero de configuración bacula-fd.conf.

CONSOLE no es en sí un demonio sino una utilidad de consola que conecta con el DIR y que es capaz de consultar el estado del sistema de backup. Esta herramienta no es la única capaz de interactuar con el DIR sino que también existen consolas gráficas, web, etc. El fichero de configuración se llama bconsole.conf

CATALOG es la base de datos donde está alojada toda la información referente a los trabajos de backup, información al respecto de los ficheros guardados, agendas de copia, información de validez, etc. Puede haber un solo CATALOG o varios, la definición del mismo se hace dentro del bacula-dir.conf.


INSTALACIÓN

Bacula puede ser instalado mediante el gestor de paquetes de tu distribución favorita ya sea Linux, BSD (también en Windows y OSX) o desde los fuentes disponibles en Sourceforge. La instalación típica incluye DIR, SD y FD además de las librerías necesarias para conectarte a un Catalog de tu elección. Una vez instalado debes usar la herramienta bconsole para conectarte a la consola de Bacula y comprobar que todos los demonios están corriendo correctamente. Deberías ver algo así:

Y… ¿ AHORA QUÉ ? Antes de meternos a editar los ficheros de configuración de los distintos componentes conviene aclarar algunos conceptos que encontraremos en ellos, conformando la forma de trabajar de Bacula así como su funcionamiento.

canonigos@arthur:~$ bconsole Connecting to Director arthur.canonigos.es:9101 1000 OK: 1 arthur.canonigos.es-dir Version: 7.0.5 (28 July 2014) Enter a period to cancel a command. *

El * significa que estás dentro de la consola de comandos de Bacula y que puedes empezar a trabajar con la herramienta.


FUNCIONAMIENTO DE BACULA: El trabajo de copia ó Job

Bacula denomina como Job a la unidad básica de un trabajo de backup. Debe constar de un nombre, un tipo, una prioridad, un nivel, un cliente, un contenido, un destino, una organización dentro del destino y una agenda para ejecutarse. Aunque normalmente incluye más características.

Job { Name = ”CopiaHTDOCS" Type = Backup Level = Full Client = arthur.canonigos.es-fd FileSet = ”DirectorioHTDOCS" Schedule = ”DeLunesAViernesNoche" Storage = File Messages = Standard Pool = ServidorWeb Priority = 10 Write Bootstrap = "/var/lib/bacula/%c.bsr" }

Este Job realizaría un backup completo del directorio /var/www de nuestro cliente arthur.canonigos.es-fd en el destino File (un directorio de nuestro servidor Bacula) y mandaría un correo al buzón definido en los mensajes Standard al finalizar (o fallar, o pedir confirmación, etc…). La prioridad fijada es de 10, esto significa que se ejecutará junto a todos los trabajos de prioridad similar y antes que los trabajos de prioridad superior en número que sean programados DeLunesAViernesNoche, es decir, al mismo tiempo.

Job { Name = "RestoreFiles" Type = Restore Client = arthur.canonigos.es-fd FileSet = ”DummyFileSet" Storage = File Pool = Default Messages = Standard Where = /tmp/bacula-restores }


FUNCIONAMIENTO DE BACULA: La agenda de copia ó Schedule

Bacula ejecutará un Job conforme a nosotros definamos su ejecución en el fichero de configuración. Los parámetros de configuración para la agenda se definen dentro de la etiqueta Schedule.

Schedule { Name = ”DeLunesAViernesNoche" Run = Full mon-fri at 23:05 }

Schedule { Name = ”CicloMensual_1” Run = Full 1st sun at 23:05 Run = Differential 2nd-5th sun at 23:05 Run = Incremental mon-sat at 23:05 }

Schedule { Name = ”CicloMensual_2" Run = Full on 1 at 23:00 Run = Differential on 15 at 23:00 Run = Incremental on 2-14 at 23:00 Run = Incremental on 16-31 at 23:00 }

Schedule { Name = ”10Minutos" Run = Level=Full hourly at 0:05 Run = Level=Full hourly at 0:15 Run = Level=Full hourly at 0:25 Run = Level=Full hourly at 0:35 Run = Level=Full hourly at 0:45 Run = Level=Full hourly at 0:55 }

De lunes a Viernes a las 23:05 copia completa.

Completa el primer domingo del mes a las 23:05, desde el segundo domingo hasta el quinto a la misma hora nivel diferencial y de lunes a sábado incremental.

Completa el día 1 a las 23:00, diferencial el día 15 a la misma hora, incremental desde el día 2 al 14 y del 16 al 31.

Completa cada diez minutos.


FUNCIONAMIENTO DE BACULA: Qué copiamos o el Fileset.

Bacula define dentro del Fileset qué contenido copia del cliente FD y con qué características, también define qué no debe copiar (a modo de filtro), si ha de utilizar características WSS en Windows, si ha de comprimir y qué tipo de firma MD5 ó SHA1 incluirá dentro del Catalog.

FileSet { Name = ”MAIL" Include { Options { signature = SHA1 compression = LZO } File = /var/vmail } }

FileSet { Name = ”DocumentosUsuario" Include { Options { Enable VSS = yes signature = SHA1 IgnoreCase = yes } File = "C:/Users/usuario/Pictures" File = "C:/Users/usuario/Desktop" File = "C:/Users/usuario/Documents" } }

FileSet { Name = "Full Set" Include { Options { wildfile = "*.Z" wildfile = "*.gz" } Options { Exclude = yes RegexFile = ".*" } File = /myfile } }

FUNCIONAMIENTO DE BACULA: De quién copiamos o el Client


En Bacula hasta ahora hemos definido el trabajo de copia (Job), la agenda de copia (Schedule), qué copiaremos (Fileset), pero no de quién lo copiaremos. Esta definición se encierra en la etiqueta Client

Client { Name = equipocliente-fd Address = equipocliente.canonigos.es FDPort = 9102 Catalog = MyCatalog Password = “Passw0rd" File Retention = 24 months Job Retention = 24 months AutoPrune = yes }


FUNCIONAMIENTO DE BACULA: Dónde lo copiamos, Device y Storage.

Bacula configura el SD en el fichero de configuración bacula-sd.conf, allí tendremos que definir los dispositivos que tiene disponible para realizar copia dentro nuestro servidor.

Device { Name = SRV-RAID1 Media Type = File Archive Device = /srv/backup LabelMedia = yes; RandomAccess = yes; AutomaticMount = yes; RemovableMedia = no; AlwaysOpen = no; Maximum Concurrent Jobs = 20 }

Device { Name = LTO-3 Media Type = LTO-3 Archive Device = /dev/nst0 AutomaticMount = yes; AlwaysOpen = yes; RemovableMedia = yes; RandomAccess = no; Maximum File Size = 4GB }

Dentro de la configuración del DIR tenemos que definir los distintos Storage que queramos usar según sus Device

Storage { Name = File Address = arthur.canonigos.es SDPort = 9103 Media Type = File Maximum Concurrent Jobs = 20 Device = SRV-RAID1 Password = ”passw0rd" }

Storage { Name = Cinta Address = arthur.canonigos.es SDPort = 9103 Media Type = LTO-3 Maximum Concurrent Jobs = 1 Device = LTO-3 Password = ”passw0rd" }


FUNCIONAMIENTO DE BACULA: Colecciones de copias o los Pools.

El concepto de Pool en Bacula se usa como una colección de volúmenes (ficheros, cintas) que cumplen un mismo uso o que se engloban en una misma categoría. Por ejemplo, puedo utilizar un Pool para las copias incrementales de mi servidor de correo y mediante unos parámetros asegurarme que al menos tengo 10 copias mensuales incrementales de mi servidor antes de reutilizar o ciclar dicha copia de seguridad. La definición quedaría así:

Pool { Name = ”mail-inc" Pool Type = Backup Recycle = yes AutoPrune = yes Maximum Volumes = 10 Recycle Oldest Volume = yes Action On Purge = Truncate Label Format = ”mail-inc-” Use Volume Once = yes }

Este Pool contendría un máximo de 10 volúmenes que se irían auto nombrando como “mail-inc-001”, “mail-inc-002”, etc… Cada volumen sería capaz de guardar un solo Job de copia. Cuando llegásemos al máximo número de volúmenes el sistema se encargaría de reciclar el más antiguo cuando vuelva a tener lugar la ejecución de la copia de seguridad.

Si ejecutásemos un trabajo de copia incremental cada viernes de la semana (según la planificación expuesta en el Schedule), ¿cuántos meses de copias incrementales tendríamos almacenados?

Los Pool junto con los parámetros de configuración Volume Retention, Volume Use Duration y Maximum Volume Jobs nos permiten ciclar las copias de seguridad sobre un set de volúmenes de forma automática y así mantener bajo control nuestro espacio en disco o uso de cintas.


¿ QUEDA MUCHO ? – Sí y No.

No hemos visto la etiqueta Messages que define una forma de comunicarse con el operador de la herramienta según el trabajo de copia, puede haber distintas definiciones de la misma, por ejemplo, una dirección de email según qué cliente estemos respaldando, etc…

Otra etiqueta muy importante que no hemos visto definida (aunque es muy simple) es la del Catalog, esta etiqueta define el acceso (usuario/pass/conector) que utilizaremos para conectarnos a la base de datos elegida para guardar los datos que Bacula genera durante su ejecución. De igual forma no tiene porqué haber un solo Catalog y su uso queda a elección de quien ajuste e implante la instalación.

No podía dejar de explicar los componentes sin presentaros la definición del Director en sí mismo. Su tarjeta de presentación dentro del fichero de configuración es esta:

Director { Name = arthur.canonigos.es-dir DIRport = 9101 QueryFile = "/etc/bacula/query.sql" WorkingDirectory = "/var/lib/bacula" PidDirectory = "/var/run" Maximum Concurrent Jobs = 20 Password = ”passw0rd” Messages = Daemon }

Un Director en Bacula se define con un nombre, un puerto de acceso (9101/tcp), una contraseña para interactuar con él y algunos datos más como el número máximo de trabajos concurrentes que es capaz de ejecutar.


YA. Bacula es una herramienta muy potente con unos ficheros de configuración algo extensos (opinión personal) que aunque pueden ser divididos en pequeños trozos e incluidos con un simple comando requieren de una edición y una implantación cuidadosa para un funcionamiento óptimo. Como siempre es de recomendada lectura la página de documentación oficial del proyecto y el wiki del mismo. Así mismo las listas de correo principal y la española bacula-es tienen un flujo diario de correos bastante bueno donde se resuelven dudas desde y hacia la comunidad. No hemos hablado de características de seguridad que están presentes en Bacula como el cifrado de conexión entre demonios, clientes y Director vía TLS o la encriptación de los datos mediante PKI que son temas que podríamos tratar en una versión avanzada de esta presentación. Tampoco hemos hablado de las características de migración y copia entre distintos Storage que nos permiten sacar de nuestra oficina las copias para mantenerlas más seguras. Dichas características le confieren a Bacula una seguridad, estabilidad y fiabilidad que lo hacen una solución de Backup completa y de propósito general para cualquier instalación ya sea a nivel personal o profesional.

Documentación Oficial: http://www.bacula.org/7.0.x-manuals/en/main/index.html Wiki del Proyecto: http://wiki.bacula.org/doku.php Lista de Correo bacula-users: http://sourceforge.net/p/bacula/mailman/bacula-users/ Lista en Español: http://sourceforge.net/p/bacula/mailman/bacula-users-es/ Blog personal de Kern Sibbald http://blog.bacula.org/category/kerns-blog/ Blog personal de Dan Langille: http://dan.langille.org/category/open-source/bacula/

¿CÓMO QUE YA?


Dar las gracias a la OSL (http://osl.ugr.es) por dejarme enseñaros el proyecto.

Al Bacula (http://www.bacula.org) y su fundador Kern Sibbald.

Y a vosotros por asistir a este Café con Bacula.

¿OTRA TAZA…? ;-) Javier Funes (@canonigos) / [email protected]


PARTE PRÁCTICA MANOS A LA SHELL


h"p://crea*vecommons.org/licenses/by-‐nc-‐sa/3.0/es/

cafe con bacula

Technology