Configurando backups en Bacula

Bien, ya vimos en una receta anterior como instalar y configurar un sistema bacula pero se nos quedó en el tintero lo más importante: ¿cómo indicar a bacula qué ficheros respaldar? ¿cuándo? ¿cómo?. En esta receta explicaremos cómo terminar de configurar un sistema bacula para su operación normal, recomendamos la lectura de la receta anterior sobre bacula... esta es como un "segundo capítulo".

Trabajos de backup

A la hora de configurar un servicio de backup, antes de modificar a diestro y siniestro archivos de backup, debemos pensar un poco de qué queremos hacer backup y, según su importancia, cuándo y cómo. En el cómo tenemos dos alternativas: completo y diferencial. Un backup completo respaldará toda la lista completa de ficheros a guardar, en cambio, un backup diferencial sólo guarda los ficheros modificados y nuevos respecto a la copia anterior (lo cual permite ahorrar espacio en cintas). Una base de datos tipo MySQL no tiene mucho sentido hacer respaldo diferencial puesto que se almacena toda ella en un único archivo binario y las más mínima modificación implicará el almacenado del fichero completo. En cambio, para una lista de ficheros de texto (un proyecto software, por ejemplo) los incrementales vienen muy bien puesto que pocas veces cambiarán todos los ficheros a la vez sino que se modifican poco a poco. Para responder al cuándo debemos pensar en la importancia de los datos y en cuánto trabajo se va al garete si se perdieran los ficheros de un día para otro. Un conjunto de ficheros que se modifiquen a diario deberían respaldarse a diario, sin embargo, para ficheros que rara vez se modifiquen puede ser aceptable respaldarlos semanalmente, incluso mensualmente. Tengamos por ejemplo un sistema Debian, en él tenemos un apache con su php y su drupal, a parte, tiene muchos usuarios que tienen sus proyectos en sus homes. ¿Cómo lo respaldaríamos? pues un ejemplo podría ser el siguiente: cada dos meses un backup del sistema completo (básicamente somos muy vagos y pasamos de reinstalarlo todo en caso de desastre, de esta forma podríamos restaurar el sistema completo sin mucho esfuerzo... aunque existen programas más adecuados para esto, ej: mindi y mondo); como la configuración del sistema es realmente más importante que el resto de archivos del sistema (puesto que un binario del sistema se encuentra a mano en el repositorio de paquetes, un archivo de configuración modificado por nosotros... pues no) realizaremos backups incrementales mansuales (tampoco se modifican taaanto) de los datos variables en la distribución, es decir /etc y parte de /var. También tenemos la base de datos MySQL, esto es más complicado puesto que no podemos hacer copia así como así de ella (¿que pasa si se modifica mientras se está haciendo backup?), la solución pasa por leerse la receta: Salvar (y recuperar) una base de datos MySQL y hacer backup de eso (esto podría ser motivo de una nueva receta). Por último tenemos los homes de los usuarios, como queremos que pierdan poco en caso de desastre realizaremos backups incrementales diarios y completos semanales (esto facilita la recuperación). Una vez decidido cómo va a funcionar nuestro servicio de backup sólo nos queda configurar bacula director para que lo haga... pues empecemos...

Resource FileSet

Este resource define la lista de ficheros a respaldar. También permite establecer opciones útiles, como por ejemplo calcular sumas MD5 de verificación, o usar compresión gz, etc. Veamos un ejemplo:

FileSet {
  Name = "configuracion sistema"
  Include {
    File = /etc
    File = /var
    Options {
      signature = MD5
    }
  }
  Exclude {
    File = /var/log
    File = /var/cache
    File = /var/tmp
  }
}

Pues muy fácil, hemos creado un conjunto de ficheros, llamado configuracion sistema que incluye todos los ficheros y subdirectorios en /etc. De /var también metemos todo menos la "guarrería" :-P. Además, de los archivos que almacenemos se calculará la suma MD5 para comprobar que se salvaron correctamente. Se pueden usar comodines en plan /usr/share/*/examples y cosas así, tanto para Include como para Exclude. Se pueden especificar ficheros aislados, etc. Echad un vistazo al manual de bacula que vienen muchos ejemplos interesantes. El FileSet por defecto de bacula es el sistema de ficheros completo. Podemos crear los que queramos y posteriormente los identificaremos por su nombre.

Resource Schedule

Mediante estos resources se crean los intervalos de tiempo que emplearemos a la hora de crear los trabajos, al igual que los FileSet los identificaremos por un nombre, por ejemplo:

Schedule {
  Name = "CicloSemanal"
  Run = Incremental mon-sat at 01:05
  Run = Full sun at 01:05
}
Schedule {
  Name = "Diario"
  Run = Full sun-sat at 23:10
}

Hemos creado dos: CicloSemanal y Diario, como véis, en el primero se realizan backups incrementales de lunes (monday) a sábado (saturday) a las 01:05h y el domingo (sunday) a la misma hora uno completo. En el otro schedule se realizan backups completos a diario. Por defecto éstos son los schedule de bacula (salvo por la hora). El diario se emplea para hacer backup del catálogo de bacula.

Resource JobDefs

Aquí es donde finalmente pegaremos todo lo anterior para definir un trabajo completo de backup, si hemos entendido todo hasta aquí no hay mucho que explicar:

JobDefs {
  Name = "estado del sistema"
  Enabled = yes
  Type = Backup
  Level = Incremental
  Client = nombre_resource_filedaemon
  FileSet = "configuracion sistema"
  Schedule = "CicloSemanal"
  Storage = nombre_resource_storage
  Messages = Standard
  Pool = Default
  Priority = 10
}

Los campos Client y Storage se explicaron suficientemente en la receta anterior. El Level también se puede especificar aquí, pero si se especifica en el Schedule se usará el de éste último. En Priority indicaremos un número, cuanto menor sea, más prioritario es el trabajo (en caso de que se envíen varias peticiones a un storage daemon, por ejemplo, se atienden por orden de prioridad). En cuanto al Pool... lo explicaremos más adelante :-P. Por defecto en bacula existen dos trabajos: DefaultJob que hace backups incrementales diarios de todo el sistema y completo los domingos, después de cada backup hace uno completo del catálogo.

Resource Job

Todos los campos de un JobDef son válidos para este resource también, la diferencia es que el anterior era la definición de un trabajo y este es el trabajo propiamente dicho. Si tenemos una buena definición, el trabajo quedaría como sigue:

Job {
  Name = "estado maquina"
  JobDefs = "estado del sistema"
  Write Bootstrap = "/var/lib/bacula/estado_maquina.bsr"
}

Con esto tendremos un trabajo en bacula llamado estado maquina, configurado como se indicó en estado del sistema. Además se creará una especie de log sobre el trabajo en el archivo indicado. Éste trabajo será el que podamos arrancar, parar, etc. Ahora sólo nos queda saber una cosa, la organización del sistema de almacenamiento: los pools.

Resource Pool

En bacula se denomina volume a una cinta física (o archivo de backup). Un conjunto de volumes es un pool. Podemos definir varios para distintos propósitos, por ejemplo: en un pool almacenamos copias incrementales y en otro copias completas. Al instalar bacula se define un pool llamado Default de la siguiente forma:

Pool {
  Name = Default
  Pool Type = Backup
  Recycle = yes
  AutoPrune = yes
  Volume Retention = 365 days
}

El parámetro Pool Type indica el tipo (uy que listo soy!), el único implementado en bacula es Backup, tienen intención de soportar otros como Migration, Cloned, etc. Los últimos tres parámetros tienen que ver con el reciclaje de cintas. Si no quedan mas volúmenes y se permite su reciclado, cuando un volumen sea más antiguo que su periodo de retención (un año en el ejemplo) será sobreescrito por backups nuevos. Hay que decir que en un Pool podemos especificar parámetros como Client o Storage, que serían los que utilizaría bacula a menos se especificase lo contrario en otra resource "superior". Así pues podemos definir una especie de "valores por defecto" en una pool. Si nos fijamos bien, en ningún parámetro se especifica qué volúmenes forman parte de esta pool... ¿cómo se hace eso? esto ya debemos hacerlo desde la bacula console. En el caso de las cintas se deben identificar con una etiqueta software que ponemos a las cintas con el comando label/relabel y posteriormente el comando add para añadir un volumen a un pool:

*label
Automatically selected Catalog: MyCatalog
Using Catalog "MyCatalog"
The defined Storage resources are:
     1: File
     2: respaldadora-sd
Select Storage resource (1-2): 2
Enter new Volume name: cinta01
*add
You probably don't want to be using this command since it
creates database records without labeling the Volumes.
You probably want to use the "label" command.
Automatically selected Catalog: MyCatalog
Using Catalog "MyCatalog"
Automatically selected Pool: Default
The defined Storage resources are:
     1: File
     2: respaldadora-sd
Select Storage resource (1-2): 2
Enter number of Volumes to create. 0=>fixed name. Max=1000: 0
Enter Volume name: cinta01

Podemos facilitarnos la vida un poco más si en el storage daemon, los resource tipo device que empleemos tienen la opción LabelMedia = yes, esto hará que bacula vaya etiquetando las cintas limpias o reciclables según vaya necesitándolas, es ese caso no necesitamos ejecutar label para nada. Pues bien, con nuestro pool bien creado y los jobs bien definidos ya tenemos nuestro servicio de backup funcionando... ahora a esperar que no tengamos que usarlo!

Apéndice A: configuración completa de un bacula director

Para hacer una receta de copia-pega vamos a incluír un archivo de configuración completo para el bacula-director, ya sabéis, el archivo /etc/bacula/bacula-dir.conf:

Director {
  Name = respaldadora-dir
  DIRport = 9101
  QueryFile = "/etc/bacula/scripts/query.sql"
  WorkingDirectory = "/var/lib/bacula"
  PidDirectory = "/var/run/bacula"
  Maximum Concurrent Jobs = 1
  Password = "password_para_respaldadora-dir"
  Messages = Daemon
  DirAddress = 127.0.0.1 # Esto obliga a que las consolas bacula solo se puedan ejecutar desde localhost
}

Client {
  Name = importante-fd
  Address = 192.168.0.1
  FDPort = 9102
  Catalog = MyCatalog
  Password = "password_para_respaldadora-dir"
  File Retention = 30 days
  Job Retention = 6 months
  AutoPrune = yes
}

Storage {
  Name = File
  Address = 192.168.0.2
  SDPort = 9103
  Password = "password_para_respaldadora-dir"
  Device = FileStorage
  Media Type = File
}

Storage {
  Name = respaldadora-sd
  Address = 192.168.0.2
  SDPort = 9103
  Password = "password_para_respaldadora-dir"
  Device = Autochanger
  Media Type = DDS-4
  Autochanger = yes
}

Catalog {
  Name = MyCatalog
  dbname = bacula; DB Address = "" ; user = bacula; password = "password_de_bbdd"
}

Messages {
  Name = Standard
  mailcommand = "/usr/lib/bacula/bsmtp -h localhost -f \"\(Bacula\) %r\" -s \"Bacula: %t %e of %c %l\" %r"
  operatorcommand = "/usr/lib/bacula/bsmtp -h localhost -f \"\(Bacula\) %r\" -s \"Bacula: Intervention needed for %j\" %r"
  mail = root@localhost = all, !skipped
  operator = root@localhost = mount
  console = all, !skipped, !saved
  append = "/var/lib/bacula/log" = all, !skipped
}

Messages {
  Name = Daemon
  mailcommand = "/usr/lib/bacula/bsmtp -h localhost -f \"\(Bacula\) %r\" -s \"Bacula daemon message\" %r"
  mail = root@localhost = all, !skipped
  console = all, !skipped, !saved
  append = "/var/lib/bacula/log" = all, !skipped
}

Pool {
  Name = Default
  Pool Type = Backup
  Recycle = yes
  AutoPrune = yes
  Volume Retention = 365 days
}

Console {
  Name = respaldadora-mon
  Password = "password_para_respaldadora-mon"
  CommandACL = status, .status
}

JobDefs {
  Name = "Usuarios"
  Enabled = yes
  Type = Backup
  Level = Incremental
  Client = importante-fd
  FileSet = "homes"
  Schedule = "Semanal"
  Storage = respaldadora-sd
  Messages = Standard
  Pool = Default
  Priority = 10
}

JobDefs {
  Name = "Sistema"
  Enabled = yes
  Type = Backup
  Client = importante-fd
  FileSet = "sistema sin homes"
  Schedule = "Mensual"
  Storage = respaldadora-sd
  Messages = Standard
  Pool = Default
  Priority = 10
}

Job {
  Name = "Backup Usuarios"
  JobDefs = "Usuarios"
  Write Bootstrap = "/var/lib/bacula/importante_homes.bsr"
}

Job {
  Name = "Backup Sistema"
  JobDefs = "Sistema"
  Write BootStrap = "/var/lib/bacula/importante_sistema.bsr"
}

FileSet {
  Name = "homes"
  Include {
    File = /home
    Options {
      signature = MD5
    }
  }
  Exclude {
    File = *.avi
    File = *.iso
    File = *.mp3
    File = ~*
    File = /home/*/tmp
  }
}

FileSet {
  Name = "Sistema sin homes"
  Include {
    File = /
    Options {
      signature = MD5
    }
  }
  Exclude {
    File = /home
    File = /var/tmp
    File = /var/log
    File = /var/cache
    File = /var/run
    File = /dev
    File = /proc
    File = /sys
    File = /lost+found
}

Schedule {
  Name = "Semanal"
  Run = Incremental mon-sat at 01:05
  Run = Full sun at 01:05
}

Schedule {
  Name = "Mensual"
  Run = Full on 1 at 01:05
}

Usar este archivo tal cual no es muy recomendable por varias razones, la más importante es que no hace backup del catálogo de bacula, el archivo por defecto de bacula si lo hace; por otro lado, tampoco tiene el trabajo de restauración de ficheros (lo cual puede ser peor...), por tanto coged las partes que os interesen. ;-)

Apéndice B: Comandos útiles en la consola de bacula

El más importante:

*help

;-) ...y después:

*m

Este último te muestra los mensajes que hubiese pendientes, tales como: Job completed o error at XXXX... lo que sea. También podemos ver que tal van las cosas en bácula:

*status

Nos preguntará de qué queremos el estado, le decimos que 4 (all) y listo. Para saber qué se va a respaldar exactamente podemos estimar el trabajo, fácil:

*estimate
*estimate listing

Primero aparecerá una lista de los trabajos configurados, elegiremos el que queramos estimar, es el primer caso nos aparecerá el número de ficheros que respaldará y cuanto ocupara la copia. En el segundo, a parte de eso, nos saldrán todos los ficheros. Para mostrar un listado de los volúmenes que tenemos configurados:

*list volumes

Esto mostrará todos los volúmenes del pool actual, cuánto llevan ocupado, retenido, etc. Si queremos saber qué tal van los trabajos también usamos list, pero esta vez:

*list jobs

Nos aparecerá un resumen de lo más chulo: trabajos terminados, erróneos, etc. Si queremos forzar la ejecución de un trabajo:

*run

Nos aparecerá una lista de trabajos y seleccionaremos el que queramos, automáticamente pasará a la lista de trabajos y de ahí a ejecutarse. Como véis la consola no es nada difícil... es hasta intuitivo... ;-)

Apéndice C: Recuperar archivos respaldados

Resulta que tenéis vuestro servicio de backup funcionando y (Santa Tecla no lo quiera) resulta que perdéis vuestros ficheros. Pues nada... no preocuparse... arrancamos la bacula console y ejecutamos lo siguiente:

* restore
First you select one or more JobIds that contain files
to be restored. You will be presented several methods
of specifying the JobIds. Then you will be allowed to
select which files from those JobIds are to be restored.
To select the JobIds, you have the following choices:
     1: List last 20 Jobs run
     2: List Jobs where a given File is saved
     3: Enter list of comma separated JobIds to select
     4: Enter SQL list command
     5: Select the most recent backup for a client
     6: Select backup for a client before a specified time
     7: Enter a list of files to restore
     8: Enter a list of files to restore before a specified time
     9: Find the JobIds of the most recent backup for a client
    10: Find the JobIds for a backup for a client before a specified time
    11: Enter a list of directories to restore for found JobIds
    12: Cancel
Select item:  (1-12):

Pues nada... seleccionaremos lo que deseemos, una buena opción es la 5: Select the most recent backup for a client, es decir: seleccionar el backup más reciente de un cliente. Seleccionamos esto y nos apareceran los FileSets disponibles:

Automatically selected Client: arco-fd
The defined FileSet resources are:
     1: homes
     2: Sistema sin homes
Select FileSet resource (1-2):

Ahora seleccionaremos el primero (o el que necesitéis), después de eso bacula buscará en qué cintas está lo que buscamos y se hará sus cuentas (buscará todos aquellos ficheros que deba recuperar) y nos mostrará una shell al estilo bash:

You are now entering file selection mode where you add (mark) and
remove (unmark) files to be restored. No files are initially added, unless
you used the "all" keyword on the command line.
Enter "done" to leave this mode.
cwd is: /
$

Si introducimos help veremos una lista de comandos disponibles, tenemos cd y ls de toda la vida (navegaremos por todos los ficheros posibles para recuperar según lo que eligiésemos). Luego tenemos mark y markdir para marcar (recursivamente) archivos a recuperar, los archivos que con ls aparezca un asterisco delante, significa que está marcado (en caso contrario no está seleccionado para recuperar).

$ mark *
94,668 files marked.

Con lsmark mostramos sólo archivos marcados. Podemos desmarcarlos con unmark y unmarkdir. También podemos estimar la cantidad de volumen que llevamos marcado con estimate. Cuando lo tengamos todo a punto:

$ done
Bootstrap records written to /var/lib/bacula/stallman-dir.restore.3.bsr
The job will require the following
   Volume(s)                 Storage(s)                SD Device(s)
===========================================================================
   cinta0004                 stallman-sd               Autochanger
94,668 files selected to be restored.
Run Restore job
JobName:    RestoreFiles
Bootstrap:  /var/lib/bacula/respaldadora-dir.restore.3.bsr
Where:      /tmp/bacula-restores
Replace:    always
FileSet:    Full Set
Client:     importante-fd
Storage:    respaldadora-sd
When:       2007-03-19 21:02:49
Catalog:    MyCatalog
Priority:   10
OK to run? (yes/mod/no):

Si decimos que yes lanzará el trabajo que se ejecutará cuanto antes. Podemos cambiar el directorio destino donde guardará todos los archivos recuperados (en el ejemplo /tmp/bacula-restores) introduciendo mod, en cuyo caso mostrará una lista de parámetros modificables. Hay que decir que este directorio es local a la máquina que ejecuta el client (un bacula file daemon) que aparece en el resumen y que seleccionamos al principio del proceso de restauración.

Enlaces

La receta Copias de seguridad con Bacula en sistemas GNU y sus enlaces... :-P Bacula: The Open Source Commercial Backup Solution

[ show comments ]

this

related

recent