Bacula
Enlaces y referencias
- Ref: Documentación de Bacula 2.4.x
- Ref: Manipulación de volúmenes y otros aspectos.
- Ref: Bacula File list specification by InkFist
Sustitución de valores
La siguiente tabla es una relación de las sustituciones de textos y valores que realiza Bacula en recursos como RunScript y MailCommand.
Texto | Valor de sustitución |
---|---|
%% | % |
%c | Nombre del cliente |
%d | Nombre del director |
%e | Código de salida del trabajo |
%i | Identificador de trabajo (JobId) |
%j | Identificador único de trabajo (Unique Job id) |
%l | Nivel de copia del trabajo (full, differential, incremental) |
%n | Nombre del trabajo |
%s | Fecha y hora de comienzo |
%t | Tipo de trabajo (Backup, Restore, ...) |
%v | Nombre del volumen (sólo en el lado del director) |
Recetario
Periodo de retención
El periodo de retención en los volúmenes se guarda junto con el resto de la información en la base de datos, más concretamente en la tabla media, y una forma de manipularlo es mediante la orden update
del menú de consola o accediendo directamente al gestor de bases de datos:
update media set
volretention = 7776000
where poolid = 5 and volretention <> 777600;
En este caso se actúa únicamente sobre el pool de volúmenes 5 y se cambia dicho periodo de retención de datos a 3 meses de tiempo puesto que el valor está expresado en segundos.
Una vez efectuado ésto, y siempre que los volúmenes estén marcados como Full o Append, bacula efectuará un purgado de los mismos si
Automatizando tareas con la consola
Es posible hacer funcionar la consola de Bacula desde un programa para automatizar su funcionalidad. Para ello se invoca el programa empleando el archivo de configuración correspondiente y se le pasan todas las órdenes procedentes de un archivo (o el mecanismo similar que proporciona el shell con el operador <<).
$ bconsole -c bconsole.conf << END_OF_COMMANDS
@output /tmp/bconsole.log
purge volume volume=copia-0012
wait
messages
@output
quit
END_OF_COMMANDS
Lo anterior está redireccionando toda la salida de información de la consola a un archivo en el directorio /tmp
, purgando un volumen, esperando el resultado, mostrando los posibles mensajes, desactivado la salida y abandonando la consola.
No hay muchas posibilidades de controlar nada a menos que se emplee algo tan potente y complejo como Expect, así que lo mejor es realizar operaciones simples en cada ocasión.
Tareas administrativas en lotes
También es posible dentro una sesión interactiva con la consola efectuar tareas por lotes.
Para ello es bueno emplear algo como lo siguiente
Connecting to Director maginot.venexma.int:9101
1000 OK: maginot-dir Version: 2.4.4 (28 December 2008)
Enter a period to cancel a command.
* @tee /tmp/bacula.log
* @input archivo-de-ordenes
* ...
ya que hace una copia de la salida de resultados en un archivo antes de leer la entrada.
AVISO: es muy importante asegurarse antes de que el archivo de órdenes es correcto, porque las consecuencias pueden resultar fatales en caso contrario, especialmente si se incluyen confirmaciones como la palabra yes. Bacula no distingue si es un humano el que está al otro lado; se limita a obedecer a mucha velocidad.
Salvar la lista de paquetes instalados
Para asegurarse de incluir desde un único punto la configuración más completa de una máquina con Debian es necesario salvar la lista de paquetes instalada.
El programa dpkg puede obtener dicha información en un formato fácilmente manejable pero debe ejecutarse, logicamente, en la máquina cliente ya que la base de datos sita en /var/lib/dpkg
es siempre local.
Así pues, creamos un pequeño script y lo guardamos en /etc/bacula/scripts/dpkg.sh
con el siguiente contenido:
#!/bin/bash /usr/bin/dpkg --get-selections > /etc/apt/dpkg-selections.txt
Ahora en el director de copias (que puede ser la misma máquina o no), en la definición del trabajo, planificamos la ejecución del anterior.
Job { ... ClientRunBeforeJob="/etc/bacula/scripts/dpkg.sh" }
Y todo lo anterior parte de la premisa de que el directorio /etc
completo será incluído en la copia. Si no es el caso el archivo resultante debería guardarse en otro sitio.
Ejecución de programas con las copias
En la definición de un trabajo de copias se puede emplear una clasúla concreta para indicar qué programas ejecutar antes y después de una copia, así como en el lado del cliente o en el del servidor.
Job { ... RunScript { Orden [Orden] ... } }
Estas son las órdenes posibles:
Orden | Valores | Por defecto | Descripción |
---|---|---|---|
Runs On Success | Yes/No | Yes | Ejecuta el programa si el trabajo de copia finaliza con éxito (JobStatus). |
Runs On Failure | Yes/No | No | Ejecuta el programa si el trabajo de copia falla. |
Runs on Client | Yes/No | Yes | Ejecuta el comando en la máquina cliente. |
Fail Job On Error | Yes/No | Yes | Da por fallido el trabajo de copia si el programa finaliza su ejecución con un código de salida distinto de cero. |
Command | (Puede aparecer múltiples veces) |
Programa a ejecutar según las condiciones anteriores. Por defecto se ejecuta antes del trabajo y en el lado cliente. El valor contenido en este campo se filtra para sustituir algunos símbolos -detallados aquí- pero el resultado final no incluye una expansión shell. | |
Console | (También puede aparecer múltiples veces) |
Orden enviada a la consola del director de copias: delete, disable, enable, estimate, list, llist, memory, prune, purge, reload, status, setdebug, show, time, trace, update, version, .client, .jobs, .pool, .storage. |
Informes por correo
Dentro de la configuración de Bacula existe un apartado dedicado al registro de los sucesos de todo el sistema bajo el nombre de Messages Resource, y que permite establecer una reglas para que cada evento sea registrado de forma diferente si es necesario.
Todos los componentes demonio de Bacula tienen uno, aunque lo habitual es que en el que se encarga de leer los ficheros (File daemon) y en el que se encarga de almacenarlos (Storage daemon) se disponga que dichos mensajes se envíen al director de copias y así garantizar que cada trabajo combine todos los mensajes que ha podido crear.
La definición completa de un recurso de mensajes es algo compleja porque clasifica los mensajes según un nivel de importancia (INFO,ERROR,...), indica por dónde pueden ir (mail, console, append, ...), a quién van (dirección de correo) y bajo qué condiciones.
En el caso de los mensajes envíados por correo existe una directiva que define el programa a emplear para enviar dichos mensajes y es
MailCommand = <command>
empleando Bacula el valor mail -s "Bacula Message" <recipients>
como sustituto en caso de ausencia de dicha directiva.
El texto command es la línea de ejecución del programa al que enviar el informe. Antes de invocarlo se le aplica una sustitución de variables como la que se detalla aquí por lo que es factible personalizar su enunciado.
Medios de copia
Recopilación de datos y hechos útiles cuando se trata de medios físicos de copia de datos.
dd: Cannot allocate memory
Si el programa dd
indica este error (en español No se pudo asignar memoria) se debe a que no se le ha especificado el tamaño de bloque para las operaciones de lectura.
Una forma de obtenerla es emplear el parámetro ibs
con un tamaño mínimo (64k por ejemplo) y seguir subiendo hasta que no aparezca el error.
# dd if=/dev/nst0 of=/dev/null
dd: leyendo «/dev/nst0»: No se pudo asignar memoria
0+0 records in
0+0 records out
0 bytes (0 B) copied, 0,00142151 s, 0,0 kB/s
# dd if=/dev/nst0 of=/dev/null ibs=64k count=1
0+1 records in
126+0 records out
64512 bytes (65 kB) copied, 0,004695 s, 13,7 MB/s
#