Bacula: copias de seguridad en red
El programa Bacula es una aplicación de software libre que permite efectuar copias de seguridad en una red de ordenadores heterogénea.
Su arquitectura está basada en los siguientes componentes:
- Servidor de archivos: para instalar en los clientes y chupar de éstos la información.
- Servidor de almacenamiento: encargado de transferir a dispositivos físicos la información producida por el servidor de archivos.
- Base de datos: encargada de registrar lo sucedido con las copias de seguridad.
- Servidor de copias: encargado de poner en marcha todo el sistema, comunicando unos con otros, anotar los resultados y generar informes de trabajo.
- Consola de control: punto de entrada para los administradores del sistema de copias.
En palabras de uno de sus creadores, en la entrevista citada más abajo:
... Also, we made a commitment to upward compatibility of backup media. DLT tapes have a retention time of 30 years, and it's only reasonable to expect your software to be able to read them if the hardware can--the software problem is a lot easier to solve!
Lo atractivo de su diseño es que los citados componentes pueden estar en máquinas diferentes de la red, y ser al mismo tiempo víctimas de las copias y servidores de éstas.
Todo el trabajo lo lleva a cabo el director de copias. Los clientes sólo saben quién puede controlarlos y a dónde tienen que enviar los mensajes. Es por eso por lo que estos servidores de archivos deben funcionar contínuamente (como servicios) en las máquinas cliente; nunca saben cuándo van a ser llamados para operar. Es más, incluso ignoran a qué servidor de almacenamiento tienen que enviar los datos; esto se les comunica por parte del director en el momento de iniciar una copia (ó una restauración).
La configuración puede ser, en ocasiones, algo compleja y es que hay que considerar que no está pensado para efectuar copias a matacaballo, y es preciso efectuar un diseño inicial detallado y una planificación de recursos cuidadosa.
Otras características son:
- La comunicación entre componentes puede cifrarse
- Es capaz de manejar varios volúmenes físicos (encadenados) si los datos no caben en uno, y recordar e identificar cuál es el correcto. Por ejemplo cintas DAT y DVDs.
Secciones
Tipos de recursos en bacula
Operaciones
A continuación un recetario sobre el uso y la administración de bacula
Verificar la configuración
Para efectuar una verificación de la configuración de bacula podemos usar el programa demonio correspondiente, pasándole el parámetro -t para verificarlos y el -c más la ruta de acceso al archivo que queremos verificar:
# cd /etc/bacula
# bacula-dir -t -c bacula-dir.conf
10-nov 10:30 bacula-dir: ERROR TERMINATION at parse_conf.c:853
Config error: Keyword "passwd" not permitted in this resource.
Perhaps you left the trailing brace off of the previous resource.
: line 8, col 8 of file /etc/bacula/sarajevo.conf
passwd = ""
lo anterior es un mensaje de error típico (e involuntario) que sirve de muestra de lo que se puede esperar.
Para el resto de los archivos se usarán los programas indicados como en:
# cd /etc/bacula
# bacula-fd -t -c bacula-fd.conf
# bacula-sd -t -c bacula-sd.conf
# bconsole -t -c bconsole.conf
Depuración
Aunque un poco pesado existe un mecanismo para verificar el funcionamiento de bacula, y que consiste en ejecutar los programas correspondientes con la opción de depuración activa:
# bacula-dir -d100 -c /etc/bacula/bacula-dir.conf
# bacula-sd -d100 -c /etc/bacula/bacula-sd.conf
y así con todos aquellos que necesitemos, sobre todo la consola:
# bconsole -d100 -c /etc/bacula/bconsole.conf
para la que existe otra posibilidad, y es la de usar la orden setdebug para cambiar la locuacidad del programa sobre la marcha, no sólo de él, sino de todos los otros componentes del sistema como puede verse en el siguiente ejemplo de sesión:
* setdebug
Enter new debug level: 100
Available daemons are:
1: Director
2: Storage
3: Client
4: All
Select daemon type to set debug level (1-4): 4
Connecting to Storage daemon Disco at maginot.venexma.int:9103
3000 OK setdebug=100
Connecting to Client sarajevo-fd at sarajevo.venexma.int:9102
2000 OK setdebug=100
*
Mensajes
Lo anterior está muy bien y es muy fácil de usar. Ahora bien, ¿ dónde se envían los dichosos mensajes de depuración ?
Pues a donde le digamos, por lo menos según la documentación, en el recurso de mensajes de la configuración del demonio correspondiente.
En el siguiente caso vamos a disponer en el cliente una claúsula especial para que añada la información a un archivo en el sistema local, además de enviarlos al director. En este caso estamos excluyendo mensajes sobre archivos excluídos del trabajo y los de terminación.
1 Messages { 2 Name = Standard 3 director = sarajevo-dir = all, !skipped, !restored 4 append = "/var/log/bacula/log" = all, !skipped, !terminate 5 }
Trazado
En un momento dado me he encontrado con que una simple conexión con el director de copias provocaba una caída completa del sistema. La pista a seguir me la ha dado (previa indicación de mi compañero Angel) que funcionase como root y no con el usuario propio bacula.
Para averigüar exactamente qué hace el programa puede utilizarse la siguiente receta:
# /etc/init.d/bacula-director stop
# strace -f -o /tmp/bacula.log /usr/sbin/bacula-dir -c \
/etc/bacula/bacula-dir.conf -u bacula -g bacula
que viene a ser la misma que utiliza el programa correspondiente en /etc/init.d.
Tras la ejecución comprobamos el archivo de traza (*/tmp/bacula.log) que, en nuestro caso, lo que fallaba era que no tenía acceso al catálogo correspondiente al cliente Sarajevo. Dicho archivo era propiedad absoluta de root y bacula era incapaz de abrirlo.
Ah, el parámetro -f de strace es útil para cuando se efectúa un fork del proceso y necesitamos seguirle la pista a los hijos.
Configuración en red
Existen varios tipos de configuración en red que presentan varios niveles de dificultad. Estoy reuniendo aquí anotaciones y referencias sobre ellos:
Anecdotario
Relación de anécdotas y casos con los que me encuentro, su explicación y posible solución si la encuentro.
Max configured use duration exceeded.
Dentro del recurso pool es posible establecer un límite de tiempo para usar
un volumen en trabajos de copia, antes de marcarlos como usados y pasar a
estar bajo la política de reciclado.
Esto puede ser útil para no emplear durante mucho tiempo volúmenes en copias incrementales ó diferenciales, e ir rotándolas entre sí.
El único problema que plantea es que este valor Volume Use Duration se
almacena junto al volumen en el momento de su creación en el catálogo, por lo
que cualquier cambio en el archivo de configuración del director de copias
sólo sirve para los nuevos volúmenes y no para los que ya existen. En caso de
necesitar cambiar este parámetro en los volúmenes existentes (usados ó no aún
en copias), es emplear una orden de la consola
llamada update:
*update
Update choice:
1: Volume parameters
2: Pool from resource
3: Slots from autochanger
Choose catalog item to update (1-3): 1
Parameters to modify:
1: Volume Status
2: Volume Retention Period
3: Volume Use Duration
4: Maximum Volume Jobs
5: Maximum Volume Files
6: Maximum Volume Bytes
7: Recycle Flag
8: Slot
9: InChanger Flag
10: Volume Files
11: Pool
12: Volume from Pool
13: All Volumes from Pool
14: Done
Select parameter to modify (1-14):
La opción número tres nos permite cambiar el valor de uso para un volumen
concreto, aunque si son muchos se convierte en una tarea muy pesada y propensa
a errores. Es mejor emplear la opción trece (All volumes from Pool) que toma
los valores de la definición del pool y las aplica a todos los volúmenes
registrados en el catálogo.
Enlaces
- Página principal de Bacula
- Entrevista a uno de los fundadores y desarrollador principal: Kern Sibbald.
- Introducción a Bacula.
- Tutorial en Libertonia de amphora
- Artículo en PDF de Linux Magazine
- Documentación de Bacula:
- Tutorial breve en bacula.org
- Configuración de demonios: