Introduction
Le volume de données utilisées en entreprise croît de façon exponentielle depuis plusieurs années, leur criticité aussi.
Quand on sait que 70% des entreprises qui subissent un crach informatique majeur font faillite dans les 2ans, on comprend que préserver l’intégrité des données est primordial.
Un système de sauvegarde fiable, robuste et performant n’est donc pas du luxe pour quiconque manipule plusieurs giga octets de données quotidiennement.
La sauvegarde est une tâche gourmande en place et en temps de réalisation, il faut donc trouver une solution de sauvegarde mutualisée qui rende cette tâche la plus sûre et la moins fastidieuse possible.
Cette article est basé sur la suite logiciel Bacula qui vous allez le voir est une solution de sauvegarde de niveau profesionnel.
1. Les différentes solutions de sauvegarde
1.1. Solutions libres
Il existe un grand nombre de projets de sauvegarde mutualisée client/serveur en open source, parmi lesquels Amanda, Remote Backup & Bacula.
Nombre de ces projets sont encore en developpement et comportent des bugs, il convient donc d’être très vigilant quand à la solution à adopter en production puisqu’il serait cocace que votre système de sauvegarde, sur lequel vous misez tous vos espoirs en cas de coup dur souffre d’un bug au moment de la récupération des données critiques.
J’ai choisi le projet Bacula (www.bacula.org) car il a acquit une certaine maturité et est développé par une équipe de professionnels. De plus, il possède un panel de fonctionnalités epoustouflant, bien que certaines ne soient pas encore implémentées.
Ce projet est porté sur la distribution Debian, il est donc très aisé à maintenir.
Sa prise en main et sa configuration restent néanmoins deux choses particulièrement délicates et déroutantes, je vous invite donc à vous réferez au copieux manuel (491 pages) après avoir lu cet article.
1.2. Solutions commerciales
Tous les grands constructeurs de matériel informatique proposent des matériels accompagnés de solutions logicielles de sauvegardes, propriétaires ou non.
Vu la spécificité de chacune des ces solutions et surtout leur coût de déploiement et de fonctionnement, je ne m’y interesserais pas dans cet article.
1.3. Pourquoi un système de sauvegarde sur Disque?
Historiquement la sauvegarde utilisait comme media les bandes magnétiques, permettant de stocker un volume collossal de données.
La donne a légérement changé ces dernières années, en effet :
– La taille des Disques Durs a considérablement augmenté (de quelques Gigaoctets il y a peu à plusieurs centaines maintenant).
– Le prix de revient du Gigaoctet sur disque dur à baissé de façon significative.
– Les disques IDE durs nouvelle génération ont gagné indéniablement en fiabilité.
La sauvegarde sur Disque Dur permet donc :
– Une sécurité des données proche de celle des Bandes magnétiques avec l’utilisation de la technologie RAID.
– Une vitesse des phases de sauvegarde mais surtout de restauration multipliée par 30 par rapport aux sauvegardes sur bandes.
– Une mise en place à moindre coût puisqu’il n’est plus nécessaire d’acheter de matériel onéreux, toutes les cartes mères sont équipées de controleurs IDE, il suffit donc d’acheter les disques nécessaires à la sauvegarde.
L’utilisation des Bandes magnétiques permet cependant une fiabilité supérieure de part la nature du support (insensible aux chocs) et offre la possibilité d’emmener les bandes quotidiennement dans un lieu sécurisé, permettant une récupération en cas de gros dégats matériels sur le serveur de stockage.
L’utilisation couplée de ces 2 systèmes est une éventualité qui offre une très grande souplesse, mais peut se révéler complexe a mettre en oeuvre au début.
2. Le projet Bacula
2.1. Présentation
Bacula est un projet de sauvegarde réseau client/serveur professionel ambitieux.
Il offre une modularité hors du commun, en effet chaque étape de la sauvegarde est décomposée en un “daemon” associé et permet donc d’assouplir considérablement l’architecture du sytème de sauvegarde.
Il permet de sauvegarder sur de nombreux médias (Disques dur, bandes magnétiques, prise en charge des chargeurs de bandes…), cependant je ne traiterais ici que les fonctionnalités de sauvegarde sur disques puisque c’est le thème de cet article.
On peut assimilier Bacula à une suite de plusieurs logiciels, chacun affecté à une tâche propre (une des bases de la philosophie linux).
Bacula est sous licence GPLv2.
2.2. Architecture du logiciel
Un schéma vaut parfois mieux que de longues explication, je reprend ici celui du manuel qui est très bien fait :
2.2.1 Le directeur
C’est le coeur du système de sauvegarde, c’est lui qui “commande” et qui unit les différents éléments.
Il se présente sour la forme d’un daemon : bacula-dir qui écoute sur le port 9101.
Il ne peut y avoir qu’un directeur par architecture de sauvegarde (pas de réplication).
2.2.2 Le Storage Daemon
Il est chargé de l’enregistrement physique des données qui lui sont fournies, c’est lui qui gère l’interaction avec le matériel, dans cet article il s’agira de disques durs. Le matériel doit donc être connecté “logiquement” au serveur qui éxécute ce storage daemon (il doit être “monté”).
Ce daemon, bacula-sd, écoute sur le port 9103.
Il reçoit les ordres du directeur mais aussi et surtout les données directement du Filer Daemon (voir ci dessous).
A noter qu’il peut evidemment y avoir plusieurs storage daemon par architecture de sauvegarde.
2.2.3 Le Filer Daemon
C’est la partie cliente à proprement parler du logiciel puisque c’est ce daemon qui sera executé sur les machines contenant les données à sauvegarder.
Il s’appelle bacula-fd, écoute sur le port 9102, reçoit les ordres du directeur et envoie les données directement au Storage Daemon.
La compression (optionnelle) a lieu au niveau de ce daemon, limitant ainsi la charge sur les machines executant le directeur et les storage daemon et permettant aussi de limiter le volume de données transitant sur le réseau.
Note : il existe en version Unix/linux & windows
2.2.4 La console
C’est elle qui permet de contrôler le directeur, mais aussi directement les filer et storage daemons.
Elle peut être executée sur une machine disctinte (connexion par le port 9101).
Il existe une version gnome, mais celle ci ne présente pour l’instant que très peu d’intérêt.
2.2.5 Le catalogue
C’est la base de données du système de sauvegarde, elle contient les attributs et caractéristiques de vos fichiers et de vos différentes sauvegardes, elle est stockée dans une base de type MySQL, SQLLite ou postgresql qui peut être hebergée sur une machine tierce. (communication par le port 3106 avec le directeur).
SQLLite est implétmenté en natif dans le projet Bacula, c’est donc lui qui est proposé par défaut et qui est conseillé si aucun sgbd n’est installé sur la machine.
3. Définition d’un plan de sauvegarde
3.1. Les types de sauvegarde
Je vais faire ici un rappel des différents types de sauvegarde qui existent et que l’on retrouve dans Bacula.
3.1.1 Sauvegarde complète
Tous les fichiers selectionnés sont sauvegardés, qu’ils aient changé ou pas, et sont marqués comme tels dans le catalog.
Ce niveau de sauvegarde est de loin le plus gourmand en temps et en espace disque, mais il est evidemment nécessaire à tout plan de sauvegarde, c’est la base de la sauvegarde.
3.1.2 Sauvegarde differentielle
Seuls les fichiers ayant été crées ou modifiés depuis la dernière sauvegarde COMPLETE sont sauvegardés.
Ce niveau de sauvegarde permet de ne sauvegarder que les modifications et est donc plus rapide à executer et moins gourmand en terme de place.
3.1.3 Sauvegarde incrementielle
Tout comme la sauvegarde differentielle, la sauvegarde incrementielle ne concerne que les fichiers crées ou modifiés.
Ce qui différencie ces 2 niveaux de sauvegarde c’est qu’à l’instar de la sauvegarde differentielle qui se réfère à la derniere sauvegarde complete connue, la sauvegarde incrementielle se réfère à la dernière sauvegarde quelque soit son type, qu’elle soit complete, differentielle ou même incrementielle.
Le gros avantage est que l’on gagne encore en place et en temps de sauvegarde.
3.1.4 Différences pratiques entre sauvegardes differentielle et incrementielle
Nous l’avons vu precedemment, le sauvegarde incrementielle ne sauvegarde que ce qui a été modifié depuis la derniere sauvegarde, ce qui permet donc de sauvegarder moins.
Le principal risque est que si vous perdez un volume sur lequel est stockée une sauvegarde incrementielle à laquelle une autre sauvegarde incrementielle plus recente s’est référée, vous perdez l’historique des données.
Alors que dans le cas de 2 sauvegardes différentielles, vous n’auriez rien perdu puisque la seconde se serait référée non pas à la premiere mais directement à la sauvegarde complete originale.
Il y a dans ce cas redondance de l’information concernant les modification effectuées, mais aussi plus grande sécurité.
3.2. Exemples de stratégies
Une stratégie de sauvegarde est essentielle, elle permet de définir les données à sauvegarder, les eventuels historiques à conserver et elle permet surtout d’approximer l’espace nécessaire. Attention, prévoyez toujours très large! L’espace occupé par les données est toujours fortemment croissant!
De plus, il est toujours très difficile d’estimer la quantité de données crées ou modifiées chaque jour, il s’agira là d’approximations.
Afin d’éclaircir les choses, mettons en pratique les différents types de sauvegarde à travers des plans de sauvegarde concrets.
3.2.1 Cas concret n°1
Vous possédez 100Go de données critiques, accédées quotidiennement du lundi au samedi.
Ces données sont frequemment modifiées, à raison d’environ 1Go / jour et du fait de leur criticité vous souhaitez conserver un certain historique de ces modifications.
Exemple de plan de sauvegarde:
– sauvegarde complete mensuelle le premier dimanche du mois, convervée 2 mois.
– sauvegarde différentielle hebdomadaire le dimanche, conservée 5 semaines.
– sauvegarde incrementielle journaliere la nuit, conservée 14 jours.
Espace necessaire:
2 sauvegardes completes : 2*100Go = 200Go
—> On conserve la sauvegarde complete en cours et la précendente.
5 sauvegardes différentielles : 6+12+18+24+30 = 90Go
—> On conserve 5 semaines d’historique de sauvegarde différentielle hedbomadaire.
RAPPEL : cette sauvegarde se base sur la derniere sauvegarde complete, le volume de données augmente donc d’autant plus que la sauvegarde complète est ancienne.
12 sauvegardes incrementielles : 12*1Go = 12Go
—> On conserve 2 semaines soit 12 jours (le dimanche la sauvegarde differentielle a lieu) de sauvegarde incrementielle.
Total : 302Go nécessaires soit environ 3 fois la taille de vos données.
Ceci permet à n’importe quel moment d’avoir:
– un historique journalier des modifications pour les 14 derniers jours
– un historique hebdomadaire des modifications pour les 5 dernieres semaines
– deux historiques mensuels.
3.2.2 Cas concret n°2
Vous possédez 20Go de données critiques, ces données bougent peu (env. 100Mo modifiés/jour) et le suivi des modifications n’est pas essentiel pour vous.
Exemple de plan de sauvegarde:
– sauvegarde complete hebdomadaire, conservée 2 semaines.
– sauvegarde incrementielle journaliere, conservée 7 jours.
Espace necessaire:
2 sauvegarde complètes : 2*20Go = 40Go
6 sauvegardes incrementielles : 6*100Mo = 600Mo
Total : 40,6Go
4. Configuration de Bacula
4.1. Installation
4.1.1 Debian
Bacula est porté sur la distribution Debian, il est donc très facile à installer.
Pour installer la suite complète :
DebianBox:~#Apt-get install bacula
A noter qu’avec cette méthode c’est le paquet bacula-director-sqlite qui sera installé par défaut, libre à vous de choisir bacula-director-mysql ou bacula-director-pgsql.
Pour n’installer que la partie FD (FilerDaemon) sur un serveur “à sauvegarder”:
DebianBox:~#Apt-get install bacula-fd
Pour n’installer que la console d’administration, sur une machine qui servira à controler le directeur, les StorageDaemons ou FilerDaemons:
Pour la version texte :
DebianBox:~#Apt-get install bacula-console
Pour la version Gnome :
DebianBox:~#Apt-get install bacula-console-gnome
4.1.2 Rpm & “from source”
Bacula existe aussi en RPM, pour cela je vous conseille www.rpmfind.net afin de trouver le paquet le plus récent.
Si vous souhaitez compiler Bacula à partir des sources afin qu’il corresponde exactement à vos attentes en environnement de production, je vous invite à vous reporter au manuel officiel sur www.bacula.org, le nombre d’options étant assez conséquent.
4.2. Configuration des FD
Une fois Bacula installé sur vos différents serveurs, il faut configurer les Filer Daemons qui tourneront, je vous le rappelle, sur les machines contenant les données à sauvegarder.
Le fichier de configuration se nomme bacula-fd.conf et se trouve dans /etc/bacula sous debian.
Il est composé de 3 éléments :
– la définition des Directeurs autorisés à l’administrer
– la configuration du FD en lui-même
– la configuration de l’envoi des messages.
Pour autoriser un Directeur à se connecter à un FD, il faut donner le nom du directeur et lui associer un mot de passe:
Director {
Name = nom-du-serveur-executant-le-directeur
Password = “password”
}
Le champ FilerDaemon traite de la configuration en elle-même du FD
Il faut définir le nom qui sera utilisé pour l’identifier depuis la console d’administration et spécifier le port sur lequel il va écouter (9102 par défaut).
Le champ Messages gère les messages spontanemment envoyés au directeur par le FD, indiquez ici le nom du directeur qui doit recevoir ces messages.
Info : par défaut, debian configure ce fichier en mettant partout le nom de la machine sur lequel le paquet est installé, veuillez donc à rectifier si la machine n’est pas le directeur.
ATTENTION, ces fichiers de configuration sont à placer en local sur les machines executant les FD, c’est à dire les machines “à sauvegarder”.
Télécharger le fichier d’exemple de configuration du FD du serveur 1
Télécharger le fichier d’exemple de configuration du FD du serveur 2
4.3. Configuration du SD
Sur le même principe que le FD, le fichier de configuration du SD (bacula-sd.conf) possède un objet Storage dans lequel il faut définir un nom pour ce Storage Daemon et un port sur lequel il tournera, un objet Director dans lequel il faut indiquer le directeur autorisé à administrer ce SD et un objet Messages concernant les messages envoyés au directeur.
Il possède en plus des objets Device qui concernent dans notre cas le(s) volume(s) Disque sur lequel vous souhaitez stocker vos sauvegardes.
Il peut y avoir autant de Device que necessaire et idéalement un par serveur sauvegardé.
Télécharger le fichier d’exemple de configuration du Storage Daemon
4.4. Configuration du directeur
Le SD et le FD sont maintenant configurés, il nous reste le gros du travail : le Directeur qui est au centre du système.
Le fichier de configuration se nomme bacula-dir.conf
L’objet Director touche à la configuration du directeur lui-même, comme partout il faut le nommer et définir le password (necessaire pour contrôler ce directeur depuis la console).
A noter la propriété “Maximum Concurrent Jobs” qui définit le nombre de tâches que Bacula peut lancer simultanement.
L’objet FileSet définit l’ensemble des fichiers à sauvegarder, généralement pour un serveur donné. (les chemins d’accès aux données étant différent d’un serveur à l’autre).
Il convient donc d’en créer autant que necessaire, en incluant de préférence le nom du serveur concerné dans le nom de FileSet afin de savoir de quoi il retourne.
C’est à ce niveau que l’on définit la compression et/ou la signature des fichiers.
Bacula gère les algorythmes SHA1 et MDA pour la signature et GZIP(GZIP6) et GZIP9 pour la compression.
Je vous rappelle que cette compression a lieu en local sur le serveur de fichiers avant l’envoi des données par le réseau, elle impactera donc sur la charge de celui-ci.
L’objet Schedule définit un modèle de planification (voir exemple).
L’objet Client donne les informations concernant les différents FD au directeur (nom, adresse, mot de passe, port…)
On définit à ce niveau combien de temps les fichiers et les jobs sont conservé dans le Catalog.
Si l’option AutoPrune est définit à YES, ces infos sont effacées automatiquement du Catalog lorsque le laps de temps est ecoulé.
L’objet Storage donne les informations concernant les différents SD au directeur, et se réfère a un Device (précedemment définis dans le fichier bacula-sd.conf).
Dans notre cas, il faut mettre Media Type = File puisque l’on va sauvegarder sur un Disque Dur.
L’objet Catalog contient les paramètres de la base de donnée utilisée pour stocker les informations.
L’objet pool définit des ensembles de volumes(dans notre cas un volume sera un fichier) et permet par exemple de stocker toutes les sauvegardes de type “Full” ensembles etc.
A noter qu’un pool par défaut est necessaire.
Il reste maintenant l’objet Job qui definit une tâche de sauvegarde à proprement parler, il y en aura donc autant que nécéssaire.
Un job peut être de plusieurs types : Backup, Restore, Verify & Admin.
– Backup, comme son nom l’indique définira une tâche de sauvegarde.
– Verify permet de vérifier que les informations de sauvegardes stockées dans le Catalog correspondent bien à ce qui est stocké physiquement sur le support.
– Restore permet de récuperer des données sauvegardées.
ATTENTION, je vous conseille fortemment de définir vos jobs “restore” en même temps que vos jobs “Backup”, il n’est en effet pas possible de restaurer quelques données que ce soit sans qu’un job restore soit convenablement défini et il est rageant de perdre un temps précieux à définir ce type de job lorsque l’on a besoin de restaurer des données.
Je ne traiterais pas du type Admin dans cet article.
Pour un Job de type Backup, il vous faut spécifier les Client, FileSet, Schedule, Storage et Pool que nous avons précedemment déclarés.
L’option Write Boostrap permet de conserver le Bootstrap d’un disque dur sauvegardé avec Bacula, de façon a pouvoir remettre sur pied un système crashé le plus rapidement possible.
L’option Priority définit quel Job s’executera en premier lorsque plusieurs Jobs sont planifiés en même temps.
Télécharger le fichier d’exemple de configuration du Director
4.5. Prise en main de la console
Autant vous le dire tout de suite, la console d’administration n’est pas le point fort de Bacula. Elle existe en version Gnome mais n’offre selon moi aucun interet supplémentaire par rapport à la version texte.
Pour la lancer, placer vous dans /etc/bacula et executez bconsole.
Voici une liste non-exhaustive des commandes qui vous permetront de démarrer:
HELP : permet de lister toutes les commandes disponibles ainsi qu’une description sommaire.
RUN : permet de forcer le démarrage d’un job, à des fins de tests par exemple.
LIST (pools | jobs | jobtotals | media | files jobid=) : affiche le contenu du catalog.
STATUS : affiche l’état des jobs en cours. Cette commande se connecte directement au directeur, au SD ou au FD.
Télécharger le fichier d’exemple de configuration de la console
Conclusion
Cet article vous a présenté les principales fonctionnalités de Bacula dans son utilisation en tant que serveur de sauvegarde sur Disque dur.
J’espère que ce logiciel vous aura convaincu et je vous invite si c’est le cas à vous plonger dans le copieux mais complet manuel d’utilisation.
A noter que la sauvegarde mutualisée sur disque n’est qu’une infime partie des possibilités qu’offre Bacula, cet article n’a pas la prétention d’en faire une présentation exhausitive.
Infos et téléchargements : www.bacula.org
[filebase:file:file4]
