Si vous êtes comme moi, vous voulez faire fonctionner Bacula immédiatement pour en avoir un aperçu, puis, plus tard, vous reviendrez en arrière pour lire et connaître tous les détails. C'est exactement ce que ce chapitre se propose d'accomplir : vous faire avancer rapidement sans tous les détails. Si vous voulez sauter la section sur les Pools, Volumes et Labels, vous pourrez toujours y revenir, mais s'il vous plaît, veuillez lire ce chapitre jusqu'à la fin, et en particulier suivre les instructions pour tester votre lecteur de bandes.
Nous supposons que vous êtes parvenus à construire et installer Bacula, sinon, vous devriez d'abord jeter un oeil aux Prérequis (système) puis au chapitre Compiler et installer Bacula de ce manuel.
Afin de rendre Bacula aussi flexible que possible, les directives lui sont données en plusieurs endroits. L'instruction principale est la ressource Job, qui définit un job. Un job de type sauvegarde consiste en général en un FileSet, un client, un Schedule pour un ou plusieurs niveaux ou horaires de sauvegardes, un Pool, ainsi que des instructions additionnelles. Un autre point de vue est de considérer le FileSet comme "Que sauvegarder ?", le Client comme "Qui sauvegarder ?", le Schedule comme "Quand sauvegarder ?" et le Pool comme "Où sauvegarder ?" (c'est à dire, "Sur quel volume ?)
Typiquement, une combinaison FileSet/Client aura un job correspondant. La plupart des directives, telles que les FileSets, Pools, Schedules, peuvent être mélangées et partagées entre les jobs. Ainsi, vous pouvez avoir deux définitions (ressources) de jobs sauvegardant différents serveurs et utilisant les mêmes Schedule, FileSet (sauvegardant donc les mêmes répertoires sur les deux machines) et peut-être même les mêmes Pools. Le Schedule définira quel type de sauvegarde sera exécuté et à quel moment (par exemple les Full le mercredi, les incrémentales le reste de la semaine), et lorsque plus d'un job utilise le même Schedule la priorité du job détermine lequel démarre en premier. Si vous avez de nombreux jobs, vous devriez utiliser la directive JobDefs, qui vous permet de définir des paramètres par défaut pour vos jobs, qui peuvent être changés au sein de la ressource Job, mais qui vous évitent de réécrire les mêmes paramètres pour chaque job. En plus des FileSets que vous voulez sauvegarder, vous devriez aussi avoir un job qui sauvegarde votre catalogue.
Enfin, sachez qu'en plus des jobs de type Backup, vous pouvez aussi utiliser des jobs de type restore, verify, admin, qui ont chacun des exigences différentes.
Si vous avez utilisé un programme tel que tar pour sauvegarder votre système, les notions de Pools, Volumes et labels peuvent vous sembler un peu confuses au premier abord. Un Volume est un simple support physique (cartouche, ou simple fichier) sur lequel Bacula écrit vos données de sauvegarde. Les Pools regroupent les Volumes de sorte qu'une sauvegarde n'est pas restreinte à la capacité d'un unique Volume. Par conséquent, plutôt que de nommer explicitement les Volumes dans votre Job, vous spécifiez un Pool, et Bacula se chargera de sélectionner le prochain Volume utilisable du Pool et vous demandera de le monter.
Bien que les options de base soient spécifiées dans la ressource Pool du fichier de configuration du Director, le Pool réel est géré par le Catalogue Bacula. Il contient les informations de la ressource Pool (bacula-dir.conf) ainsi que les informations concernant tous les Volumes qui ont été ajoutés au Pool. L'ajout de Volumes se fait en principe manuellement depuis la Console grâce à la commande label.
Pour chaque Volume, Bacula gère une quantité d'informations considérable telles que les première et dernière date et heure d'écriture, le nombre de fichiers sur le Volume, le nombre de bytes sur le Volume, le nombre de montages, etc.
Pour que Bacula puisse lire ou écrire sur un Volume physique, celui-ci doit avoir reçu un étiquettage logiciel afin que Bacula soit assuré que le bon Volume est monté. Ceci s'effectue en principe manuellement depuis la Console grâce à la commande label.
Les étapes de création de Pool, ajout de Volumes à ce Pool, et écriture d'étiquettes logicielles sur les Volumes, peuvent sembler pénibles au premier abord, mais en fait, elles sont tout à fait simples à franchir, et elles vous permettent d'utiliser plusieurs Volumes (plutôt que d'être limité à la capacité d'un seul). Les Pools vous procurent aussi une flexibilité importante pour votre politique de sauvegarde. Par exemple, vous pouvez avoir un Pool de Volumes "Daily" pour vos sauvegardes Incrémentales et un Pool de Volumes "Weekly" pour vos sauvegardes complètes (Full). En spécifiant le Pool approprié dans les Jobs de sauvegarde quotidiens et hebdomadaires, vous garantissez qu'aucun Job quotidien n'écrira jamais sur un Volume du Pool réservé aux sauvegardes hebdomadaire et vice versa, et Bacula vous dira quelle cartouche est requise, et quand.
Pour plus de détails concernant les Pools, consultez la section Ressource Pool du chapitre sur la configuration du Director, ou poursuivez votre lecture, nous reviendrons plus tard sur ce sujet.
Après avoir exécuté la commande ./configure ad hoc, make et make install, si c'est la première fois que vous exécutez
Bacula, vous devez créer des fichiers de configuration valides pour le
Director, le File Daemon, le Storage Daemon et le programme Console. Si vous
avez suivi nos recommandations, des fichiers de configuration par défaut
ainsi que les binaires des daemons seront situés dans votre
répertoire d'installation. Dans tous les cas les binaires se trouvent dans
le répertoire que vous avez spécifié au niveau de l'option --sbindir de la commande ./configure, et les fichiers de configuration
se trouvent dans le répertoire que vous avez spécifié au niveau de
l'option --sysconfdir.
Lors des paramétrages initiaux de Bacula, il vous faudra investir un peu de temps pour modifier les fichiers de configuration par défaut afin de les adapter à votre environnement. Ceci peut nécessiter de redémarrer Bacula plusieurs fois jusqu'à ce que tout fonctionne correctement. Ne cédez pas au désespoir. Une fois que vous aurez créé vos fichiers de configuration, vous n'aurez que rarement besoin de les changer et de redémarrer Bacula. Le gros du travail consistera à changer la cartouche quand elle est pleine.
Le programme console est utilisé par l'administrateur pour interagir avec le Director et pour arrêter et démarrer manuellement des jobs, ou encore pour obtenir des informations sur les jobs en cours d'exécution ou programmés.
Le fichier de configuration de la Console se trouve dans le répertoire que
vous avez spécifié au niveau de l'option --sysconfdir de la commande
./configure et par défaut se nomme console.conf.
Si vous avez choisi de construire la Console GNOME avec l'option --enable-gnome, vous y trouverez également son fichier de configuration par
défaut, nommé gnome-console.conf.
Il en va de même pour la console wxWidgets, qui est construite par l'option
--enable-bwx-console, et le nom du fichier de configuration par défaut
est, dans ce cas, bwx-console.conf.
Normalement, pour les nouveaux utilisateurs, aucune modification n'est requise pour ces fichiers. Les réglages par défaut sont raisonnables.
Le programme Monitor est typiquement une icône dans la barre des tâches. Cependant, lorsque l'icône est étendue en une fenètre, l'administrateur ou l'utilisateur peut obtenir des informations concernant le Director ou l'état des sauvegardes sur la machine locale ou n'importe quelle autre daemon Bacula configuré.
L'image montre le tray-monitor configuré pour trois daemons. En cliquant sur les boutons radio dans le coin en haut à gauche de l'image, vous pouvez voir l'état de chacun des daemons. L'image montre l'état du Storage Daemon (MainSD) sélectionné.
Le fichier de configuration du Monitor se trouve dans le répertoire
spécifié au niveau de l'option --sysconfdir de la commande ./configure et se nomme par défaut tray-monitor.conf. En principe,
pour les nouveaux utilisateurs, il suffit de changer les permissions de ce
fichier pour permettre aux utilisateurs non-root d'exécuter le Monitor, en
effet cette application doit être exécuté par le même utilisateur que
l'environnement graphique (n'oubliez pas de donner aux non-root le droit
d'exécuter bacula-tray-monitor). Ceci ne constitue pas une faille de
sécurité tant que vous utilisez les réglages par défaut.
Le File Daemon, est le programme qui s'exécute sur chaque machine cliente. A la demande du Director, il détermine les fichiers à sauvegarder et les expédie au Storage Daemon.
Le fichier de configuration du File Daemon se trouve dans le répertoire
spécifié au niveau de l'option --sysconfdir de la commande ./configure et se nomme par défaut bacula-fd.conf. Normalement, pour
les nouveaux utilisateurs, aucune modification n'est requise pour ce fichier.
Les réglages par défaut sont raisonnables. Cependant, si vous envisagez de
sauvegarder plus d'une machine, il vous faudra installer le File Daemon avec
un fichier de configuration spécifique sur chaque machine à sauvegarder.
Les informations concernant chaque File Daemon doivent apparaître dans le
fichier de configuration du Director.
Le director est le programme central qui contrôle tous les autres daemons. Il planifie et surveille les jobs à exécuter.
Le fichier de configuration du Director se trouve dans le répertoire
spécifié au niveau de l'option --sysconfdir de la commande ./configure et se nomme par défaut bacula-dir.conf.
En général, la seule modification nécessaire consiste à faire en sorte que la directive Include de la Ressource FileSet contienne au moins une ligne avec un nom de fichier ou de répertoire valide à sauvegarder.
Si vous ne possédez pas de lecteur DLT, vous voudrez probablement modifier la ressource Storage pour donner un nom plus représentatif de votre périphérique de stockage. Vous pouvez toujours utiliser les noms existants puisque vous êtes libre de les assigner arbitrairement, mais ils doivent s'accorder avec les noms correspondants dans le fichier de configuration du Storage Daemon.
Vous pouvez aussi changer l'adresse électronique pour les notifications vers votre propre adresse e-mail plutôt que vers celle de root (configuration par défaut).
Enfin, si vous avez plusieurs systèmes à sauvegarder, il vous faudra spécifier un File Daemon (ou client) pour chaque système sauvegardé, précisant ses nom, adresse et mot de passe. Nous estimons que baptiser vos daemons du nom de vos systèmes suffixés avec -fd aide beaucoup à corriger les erreurs. Ainsi, si votre système est foobaz, vous nommerez le daemon foobaz-fd. Pour le Director, vous pourriez utiliser foobaz-dir, et foobaz-sd pour le Storage Daemon. Chacun de vos composants de Bacula doit avoir un nom unique Si vous les nommez tous à l'identique, en plus de ne jamais savoir quel daemon envoie quel message, s'ils partagent le même répertoire de travail (working directory), les noms de fichiers temporaires des daemons ne seront pas uniques et vous aurez d'étranges erreurs.
Le Storage Daemon est responsable, sur demande du Director, de la réception des données en provenance des File Daemons, et de leur écriture sur le medium de stockage, ou, dans le cas d'une restauration, de trouver les données pour les envoyer vers le File Daemon.
Le fichier de configuration du Storage Daemon se trouve dans le répertoire
spécifié au niveau de l'option --sysconfdir de la commande ./configure et se nomme par défaut bacula-sd.conf. Modifiez ce
fichier pour accorder les noms de périphériques de stockage à ceux que
vous possédez. Si le processus d'installation a convenablement détecté
votre système, elles seront déjà correctement réglées. Ces
ressources de stockage "Name" et "Media Type" doivent être les mêmes
que leurs correspondantes du fichier de configuration du Director bacula-dir.conf. Si vous souhaitez sauvegarder vers un fichier plutôt que
sur des bandes, la ressource Device doit pointer vers un répertoire où des
fichiers seront créés en guise de Volumes lorque vous étiquetterez
(label) vos Volumes.
Vous pouvez tester la validité syntaxique de vos fichiers de configuration, afficher tout message d'erreur et terminer. Par exemple, en supposant que vous avez installé vos binaires et fichiers de configuration dans le même répertoire,
cd <installation-directory> ./bacula-dir -t -c bacula-dir.conf ./bacula-fd -t -c bacula-fd.conf ./bacula-sd -t -c bacula-sd.conf ./bconsole -t -c bconsole.conf ./gnome-console -t -c gnome-console.conf ./bwx-console -t -c wx-console.conf su <normal user> -c "./bacula-tray-monitor -t -c tray-monitor.conf"
testera le fichier de configuration de chacun des principaux programmes. Si le fichier de configuration est correct, le programme se termine sans rien afficher. Veuillez noter que selon les options de configuration que vous avez choisies, il se peut qu'aucune des commandes ci-dessus ne soit valable sur votre système. Si vous avez installé les binaires dans les répertoires traditionnels d'Unix plutôt que dans un simple répertoire, il vous faudra modifier les commandes ci-dessus en conséquence (pas de "./" devant les commandes, et un chemin devant les fichiers de configuration).
Avant de gaspiller votre temps avec Bacula pour finalement constater qu'il ne fonctionne pas avec votre lecteur de bandes, veuillez s'il vous plaît lire le chapitre btape -- Tester votre lecteur de bandes de ce manuel. Si vous possédez un lecteur standard SCSI moderne sur un Linux ou un Solaris, fort probablement, il fonctionnera, mais mieux vaut tester que d'être déçu. Pour FreeBSD (et probablement les autres xBSD), la lecture du chapitre mentionné ci-dessus est un devoir. Pour FreeBSD, consultez aussi The FreeBSD Diary pour une description détaillée de la méthode pour faire fonctionner Bacula sur votre système. De plus, les utilisateurs de versions de FreeBSD antérieures à 4.9-STABLE datée du lundi 29 décembre 2003 15:18:01 UTC qui prévoient d'utiliser des lecteurs de bandes sont invités à lire le fichier platforms/freebsd/pthreads-fix.txt du répertoire principal de Bacula, qui contient d'importantes informations sur la compatibilité de Bacula avec leur système.
La nouvelle librairie pthreads /lib/tls installée par défaut sur les systèmes Red Hat récents (kernels 2.4.x) est défectueuse. Vous devez la supprimer ou la renommer, puis rebooter votre système avant d'exécuter Bacula, faute de quoi, après environ une semaine de fonctionnement, Bacula se bloquera pour de longues périodes, voire définitivement. Veuillez consulter le chapitre Systèmes supportés pour plus d'informations sur ce problème.
Ce problème n'existe plus avec les noyaux 2.6.
La partie la plus importante de l'exécution de Bacula est probablement la capacité de restaurer les fichiers. Si vous n'avez pas essayé de récupérer des fichiers au moins une fois, vous subirez une bien plus forte pression le jour où vous devrez réellement le faire, et serez enclin à commettre des erreurs que vous n'auriez pas commises si vous aviez déjà essayé.
Pour avoir rapidement une bonne idée de la façon d'utiliser Bacula, nous vous recommandons fortement de suivre les exemples du chapitre exécuter Bacula de ce manuel, où vous trouverez des informations détaillées sur l'exécution de Bacula.
Si vous utilisez le bacula-dir.conf par défaut ou une variante, vous constaterez qu'il récupère toutes les sorties de Bacula dans un fichier. Pour éviter que ce fichier ne croisse sans limites, nous vous recommandons de copier le fichier logrotate depuis scripts/logrotate vers /etc/logrotate.d/bacula. Ainsi les fichiers de logs subiront une rotation mensuelle et seront conservés pour une durée maximum de cinq mois. Vous pouvez éditer ce fichier pour adapter la rotation à votre convenance.
Si vous avez l'intention d'utiliser Bacula en tant qu'outil de disaster recovery plutôt que comme un simple programme pour restaurer les fichiers perdus, vous serez intéressé par le chapitre Plan de reprise d'activité avec Bacula de ce manuel.
De toute façon, vous êtes fortement invité à tester soigneusement la restauration de quelques fichiers que vous aurez préalablement sauvegardés, plutôt que d'attendre qu'un désastre ne frappe. Ainsi, vous serez préparé.