Effectuez vos sauvegardes avec Bareos

1. Introduction à la sauvegarde

Pour bien comprendre quel type de sauvegarde nous allons aborder dans cet article, il convient de clarifier quelques notions :

• La réplication de fichiers : ce type de technologie est utilisée dans les architectures dites à haute disponibilité (ou HA pour High Availibility). Un service en haute disponibilité sous-entend qu’il s’appuie sur plusieurs ressources et que l’indisponibilité d’une des ressources ne l’interrompt pas.
• Les services de snapshots : un snapshot est un état du système de fichiers à un instant ‘t’. En pratique, cela consiste à conserver une copie de chaque bloc de donnée modifié depuis cet instant ‘t’ pour être capable de revenir à cet état à tout moment. La profondeur temporelle du snapshot est limitée par l’espace qui lui est alloué.
• La synchronisation : une synchronisation est une réplication qui intègre la notion de « hors ligne ». Un client peut être connecté de façon intermittente à une ressource. Le processus de synchronisation détecte la disponibilité de la ressource distante et envoie les nouvelles données. Les systèmes de synchronisation évolués tentent de gérer les conflits générés par la multiplicité de clients pour la même ressource (clients lourds, services web, smartphones, etc.).
• Une action volontaire de l’utilisateur : un disque externe connecté sur la machine avec un rsync dans un cron. C’est mieux que rien...

Tous ces mécanismes concernent ce que l’on appelle la donnée chaude, c’est-à-dire que la donnée est immédiatement accessible, car rapidement consultée.

Dans cet article, je vais aborder les données froides. Les données sont archivées et consultées uniquement en cas de remédiation à un sinistre physique qui n’a pu être conjuré ni par la réplication, ni par les snapshots. Dans le monde du libre, il y a un certain nombre d’outils pour faire de la sauvegarde. Les plus significatifs sont BackupPC, Bacula et Bareos.

J’ai écarté BackupPC, car je dois aussi sauvegarder du Windows. BackupPC s’appuie massivement sur rsync et je ne voulais pas installer la couche Cygwin.

Bacula et Bareos sont strictement identiques d’un point de vue fonctionnel. Et pour cause, Bareos est un fork de Bacula. Ce fork est principalement motivé par des problèmes de licence [2].

1.1 Généralités sur les logiciels de sauvegarde

Pour quasiment tous les logiciels de sauvegarde de la terre, il existe trois types de sauvegardes : incrémentales, différentielles et complètes. La complète passe l’intégralité du jeu de fichiers définit par la politique dans la sauvegarde. La différentielle passe les fichiers modifiés depuis la dernière complète. L’incrémentale passe les fichiers modifiés depuis la dernière sauvegarde (qu’elle soit complète ou incrémentale). On notera que la différentielle peut sauvegarder plusieurs fois les mêmes états de fichiers. En contrepartie, la remontée de ceux-ci lors d’une restauration est grandement simplifiée.

Justement, à propos de la restauration, chaque logiciel de sauvegarde intègre un catalogue qui contient toutes les informations pour restaurer des fichiers sans avoir à parcourir séquentiellement tous les médias de stockage (ce qui est encore plus dommage quand on fait de la sauvegarde sur disque à accès aléatoire). Ce catalogue se présente généralement sous la forme d’une base de données. Nous allons utiliser MySQL pour gérer le catalogue de notre instance Bareos. Je considère dans la suite de l’article que nous avons un serveur MySQL en état de marche.

1.2 Installation

L’installation de Bareos est très simple dans la mesure où l’équipe de développement propose des paquets tout faits pour (quasiment) toutes les distributions. Nous allons l’installer sous Debian Jessie. En premier lieu, il faut ajouter les dépôts Bareos aux sources d’apt :

Et récupérer la clé publique de ce nouveau dépôt :

Ensuite, on passe à l’installation proprement dite de Bareos :

Enfin, il faut préparer la base de données du catalogue de sauvegarde. Nous avons trois scripts à disposition qui ne sont que des surcouches de la commande mysql. Il faut les exécuter dans la séquence suivante :

On crée un utilisateur bareos dans MySQL qui sera utilisé par le logiciel pour accéder au catalogue :

Il ne reste plus qu’à lancer les démons :

Nous disposons d’une installation fonctionnelle.

2. Architecture de Bareos

L’architecture de Bareos est exactement la même que celle de Bacula déjà présentée dans GMLF [3]. Pour mémoire, Bareos se divise en trois démons bareos-dir, bareos-sd et bareos-fd, respectivement « Director », « Storage daemon » et « File daemon ». Nous allons illustrer le fonctionnement des trois démons en appliquant une politique de sauvegarde. Cette politique consiste à sauvegarder le contenu d’un serveur en faisant une totale le premier de chaque mois et une incrémentale tous les jours. Nous conservons une profondeur de catalogue de deux mois pour chaque type de sauvegarde. Toute la configuration est localisée dans le répertoire /etc/bareos. Commençons par la partie la plus indigeste, la configuration de bareos-dir.

Avant de se lancer dans l’explication des fichiers de configuration, il convient de tracer à gros traits les interactions entre les différents démons. Le démon bareos-dir s’exécute sur le serveur de sauvegarde. Le démon bareos-sd sur le serveur de stockage (dans notre article, bareos-sd et bareos-dir tournent sur la même machine). Enfin, bareos-sd tourne sur le client à sauvegarder. Le programme bareos-dir est le chef d’orchestre de Bareos. C’est lui qui est en charge de la planification des travaux de sauvegarde et les initie. Il a également la connaissance des fichiers à sauvegarder pour chaque machine ainsi que des ressources à utiliser pour le stockage. Il contacte donc le démon bareos-fd pour lui indiquer les fichiers à sauvegarder et lui remettre un cookie d’authentification. À la réception de la requête, le service bareos-fd utilise le cookie pour s’authentifier auprès du démon bareos-sd et lui envoie les données à sauvegarder. Enfin, bacula-sd écrit les données sur le média physique (disques, bandes, etc.) indiqué par bareos-dir.

 

2.1 bareos-dir

Deux programmes interagissent de façon interactive avec bareos-dir : bconsole et la webui. Comme leurs noms l’indiquent, bconsole est en mode texte et webui en mode web. L’accès à bareos-dir se configure dans le fichier bareos-dir.d/director/bareos-dir.conf :

À ce stade, il faut lever une petite ambiguïté qui m’a causé soucis lors de la prise en main de Bareos. La section Director n’est pas liée au démon bareos-dir (qu’on peut aussi trouver nommé Director dans certaines documentations, ce qui est piégeux). La section Director dans les fichiers sert à définir les modalités d’accès aux services Bareos à savoir bareos-dir, bareos-fd et bareos-sd. Cette section contient un mot de passe qui est un secret partagé entre le service et les clients ayant besoin d’y accéder. Il contient également les paramètres TLS et différentes autres options d’accès. Les services de Bareos peuvent être tour à tour clients et serveurs les uns des autres.

Une fois bareos-dir accessible, il faut implémenter la planification de la sauvegarde. Il faut ajouter un fichier dans le répertoire bareos-dir.d/schedule avec la configuration suivante :

Ce fichier définit trois travaux, respectivement par ordre des lignes :

• une sauvegarde totale tous les premiers dimanche du mois à 1h ;
• une incrémentale les autres dimanches (2nd-5th) à 1h ;
• une incrémentale tous les soirs du lundi au samedi à 1h.

Ce qui est intéressant ici c’est que chaque travail est lié à un pool. Un pool est un ensemble de ressources physiques un peu abstraites sur lesquelles vont se faire les sauvegardes. Nous en avons deux, DFSFull et DFSIncremental. Je donne l’exemple de la configuration de DFSFull.

La configuration de notre pool se trouve dans bareos-dir.d/pool/DFSFull.conf :

D’après le fichier, notre ensemble de ressources est composé de 30 volumes (Maximum Volumes) de 200GB (Maximum Volume Bytes). À ce stade de la configuration, on ne sait pas s'il s’agit de cassettes type LTO de 200GB, de fichiers de 200GB etc. Ces volumes seront physiquement personnifiés plus tard. Il est également indiqué que les volumes seront automatiquement labellisés sous la forme DFSFull-XX. Dans les logiciels de sauvegarde, la labellisation des volumes sert à les identifier au niveau du catalogue pour savoir quoi (les fichiers) se trouve où (le label). Les volumes sont automatiquement purgés (AutoPrune = yes) de la base de données catalogue au bout de deux mois (Volume Retention = 2 months) et marqués comme recyclables (Recycle = yes). La question suivante est : mais qu’est-ce qu’on va sauvegarder ? C’est ici que nous allons définir les ensembles de fichiers à sauvegarder sur nos clients.

Notre lot de fichiers à sauvegarder est défini dans le fichier DFSAll.conf du répertoire bareos-dir.d/fileset/ :

Les plus observateurs auront remarqué qu’il s’agit de sauvegarder un client Windows. La première chose à faire est d’activer le VSS (Volume Shadow copy Service) pour que le système de fichiers soit dans un état stable lors de la copie d’un fichier. Ensuite, on définit des expressions régulières de fichiers (WildFile) à ne pas sauvegarder (Exclude = yes). Enfin, on donne le chemin du répertoire à sauvegarder (File = "D:/DFS").

Le lien avec le démon bareos-sd est fait par le fichier NFSStorage.conf que nous avons créé dans bareos-dir.d/storage :

Ce fichier nous indique l’emplacement du démon bareos-sd (Address) ainsi que le secret pour y accéder (Password). Il spécifie également le type de média (Media Type) ainsi que son nom (Device). Ce nom fait du sens au niveau de bacula-sd pour décrire l’emplacement physique des volumes de sauvegarde (définis pour mémoire dans le fichier DFSFull.conf).

Il reste à définir les paramètres de connexion au client sur la machine à sauvegarder. On les retrouve dans le répertoire bareos-dir.d/client. Il faut y ajouter un fichier avec le contenu suivant :

À l’instar de la connexion au démon bareos-sd, il faut définir l’adresse du client (Address) et le mot de passe pour s’authentifier auprès du Director du bareos-fd du client (Password). Ouf ! Il nous reste la dernière partie, celle qui fait le lien entre toutes ces configurations pour faire un travail de sauvegarde (job).

Un travail est défini dans deux répertoires : bareos-dir.d/job et bareos-dir.d/jobdefs. La relation entre les deux est que chaque fichier du répertoire job correspond à un travail réel à effectuer sur un client tandis que le répertoire jobdefs contient des fichiers de templates. Ces templates sont inclus dans la définition des travaux de job un peu à la manière des headers en C. Commençons par voir le contenu d’un fichier du répertoire job :

Les pièces commencent à s’imbriquer. Ce fichier fait l’association entre le client à sauvegarder (Client) et le pool à utiliser pour les sauvegardes incrémentales (Incremental Backup Pool) et complètes (Full Backup Pool). On peut aussi y voir l’inclusion d’un jobdefs (JobDefs). Allons en examiner le contenu dans le répertoire jobdefs :

Ici, on fait le lien entre le lot de fichiers à sauvegarder sur le client (FileSet), la planification du job (Schedule) et le stockage à utiliser (Storage). Les deux autres démons sont infiniment plus simples !

 

2.2 bareos-sd

La configuration du démon bareos-sd se compose de deux parties : une pour définir les paramètres de son Director et une autre pour définir le(s) stockage(s) physique(s) (cf. l’attribut Device des fichiers contenus dans la section Storage de bareos-dir). Voyons la configuration du Director qui se trouve dans les fichiers situés dans le répertoire bareos-sd.d/director :

Nous avons juste un nom et un mot de passe. Ce mot de passe est utilisé par bareos-dir pour se connecter à bareos-sd (cf. l’attribut Password des fichiers contenus dans la section Storage de bareos-dir). Pour la seconde partie, la configuration se fait dans le répertoire bareos-sd.d/device :

C’est la dernière brique côté serveur ! Nous avons un type de média (Media Type) qui nous dit que les volumes correspondent à des fichiers situés dans /nfs/bareos/backup (Archive Device). En conséquence, l’accès est aléatoire (Random Access = yes) et non séquentiel comme avec des bandes. Les autres paramètres sont assez explicites.

2.3 bareos-fd

C’est presque le bout du tunnel. La configuration du client se divise en deux grandes sections. La première est, sans surprises, le Director qui permet à bareos-dir de se connecter à bareos-fd pour initier le travail de sauvegarde. La seconde définit les paramètres de configurations du démon bacula-fd. Commençons par le Director, la configuration est stockée dans le répertoire bareos-fd.d/director :

On retrouve le classique nom accompagné du mot de passe permettant à bareos-dir de se connecter (cf. l’attribut Password des fichiers contenus dans la section Clientde bareos-dir). La seconde partie de la configuration se trouve dans bareos-fd.d/client :

2.4 Configuration du TLS

Le TLS se configure de façon assez classique sur Bareos. Il existe une documentation de grande qualité sur Internet qui couvre ce point [4] sur Bacula, mais elle est transposable à Bareos. Je vous conseille de la suivre scrupuleusement, car elle détaille une à une les connexions à sécuriser : de Bconsole à Bareos-dir, de Bareos-dir à Bareos-fd, de Bareos-dir à Bareos-fd et enfin, de Bareos-fd à Bareos-sd. D’autres documentations préconisent l’utilisation de stunnel. Cette solution peut être particulièrement pratique si on a Bareos-dir et Bareos-sd sur la même machine (donc pas besoin de TLS) et quelques Bareos-fd éparses.

3. Management de Bareos

3.1 Bconsole

La console Bareos est utilisée par l’administrateur pour interagir avec le processus bareos-dir afin de lancer des jobs, restaurer des fichiers, explorer des archives, visionner le catalogue, etc. Cette console se configure de façon extrêmement simple via un fichier bconsole.conf :

Ensuite, on peut invoquer la console et remonter l’état du bareos-dir :

Ceci nous renvoie l’état de l’infrastructure Bareos ; ce rapport est très complet.

3.2 webui

Le package Debian fournit une configuration type pour l’interface web. Il suffit de l’activer :

Ensuite, on passe par bconsole pour créer un utilisateur administrateur de la sauvegarde :

Le profil webui-admin de l’utilisateur admin est consultable dans le fichier /etc/bareos/bareos-dir.d/profile/webui-admin.conf. Vous pouvez maintenant vous connecter sur http://<fqdn_bareos_serveur>/bareos-webui.

4. Troubleshooting Bareos

Lors de notre installation de Bareos, nous avons eu quelques soucis avec le pare-feu du site. Lorsque bareos-fd doit sauvegarder un volume de données, il commence par l’analyser pour générer les enregistrements à ajouter au catalogue. Or, cette phase peut durer un certain temps. Durant cette phase, la connexion TCP avec le director est toujours maintenue (pour mémoire, la configuration du catalogue se fait au niveau de bareos-dir), mais aucune donnée ne transite. Au bout d’un certain délai de garde, le pare-feu met fin unilatéralement à la connexion TCP entraînant l’échec de la sauvegarde. Bareos intègre un mécanisme de heartbeat, c’est-à-dire qu’un paquet vide est envoyé à intervalle régulier pour maintenir la connexion active du point de vue du pare-feu. Il faut ajouter une directive dans la configuration du client au niveau de bareos-dir :

Toutes les deux minutes (120 secondes), un paquet vide est envoyé pour maintenir la connexion active.

Nous avons également eu un second souci plus vicieux. Avec de grosses sauvegardes (environ 2 Tio) depuis un bacula-fd, la sauvegarde continuait de planter suite à des soucis de connexion réseau. Après quelques (longues) recherches sur les forums de Bareos, il semblerait que certains drivers de carte réseau sous Windows supporteraient mal les heartbeats (comme certains anciens chipsets réseau NVIDIA). La solution dans ce cas est de se rabattre sur les TCP Keepalives. Dans ce cas, ce n’est plus le logiciel bareos-fd qui forge un paquet heartbeat, mais c’est le noyau qui indique à la socket d’envoyer un paquet TCP à intervalle régulier. Nous avons donc aligné le délai des TCP Keepalives sur celui des heartbeats. Pour ce faire, il faut modifier une variable du noyau via un sysctl :

Conclusion

Bareos est donc un logiciel performant, tout à fait fonctionnel et utilisable quasiment « out-of-the-box ». Cependant, à une époque de forte décentralisation de l’informatique vers des infrastructures en nuage, il convient de se poser des questions sur l’avenir de telles solutions. À terme, la sauvegarde pourrait se résumer à envoyer des fichiers vers du stockage central versionné de telle façon que les utilisateurs pourront restaurer leurs fichiers sans intervention de l’administrateur.

Références

[1] « Une attaque informatique de portée mondiale crée la panique » : http://www.lemonde.fr/pixels/article/2017/05/12/des-hopitaux-anglais-perturbes-par-un-rancongiciel_5127034_4408996.html

[2] « Why have you started a fork from Bacula.org ? » : https://www.bareos.org/en/faq/why_fork.html

[3] MOUREY S., « Bacula : le vampire qui m’a sauvé la vie », GNU/Linux Magazine n°145, janvier 2012 : https://connect.ed-diamond.com/GNU-Linux-Magazine/GLMF-145/Bacula-le-vampire-qui-m-a-sauve-la-vie

[4] Documentation Bacula/TLS : https://www.devco.net/pubwiki/Bacula/TLS/