Table des matières
Bacula : installation du Directeur
Installation de Bacula, le meilleur système de backup in the world 
Si vous cherchez un truc clair avec des belles images, c'est par là : http://www.artduweb.com/tutoriels/bacula
Si vous n'avez pas peur de lire mes notes, vous pouvez continuer la lecture…
~~READMORE~~
Les bases
Bacula est donc une infrastructure pour réaliser des backups.
Les participants
Il y a 3 types de logiciels Bacula qui collaborent ensemble pour réaliser des tâches différentes et complémentaires.
Le Directeur ("DIR")
Il s'agit du service qui va organiser les backups.
Il a besoin d'une base de données: Je vais utiliser PostgreSQL pour des raisons de performances, mais MySQL peut aussi convenir.
Besoin: un peu de RAM et de disk pour traiter et stocker la base de données.
 Il peut y avoir plusieurs directeurs |
Les service de Stockages ("SD")
SD=“Storage Daemon”
Dans cette petite doc, je parlerais de “Storage”.
Ces services permettent de stocker les backups.
Dans mon installation, ce sera des stockages dans des fichiers.
Besoin: Beaucoup d'espace disque.
Les Clients ("FD")
Aussi nommé les “File Daemon”.
Il s'agit simplement du logiciel client qui attend les ordres des directeurs pour effectuer les backups.
Sur chaque poste (ou serveur) a backuper , il faudra installer le démon “File Daemon”.
Fonctionnement de l'ensemble
Le gros de la configuration est sur le directeur:
Il a toute les infos sur les clients, les storages, les traitements prévus, faits, etc…
Le directeur attend le moment de démarrer les backups…
Le moment venu, il contacte le client (“FD”) et lui ordonne d'effectuer un backup de tel ou telle manière, en stockant les données sur tel “Storage”.
| Directeur → Client |
| Client → Storage |
C'est important de bien comprendre que le Directeur dit au Client de faire çi ou ça…
Ensuite, le Directeur supervise les traitements mais le Client transmet directement ses données de backups au “storage”.
Installation du Directeur
C'est le plus lourd à faire.
J'imagine que des tas de brave gars abandonnent l'installation de Bacula a cause de ce p*tain de Directeur ! 
Base de données: PostgreSQL
Comme dit en intro, vous pouvez utiliser MySQL par exemple, mais en production, Out Of The Box, c'est PostgreSQL qui est le plus efficace lorsqu'il y a des centaines de millions d'informations sur des fichiers stockés en base.
N'étant pas un fin connaisseur des bases de données et de PostgreSQL, mes explications seront simple mais pragmatique.
Packages (Debian)
# aptitude update # aptitude install postgresql
Pour info, divers conf par là:
/etc/postgresql/9.4/main/
… et un nouvel utilisateur est créé (voir dans “/etc/passwd” ) :
postgres:x:109:118:PostgreSQL administrator,,,:/var/lib/postgresql:/bin/bash
La particularité (un peu chiante) de PostgreSQL , c'est qu'on doit être l'utilisateur “postgres” pour contrôler la base de données. Soit.
Package bacula-dir
# aptitude install bacula-director-pgsql
Lorsque “dbconfig” vous demande un mot de passe: n'en faite rien, il est inutile d'en choisir un.
Il n'y a que root et bacula lui-même qui pourront se connecter à la base.
Compte bacula
Vérifions que le compte “bacula” est créé dans “postgresql”
# su - postgres
$ psql -l
...
Nom | Propriétaire | Encodage | Collationnement | Type caract. | Droits d'accès
-----------+--------------+-----------+-----------------+--------------+-----------------------
bacula | postgres | SQL_ASCII | fr_FR.UTF-8 | fr_FR.UTF-8 |
...
Ou encore:
$ psql -c "\du"
Liste des rôles
Nom du rôle | Attributs | Membre de
-------------+--------------------------------------------------------------+-----------
bacula | | {}
postgres | Superutilisateur, Créer un rôle, Créer une base, Réplication | {}
...
Il est bien là.
Remarque amusante (?) : un mot de passe a été créé automatiquement pour accéder à la base “bacula”.
On peut le trouver dans le fichier /etc/bacula/bacula-dir.conf …
Mais en pratique, il ne sert pas a “bacula”, mais a “root” pour accèder à la base…
En effet, “bacula” va accéder à la base sans mot de passe, du fait de la configuration qui vient avec Debian , mais pour 'root', il pourra se connecter avec le mot de passe comme ceci:
# psql -h 0 -U bacula
la base de données
C'est good ?
# su - postgres
$ psql -c "\dp" bacula
Droits d'accès
Schéma | Nom | Type | Droits d'accès | Droits d'accès à la colonne
---------+-----------------------------------+-----------+-----------------+-------------------------------
public | basefiles | table | |
public | basefiles_baseid_seq | séquence | |
public | cdimages | table | |
public | client | table | |
...
Ok.
bacula-dir.conf
Ainsi donc, le gros de la configuration est là dedans: “/etc/bacula/bacula-dir.conf”
Ne croyez pas ce que vous retourne:
# /etc/init.d/bacula-director status ● bacula-director.service - LSB: Start Bacula Director at boot time Loaded: loaded (/etc/init.d/bacula-director) Active: active (running) ... ...
Bacula n'est pas totalement fonctionnel.
A ce stade, ce qui lui-manque:
- permettre a root de tester la conf !
- un petit nom sympa
- débrider quelques paramètres…
- une console pour le contrôler
- sa propre configuration de sauvegarde.
- une configuration pour stocker ses propres backups.
La configuration par défaut de “bacula-dir” est un peu brouillonne.Je vais partir de ce “brouillon” pour faire un truc qui marche… |
Les mots de passes
Pendant l'installation, plusieurs mot de passe ont été créés pour vous et ils sont directement injectés dans les configurations.
Libre à vous de les garder ou de les changer.
Moi, je préfère les générer moi-même à coup de “pwgen -s 42” .
Petits bugs
Avant de se taper la tête contre les murs, 2 corrections a faire:
Un script qui ne va pas s’exécuter si on ne corrige pas les droits:
# chown root:bacula /etc/bacula/scripts/delete_catalog_backup # chmod 0755 /etc/bacula/scripts/delete_catalog_backup
Source: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=718641
Des logs qui ne vont pas se faire si on ne corrige pas les droits:
# chown bacula: /var/log/bacula/bacula.log
: En fait, ce fichier a tendance a grossir a l'infini… A revoir avec “logrotate” ?
''root'' tout puissant
Normalement, on est censé pouvoir tester la configuration de “bacula-dir” qui est dans “/etc/bacula/bacula-dir.conf” , comme ceci:
# bacula-dir -t -c /etc/bacula/bacula-dir.conf
Mais ça ne marchera pas !!!
Il faut corriger une petite erreur dans la configuration dans la section suivante:
Catalog {
Name = MyCatalog
# Uncomment the following line if you want the dbi driver
# dbdriver = "dbi:postgresql"; dbaddress = 127.0.0.1; dbport =
dbname = "bacula"; DB Address = ""; dbuser = "bacula"; dbpassword = "xxxxx"
}
Il manque l'adresse IP du service PostgreSQL qui gère notre base de données !
Donc, par exemple, il faut mettre à la ligne “dbname = …” :
dbname = "bacula"; DB Address = "127.0.0.1"; dbuser = "bacula"; dbpassword = "xxxxx"
Et maintenant, ça marche:
# bacula-dir -t -c /etc/bacula/bacula-dir.conf
(Aucun message d'erreur n'apparait)
On peut recharger la conf sans crainte:
# /etc/init.d/bacula-director reload
Les mails
bacula-dir va vous pourrir de mails !
Enfin, c'est pour votre bien: vous serez toujours informés de l'état des backups… et si ça va mal, vous recevrez des mails de relance vous invitant a réparer.
Donc: installez un petit serveur mail en local, ou envoyez les mails via votre fournisseur préféré.
Par défaut, les mails sont envoyés à “root”.
Pour changer ça, modifiez la conf (section “message {…}” ) ou modifiez le fichier “/etc/aliases”.
Personnalisation
Dans la première section , dans /etc/bacula/bacula-dir.conf :
Director { # define myself
Name = <NAME>
DIRport = 9101 # where we listen for UA connections
QueryFile = "/etc/bacula/scripts/query.sql"
WorkingDirectory = "/var/lib/bacula"
PidDirectory = "/var/run/bacula"
# --- TJ ------------------
##!Maximum Concurrent Jobs = 1
Password = "<PASSWORD_DIR>" # Console password
Messages = Daemon
##!DirAddress = 127.0.0.1
Maximum Concurrent Jobs = 10 # <- voir plus
DirAddress = 0.0.0.0 # <- ouverture au Monde
# -------------------------
}
Dans mon cas:
<NAME> | ziltoid-dir |
Ceci fait, on va faire les choses convenablement:
- On test la configuration
- On fait recharger la conf.
si “bacula-dir” charge une configuration qui n'a pas été préalablement testé avec succès, alors le service peut planter !!!! |
Test:
# bacula-dir -t -c bacula-dir.conf
Si aucun message d'erreur:
# /etc/init.d/bacula-director reload
Commenter les exemples et rectifier des bricoles
Exemples
Il y a plusieurs exemples, et on peut les commenter.
Toujours dans “/etc/bacula/bacula-dir.conf” , voici une section a commenter:
# --- TJ ------------------
##!Job {
##! Name = "BackupClient1"
##! JobDefs = "DefaultJob"
##!}
# -------------------------
Rectifier
JobDefs: DefaultJob
C'est facultatif.
Voir la doc pour des explications.
JobDefs {
Name = "DefaultJob"
...
# --- TJ -----------------
Allow Duplicate Jobs = no
Allow Mixed Priority = yes
# ------------------------
}
le Template "RestoreFile"
C'est facultatif.
Voir la doc pour des explications.
Job {
Name = "RestoreFiles"
Type = Restore
...
# --- TJ --------------------
##!Where = /nonexistant/path/to/file/archive/dir/bacula-restores
Where = /tmp/bacula-restores
Priority = 4
Allow Mixed Priority = yes
# ---------------------------
}
Par défaut, les restaurations de backup iront dans “/tmp/bacula-restores”.
FileSet : Full Set
Vu que c'est utilisé par défaut, il vaut mieux que ça soit cohérent. Donc:
# List of files to be backed up
FileSet {
Name = "Full Set"
Include {
...
# --- TJ --------------
##!File = /usr/sbin
File = /
# ---------------------
}
...
Exclude {
# --- TJ --------------
##!File = /var/lib/bacula
##!File = /nonexistant/path/to/file/archive/dir
# ---------------------
File = /proc
File = /tmp
File = /.journal
File = /.fsck
}
}
Storage : File
Il faut définir correctement où on va stocker les backups par défaut:
Moi, je vais avoir un “storage” en local sur le même serveur, mais ce n'est pas forcément votre cas.
Donc, je n'ai (presque) rien a toucher dans cette section:
Storage {
Name = File
# Do not use "localhost" here
# --- TJ --------------------
##!Address = localhost # N.B. Use a fully qualified name here
Address = 127.0.0.1 # <- voir plus loin.
# ---------------------------
SDPort = 9103
Password = "<PASSWORD_SD>"
Device = FileStorage
Media Type = File
}
Mais j'aurai pu changer le nom du “Device” ou changer l'“Address” du storage.
En fait, j'ai juste remplacé “localhost” par “127.0.0.1” parce que je vais installer un “storage” en local.
Pool : File
Cette section est un peu délirante, donc je la corrige comme ceci:
Pool {
Name = File
Pool Type = Backup
Recycle = yes # Bacula can automatically recycle Volumes
AutoPrune = yes # Prune expired volumes
# --- TJ -------------------
##!Volume Retention = 365 days # one year
##!Maximum Volume Bytes = 50G # Limit Volume size to something reasonable
##!Maximum Volumes = 100 # Limit number of Volumes in Pool
Volume Retention = 3m
Maximum Volume Bytes = 4G # Limit Volume size to something reasonable
Maximum Volumes = 10 # Limit number of Volumes in Pool
Label Format = "ziltoid-dir-pool-file-" # <- C'est plus mieux comme nom de fichier...
# --------------------------
}
3 mois de retention, et 4 * 10 Giga pour le stockage des backups…
le seul Client
Il y a un client de déclaré, mais je le corrige comme suit:
Client {
Name = ziltoid-fd # <--- ADAPTER LE NOM
Address = localhost
FDPort = 9102
Catalog = MyCatalog
Password = "xxxx" # password for FileDaemon
# --- TJ -----------------
##!File Retention = 30 days # 30 days
##!Job Retention = 6 months # six months
##!AutoPrune = yes # Prune expired Jobs/Files
# ------------------------
}
En fait, le “Client” déclaré va utiliser le “Pool” par defaut déclaré dans “bacula-dir”.
Les retentions déclarés étant fantaisistes, je les commente.
Appliquer les modifs
# bacula-dir -t -c bacula-dir.conf # /etc/init.d/bacula-director reload
A propos des Pool
On a modifié la configuration d'un Pool, mais , malgré le “reload” , elle n'est pas appliqué sur les volumes existants (s'il y en a).
On va installer “bconsole” au chapitre suivant, mais pour mettre a jour les Pools, il faudra faire dans la console:
- update pool
Puis sélectionner le pool a mettre a jour.
bconsole
Il existe un logiciel en ligne de commande pour interagir avec le “bacula-dir”, il s'agit de “bconsole” .
D'autres interfaces plus “friendly” existent, mais je préfère un truc qui me pique les yeux et me fait mal aux doigts.
# aptitude update # aptitude install bacula-console
On complète la configuration dans /etc/bacula/bconsole.conf avec les bons paramètres ( “nom” et “mot de passe”, …) . Exemple:
Director {
Name = ziltoid-dir
DIRport = 9101
address = localhost
Password = "<PASSWORD>"
}
Heureusement, “bconsole” peut aussi être utilisé à partir d'un autre poste: de l'interêt d'ouvrir “bacula-dir” au Monde.
Un petit test
# bconsole Connecting to Director localhost:9101 1000 OK: ziltoid-dir Version: 5.2.6 (21 February 2012) Enter a period to cancel a command. *
Yippee , je suis dedans.
Une petite commande:
*status dir
ziltoid-dir Version: 5.2.6 (21 February 2012) x86_64-pc-linux-gnu debian jessie/sid
Daemon started 2-sept2015 01:40. Jobs: run=0, running=1 mode=0,0
Heap: heap=409,600 smbytes=63,797 max_bytes=67,958 bufs=240 max_bufs=311
Scheduled Jobs:
Level Type Pri Scheduled Name Volume
===================================================================================
Full Backup 11 02-sept2015 23:10 BackupCatalog *unknown*
Differential Backup 10 03-sept2015 23:05 BackupClient1 *unknown*
====
Running Jobs:
Console connected at 2-sept2015 03:06
JobId Level Name Status
======================================================================
1 Full BackupClient1.2015-09-02_23.05.00_02 is waiting on Storage "File"
====
No Terminated Jobs.
====
You have messages.
Un message ?
*message 02-sept. 23:05 ziltoid-dir JobId 1: No prior Full backup Job record found. 02-sept. 23:05 ziltoid-dir JobId 1: No prior or suitable Full backup found in catalog. Doing FULL backup. 02-sept. 23:05 ziltoid-dir JobId 1: Start Backup JobId 1, Job=BackupClient1.2015-09-02_23.05.00_02
Et là, vous constatez qu'il y a déjà des trucs dans la conf ! On à déjà nettoyé ça précédement…
Pour sortir de la console:
*exit
Sinon, a partir de la console, on peut (entre bien d'autres choses) , recharger la configuration avec:
- reload
Pour les utilisateurs de confiance
J'en profite pour mettre mon compte a moi dans le groupe “bacula” :
Ainsi, je pourrai utiliser “bconsole” sans avoir besoin de devenir root.
# adduser thierry bacula
le directeur et "bacula-sd"
On a un storage de défini dans la conf , mais il serait peut être temps de l'installer.
Notre “storage” va stocker des volumes sous forme de fichiers. On a besoin d'un peu de place disk.
Dans mon cas, j'ai dédié un disk pour ça , et il est monter en “/mnt/bacula-data”.
Package
# aptitude install bacula-sd-pgsql
Malgré le nom du package, “bacula-sd” n'utilise pas de base de données, mais vient avec des logiciels qui peuvent être utilisés pour restaurer une base de données “Bacula” cassé. (voir la doc) |
Répertoires
On prépare une place pour stocker les futurs backups.
Donc, je créé un point de montage et mo(u)nté un gros disk là dedans:
/mnt/bacula-data
Faites comme bon vous chante, mais moi, je créé un répertoire pour chaque directeur (j'en ai qu'1), puis je créé des sous-répertoires pour les volumes.
# mkdir /mnt/bacula-data/ziltoid-dir # cd /mnt/bacula-data/ziltoid-dir
En créant les répertoires, faire en sorte que “bacula” aient les droits de lire et d'écrire, et que la création de nouveaux fichiers comportent ses mêmes droits…
# mkdir -m 2770 myhome # chown bacula:tape myhome
Autre manière pour d'autres sous-répertoire:
# mkdir dedibox-miley
# mkdir dedibox-cyrus
# chmod g+ws,o-rwx dedibox-{miley,cyrus}
# chown bacula:tape dedibox-{miley,cyrus}
bacula-sd.conf
J'adapte la conf dans “/etc/bacula/bacula-sd.conf” :
Storage { # definition of myself
Name = <NAME>-sd
SDPort = 9103 # Director's port
WorkingDirectory = "/var/lib/bacula"
Pid Directory = "/var/run/bacula"
Maximum Concurrent Jobs = 20
# --- TJ -------------
##!SDAddress = 127.0.0.1
SDAddress = 0.0.0.0
# --------------------
}
Mettre le “<NAME>” qui vous chante, et j'ouvre bacula-sd au Monde: “SDAddress = 0.0.0.0”
Eventuelle, adapté aussi la section “Director {…}” .
Si vous n'utilisez pas le “tray-monitor”, vous pouvez commenter la section suivante.
Je corrige le “Device” par défaut:
Device {
Name = FileStorage
Media Type = File
# --- TJ -------------------------
##!Archive Device = /nonexistant/path/to/file/archive/dir
Archive Device = /mnt/bacula-data/ziltoid-dir/myhome
# --------------------------------
LabelMedia = yes; # lets Bacula label unlabeled media
Random Access = Yes;
AutomaticMount = yes; # when device opened, read it
RemovableMedia = no;
AlwaysOpen = no;
}
Je fais pointer les “Archives” vers le bon répertoire que je viens de créer.
Rappel: Ce device est déclaré dans la conf de “bacula-dir”. Il va nous servir a backuper le directeur lui-même.
Le reste de la configuration contient des examples mis en commentaire.
# bacula-sd -t -c bacula-sd.conf # /etc/init.d/bacula-sd restart
pas de “reload”, mais un vilain “restart”. Dommage. |
bconsole
Maintenant, on peut vérifier que le directeur voit se storage:
# bconsole
*status stor
On devrait voir le “storage” sans erreur.
le directeur et "bacula-fd"
Maintenant, on peut préparer un client pour sauvegarder le directeur lui-même.
On installe son propre client.
# aptitude update # aptitude install bacula-fd
bacula-fd.conf
Adapter le nom du directeur, le mot de passe, etc… toujours en ayant un regard dans “bacula-dir.conf”:
Il faut les mêmes mots de passe…
Une petite remarque: le “Password” de la section “Director” correspond bien au mot de passe du “Client” (et non pas du “Director” dédié à la Console dans “bacula-dir.conf”).
Ouvrir ce “File Daemon” au Monde:
FileDaemon { # this is me
Name = ziltoid-fd
FDport = 9102 # where we listen for the director
WorkingDirectory = /var/lib/bacula
Pid Directory = /var/run/bacula
Maximum Concurrent Jobs = 20
# --- TJ ------------------
##!FDAddress = 127.0.0.1
FDAddress = 0.0.0.0
# -------------------------
}
Et puis on redemarre:
# bacula-fd -t -c bacula-fd.conf # /etc/init.d/bacula-fd restart
bconsole
mon client
Vérifions que le client est vu par “bacula-dir”.
# bconsole
Le client (le seul déclare), doit être visible quand on tape cette commande:
*status client Automatically selected Client: ziltoid-fd Connecting to Client ziltoid-fd at localhost:9102 ...
premier backup
On devrait pouvoir démarrer un backup:
# bconsole
*run
Automatically selected Catalog: MyCatalog
Using Catalog "MyCatalog"
A job name must be specified.
The defined Job resources are:
1: BackupCatalog
2: RestoreFiles
Select Job resource (1-2): 1
Run Backup job
JobName: BackupCatalog
Level: Full
Client: ziltoid-fd
FileSet: Catalog
Pool: File (From Job resource)
Storage: File (From Job resource)
When: 2015-09-02 03:13:30
Priority: 11
OK to run? (yes/mod/no):
Entrée: “yes” bien sur.
Job queued. JobId=3
*status dir ... Scheduled Jobs: Level Type Pri Scheduled Name Volume =================================================================================== Full Backup 11 13-sept2015 23:10 BackupCatalog ziltoid-dir-pool-file-0001 ==== ...
Déjà fini !
*message ... Termination: Backup OK ... 03-sept. 03:15 ziltoid-dir JobId 3: shell command: run AfterJob "/etc/bacula/scripts/delete_catalog_backup" 03-sept. 03:15 ziltoid-dir JobId 3: Error: Runscript: AfterJob returned non-zero status=200. ERR=Permission non accordée
Grrr… Problème de droits.
Corriger (déjà vu plus haut):
# chown root:bacula /etc/bacula/scripts/delete_catalog_backup # chmod 0755 /etc/bacula/scripts/delete_catalog_backup
Recommencer la procédure de backup après correction.
Normalement, on doit avoir à la fin:
Et un beau mail annoncant que ça a fonctionné.
... Termination: Backup OK ... 03-sept. 03:25 ziltoid-dir JobId 4: shell command: run AfterJob "/etc/bacula/scripts/delete_catalog_backup"
Conclusion
On a installé un “directeur bacula”.
Par défaut, il a des petits traitements en faire, enfin surtout 1 seul:
- sauvegarder sa propre base données
Pour le contenter, on a installer “bacula-sd” et “bacula-fd” et puis voila.
1 job fonctionne.
Choses a revoir
La manière dont la base de données est extraite puis backupé est un problème pour moi.
Avant le backup, un “dump” de la base est fait en “/var/lib/bacula/bacula.sql”.
A suivre ?
- Intégrer nos premiers clients
- Support du TLS
- Chiffrement des backups