Hoy toca iniciar otra serie de entradas de “divulgación informática” (sin olvidar otras pendientes o en curso, q todo llegará a su debido momento), algo asi como una “Introducción a la gestión de copias de seguridad con fundamento”. La idea es no solo montar un Bacula sino refrescar un poco los típicos conceptos del mundillo de las copias de seguridad para tenerlos bien amarrados y asi poder saltar a otras soluciones con facilidad.
Qué es Bacula y cuándo utilizarlo
Bacula es un software libre que realiza copias de seguridad a nivel de fichero. Punto. Ni es un sistema para hacer imágenes completas ni está´orientado específicamente a restaurar sistemas totalmente descojonados, aunque puede ayudar claro está.
La diferencia fundamental entre el típico scripiti que todos nos hemos currado en bash en algún momento, tirando de herramientas como cp o dd o tar para hacer copias de ficheros, rotarlos y moverlos a otras máquinas, y Bacula son 2 fundamentalmente:
-
Bacula mantiene un Catálogo en base de datos donde se registran todas las operaciones realizadas.
-
A grandes rasgos Bacula implementa 2 módulos independientes: el Director o programa que gestiona las copias de seguridad, y los agentes, instalados en cada máquina a hacer backup.
Como se verá a lo largo de estos articulillos este esquema está muy simplificado ya que en realidad el sistema permite desgranar sus diversas funciones en otros tantos procesos independientes, de forma que retengamos el máximo control a la hora de hacer el deploy de las diferentes piezas para poder así disponer de un sistema bien balanceado. Si embargo a los efectos puede que sea complicar innecesariamente la solución ya que la mayor parte de la gente solo va a tener 1 servidor de copias y luego n agentes desperdigados por la red, tal y como se muestra en la figura. En este caso concreto la máquina que alberga al Director tendrá también el Catalogo y los sistemas de almacenamiento (típicamente cintas o disco duro) directamente conectados; por la otra parte habrá agentes, uno en cada servidor que vayamos a copiar.
Sobre las plataformas soportadas solo decir que el agente funciona tanto en el mundo Windows como Linux o Mac pero el Director solo rula Linux que yo sepa. No voy a tratar temas concretos de Sistemas Operativos en esta serie de artículos asi que mas o menos y con las salvedades típicas en este mundillo (Unidades, ACLs etc) , todo lo que se diga es “SO independendent”.
Tampoco se verán temas específicos de cintas: se trata de visualizar un poco el tema de forma general concretando para un caso particular y dando las herramientas necesarias para poder retorcer la configuración a nuestro gusto, ampliando la lectura de lo aqui expuesto, y no de resolver “porque mi distro no me detecta la cinta de marca tal”.
Procesos
Vamos a poner nombre y función a los procesos que intervienen en este tinglado aunque por la figura de arriba bien se pueden intuir cuales van a ser:
-
Director: es la madre del cordero. Podemos pensar en el Director como en un director de orquesta y en un router de datos: dice cuando hacer las cosas, obtiene los resultados y los manda a los procesos necesarios.
-
File Daemon (FD): Es el Agente de la figura: un proceso que corre en el servidor del que vamos a hacer la copia. Recibe ordenes del Director, inicia las copias y se las pasa a éste.
-
Console: no esta representado en la figura, es un proceso que se conecta al Director para administrar el servicio. Hay varios tipos de consola soportados pero aqui se usara el principal, la consola de línea de comandos, que es la mas completa de todas las opciones.
-
Storage Daemon (sd): Es el proceso que maneja los medios de almacenamiento. Normalmente van a estar conectados al Director pero podría ser que tuviéramos un servidor externo conectado a una cabina de discos, o de cintas. Este proceso recibe los datos y los vuelca en los medios definidos.
-
Catalog: es un proceso que interactúa con la base de datos que contiene el catalogo. Típicamente también va en la maquina que alberga el proceso Director pero puede ir en una independiente. El Catalogo será explicado mas adelante, pero para ir afinando diré que es una base de datos donde quedan grabados todos los procesos de copia y la información de todos los ficheros que lo componen, con su fecha y hora, tamaño de cada fichero y de la copia completa, lugar donde se restauran, lugar donde se almacenan físicamente etc. Es una especie de índice de todo lo que va ocurriendo. Ojo que no contiene los datos, los ficheros en si mismos. La consola entonces es, en esencia, un traductor o front-end de la base de datos formado en base a comandos más o menos amigables, generando las sentencias Select necesarias sobre esa base de datos y recabando y formateando los resultados. El catalogo en si mismo puede estar almacenado en MySQL, SQLite o PostGreSQL. Aqui se usara MySQL aunque para volúmenes muy bajos de datos quizá valga con SQLite.
-
Monitor: tampoco queda reflejado en la figura anterior y de hecho este modulo no lo vamos a tocar. Solo funciona en GTK+ asi que lo suyo seria instalar unas X en el Director (cosa que no haremos) para poder ejecutar ese programa, que nos reporta de forma grafica el estado de las copias y el de cada uno de los procesos aqui descritos.
En resumen: tenemos un Director que pide datos a los FD y los manda al SD que los graba en el medio de almacenamiento definido. A su vez el Director envía datos de carácter informativo (algo asi como MetaDatos) al Catalog que los escribe en el motor de base de datos de nuestra elección. Y de regalo tenemos una consola que se conecta al Director para ver el estado de las copias, listar su contenido etc.
Conceptos y términos
A continuación indico los conceptos fundamentales sobre los que descansa todo el entramado. Esto no solo hay que tenerlo claro sino que hay que manejarlo con soltura. Primero lo suelto a zorrombollón y luego desgrano un poco.
“Una copia de seguridad esta formada por una serie de Jobs de varias Clases y Tipos, que involucran diferentes FileSets obtenidos de uno o mas FDs, grabados en uno o mas Pools de Volúmenes ejecutados según se defina en un Schedule.”
El Job o Trabajo define practicamente todo lo necesario para empezar a funcionar en Bacula:
-
El “Qué” se copia: Se copia el resultado de aplicar un FileSet (definiciones de grupos de ficheros, con inclusiones y exclusiones de directorios, tipos de archivos por extensión etc)
-
El “De Donde” se copia: Los datos se obtienen de aplicar un FileSet a uno o varios FDs (File Daemon, los agentes instalados en los servidores a copiar)
-
El “Cuando”: el Scheduler indica que días, a que horas y con que periodicidad se lanzan los Jobs.
-
La Clase del trabajo: restauración, backup o verificación.
-
El Tipo: Completa, incremental, diferencial.
-
El “Hacia Donde se copia”: donde se dejan las copias. En primera instancia se envían al SD (Storage Daemon) pero además se indica la agrupación de medios de almacenamiento (Pool formado por Volúmenes) donde se dejaran los datos: típicamente un grupo de 7 cintas para hacer el rotado diario, un grupo de 4 cintas para el semanal etc…
En resumen: tenemos una copia de seguridad formada por el Job “copia webs” de clase “backup” y de tipo “Full” (copia completa), que se conecta al FD “servidor Web” con un FileSet que incluye el directorio local al servidor web “/var/html/” del que sacara todos los ficheros a copiar, dejando los datos en el Pool “Webs” formado por 7 Volúmenes (cintas) llamadas “Copia-x“, donde x será la fecha de la copia, que el Scheduler lanzará a la 1 de la mañana todos los días.
Un diagrama complementario podría ser el siguiente:
Vemos al Director recibiendo los ficheros a hacer backup desde los File Daemon (lo que se copia de cada File Daemon se define en un FileSet o set de ficheros), enviando la información del Job al Catalogo (que puede ser un servidor externo con MySQL o el mismo Director), recibiendo instrucciones del cuando hacer la copia por parte del Scheduler y enviando los ficheros al Storage Daemon que en este caso tiene una única unidad de cinta conectada y el Pool “1” definido, que consta de 2 Volúmenes, de tipo cinta, que el administrador del sistema cambiara cuando el Bacula se lo pida.
Prácticamente esto es todo lo necesario para empezar a trabajar con Bacula; no obstante en la próxima entrega ampliaremos un poco mas algunos de los conceptos vistos, ya que hay cosas como los Pools, los Volúmenes y su reciclado o el mismo Catalogo que merecen ser bien tratados.