Bacula 2021

INSTALACIÓN Y CONFIGURACIÓN DE BACULA
DOCUMENTO DISTRIBUIDO BAJO LICENCIA CREATIVE COMMONS BY-SA.
Para conocer las condiciones de esta licencia, por favor, consulta en

http://creativecommons.org/licenses/by-sa/3.0/es/
Basado en los documentos “Instalar un sistema Bacula en GNU” y “Configurando Backups

en Bacula”,ambos de Tobías Díaz Díaz-Chirón.
Qué es bacula
Bacula es un programa para hacer copias de seguridad de una máquina... pues no del todo: bacula es una
colección de demonios que cooperan entre sí para realizar copias de respaldo de los archivos necesarios,
sean de la máquina que sea. Para interactuar con bacula se necesita un elemento más: la consola de
bacula. Todos estos elementos son independientes entre sí y pueden estar en máquinas distintas, así pues
el principal problema a la hora de configurar bacula consiste en hacer que todos estos elementos se
comuniquen correctamente entre ellos.
Los elementos necesarios para que bacula funcione son:
• bacula-dir (o bacula-director)
• bacula-sd (o bacula-storage daemon)
• bacula-fd (o bacula-file daemon)
Si, como es de suponer, queremos poder interactuar con el servicio de backup, necesitaremos:
• bacula-console (disponible en varios sabores:gnome y wx)
bacula-director
Es el demonio que maneja al resto. El servidor de la base de datos MySQL debe estar accesible desde la
máquina que ejecuta el director (o estar en ella misma y escuchar en localhost... como viene siendo
habitual en Debian). Debe poder acceder tanto al bacula-sd como al bacula-fd para poder leer los archivos
a guardar y para poder guardarlos en el soporte físico final.
En el archivo de configuración del director configuraremos dónde y cómo acceder al resto de demonios, la
contraseña para el acceso mediante bacula-console y los trabajos o jobs.
IMPLANTACIÓN DE SISTEMAS OPERATIVOS PROFESOR: JOSÉ CARLOS GALLEGO CANO

bacula-storage daemon
Este demonio es el encargado de manejar el dispositivo de almacenamiento de los backups; esto exige
que este demonio esté instalado en la máquina que contenga físicamente el dispositivo de
almacenamiento, que puede ser: archivos en el disco local, grabadoras de CD o DVD y unidades de cinta.
Su archivo de configuración define el (o los) dispositivos de almacenamiento que maneja así como que
directores pueden utilizarlo.
bacula-file daemon
Mediante este demonio bacula obtiene los ficheros que necesita respaldar, así pues éste es el componente
que hay que instalar en las máquinas que necesiten respaldo.
El archivo de configuración es el más simple de todos, símplemente especifica qué directores pueden
realizarle peticiones.
bacula-console
Una vez instalado y configurado bacula comenzará a realizar copias de seguridad el solito sin intervención
nuestra, pero puede suceder que queramos forzar una copia cuando nosotros lo deseemos, o que
tengamos que recuperar unos ficheros (protégenos Santa Tecla) o símplemente saber qué tal está nuestro
bacula. Para ello necesitamos este componente, similar a una shell pero con pocos comandos (resulta
hasta intuitivo... en serio...). Existen varios tipos de consolas: en modo texto, para gnome, con widgets
wx, etc. Supongo que también existirán clientes gráficos que no tengan nada que ver con una consola y
que harán lo mismo... yo por ahora no he buscado ninguno...
Qué necesitamos
Bueno, bacula necesitará de una base de datos SQL para apuntar sus cosillas, así pues es necesario tener
instalado y configurado MySQL.
No es obligatorio pero si muy recomendable que todas las máquinas que intervengan en el proceso sean
accesibles por un nombre de dominio (o tengan IP estática).
Si tenemos nuestra base de datos lista ya podemos instalar en la máquina que realizará los backups los
siguientes paquetes:

# apt-get install bacula-director-mysql
Bueno, hay que decir que exiten más versiones del director: pqsql (para postgress SQL, sqlite y sqlite3
(imaginad...). En la instalación del director os pedirán los datos necesarios para configurar la base de
datos que necesitará bacula. Es muy sencillo y si os equivocáis simplemente haced:
# dpkg-reconfigure bacula-director-mysql
Y arregláis el fallo.
Ahora, en la máquina que tenga nuestra unidad de almacenamiento (una cinta, por ejemplo) y que puede
ser la misma o no que la anterior, instalamos lo siguiente:
# apt-get install bacula-sd bacula-sd-tools
Al igual que el director, este componente también tiene más alternativas: mysql, pgsql, sqlite y sqlite3.
Usaremos el simple porque nuestro director ya se encargará de crear catálogos y todo eso, no es
necesario que nos los cree también el storage daemon.
Finalmente, instalaremos lo siguiente en la máquina que queramos respaldar:
# apt-get install bacula-fd
Ahora sólo nos faltará configurar todo esto para que se comuniquen entre sí... vamos a ello!

Configurando bacula-fd
Por ser más simple será el primero que configuremos, echemos un vistazo a su archivo de configuración
(/etc/bacula/bacula-fd.conf):
Director {
Name = director_admitido1
Password = "password_chorrotronica_para_el_director_admitido1"
Director {
Name = backup-mon
Password = "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
Monitor = yes
FileDaemon {
Name = nombre_del_file-daemon
FDport = 9102
WorkingDirectory = /var/lib/bacula
Pid Directory = /var/run/bacula
Maximum Concurrent Jobs = 20
FDAddress = maquina.dominio # O si tiene IP estatica pues X.X.X.X
# Esto es nuevo en bacula 2.0.0
Messages {
Name = Standard
director = director_admitido1 = all, !skipped, !restored

Vemos que los archivos de configuración tienen una estructura que se repite:
nombre_resource {
opcion = valor
...
Es lo que en bacula llaman resources. Un resource define un elemento de bacula, hay muchos tipos de
resources diferentes, cada uno con sus propias opciones. El manual describe detalladamente todos ellos...
En este archivo hemos definido tres tipos de resources distintos:
• Director: Identifica qué director puede conectarse con este file daemon; como veis se definen dos:
director_admitido1 y backup-mon. El segundo es un director especial que actúa de monitor... se
configura automáticamente. El primero es el que hemos añadido/modificado nosotros. El nombre
que especificamos es el nombre que hemos dado a nuestro director (lo veremos más adelante) y la
password es la que se espera que dé cuando se autentifique.
• FileDaemon: Define los parámetros del propio file daemon, parámetros como el puerto de escucha
o la IP a la que debe asociarse (recordad que si esa IP es 127.0.0.1 el demonio sólo aceptará
conexiones de la propia máquina local). Como véis también especifica el nombre que se da a
nuestro file daemon, es importante que coincida con el nombre que luego introduciremos en el
director.
• Messages: Indica qué mensajes podemos enviar a cada director.
Una vez modificado el archivo reiniciaremos el demonio y lo tendremos listo para funcionar con bacula,
ahora vayamos con el siguiente.

Configuración de bacula-sd
Abramos su archivo de configuración (/etc/bacula/bacula-sd.conf) y veamos sus resources (este es
una modificación del "original", para utilizar como almacenamiento un carrusel automático de cintas con
seis slots):
Storage {
Name = nombre_del_storage-daemon
SDPort = 9103
WorkingDirectory = "/var/lib/bacula"
Pid Directory = "/var/run/bacula"
SDAddress = maquina.dominio
Director {
Director {
Name = backup-mon
Password = "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
Monitor = yes
Device {
Name = FileStorage
Media Type = File
Archive Device = /tmp
LabelMedia = yes; # lets Bacula label unlabeled media
Random Access = Yes;
AutomaticMount = yes; # when device opened, read it

RemovableMedia = no;
AlwaysOpen = no;
Autochanger {
Name = Autochanger
Device = Tape1, Tape2, Tape3, Tape4, Tape5, Tape6
Changer Command = "/etc/bacula/scripts/mtx-changer %c %o %S %a %d"
Changer Device = /dev/sg2
Device {
Name = Tape1
Drive Index = 0
Autochanger = yes
Media Type = DDS-4
Archive Device = /dev/nst0
AutomaticMount = yes
RemovableMedia = yes
RandomAccess = no
AutoChanger = yes
LabelMedia = yes
...
Device {
Name = Tape6
Drive Index = 0
Autochanger = yes
Media Type = DDS-4

RandomAccess = no
AutoChanger = yes
LabelMedia = yes
Messages {
Name = Standard
director = director_admitido1 = all
• Storage: Como antes, se define así mismo y qué parámetros usar.
• Director: Igual que en el file daemon.
• Device: Especifica un dispositivo de almacenamiento manejado por el storage daemon. El nombre
que se le da aquí y el tipo de medio es el que luego necesitaremos usar en el director. Es
importante aclarar que si tenemos un dispositivo de cintas con una sola unidad no será necesario
definir tantos "devices" como cintas tengas, ya que todas serán cargadas por el autochanger
• Autochanger: Es un Device especial que define un cargador automático de cintas. Se debe indicar
el comando a emplear para usar el cargador.
Existen muchísimos parámetros para los resources de tipo device…
Configurando bacula-director
Este es el archivo más complicado. Ahora veremos una parte y más adelante la otra.
Veamos la parte que nos interesa ahora, tenemos esto en el fichero /etc/bacula/bacula-dir.conf:
Director {
DIRport = 9101
QueryFile = "/etc/bacula/scripts/query.sql"
PidDirectory = "/var/run/bacula"

Password = "password_chorrotronica_para_las_consolas" # Console password
Messages = Daemon
DirAddress = 127.0.0.1 # Esto sólo vale para las consolas
[... cosas interesantísimas que ahora no vienen a cuento ...]
Client {
Name = nombre_del_file-daemon
Address = maquina.dominio
FDPort = 9102
Catalog = MyCatalog
Password = "password_chorrotronica_para_el_director_admitido1" # pwd for FD
File Retention = 30 days # 30 days
Job Retention = 6 months # six months
AutoPrune = yes # Prune expired Jobs/Files
Storage {
Name = File
SDPort = 9103
Device = FileStorage
Media Type = File
Storage {
Name = nombre_del_almacenamiento

SDPort = 9103
Device = Autochanger
Media Type = DDS-4
Autochanger = yes
Catalog {
Name = MyCatalog
dbname = bacula; DB Address = "" ; user = bacula; password = "XXXXX"
[...cosas tremendamente interesantes que ahora tampoco explicaremos...]
Como este tiene más complicación, explicaremos resource a resource más despacito.
Director
Igual que en los casos anteriores, se define a sí mismo, los campos habituales son:
• Name: Nombre que damos al director. Es el mismo nombre que hemos permitido en los otros
demonios.
• DIRport: Puerto de escucha para las consolas.
• QueryFile: Archivo con las consultas a la bbdd.
• WorkingDirectory: Directorio de trabajo (no cambiar).
• PidDirectory: Directorio donde crear los archivos con pid.
• Maximum Concurrent Jobs: Número máximo de trabajos concurrentes que acepta. En los casos
anteriores teníamos un valor mayor a 1, esto permitirá que varios directores utilicen esos
demonios a la vez. Establecer aquí este valor a 1 implica que el director sólo hará un trabajo cada
vez, que es el valor por defecto.
• Password: Contraseña que se pedirá al programa de consola. Esta contraseña no se pide por
teclado sino que también se almacena en el archivo de configuración del programa de consola.
• Messages: Donde se enviarán los mensajes no asociados a un trabajo concreto.

• DirAddress: Dirección donde escuchará el director. Indicar 127.0.0.1 implicará que no podrán
abrirse consolas bacula en máquinas remotas, pero no causa problemas si tenemos los demás
demonios en otras máquinas puesto que es el director el que abre las conexiones con los otros
demonios.
Client
Aquí especificaremos los datos del bacula file daemon con el que necesitamos conectar para leer los
ficheros necesarios. Para ello especificaremos lo siguiente:
• Name: Nombre del file daemon. Este nombre no tiene porqué coincidir con el que dimos a nuestro
file daemon, es para nombralo dentro de bacula. Mi recomendación es que coincida, más que nada
para entendernos mejor.
• Address: IP o hostname de la máquina que tiene nuestro file daemon.
• FDPort: Puerto donde escucha el file daemon.
• Catalog: Qué catálogo usa nuestro file daemon. Un catálogo es algo así como un listado de los
ficheros que se están respaldando.
• Password: Contraseña que enviará el director al file daemon para autentificarse.
• File Retention: Este parámetro indica cuanto tiempo deben permanecer los archivos en el catálogo.
Pasado este tiempo se eliminan del catálogo (pero esto no influye en que se haga o no backups de
estos ficheros).
• Job Retention: Indica cuanto tiempo como máximo estará un trabajo esperando.
• AutoPrune: Si está a yes, una vez pasados los periodos File Retention y/o Job Retention se
eliminan del catálogo y/o cola los ficheros/trabajos.
Storage
Ahora especificaremos los dispositivos que podrá emplear bacula para hacer las copias de respaldo,
pueden existir varios (que se diferenciarán por el nombre). Debemos indicar los siguientes campos:
• Name: Nombre del medio de backup. No es el nombre del storage daemon sino del medio, por
ejemplo: Carrusel_cintas o Fichero_local, etc.
• Address: Máquina donde está el storage daemon que maneja el medio de almacenamiento.
• SDPort: Puerto de escucha.
• Password: Contraseña que enviará el director para autentificarse contra el storage daemon.

• Device: Nombre del medio configurado en el storage daemon que debemos usar. Como dijimos,
el storage daemon configura uno o varios dispositivos de almacenamiento, nombrándolos de
alguna manera. Pues ese nombre es el que usamos aquí.
• Media Type: Cuando se configura el medio se especifica que tipo de medio es, aquí también
tenemos que indicarlo (y debe coincidir). Bacula lo usa para "hacer sus cuentas".
• Autochanger: Parámetro opcional, indica si es o no un autocargador.
Catalog
• Name: Nombre del catálogo (que usamos en el resource del file daemon).
• dbname: Nombre de la base de datos.
• DB Address: Máquina donde tenemos nuestro servidor MySQL.
• user: Usuario con privilegios en la base de datos especificada anteriormente suficientes como para crear
y modificar datos.
• password: Password de dicho usuario en esa base de datos.
Bien, con todo esto ya tenemos un sistema bacula distribuido funcionando a las mil maravillas... para
comprobarlo podemos hacer lo siguiente:
# apt-get install bacula-console
Y lo configuramos para conectarse a nuestro director modificando /etc/bacula/bconsole.conf:
Director {
Name = nombre_director-dir
DIRport = 9101
address = maquina_director.dominio
Password = "passwordchorrotronicaparalasconsolas"
}
Si todo ha ido bien podremos ejecutar bconsole como root o como un usuario que pertenezca al grupo
bacula y teclear lo siguiente:
*status
El asterisco es el prompt de la consola de bacula, ejecutamos status y le decimos que all cuando nos
pregunte de qué queremos el estado. Si algún componente no puede contactarse, se notificará con el error
correspondiente. Si no obtenemos ninguno de esos errores tenemos el bácula funcionando. Ahora sólo nos
queda indicarle qué archivos hay que respaldar y cuando.

Existe un problema que no puede detectarse así y que es muy peligroso: puede suceder que el director
pueda comunicarse con el storage daemon y con el file daemon, por tanto dirá que todo esta funcionando;
sin embargo, el storage daemon y el file daemon no puedan conectarse entre sí; esto provocará que los
backups darán siempre error y no se realizarán. Esto sucede porque cuando el director va a hacer una
copia, conecta al file daemon con el storage daemon directamente y ellos dos realizan las transferencias
de datos. Debéis tener esto en cuenta cuando pongáis vuestro bacula a funcionar.
Apéndice A: Preparar la base de datos bacula en MySQL
Bueno, como dijimos antes, la instalación de bacula por paquetes no crea la base de datos que utiliza para
realizar los backups, así que nosotros haremos ese trabajo "a mano". Vamos a asumir que tenemos
correctamente instalado y funcionando MySQL Server y phpmyadmin (tal y como se quedan después de
una instalación con apt-get).
La base de datos que debemos crear es la que se especificó en el resourceCatalog que vimos
anteriormente, por ejemplo una base de datos llamada bacula (que es la usada por defecto). La creamos
con phpmyadmin, también podemos crear el usuario (que por defecto también debe ser uno llamado
bacula) con la contraseña que hayamos especificado. Lo único que debemos hacer ahora es crear unas
tablillas y listo, la siguiente porción de código SQL (que se puede pegar directamente en phpmyadmin y
listo) lo debería resolver (por cierto que está sacado de un script que viene en los paquetes de bacula pero
que a mi no me funcionaba):
USE bacula;
CREATE TABLE Filename (
FilenameId INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
Name BLOB NOT NULL,
PRIMARY KEY(FilenameId),
INDEX (Name(255))
);
CREATE TABLE Path (
PathId INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
Path BLOB NOT NULL,
PRIMARY KEY(PathId),

INDEX (Path(255))
);
CREATE TABLE File (
FileId INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
FileIndex INTEGER UNSIGNED DEFAULT 0,
JobId INTEGER UNSIGNED NOT NULL REFERENCES Job,
PathId INTEGER UNSIGNED NOT NULL REFERENCES Path,
FilenameId INTEGER UNSIGNED NOT NULL REFERENCES Filename,
MarkId INTEGER UNSIGNED DEFAULT 0,
LStat TINYBLOB NOT NULL,
MD5 TINYBLOB,
PRIMARY KEY(FileId),
INDEX (JobId),
INDEX (PathId),
INDEX (FileNameId, PathId),
INDEX (JobId, PathId, FilenameId)
);
CREATE TABLE MediaType (
MediaTypeId INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
MediaType TINYBLOB NOT NULL,
ReadOnly TINYINT DEFAULT 0,
PRIMARY KEY(MediaTypeId)
);
CREATE TABLE Storage (
StorageId INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
Name TINYBLOB NOT NULL,
AutoChanger TINYINT DEFAULT 0,
PRIMARY KEY(StorageId)

);
CREATE TABLE Device (
DeviceId INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
MediaTypeId INTEGER UNSIGNED DEFAULT 0 REFERENCES MediaType,
StorageId INTEGER UNSIGNED DEFAULT 0 REFERENCES Storage,
DevMounts INTEGER UNSIGNED DEFAULT 0,
DevReadBytes BIGINT UNSIGNED DEFAULT 0,
DevWriteBytes BIGINT UNSIGNED DEFAULT 0,
DevReadBytesSinceCleaning BIGINT UNSIGNED DEFAULT 0,
DevWriteBytesSinceCleaning BIGINT UNSIGNED DEFAULT 0,
DevReadTime BIGINT UNSIGNED DEFAULT 0,
DevWriteTime BIGINT UNSIGNED DEFAULT 0,
DevReadTimeSinceCleaning BIGINT UNSIGNED DEFAULT 0,
DevWriteTimeSinceCleaning BIGINT UNSIGNED DEFAULT 0,
CleaningDate DATETIME DEFAULT 0,
CleaningPeriod BIGINT UNSIGNED DEFAULT 0,
PRIMARY KEY(DeviceId)
);
CREATE TABLE Job (
JobId INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
Job TINYBLOB NOT NULL,
Type BINARY(1) NOT NULL,
Level BINARY(1) NOT NULL,
ClientId INTEGER DEFAULT 0 REFERENCES Client,
JobStatus BINARY(1) NOT NULL,
SchedTime DATETIME DEFAULT 0,
StartTime DATETIME DEFAULT 0,

EndTime DATETIME DEFAULT 0,
RealEndTime DATETIME DEFAULT 0,
JobTDate BIGINT UNSIGNED DEFAULT 0,
VolSessionId INTEGER UNSIGNED DEFAULT 0,
VolSessionTime INTEGER UNSIGNED DEFAULT 0,
JobFiles INTEGER UNSIGNED DEFAULT 0,
JobBytes BIGINT UNSIGNED DEFAULT 0,
JobErrors INTEGER UNSIGNED DEFAULT 0,
JobMissingFiles INTEGER UNSIGNED DEFAULT 0,
PoolId INTEGER UNSIGNED DEFAULT 0 REFERENCES Pool,
FileSetId INTEGER UNSIGNED DEFAULT 0 REFERENCES FileSet,
PriorJobId INTEGER UNSIGNED DEFAULT 0 REFERENCES Job,
PurgedFiles TINYINT DEFAULT 0,
HasBase TINYINT DEFAULT 0,
PRIMARY KEY(JobId),
INDEX (Name(128))
);
CREATE TABLE Location (
LocationId INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
Location TINYBLOB NOT NULL,
Cost INTEGER DEFAULT 0,
Enabled TINYINT,
PRIMARY KEY(LocationId)
);
CREATE TABLE LocationLog (
LocLogId INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
Date DATETIME DEFAULT 0,
Comment BLOB NOT NULL,
MediaId INTEGER UNSIGNED DEFAULT 0 REFERENCES Media,

LocationId INTEGER UNSIGNED DEFAULT 0 REFERENCES Location,
NewVolStatus ENUM('Full', 'Archive', 'Append', 'Recycle', 'Purged',
'Read-Only', 'Disabled', 'Error', 'Busy', 'Used', 'Cleaning') NOT NULL,
NewEnabled TINYINT,
PRIMARY KEY(LocLogId)
);
CREATE TABLE FileSet (
FileSetId INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
FileSet TINYBLOB NOT NULL,
MD5 TINYBLOB,
CreateTime DATETIME DEFAULT 0,
PRIMARY KEY(FileSetId)
);
CREATE TABLE JobMedia (
JobMediaId INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
MediaId INTEGER UNSIGNED NOT NULL REFERENCES Media,
FirstIndex INTEGER UNSIGNED DEFAULT 0,
LastIndex INTEGER UNSIGNED DEFAULT 0,
StartFile INTEGER UNSIGNED DEFAULT 0,
EndFile INTEGER UNSIGNED DEFAULT 0,
StartBlock INTEGER UNSIGNED DEFAULT 0,
EndBlock INTEGER UNSIGNED DEFAULT 0,
VolIndex INTEGER UNSIGNED DEFAULT 0,
Copy INTEGER UNSIGNED DEFAULT 0,
Stripe INTEGER UNSIGNED DEFAULT 0,
PRIMARY KEY(JobMediaId),
INDEX (JobId, MediaId)
);

CREATE TABLE Media (
MediaId INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
VolumeName TINYBLOB NOT NULL,
Slot INTEGER DEFAULT 0,
PoolId INTEGER UNSIGNED DEFAULT 0 REFERENCES Pool,
MediaType TINYBLOB NOT NULL,
MediaTypeId INTEGER UNSIGNED DEFAULT 0 REFERENCES MediaType,
LabelType TINYINT DEFAULT 0,
FirstWritten DATETIME DEFAULT 0,
LastWritten DATETIME DEFAULT 0,
LabelDate DATETIME DEFAULT 0,
VolJobs INTEGER UNSIGNED DEFAULT 0,
VolFiles INTEGER UNSIGNED DEFAULT 0,
VolBlocks INTEGER UNSIGNED DEFAULT 0,
VolMounts INTEGER UNSIGNED DEFAULT 0,
VolBytes BIGINT UNSIGNED DEFAULT 0,
VolParts INTEGER UNSIGNED DEFAULT 0,
VolErrors INTEGER UNSIGNED DEFAULT 0,
VolWrites INTEGER UNSIGNED DEFAULT 0,
VolCapacityBytes BIGINT UNSIGNED DEFAULT 0,
VolStatus ENUM('Full', 'Archive', 'Append', 'Recycle', 'Purged',
'Read-Only', 'Disabled', 'Error', 'Busy', 'Used', 'Cleaning') NOT NULL,
Enabled TINYINT DEFAULT 1,
Recycle TINYINT DEFAULT 0,
VolRetention BIGINT UNSIGNED DEFAULT 0,
VolUseDuration BIGINT UNSIGNED DEFAULT 0,
MaxVolJobs INTEGER UNSIGNED DEFAULT 0,
MaxVolFiles INTEGER UNSIGNED DEFAULT 0,
MaxVolBytes BIGINT UNSIGNED DEFAULT 0,
InChanger TINYINT DEFAULT 0,

StorageId INTEGER UNSIGNED DEFAULT 0 REFERENCES Storage,
DeviceId INTEGER UNSIGNED DEFAULT 0 REFERENCES Device,
MediaAddressing TINYINT DEFAULT 0,
VolReadTime BIGINT UNSIGNED DEFAULT 0,
VolWriteTime BIGINT UNSIGNED DEFAULT 0,
EndFile INTEGER UNSIGNED DEFAULT 0,
EndBlock INTEGER UNSIGNED DEFAULT 0,
LocationId INTEGER UNSIGNED DEFAULT 0 REFERENCES Location,
RecycleCount INTEGER UNSIGNED DEFAULT 0,
InitialWrite DATETIME DEFAULT 0,
ScratchPoolId INTEGER UNSIGNED DEFAULT 0 REFERENCES Pool,
RecyclePoolId INTEGER UNSIGNED DEFAULT 0 REFERENCES Pool,
Comment BLOB,
PRIMARY KEY(MediaId),
INDEX (PoolId)
);
CREATE INDEX inx8 ON Media (PoolId);
CREATE TABLE Pool (
PoolId INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
NumVols INTEGER UNSIGNED DEFAULT 0,
MaxVols INTEGER UNSIGNED DEFAULT 0,
UseOnce TINYINT DEFAULT 0,
UseCatalog TINYINT DEFAULT 0,
AcceptAnyVolume TINYINT DEFAULT 0,
VolRetention BIGINT UNSIGNED DEFAULT 0,
VolUseDuration BIGINT UNSIGNED DEFAULT 0,
MaxVolJobs INTEGER UNSIGNED DEFAULT 0,
MaxVolFiles INTEGER UNSIGNED DEFAULT 0,

MaxVolBytes BIGINT UNSIGNED DEFAULT 0,
AutoPrune TINYINT DEFAULT 0,
Recycle TINYINT DEFAULT 0,
PoolType ENUM('Backup', 'Copy', 'Cloned', 'Archive', 'Migration', 'Scratch') NOT NULL,
LabelType TINYINT DEFAULT 0,
LabelFormat TINYBLOB,
Enabled TINYINT DEFAULT 1,
ScratchPoolId INTEGER UNSIGNED DEFAULT 0 REFERENCES Pool,
RecyclePoolId INTEGER UNSIGNED DEFAULT 0 REFERENCES Pool,
NextPoolId INTEGER UNSIGNED DEFAULT 0 REFERENCES Pool,
MigrationHighBytes BIGINT UNSIGNED DEFAULT 0,
MigrationLowBytes BIGINT UNSIGNED DEFAULT 0,
MigrationTime BIGINT UNSIGNED DEFAULT 0,
UNIQUE (Name(128)),
PRIMARY KEY (PoolId)
);
CREATE TABLE Client (
ClientId INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
Uname TINYBLOB NOT NULL, /* full uname -a of client */
AutoPrune TINYINT DEFAULT 0,
FileRetention BIGINT UNSIGNED DEFAULT 0,
JobRetention BIGINT UNSIGNED DEFAULT 0,
UNIQUE (Name(128)),
PRIMARY KEY(ClientId)
);
CREATE TABLE Log (
LogId INTEGER UNSIGNED AUTO_INCREMENT,
JobId INTEGER UNSIGNED DEFAULT 0 REFERENCES Job,

Time DATETIME DEFAULT 0,
LogText BLOB NOT NULL,
PRIMARY KEY(LogId),
INDEX (JobId)
);
CREATE TABLE BaseFiles (
BaseId INTEGER UNSIGNED AUTO_INCREMENT,
BaseJobId INTEGER UNSIGNED NOT NULL REFERENCES Job,
FileId INTEGER UNSIGNED NOT NULL REFERENCES File,
FileIndex INTEGER UNSIGNED,
PRIMARY KEY(BaseId)
);
CREATE TABLE UnsavedFiles (
UnsavedId INTEGER UNSIGNED AUTO_INCREMENT,
PathId INTEGER UNSIGNED NOT NULL REFERENCES Path,
FilenameId INTEGER UNSIGNED NOT NULL REFERENCES Filename,
PRIMARY KEY (UnsavedId)
);
CREATE TABLE Counters (
Counter TINYBLOB NOT NULL,
MinValue INTEGER DEFAULT 0,
MaxValue INTEGER DEFAULT 0,
CurrentValue INTEGER DEFAULT 0,
WrapCounter TINYBLOB NOT NULL,
PRIMARY KEY (Counter(128))
);

CREATE TABLE CDImages (
MediaId INTEGER UNSIGNED NOT NULL,
LastBurn DATETIME NOT NULL,
PRIMARY KEY (MediaId)
);
CREATE TABLE Status (
JobStatus CHAR(1) BINARY NOT NULL,
JobStatusLong BLOB,
PRIMARY KEY (JobStatus)
);
INSERT INTO Status (JobStatus,JobStatusLong) VALUES
('C', 'Created, not yet running'),
('R', 'Running'),
('B', 'Blocked'),
('T', 'Completed successfully'),
('E', 'Terminated with errors'),
('e', 'Non-fatal error'),
('f', 'Fatal error'),
('D', 'Verify found differences'),
('A', 'Canceled by user'),
('F', 'Waiting for Client'),
('S', 'Waiting for Storage daemon'),
('m', 'Waiting for new media'),
('M', 'Waiting for media mount'),
('s', 'Waiting for storage resource'),
('j', 'Waiting for job resource'),
('c', 'Waiting for client resource'),
('d', 'Waiting on maximum jobs'),

('t', 'Waiting on start time'),
('p', 'Waiting on higher priority jobs');
CREATE TABLE Version (
VersionId INTEGER UNSIGNED NOT NULL
);
INSERT INTO Version (VersionId) VALUES (10);
Ejecutáis eso (como administradores de MySQL si queréis), dáis permisos al usuario bácula en todas esas
tablas creadas y ya tenéis la base de datos lista para su uso por parte del director.
Apéndice B: Archivos de configuración de ejemplo
Por último, pondré unos archivos que uso yo y están funcionando, para que veáis unos ya configurados y
tal. Las contraseñas debéis cambiarlas (es un consejo). El escenario es el siguiente: tenemos un equipo
con cargador de cintas (de tres slots) que hace backup de un segundo equipo. Para no instalar muchas
cosas en el segundo equipo (no interferir en su funcionanmiento) lo único que instalaremos en ese equipo
es el file daemon. El equipo con el cargador va a tener por tanto el director y el storage daemon. La
máquina con el director se llamará respaldadora (192.168.0.2) y de la que queremos hacer backup se
llamará importante (192.168.0.1).
Primero instalamos bacula-fd en importante y lo configuramos con este fichero (/etc/bacula/bacula-
fd.conf):
Director {
Name = backup-mon
Password = "password_para_backup-mon"
Monitor = yes
FileDaemon {
Name = importante-fd # Podria ser cualquier otro nombre
FDport = 9102

WorkingDirectory = /var/lib/bacula
Pid Directory = /var/run/bacula
FDAddress = 192.168.0.1
Messages {
Name = Standard
director = respaldadora-dir
dir = all, !skipped, !restored
Reinciamos el demonio y ya podemos olvidarnos de esta máquina .
Ahora vamos con respaldadora,, primero instalamos el storage daemon y lo configuramos con el siguiente
arhivo (/etc/bacula/bacula-sd.conf
sd.conf):
Storage {
Name = respaldadora-sd
SDPort = 9103
Pid Directory = "/var/run/bacula"

0
SDAddress = 192.168.0.2
Director {
Name = respaldadora-dir
Password = "password_para_respaldadora-dir"
"password_para_respaldadora
Director {
Name = respaldadora-mon

Password = "password_para_respaldadora-mon"
Monitor = yes
Device {
Name = FileStorage
Media Type = File
Archive Device = /tmp
LabelMedia = yes;
Random Access = Yes;
AutomaticMount = yes;
RemovableMedia = no;
AlwaysOpen = no;
Autochanger {
Name = Autochanger
Device = Tape1, Tape2, Tape3
Changer Command = "/etc/bacula/scripts/mtx-changer %c %o %S %a %d"
Changer Device = /dev/sg2
Device {
Name = Tape1
Drive Index = 0
Autochanger = yes
Media Type = DDS-4
RandomAccess = no

AutoChanger = yes
LabelMedia = yes
Device {
Name = Tape2
Drive Index = 0
Autochanger = yes
Media Type = DDS-4
RandomAccess = no
AutoChanger = yes
LabelMedia = yes
Device {
Name = Tape3
Drive Index = 0
Autochanger = yes
Media Type = DDS-4
RandomAccess = no
AutoChanger = yes
LabelMedia = yes
Messages {
Name = Standard

director = respaldadora-dir = all
Y finalmente instalamos el bacula director y lo configuramos, muy importante: este archivo no está
completo, falta la definicion de trabajos que se explica más adelante. El archivo es el siguiente
(/etc/bacula/bacula-dir.conf):
Director {
DIRport = 9101
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
File Retention = 30 days
Job Retention = 6 months
AutoPrune = yes
Storage {
Name = File
Address = 192.168.0.2

SDPort = 9103
Media Type = File
Storage {
Address = 192.168.0.2
SDPort = 9103
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"

Pool {
Name = Default
Pool Type = Backup
Recycle = yes
AutoPrune = yes
Volume Retention = 365 days
Console {
CommandACL = status, .status
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. 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" . 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 anteriormente. 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 . 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
El parámetro Pool Type indica el tipo, 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 más 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á sobrescrito 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 {

DIRport = 9101
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
File Retention = 30 days
Job Retention = 6 months
AutoPrune = yes
Storage {
Name = File
Address = 192.168.0.2
SDPort = 9103
Media Type = File

Storage {
Address = 192.168.0.2
SDPort = 9103
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"
operator = root@localhost = mount
Messages {
Name = Daemon
mailcommand = "/usr/lib/bacula/bsmtp -h localhost -f \"$Bacula$ %r\" -s \"Bacula

daemon message\" %r"

Pool {
Name = Default
Pool Type = Backup
Recycle = yes
AutoPrune = yes
Console {
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,
aparte 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.
Apéndice C: Recuperar archivos respaldados
Resulta que tenéis vuestro servicio de backup funcionando y 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-1921: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
El maravilloso manual de bacula: http://www.bacula.org/en/?page=documentation.

Bacula 2021

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Bacula 2021

Cargado por

Copyright:

Formatos disponibles

INSTALACIÓN Y CONFIGURACIÓN DE BACULA

DOCUMENTO DISTRIBUIDO BAJO LICENCIA CREATIVE COMMONS BY-SA.

Para conocer las condiciones de esta licencia, por favor, consulta en

Basado en los documentos “Instalar un sistema Bacula en GNU” y “Configurando Backups

comuniquen correctamente entre ellos.

Los elementos necesarios para que bacula funcione son:

• bacula-sd (o bacula-storage daemon)

• bacula-fd (o bacula-file daemon)

• bacula-console (disponible en varios sabores:gnome y wx)

a guardar y para poder guardarlos en el soporte físico final.

contraseña para el acceso mediante bacula-console y los trabajos o jobs.

IMPLANTACIÓN DE SISTEMAS OPERATIVOS PROFESOR: JOSÉ CARLOS GALLEGO CANO

directores pueden utilizarlo.

que hay que instalar en las máquinas que necesiten respaldo.

que harán lo mismo... yo por ahora no he buscado ninguno...

instalado y configurado MySQL.

accesibles por un nombre de dominio (o tengan IP estática).

IMPLANTACIÓN DE SISTEMAS OPERATIVOS PROFESOR: JOSÉ CARLOS GALLEGO CANO

# apt-get install bacula-director-mysql

datos que necesitará bacula. Es muy sencillo y si os equivocáis simplemente haced:

ser la misma o no que la anterior, instalamos lo siguiente:

# apt-get install bacula-sd bacula-sd-tools

necesario que nos los cree también el storage daemon.

Finalmente, instalaremos lo siguiente en la máquina que queramos respaldar:

# apt-get install bacula-fd

IMPLANTACIÓN DE SISTEMAS OPERATIVOS PROFESOR: JOSÉ CARLOS GALLEGO CANO

Pid Directory = /var/run/bacula

Maximum Concurrent Jobs = 20

FDAddress = maquina.dominio # O si tiene IP estatica pues X.X.X.X

# Esto es nuevo en bacula 2.0.0

director = director_admitido1 = all, !skipped, !restored

IMPLANTACIÓN DE SISTEMAS OPERATIVOS PROFESOR: JOSÉ CARLOS GALLEGO CANO

En este archivo hemos definido tres tipos de resources distintos:

director_admitido1 y backup-mon. El segundo es un director especial que actúa de monitor... se

configura automáticamente. El primero es el que hemos añadido/modificado nosotros. El nombre

password es la que se espera que dé cuando se autentifique.

• Messages: Indica qué mensajes podemos enviar a cada director.

ahora vayamos con el siguiente.

IMPLANTACIÓN DE SISTEMAS OPERATIVOS PROFESOR: JOSÉ CARLOS GALLEGO CANO

Abramos su archivo de configuración (/etc/bacula/bacula-sd.conf) y veamos sus resources (este es

Pid Directory = "/var/run/bacula"

Maximum Concurrent Jobs = 20

Media Type = File

Archive Device = /tmp

LabelMedia = yes; # lets Bacula label unlabeled media

Random Access = Yes;

AutomaticMount = yes; # when device opened, read it

IMPLANTACIÓN DE SISTEMAS OPERATIVOS PROFESOR: JOSÉ CARLOS GALLEGO CANO

Device = Tape1, Tape2, Tape3, Tape4, Tape5, Tape6

Changer Command = "/etc/bacula/scripts/mtx-changer %c %o %S %a %d"

Changer Device = /dev/sg2

Media Type = DDS-4

Archive Device = /dev/nst0

Media Type = DDS-4

Archive Device = /dev/nst0

IMPLANTACIÓN DE SISTEMAS OPERATIVOS PROFESOR: JOSÉ CARLOS GALLEGO CANO

director = director_admitido1 = all

• Storage: Como antes, se define así mismo y qué parámetros usar.

• Director: Igual que en el file daemon.

• Device: Especifica un dispositivo de almacenamiento manejado por el storage daemon. El nombre

que se le da aquí y el tipo de medio es el que luego necesitaremos usar en el director. Es

el comando a emplear para usar el cargador.