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~~

Bacula est donc une infrastructure pour réaliser des backups.

Il y a 3 types de logiciels Bacula qui collaborent ensemble pour réaliser des tâches différentes et complémentaires.

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

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.

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”.

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”.

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”.

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 !

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.

# 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.

# 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.

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

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.

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…

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” .

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” ?

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

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”.

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:

Ceci fait, on va faire les choses convenablement:

1. On test la configuration
2. 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

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"
##!}
# -------------------------

C'est facultatif.

Voir la doc pour des explications.

JobDefs {
  Name = "DefaultJob"
  ...

  # --- TJ -----------------
  Allow Duplicate Jobs = no
  Allow Mixed Priority = yes
  # ------------------------
}

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”.

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
  }
}

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.

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…

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.

# bacula-dir -t -c bacula-dir.conf
# /etc/init.d/bacula-director reload

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.

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.

# 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

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

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”.

# 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)

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}

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.

Maintenant, on peut vérifier que le directeur voit se storage:

# bconsole

*status stor

On devrait voir le “storage” sans erreur.

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

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

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
...

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"

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.

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”.

• Intégrer nos premiers clients
• Support du TLS
• Chiffrement des backups