Ecrit Par ******ARTICLE EN COURS DE REDACTION ******
SOMMAIRE :
————
-Configurer le fichier bacula-dir.conf
——–| Exemple de FileSet Windows
—-Les ressources “Job” et “JobDefs”
Aperçu :
Cet article décrit de manière générale le serveur de sauvegarde Bacula et sa configuration. Vous y trouverez un aperçut des fichiers de configuration et une brève description des directives utilisées lors de la mise en place de ce système. Le contenu de cet article doit quand même permettre de monter un serveur de sauvegarde sur disque dur opérationnel, simple et efficace.
Bacula est un programme client/serveur de centralisation des sauvegardes dont la partie serveur tourne sous Linux. Il intègre les fonctions VSS, qui permettent de sauver même des fichiers ouverts et en cours d’utilisation. En revanche, à ma connaissance, pas de Wake on LAN en natif, mais on peut intégrer une commande externe, donc en installant l’outils “wakeonlan” sur le système c’est faisable…
Bacula nécessite une base de donnée pour fonctionner, il référencera tout dedans, le status des jobs, leur type (sauvegarde, restauration etc..), les pools et les volumes contenus dans ces pools, et plus encore. Donc attention à choisir la version des daemon en fonction de votre SGBD (ici MySQL) !
Plusieurs outils seront à notre disposition pour gérer les sauvegardes, notamment la console de commandes nommée bacula-console (ou bconsole) qui offre un terminal de commandes reconnues par bacula. Il existe aussi l’outils Bacula Administration Tool (bat) qui offre une interface graphique pour gérer bacula. Ces outils sont installables sous windows comme sous linux (sous windows, les console et bat sont contenus dans l’installeur du client bacula, il est possible d’y sélectionner ou déselectionner les éléments à installer, on évitera donc d’installer les consoles d’administration sur les machines clientes !!!). Webmin peut afficher l’état de bacula et permet aussi de lancer des jobs, mais je ne me suis pas pencher la dessus, pas vraiment nécessaire si on a le “bat”. Les outils “bconsole” et “bat” ne seront pas obligatoirement installés sur le serveur, mais plutôt sur les machines qui serviront à piloter Bacula (sur votre client windows par exemple).
*** Il est obligatoire d’installer au moins bconsole sur le poste qui servira à piloter Bacula pour pouvoir interagir avec le serveur.***
—–> Pour le VSS, sous Windows, il faudra configurer le service “Cliché instantané de volume” en mode de démarrage automatique. On peut aussi configurer ce service de manière à ce qu’il redémarre automatiquement en cas de défaillance.
—–> Toujours sous Windows, le service client de bacula apparaitra comme service sous le nom “Bacula-fd” (nom complet : Bacula File Service) , et il serait utile de régler la récupération d’erreur du service de manière à ce qu’il redémarre automatiquement en cas de défaillance.
—–> Sauvegarde différentielle : ce niveau de sauvegarde s’appuie sur la dernière sauvegarde complète existante, ce qui peut s’avérer lourd en données à conserver. Par exemple, si on fait une full le lundi et une différentielle du mardi au vendredi, ces dernières analyseront la full du lundi, et sauverons la différence. Il y aura donc des fichiers sauvés en double, en triple, puis en quadruple ! Bien choisir ses niveaux de sauvegarde donc…
—–> Pour du Wake On Lan, installer d’abord l’outil “wakeonlan” sur le serveur, recenser les adresses MAC des cartes réseau et configurer les postes client en mode Wake on Lan.
Pré-requis : mysql
A savoir : On peut éclater les fichiers de configuration, pour une organisation plus facile, en indiquant leur chemin absolu au tout début du fichier bacula-dir.conf :
@/etc/bacula/clients.conf
@/etc/bacula/jobs.conf
Il est alors possible de configurer tout les “Clients” et tout les “Jobs” dans leur fichier propre…
Bacula permet de sauvegarder aussi bien des clients windows que linux. Il se compose de trois services :
bacula-dir : le daemon principal, le fichier de config est bacula-dir.conf.
bacula-sd : le storage daemon, qui s’occupe du stockage, dont le fichier de config est bacula-sd.conf.
bacula-fd : le file daemon, c’est le service client, à n’installer que sur les machines clientes donc, et dons le fichier de config est bacula-fd.conf.
Installer et configurer simplement Bacula sous Fedora 14 :
Je pars du principe que MySQL est déja installé..
yum install bacula-director-mysql
yum install bacula-storage-mysql
***Sous Debian 5.0.6 j’ai du ajouter les dépots de test pour trouver Bacula sous forme de paquets. Voici les dépots à ajouter dans le fichier /etc/apt/source.list :
deb http://ftp2.fr.debian.org/debian testing main contrib
deb-src http://ftp2.fr.debian.org/debian testing main contrib
En installant bacula sous debian, il vous sera demandé si vous voulez configurer la base de donnée avec dbconfig-common, acceptez et on vous demandera le mot de passe admin de mysql, puis on vous demandera de choisir le mot de passe de l’utilisateur mysql nommé “bacula”; Ce mot de passe nous sera utile plus tard.***
Mon client de test étant un windows XP, je n’installe pas le paquet bacula-client ( bacula-fd ) sur cette machine, mais j’aurais pu si j’avais voulu sauver l’OS propre à bacula…
Configurer MySQL
Maintenant il faut créer un utilisateur, une base et des tables dans mysql (sauf si vous l’avez déja fait avec dbconfig-common !). Heureusement bacula fournit des scripts pour ça. Pour mysql il y en à trois dans /usr/libexec/bacula, il faut les exécuter sur le champ !
Pour que ces scripts fonctionne, rajouter “-u root -p”
ex :
cd /usr/libexec/bacula
./grant_mysql_privileges -u root -p
Entrez votre mot de passe : ….
./create_mysql_database -u root -p
./make_mysql_tables -u root -p
Un petit tour dans phpmyadmin pour définir le mot de passe de l’utilisateur mysql “bacula”.
Bon et bien il n’y a plus qu’a mettre les mains dans le cambouis ! Mais sauvons les fichiers originaux d’abord :
cd /etc/bacula
cp bacula-dir.conf bacula-dir.conf.bak
cp bacula-sd.conf bacula-sd.conf.bak
Aller, c’est parti !
####################################################################
LE FICHIER BACULA-DIR.CONF
####################################################################
On y trouve (dans le désordre) :
La ressource “Director” :
Director {
Name = bacula-dir
DIRport = 9101
QueryFile = “/etc/bacula/query.sql”
WorkingDirectory = “/var/spool/bacula”
PidDirectory = “/var/run”
Maximum Concurrent Jobs = 1
FD Connect Timeout = 1 mins
Password = “@@DIR_PASSWORD@@”
Messages = Daemon
}
“Name” donne un nom au director. Beaucoup de ressources d’autres fichiers devront faire référence à ce nom. A part ça, on peut renseigner simplement le mot de passe du director, en md5 par exemple, ce dernier sera également nécessaire à la configuration du client et du Storage Daemon. On peut définir aussi le port d’écoute, par défaut 9101. “Maximum Concurrent Jobs” permet de définir combien d’actions se dérouleront en même temps, à définir en fonction de la capacité du réseau.
“FD Connect Timeout = 1 mins” signifie que si le client n’est pas joignable pendant 1 minute, bacula abandonne le job correspondant.
Bien choisir le mot de passe, qui sera à renseigner plus tard, dans les autres fichiers de configuration.
###############################################################
La ressource “Storage” :
Storage {
Name = File
Address = Nom.de.domaine_ou_IP
SDPort = 9103
Password = “@@SD_PASSWORD@@”
Device = FileStorage
Media Type = File
}
On configurera, à l’aide de cette ressource, la communication entre le bacula-director et bacula-storage.
-Name : donne un nom à la ressource en question. Ce nom sera utilisé dans les jobs.
-Address : définit l’endroit ou se trouve le storage daemon (sd), car il peut très bien se trouver sur une autre machine. Éviter de mettre localhost ici, mais plutot l’IP du serveur ou est installé le daemon bacula-storage (car il peut très bien être sur un autre serveur), ou le nom de domaine pleinement qualifié..
-SDport : permet de définir le port d’écoute, 9102 par défaut.
-Password : sert à authentifier le director daemon auprés du storage daemon. Il peut être différent de celui du director (présent dans la ressource “Director” du bacula.conf), mais doit correspondre avec le mot de passe indiqué dans la ressource “Director” du fichier bacula-sd.conf.
-Device : Ce nom doit correspondre avec la directive “Name” de la ressource “Device” du fichier bacula-sd.conf. On choisira plutôt un nom évoquant (jusqu’à 127 caractères max), ici je laisse par défaut “FileStorage” car ça me va bien vu que je veux stocker les sauvegarde dans des simples fichiers sur disque dur. Cette ressource sert surtout quand on veut configurer plusieurs ressources “Storage” dans le bacula-dir.conf (cela est utile quand on dispose de plusieurs types différents de support de stockage). Ici, nous utiliserons seulement le stockage sous forme de fichiers sur une partition du disque dur, on vérifiera juste la concordance avec la directive “Name” de la ressource “Device” du fichier bacula-sd.conf, car c’est dans cette ressource-la qu’on configurera le stockage des sauvegardes (mais on verra ça en configurant le bacula-sd.conf).
-Media Type : définit le type de media à utiliser. On choisira un nom évoquant le type (127 caractères max). On veillera à la concordance avec la directive “Media Type” de la ressources “Device” du bacula-sd.conf. Je ne saurais pas vous expliquer le fonctionnement exact, mais “Media Type” servirait à différencier des supports de stockage identiques qui auraient des formats incompatibles.
##################################################################
La ressource “Pool” :
Pool {
Name = Default
Label Format = “Default-”
Pool Type = Backup
Recycle = yes
Storage = File
AutoPrune = yes
Volume Retention = 40 days
Maximum Volume Jobs = 3
Recycle Oldest Volume = yes
}
Pool {
Name = Full-Pool
Pool Type = Backup
Recycle = yes
AutoPrune = yes
Volume Retention = 14 days
#Maximum Volume Jobs = 1
Label Format = Full-
Maximum Volumes = 10
Storage = File
Recycle Oldest Volume = yes
#Use Volume Once = yes
Maximum Volume Bytes = 100000000000
Recycle Current Volume = yes
}
Pool {
Name = Diff-Pool
Pool Type = Backup
Recycle = yes
AutoPrune = yes
Storage = File
Volume Retention = 14 days
#Maximum Volume Jobs = 1
Label Format = Diff-
Maximum Volumes = 10
Recycle Oldest Volume = yes
#Use Volume Once = yes
Maximum Volume Bytes = 100000000000
Recycle Current Volume = yes
}
Pool {
Name = Inc-Pool
Pool Type = Backup
Recycle = yes
AutoPrune = yes
Storage = File
Volume Retention = 14 days
#Maximum Volume Jobs = 1
Label Format = Inc-
Maximum Volumes = 10
Recycle Oldest Volume = yes
# Use Volume Once = yes
Maximum Volume Bytes = 100000000000
Recycle Current Volume = yes
}
La ressource “Pool” sert à configurer la manière dont les fichiers de sauvegarde seront organisés.
Un pool correspond en fait à un ensemble de fichiers de sauvegarde que l’on appellera des volumes. Chaque pool peut contenir plusieurs volumes de sauvegarde, on pourra donc créer un pool pour les sauvegardes complètes, et un autre pour les différentielles par exemple. Ou même un pool par machine à sauvegarder. Les ressources “Job” se réfèrent toujours à un Pool, ou plusieurs pools, en fonction du niveau de sauvegarde. On verra ça en configurant une ressource “Job”.
*** Il est important de souligner que chaque type de pool DOIT contenir presque obligatoirement plusieurs volumes : par exemple, si votre pool de “Full” ne contient qu’un seul volume illimité en taille, ce dernier ne pourra pas se recycler car il est impossible de recycler juste une partie d’un volume. En effet, les volumes se recyclent en fonction des périodes de “retention” que l’on définit, donc si je configure bacula pour que les sauvegardes vieilles de 2 semaines se purgent, alors que ces sauvegardes sont contenues dans un volume qui contient également des sauvegardes vieilles de 1 semaine, le volume en question ne pourra alors PAS se purger. Pour expliquer ça simplement, les volumes ne peuvent PAS se purger s’ils contiennent des sauvegardes qui n’ont pas dépassé leur période de retention. Il est donc primordial de limiter la taille des volumes contenus dans les pools avec la directive “Maximum Volume Bytes” (à exprimer en nombre d’octets, dans l’exemple : 100000000000 = 100 Go) ***
***De plus, je n’ai pas compris pourquoi mais bacula semble ne pas fonctionner si le pool nommé “Default” n’existe pas. J’en ai donc laissé un, même s’il m’est inutile…***
PS : Si vous vous sentez confus avec ces histoires de job retention, volume retention etc, ne vous inquiétez pas, c’est normal au début, mais la pratique mettra ça en place dans votre tête….
Name : On donne un nom à notre Pool, afin qu’un job puisse s’y référer.
Storage : Définit à quel ressources “Storage” du bacula-dir.conf se réfère ce pool. Directive indispensable.
Pool Type : Pour définir le type de pool, ici Backup. D’après la doc, seule l’option “Backup” est implémentée..
Volume Retention : On définit ici le delai avant la purge d’un volume (purge = effacement dans la base donnée. Les données, elles, ne sont pas effacées tant que le volume purgé n’est pas physiquement écrasé)
AutoPrune : cette directive permet d’appliquer automatiquement la directive “Volume Retention”, quand aucun volume n’est disponible. On comprend donc que bacula n’execute pas la directive “Volume Retention” en temps réèl, mais seulement quand il est nécessaire de libérer des volumes trop vieux.
Recycle : {yes / no} Permet de réutiliser un volume dont l’enregistrement en base de donnée à été purgé. Par exemple, avec la directive “Volume Retention”, on définira combien de temps un volume doit être conservé, quand ce temps est écoulé, bacula purge ce volume, c’est à dire qu’il efface sont enregistrement dans la base données, et marque le volume comme “écrasable”. La directive “Recycle” permet donc a bacula de chercher les volumes purgés, et de les écraser si aucun volume n’est disponible. Il est donc indispensable de bien gérer le recyclage des volumes, pour éviter de stocker des sauvegardes trop vieilles pour rien.
—> Explication de “Volume Retention”, “AutoPrune”, et “Recycle” :
Prenons le pool “Full-Pool” : Mon volume doit être conservé 6 mois. Quand un job de sauvegarde se lance, mais qu’aucun volume n’est disponible pour écrire les données (plus de place sur le média par exemple), la directive Autoprune cherche alors les volumes plus vieux que 6 mois (comme définit dans “Volume Retention”), pour les purger, puis “Recycle” cherche les volumes qui sont purgés (et donc libres d’être écrasés), et autorise le Storage daemon à les réutiliser.
Label Format : Permet de définir un préfixe pour les fichiers (pools) de sauvegarde créé. Pour le pool “Full-Pool”, les fichiers seront créés sous la forme Full-001.
Recycle Oldest Volume : ordonne à bacula de purger et recycler les volumes LES PLUS VIEUX en priorité, si aucun volume n’est disponible, en respectant les “Volume Retention”.
#################################################################
La ressource “Schedule” :
Schedule {
Name = “WeeklyCycle”
Run = Level = Full mon at 12:00
Run = Level = Differential tue-fri at 12:00
}
La ressource sert à programmer les horaires des sauvegarde. Pour nous, ce sera assez simple car on ne souhaite qu’une sauvegarde Complète tout les Lundi à 12h, et des Différentielles du Mardi au Vendredi à 12h.
Name : On donne un nom à notre ressource Schedule. Ce nom devra être référencé dans le job qui devra obéir à cette programmation. On retrouvera donc ce nom dans la directive “Schedule” de la ressource “Job” concernée (ou dans un JobDefs, rappelons que toute directive configurable dans un job peut être placée dans un JobDefs à la place, pour des raisons d’organistaion…)
Bacula reconnait donc certains mots-clés anglais concernant le temps, ici “Lundi” se dira “mon”, pour “Monday”. Là chaine “tue-fri” représente chaque jour de mardi à vendredi.
Pour les différents mot-clés concernant le temps, se référer à la doc officielle : ICI
#################################################################
La ressource “FileSet” :
La ressource FileSet sert à configurer les arborescences de répertoires que l’on souhaite sélectionner pour être sauvegardés. C’est ici qu’on définit les chemins vers les fichiers à sauver, depuis les machines clientes (par exemple, c’est dans cette ressource qu’on dira à bacula de sauver ce qui se trouve dans “C:\Documents and Settings”). On y définira aussi les exclusions de répertoires, et de types de fichiers, par exemple pour éviter de sauver les fichiers avi ou autre. Si vos clients tournent tous sous le même OS, le fileset sera donc plus simple à créer, et un seul fileset suffira. Si au contraire, les clients ont des systèmes linux ET windows , il faudra configurer plusieurs fileset. En effet, si on configure un job pour une machine linux, il faudra que ce job pointe vers un fileset créé pour linux, logique…Nos ressources “Job” auront donc forcément une directive “FileSet” à renseigner.
Exemple de FileSet Windows :
FileSet {
Name = “Full Set Windows”
Enable VSS = yes
Include {
File = “c:/documents and settings”
File = “d:/Documents and Settings”
Options {
signature = MD5
IgnoreCase = yes
Exclude=yes
compression=GZIP
wild =”*.avi”
wild =”*.mp3″
wild =”*.mpg”
wild =”*.exe”
wild =”*.iso”
wild =”*.wmv”
wild =”*.jpg”
wilddir = “c:/Documents and Settings/Administrateur”
wilddir = “c:/Documents and Settings/All Users”
wilddir = “c:/Documents and Settings/Default User”
wilddir = “c:/Documents and Settings/LocalService”
wilddir = “c:/Documents and Settings/NetworkService”
wilddir = “c:/Documents and Settings/*/Cookies”
wilddir = “c:/Documents and Settings/*/IECompatCache”
wilddir = “c:/Documents and Settings/*/IETIdCache”
wilddir = “c:/Documents and Settings/*/Local Settings”
wilddir = “c:/Documents and Settings/*/PrivacIE”
wilddir = “c:/Documents and Settings/*/Recent”
wilddir = “c:/Documents and Settings/*/SendTo”
wilddir = “c:/Documents and Settings/*/temp”
wilddir = “c:/Documents and Settings/*/UserData”
}
}
}
Voici un exemple de FileSet pur windows. On constate qu’il faudra remplacer les anti-slash des chemins par des slash. Ici, les directives “wilddir” servent à exclure un chemin complet, et les “wild” à exclure des types de fichiers
Exemple de FileSet Linux :
FileSet {
Name = “Full Set linux”
Include {
Options {
signature = MD5
IgnoreCase = yes
compression=GZIP
}
File = “/home/”
File = “/var/www”
File = “/media/commun/Mes documents”
}
Exclude {
File = /proc
File = /tmp
}
}
Les extensions de fichiers étant inexistantes sous Linux, les exclusions de types de fichiers n’existent pas non plus. Sous Linux, le VSS perd tout son sens et n’est pas nécessaire à la copie des fichiers en cours d’utilisation.
!!!! Étudiez bien votre FileSet, et vous économiserez énormément de place sur votre média de sauvegarde. !!!!
#################################################################
La ressource “Catalog” :
C’est ici que l’on définira la localisation de la base de données, et l’authentification :
Catalog {
Name = MyCatalog
# Uncomment the following line if you want the dbi driver
# dbdriver = “dbi:sqlite3″; dbaddress = 127.0.0.1; dbport =
dbname = nom_de_BDD; DB Address = “localhost”; dbuser = “user_avec_privilèges”; dbpassword = “mot_de_passe”
}
“Name” donne un nom à la ressources, et sera appelé par les ressources “Client”. On pourrait donc configurer plusieurs catalogues avec plusieurs BDD. Ici, un catalogue seul nous suffira. Rien à ajouter, si ce n’est qu’il vous faudra dé-commenter la ligne 4 pour utiliser un pilote “dbi” pour communiquer avec la base données…
##################################################################
La ressource “Message” :
Messages {
Name = Daemon
mailcommand = “/usr/lib/bacula/bsmtp -h localhost -f \”\(Bacula\) \<%r\>\” -s \”Bacula daemon message\” %r”
mail = root@localhost = all, !skipped
console = all, !skipped, !saved
append = “/var/lib/bacula/log” = all, !skipped
}
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
catalog = all
}
Cette ressource permet de “diriger”, en quelques sortes, les messages de type “INFO, WARNING, ERROR, FATAL”, générés par bacula. On pourra alors les envoyer ou on le souhaite. Je ne me suis pas penché sur le sujet, mais je pense que ça peut servir pour garder un œil sur les alertes, quand on est loin du serveur bacula. La configuration par défaut fonctionne en tout cas. Dans le fichier bacula-sd.conf, la ressource “Message” est présente là aussi, et appelle la ressource “Message” nommée “Standard”. On retrouve aussi une ressource “Message” dans le bacula-fd.conf, et elle pointe aussi vers cette ressource nommée “Standard”. Les daemon s’appuient donc sur cette configuration.
#####################################################################
La ressource “Console” :
Console {
Name = Bacula-mon
Password = “mot_de_passe_d’accès_pour_les_consoles_d’admin”
CommandACL = status, .status
}
On définit ici les identifiants à utiliser pour autoriser les outils d’administration à interagir avec bacula-dir et bacula-sd. Ces identifiants seront donc utilisés pour configurer la bacula-console (bconsole.conf) et le “bat” (bat.conf) par exemple, et il faudra aussi les entrer dans le bacula-sd.conf, quand on le configurera.
“CommandACL” est sensé permettre de définir les commandes que la bacula-console sera autorisée à utiliser, mais j’avoue que je n’ai pas trop compris car avec cette simple configuration, toutes les commandes de base ont l’air accessibles, je laisse donc ainsi…
#####################################################################
La ressource “Client” :
Client {
Name = nom_du_client_1-fd
Address = 192.168.0.1
FDPort = 9102
Catalog = MyCatalog
Password = “mot_de_passe”
File Retention = 30 days
Job Retention = 6 months
AutoPrune = yes
}
Client {
Name = nom_du_client_2-fd
Address = 192.168.0.2
FDPort = 9102
Catalog = MyCatalog
Password = “mot_de_passe”
File Retention = 30 days
Job Retention = 6 months
AutoPrune = yes
}
La ressource “Client” permet de définir les clients à sauvegarder. Une ressource “Client” définit une et une seule machine cliente. Heureusement, on peut définir autant de ressources “Client” que nécessaire.
Name : On donne un nom à la ressource, le mieux étant d’en définir un qui soit parlant, le nom de machine du client par exemple.
Address : L’IP de la machine cliente.
FDPort : Le port d’écoute du File Daemon (par défaut 9102).
Catalog : Entrer le même nom que la directive “Name” de la ressource “Catalog”.
Password : Entrer le même mot de passe que celui de la ressource “Director” du fichier bacula-fd.conf de la machine cliente.
File Retention : Cette directive sert à définir combien de temps les enregistrements des fichiers dans la BDD seront conservés. S’il existe une directive “Autoprune = yes”, alors la base de donnée sera purgée automatiquement de ces enregistrements. Cela n’affecte pas les fichiers physique existants mais seulement leur enregistrement en base de donnée (n’oublions pas que tout y est enregistré constamment).
Job Retention : Cette directive est identique à “File Retention”, hormis qu’il s’agit ici des enregistrements concernant les jobs et non les fichiers sauvés (Statuts des jobs).
Autoprune = yes / no : Et enfin “Autoprune” sert à purger automatiquement les enregistrements en question. Si on mets “non”, la base de données se verra grandir de manière incommode !
Voila donc l’enregistrement basique d’une machine cliente. Sur un parc, la liste peut devenir longue, il est donc vivement conseillé de les insérer dans un fichier propre aux machines clientes, en indiquant l’emplacement absolu du fichier au tout début du bacula-dir.conf comme ceci :
@/etc/bacula/clients.conf
#####################################################################
Les ressources “Job” et “JobDefs” :
Il ne nous reste maintenant qu’à configurer les “Job”, c’est à dire les travaux que Bacula va effectuer. Un job se rattache à un et un seul client, il faudra donc créer une ressource “Job” liée à chaque machine. Heureusement, la ressource “JobDefs” est là pour faciliter le boulot, et éviter d’avoir à remplir des dizaines de ressources “Job”.
Je m’explique :
-Les ressources “Job” et “JobDefs” peuvent contenir toutes les deux les mêmes directives, on pourra donc définir une ou plusieurs “JobDefs” génériques, et des “Job” bien plus épurés qui s’y réfèreront. En définitive on aura de bonnes grosses “JobDefs” et nos “Job” viendront se greffer dessus de manière simple et évolutive. De cette manière, on pourra aussi plus facilement changer la configuration des job en masse.
Job {
Name = “Backup-nom_de_machine_1-fd”
Client = nom_du_client_1-fd
JobDefs = “DefaultBackup”
Run Before Job = “wakeonlan xx:xx:xx:xx:xx:xx”
Run After Job = “net rpc shutdown -f -I IP_client -U admin_distant%mot_de_passe -t 10 -C “Arrêt du PC”"
}
Job {
Name = “Backup-nom_de_machine_2-fd”
Client = nom_du_client_2-fd
JobDefs = “DefaultBackup”
Run Before Job = “wakeonlan xx:xx:xx:xx:xx:xx”
Run After Job = “net rpc shutdown -f -I IP_client -U admin_distant%mot_de_passe -t 10 -C “Arrêt du PC”"
}
JobDefs {
Name = “DefaultBackup”
Type = Backup
Level = Full
Max Run Time = 360 mins
FileSet = “Full Set Windows”
Schedule = “WeeklyCycle”
Storage = File
Messages = Standard
Accurate = yes
Pool = Full-Pool
Full Backup Pool = Full-Pool
Differential Backup Pool = Diff-Pool
Incremental Backup Pool = Inc-Pool
Priority = 10
Reschedule On Error = yes
Reschedule Interval = 15 minutes
Reschedule Times = 5
Write Bootstrap = “/var/spool/bacula/Client1.bsr”
}
“Job” :
-Name : On donne un nom à notre ressource “Job”. Ce nom sera utilisé régulièrement à travers la console d’administration et autres outils d’admin, pour exécuter des tâches manuellement par exemple. On choisira donc un nom évoquant le type de travail (“Backup, par exemple”), et le nom de machine.
-Client : Notre “Job” devant être lié à une machine cliente, on indiquera laquelle par cette directive. C’est pourquoi on entrera le même nom que celui choisi dans la directive “Name” de la ressource “Client” liée à ce “Job”
-JobDefs : C’est ici qu’on indique sur quelle “JobDefs” s’appuiera notre “Job”. On entrera donc le même nom que celui choisi pour la directive “Name” de la ressource “JobDefs” en question.
Ensuite on va configurer la “JobDefs”, puisque sans elle, notre “Job” ne veut rien dire du tout. Il faut savoir que le contenu du “Job” est prioritaire sur celui de la “JobDefs”, ça peut être utile quand un “Job” sort un peu du lot…
-Run Before Job : Permet de rentrer une commande externe à Bacula, comme une commande de Wake on LAN par exemple, qui sera exécutée avant le “Job”.
-Run After Job : Permet d’executer une commande APRES le job.
“JobDefs” :
-Name : On nomme notre ressource, afin que la directive “JobDefs” des ressources “Job” puissent s’y référer.
-Type : On définit le type de job (Backup, Restore, Verify ou Admin). Ici nous n’aborderons que le type “Backup” et très rapidement “Restore”.
-Level : Selon le type de job définit dans “Type”, on choisira un “Level” adapté. Par exemple, pour un type de job “Backup”, les “Level” différents seront “Full | Differential | Incremental”. Pour un job de type “Restore”, il n’y a pas de différents niveaux, donc pas de directive “Level” nécessaire. Pour les jobs de type “Verify”, plusieurs niveaux intéressants sont à étudier, notamment ceux qui permettent la vérification des attributs de fichiers. Pour mieux connaitre le fonctionnement des types de job “Verify”, se référer à la doc officielle : Documentation officielle.
-Max Run Time : Permet de définir une durée maximal de déroulement du job. Le job en question sera automatiquement annulé si sa durée dépasse celle qui est définie ici. Cette ressource n’est pas indispensable.
-FileSet : On indique ici le nom du FileSet associé à la “JobDefs”. On entrera donc la même chaine que dans la directive “Name” de la ressource “FileSet” concernée.
-Schedule : On indique la ressource “Schedule” associée à notre “JobDefs”. On entrera donc la même chaine que dans la directive “Name” de la ressource “Schedule” concernée.
-Storage : On définit ici la ressource “Storage” utilisée pour le stockage des sauvegarde, on entrera donc la même chaine que dans la directive “Name” de la ressource “Storage” concernée (ici, une seule ressource “Storage” nommée “File” existe).
-Messages : On entrera ici la même chaine que la directive “Name” de notre ressource “Messages”.
-Accurate = yes / no : En mode accurate, Bacula garde en mémoire (RAM) la liste des fichiers et répertoires dernièrement sauvegardés. Cela lui permet de manipuler des fichiers renommés ou supprimés. Cette fonction peut être lourde en terme de mémoire vive (64Mo environ pour 500 000 fichiers), et n’est pas obligatoire.
-Pool : Sert à définir quelle ressource “Pool” doit être utilisée par la “JobDefs”. La chaine doit être identique à celle de la directive “Name” de la ressource “Pool” concernée. Nous sommes intéressés par l’idée d’avoir un pool pour chaque niveau de sauvegarde différent, on pourra donc renseigner les directives suivantes :
Full Backup Pool = Full-Pool
Differential Backup Pool = Diff-Pool
Incremental Backup Pool = Inc-Pool
En prenant soin de créer les ressources “Pool” nommées Full-Pool, Diff-Pool et Inc-Pool.
—> Même si on utilise plusieurs Pools différents, la directive “Pool” – tout court – reste obligatoire (je n’ai pas compris pourquoi finalement), c’est pourquoi ma directive “Pool” à la même valeur que ma directive “Full Backup Pool”
-Priority : Sert à définir un ordre de priorité aux jobs.
#####################################################################
–Directives pour relancer un job qui n’a pas pu se faire, par exemple si le client est éteint. Ces directives sont a placer dans un job, ou mieux, dans une jobdefs :
Reschedule On Error = yes
Reschedule Interval = 15 minutes
Reschedule Times = 5
L’ordre se résume ainsi : Ressayer de lancer la sauvegarde échouée toutes les 15 minutes, 5 fois. Le terme “Minutes” est un mot clé que bacula reconnait. Pour les différents mot-clés concernant le temps, se référer à la doc officielle : ICI
#####################################################################
Nous avons fait le tour du fichier “bacula-dir.conf” (dites moi si vous remarquez une erreur !), mais cela ne suffit pas à faire fonctionner le serveur. La prochaine étape consiste à configurer le fichier “bacula-sd.conf”, pour définir où et comment les données seront physiquement écrites.
####################################################################
LE FICHIER BACULA-SD.CONF
####################################################################
