next up previous contents index
suivant: Configuration du Client/File Daemon monter: Adapter les fichiers de précédent: Informations détaillées sur chaque   Table des matières   Index

Sous-sections


Configurer le Director

Parmi tous les fichiers de configuration requis pour exécuter Bacula, celui du Director est le plus compliqué, et c'est celui que vous modifierez le plus souvent, en ajoutant des clients ou en modifiant les FileSets.

Pour une discussion générale concernant les fichiers et ressources ainsi que les types de données reconnus par Bacula, veuillez consulter le chapitre Configuration de ce manuel.

Les types de ressources du Director

Les types de ressources du Director sont :

Job, JobDefs, Client, Storage, Catalog, Schedule, FileSet, Pool, Director, et Messages. Nous les présentons ici dans l'ordre le plus logique (relativement au fichier de configuration du Director) :


La ressource Director

La ressource Director définit les attributs du Director exécuté sur le réseau. Dans l'implémentation actuelle, il n'y a qu'une ressource Director, mais la réalisation finale contiendra plusieurs Directors pour maintenir la redondance de la base des indexes et média.

Director
Début de la ressource Director. Une ressource Director et une seule doit être définie.

Name = <nom>
Le nom du Director utilisé par l'administrateur système. Cette directive est requise

Description = < texte>
Le champ texte contient une description du Director qui sera affichée dans l'interface graphique. Cette directive est optionnelle.

Password = <UA-password>
Spécifie le mot de passe qui doit être fourni par la Console Bacula par défaut pour être autorisée. Le même mot de passe doit apparaître dans la ressource Director du fichier de configuration de la console. Pour plus de sécurité, le mot de passe ne transite jamais sur le réseau, l'authentification se fait via un échange de type challenge-response d'un hash code créé avec le mot de passe. Cette directive est requise. Si vous disposez de /dev/random ou bc sur votre machine, Bacula génèrera un mot de passe aléatoire lors du processus d'installation, sinon il sera laissé blanc et vous devrez en définir un manuellement.

Messages = <Nom-de-ressource-Messages>
La ressource messages spécifie où doivent être délivrés les messages du Director qui ne sont pas associés à un job spécifique. La plupart des messages sont relatifs à un job et seront dirigés vers la ressource messages spécifiée par le job. Cependant, quelques messages peuvent être générés lorsque aucun job n'est actif. Cette directive est requise.

Working Directory = <Répertoire>
Cette directive spécifie un répertoire où le Director peut déposer ses fichiers d'états. Ce répertoire ne devrait être utilisé que par Bacula, mais il peut être partagé par d'autres daemons Bacula. Notez cependant que si ce répertoire est partagé avec d'autres daemons Bacula, vous devez vous assurer que le nom Name donné à chaque daemon est unique afin d'éviter des collisions entre les fichiers temporaires utilisés. Par défaut, le processus de configuration de Bacula créé des noms de daemons uniques en les postfixant avec -dir, -fd et -sd. Les substitutions shell standard sont effectuées à la lecture du fichier de configuration, de sorte que des valeurs telles que $HOME seront correctement substituées. Cette directive est requise.

Si vous avez spécifié un utilisateur et/ou un groupe pour le Director lors de la configuration avec les options --with-dir-user et/ou --with-dir-group de la commande ./configure, le répertoire de travail Working Directory doit appartenir doit appartenir à ce groupe et à cet utilisateur.

Pid Directory = <Répertoire>
Cette directive spécifie un répertoire où le Director peut déposer son fichier d'Id de processus. Ce fichier est utilisé pour stopper Bacula et prévenir l'exécution simultanée de plusieurs copies de Bacula. Les substitutions shell standard sont effectuées à la lecture du fichier de configuration, de sorte que des valeurs telles que $HOME seront correctement substituées.

Typiquement, sur les systèmes Linux, vous utiliserez ici /var/run. Si vous n'installez pas Bacula dans les répertoires système, vous pouvez utiliser le répertoire de travail Working Directory défini plus haut. Cette directive est requise.

Scripts Directory = <Directory>
Cette directive spécifie le répertoire dans lequel le Director devra rechercher le script Python de démarrage DirStartup.py. Ce répertoire peut être partagé par d'autres daemons Bacula.Les substitutions shell standard sont effectuées à la lecture du fichier de configuration, de sorte que des valeurs telles que $HOME seront correctement substituées. Cette directive est optionnelle.

QueryFile = <Path>
Cette directive spécifie un répertoire et un fichier dans lequel le Director peut trouver les requêtes SQL préétablies pour la commande Query de la Console. Les substitutions shell standard sont effectuées à la lecture du fichier de configuration, de sorte que des valeurs telles que $HOME seront correctement substituées. Cette directive est requise.

Maximum Concurrent Jobs = <nombre>

Où <nombre> est le nombre maximal de jobs qui peuvent être exécutés simultanément par le Director. La valeur par défaut est 1, mais vous pouvez utiliser une valeur plus grande. Notez que le format des volumes devient beaucoup plus compliqué avec plusieurs jobs exécutés simultanément. De ce fait, les restaurations peuvent prendre beaucoup plus de temps si Bacula doit faire le tri parmi les segments entremélés de ces jobs. Ceci peut être évité en s'arrangeant pour que chacun des jobs exécutés simultanément écrive sur un volume distinct. Une autre possibilité consiste à utiliser le data spooling : les données seront d'abord "spoolées" sur disque simultanément, ensuite les fichiers "spool" seront écrits séquentiellement sur le volume.

Dans certains cas, des directives telles que Maximum Volume Jobs ne sont pas correctement synchronisées avec le nombre de jobs simultanés, et des problèmes de synchronisation subtils peuvent survenir, aussi des tests minutieux sont recommandés.

Actuellement, il n'y a aucun paramètre de configuration pour régler ou limiter le nombre de connections par console. Un maximum de cinq connection simultanées est autorisé.

Pour plus de détails concernant l'exécution simultanée de plusieurs jobs, consultez la partie Exécution simultanée de plusieurs jobs du chapitre Astuces de ce manuel.

FD Connect Timeout = <durée>
Où durée est le délai durant lequel le Director tente de contacter le File Daemon pour démarrer un job. Une fois ce délai écoulé, le Director supprimera le job. La valeur par défaut est 30 minutes.

SD Connect Timeout = <durée>
Où durée est le délai durant lequel le Director tente de contacter le Storage Daemon pour démarrer un job. Une fois ce délai écoulé, le Director supprimera le job. La valeur par défaut est 30 minutes.

DirAddresses = <Spécification-adresses-IP>
Spécifie les ports et adresses sur lesquels le Director se met en attente de connections de Consoles Bacula. La meilleure explication est sans doute un exemple : 

 DirAddresses  = { 
    ip = { addr = 1.2.3.4; port = 1205;}
    ipv4 = {
        addr = 1.2.3.4; port = http;}
    ipv6 = {
        addr = 1.2.3.4;
        port = 1205;
    }
    ip = {
        addr = 1.2.3.4
        port = 1205
    }
    ip = { addr = 1.2.3.4 }
    ip = { addr = 201:220:222::2 }
    ip = {
        addr = bluedot.thun.net
    }
 }

où "ip", "ip4", "ip6", "addr", et "port sont les mots clef. Notez que les adresses peuvent être spécifiées sous forme de quadruplets pointés, ou suivant la notation à doubles points IPv6, ou encore sous forme de nom symbolique (seulement pour la spécification ip). D'autre part, le port peut être spécifié par un nombre, ou par une valeur mnémonique du fichier /etc/services. Si un port n'est pas précisé, celui par défaut sera utilisé. Si une section ip est spécifiée, la résolution peut être faite soit par IPv4, soit par IPv6. Si ip4 est spécifié, seules les résolutions IPv4 seront permises. Il en va de même avec ip6.

Notez que si vous utilisez la directive DirAddresses, vous ne devez utiliser ni la directive DirPort, ni la directive DirAddress dans la même ressource.

DIRport = <numéro-de-port>
Spécifie le port (un entier positif) sur lequel le Director est à l'écoute de connections de Consoles Bacula. Ce même numéro de port doit être spécifié dans la ressource Director du fichier de configuration de la console. La valeur par défaut est 9101, aussi, il n'est en principe pas nécessaire de renseigner cette directive. Elle n'est pas requise si vous spécifiez des DirAdresses.

DirAddress = <Adresse-IP>
Cette directive est optionnelle. Lorsqu'elle est spécifiée, le Director n'accepte de connections Console que de l'adresse spécifiée Adresse-IP, qui peut être soit un nom de domaine, soit une adresse IP au format quadruplet pointé ou chaîne quotée. Si cette directive n'est pas spécifiée, le Director acceptera des connections de Console de toute adresse valide. Notez que contrairement à la spécification DirAdresses décrite plus haut, cette directive ne permet de spécifier qu'une seule adresse. Cette directive n'est pas requise si vous utilisez la directive DirAdresses.

Voici un exemple d'une ressource Director valide : 

Director {
  Name = HeadMan
  WorkingDirectory = "$HOME/bacula/bin/working"
  Password = UA_password
  PidDirectory = "$HOME/bacula/bin/working"
  QueryFile = "$HOME/bacula/bin/query.sql"
  Messages = Standard
}


La ressource Job

La ressource Job définit un Job (sauvegarde, restauration,...) que Bacula doit exécuter. Chaque définition de ressource Job contient le nom d'un client, la liste des éléments à sauvegarder (FileSet), la planification (Schedule) pour ce Job, le lieu où sauvegarder ces données (Storage Device) et quel groupe de media utiliser (Pool). En effet, chaque ressource Job doit répondre aux questions : "Quoi ?", "Où ?", "Quand ?" et "Comment ?" soit, respectivement Fileset, Storage, Schedule, Type et Niveau (Sauvegarde/Restauration - Full/Differentielle/Incrémentale). Notez que le FileSet doit être spécifié lors des restaurations pour des raisons historiques, mais il n'est plus utilisé.

Un seul type (Backup, Restore, ...) peut être spécifié pour un Job donné. Si vous voulez sauvegarder plusieurs FileSets sur le même client, vous devez définir un Job pour chacun d'entre eux.

Job
Début de la ressource Job. Il faut définir au moins une ressource Job.

Name = <name>
Le nom du Job. Ce nom peut être utilisé avec la commande Run du programme Console pour lancer un Job. Si le nom contient des espaces, il doit être placé entre quotes. C'est généralement une bonne idée de nommer vos Jobs du nom du Client qu'ils sauvegardent, afin de les identifier aisément.

Lors de l'exécution d'un Job, son nom unique est composé du nom que vous avez spécifié ici suffixé avec la date et l'heure de sa planification. Cette directive est requise.

Enabled = <yes|no>
Cette directive permet d'activer ou désactiver l'exécution automatique d'un job par le planificateur.

Type = <job-type>
La directive Type spécifie le type de Job, qui peut être l'un des suivants : Backup, Restore, Verify, ou Admin. Cette directive est requise. Pour chaque type de Job, il existe différents niveaux, qui seront décrits dans les prochains paragraphes.

Backup
Définit une sauvegarde. En principe, vous aurez au moins un job de type Backup par client sauvegardé. A moins que vous ne désactiviez le catalogue, la plupart des données et statistiques concernant les fichiers sauvegardées seront écrites dans le catalogue.

Restore
Définit une restauration. En principe, vous ne créerez qu'un seul job de ce type, que vous utiliserez comme un prototype que vous modifierez à l'aide de la console lorsque vous devrez restaurer. Bien que certaines informations basiques soient conservées dans le catalogue lors de restaurations, leur quantité est infime en regard des informations stockées pour une sauvegarde -- par exemple, aucune entrée de nom de fichier n'est générée, puisqu'aucun fichier n'est sauvegardé.

Verify
Définit un Job de type Verify. Le Jobs de type verify permettent de comparer le catalogue au système de fichiers ou à ce qui a été sauvegardé. Vous pouvez l'utiliser pour vous assurer qu'une cartouche de données est lisible, mais aussi comme un système de détection d'intrusion à la façon de Tripwire.

Admin
Définit un Job de type Admin. Un Admin peut s'utiliser pour "élaguer" périodiquement le catalogue, si vous ne souhaitez pas que ceci soit fait à la fin de chaque sauvegarde. Bien que les Jobs de type admin soient enregistrés dans le catalogue, la quantité de données générée est infime.

Level = <job-level>
La directive Level spécifie le niveau d'exécutiondu job par défaut. Chaque type de job a son propre jeu de niveaux qui peuvent être spécifiés. Le niveau d'exécution est en général surchargé par une valeur différente spécifiée dans la ressource Schedule. Cette directive n'est pas requise mais doit être spécifiée soit ici, soit en tant que surcharge dans la ressource Schedule.

Pour un job de type Backup le niveau doit être l'un des suivants :

Full
Tous les fichiers du FileSet, qu'ils aient été modifiés ou non.

Incremental
Tous les fichiers modifiés depuis la dernière sauvegarde valide du FileSet spécifié pour le même job. Si le Director ne peut trouver une sauvegarde Full antérieure, le niveau du job sera élevé en une sauvegarde Full. Lorsque le Director recherche une Full valide dans le catalogue, il recherche un job avec les caractéristiques suivantes :

  • le même nom de job ;
  • le même nom de client ;
  • le même FileSet (toute modification de la définition du FileSet telle que l'ajout ou la suppression de fichiers dans les sections Include ou Exclude constitue un changement de FileSet).
  • le niveau requis (Full, Differential ou Incremental)
  • le job s'est terminé normalement, c'est à dire un qu'il ne s'est pas terminé en échec, et n'a pas été effacé.

Si toutes les conditions ci-dessus ne sont pas réalisées, le Director augmentera la sauvegarde incrémentale en une sauvegarde Full. Dans le cas contraire, la sauvegarde incrémentale sera effectuée normalement.

Le File Daemon (Client) détermine les fichiers à sauvegarder pour une incrémentale par comparaison de l'heure de démarrage du Job précédent (Full, Différentiel ou Incrémental) avec les dates de dernière modification de chaque fichier (st_mtime) et de ses attributs (st_ctime). Si le fichier ou ses attributs ont changés depuis cette date de démarrage, alors le fichier sera sauvegardé.

Veuillez noter que certains logiciels anti-virus peuvent modifier la date st_time lors de leurs opérations de scan. Ainsi, si l'antivirus modifie la date d'accès (st_atime), qui n'est pas utilisée par Bacula, il provoquera une modification du st_ctime et conduira Bacula à sauvegarder les fichiers concernés lors des incrémentales et différentielles. Dans le cas de l'antivirus Sophos, vous pouvez éviter cet inconvénient en utilisant l'option --no-reset-atime. Pour les autres logiciels, voyez leurs manuels.

Lorsque Bacula effectue une sauvegarde incrémentale, tous les fichiers modifiés présents sur le système sont sauvegardés. Cependant, tout fichier supprimé depuis la dernière Full demeure dans le catalogue, ce qui signifie que si vous effectuez une restauration à partir de sauvegardes incrémentales (et de la Full associée), les fichiers supprimés depuis la dernière Full seront aussi restaurés. Ces fichiers n'apparaîtront plus dans le catalogue après avoir fait une nouvelle sauvegarde Full. Le processus pour supprimer ces fichiers du catalogue lors d'une incrémentale ralentirait fortement les sauvegardes incrémentales. Il n'est actuellement pas implémenté dans Bacula.

De plus, si vous déplacez un répertoire plutôt que de le copier, les fichiers qu'il contient voient leurs dates de dernière modification (st_mtime) et de dernier accès (st_ctime) inchangés. Par conséquent, ces fichiers ne seront probablement sauvegardés par aucune incrémentale ou différentielle, puisque ces dernières ne se réfèrent qu'à ces indicateurs. Aussi, il est préférable de copier un dossier avant de supprimer l'original plutôt que de le déplacer, si vous voulez qu'il soit correctement sauvegardé.

Differential
Tous les fichiers modifiés depuis la dernière sauvegarde Full valide du FileSet spécifié pour le même job. Si le Director ne peut trouver une sauvegarde Full antérieure, le niveau du job sera élevé en une sauvegarde Full. Lorsque le Director recherche une Full valide dans le catalogue, il recherche un job avec les caractéristiques suivantes :

  • le même nom de job ;
  • le même nom de client ;
  • le même FileSet (toute modification de la définition du FileSet telle que l'ajout ou la suppression de fichiers dans les sections Include ou Exclude constitue un changement de FileSet).
  • le Job était une sauvegarde FULL
  • le Job s'est terminé normalement, c'est à dire qu'il ne s'est pas terminé en échec, et n'a pas été effacé.

Si toutes les conditions ci-dessus ne sont pas réalisées, le Director augmentera la sauvegarde différentielle en une sauvegarde Full. Dans le cas contraire, la sauvegarde différentielle sera effectuée normalement.

Le File Daemon (Client) détermine les fichiers à sauvegarder pour une différentielle par comparaison de l'heure de démarrage de la dernière sauvegarde Full avec les dates de dernière modification de chaque fichier (st_mtime) et de ses attributs (st_ctime). Si le fichier ou ses attributs ont changés depuis cette date de démarrage, alors le fichier sera sauvegardé. La date de démarrage utilisée est affiché après le Since du rapport de Job. Dans de rares cas, certains fichiers sont sauvegardés deux fois à cause de l'utilisation de la date de démarrage de la sauvegarde précédente, mais ceci assure qu'aucun changement n'est perdu. Comme pour les incrémentales, vous devriez vous assurer que les horloges de votre serveur Bacula et de vos clients sont synchronisées, ou aussi proches que possible, pour éviter le risque d'omission d'un fichier. Notez qu'à partir de la version 1.33, Bacula effectue automatiquement ces ajustements de sorte que les horloges utilisées par Bacula soient synchrones.

Veuillez noter que certains logiciels anti-virus peuvent modifier la date st_time lors de leurs opérations de scan. Ainsi, si l'antivirus modifie la date d'accès (st_atime), qui n'est pas utilisée par Bacula, il provoquera une modification du st_ctime et conduira Bacula à sauvegarder les fichiers concernés lors des incrémentales et différentielles. Dans le cas de l'antivirus Sophos, vous pouvez éviter cet inconvénient en utilisant l'option --no-reset-atime. Pour les autres logiciels, voyez leurs manuels.

Lorsque Bacula effectue une sauvegarde différentielle, tous les fichiers modifiés présents sur le système sont sauvegardés. Cependant, tout fichier supprimé depuis la dernière Full demeure dans le catalogue, ce qui signifie que si vous effectuez une restauration à partir de sauvegardes différentielles (et de la Full associée), les fichiers supprimés depuis la dernière Full seront aussi restaurés. Ces fichiers n'apparaîtront plus dans le catalogue après avoir fait une nouvelle sauvegarde Full. Le processus pour supprimer ces fichiers du catalogue lors d'une incrémentale ralentirait fortement les sauvegardes différentielles. Il n'est actuellement pas implémenté dans Bacula, mais plannifié pour une future version de Bacula.

Comme noté ci-dessus, si vous déplacez un répertoire plutôt que de le copier, les fichiers qu'il contient voient leurs dates de dernière modification (st_mtime) et de dernier accès (st_ctime) inchangés. Par conséquent, ces fichiers ne seront probablement sauvegardés par aucune incrémentale ou différentielle, puisque ces dernières ne se réfèrent qu'à ces indicateurs. Aussi, il est préférable de copier un dossier avant de supprimer l'original plutôt que de le déplacer, si vous voulez qu'il soit correctement sauvegardé.

Régulièrement, quelqu'un demande à quoi servent les sauvegardes différentielles du moment que les incrémentales récupèrent tous les fichiers modifiés. Il existe plusieurs réponses à cette question, mais la plus importante à mes yeux est de combiner toutes les incrémentales et différentielles depuis la dernière full en une seule différentielle. Ceci a deux effets : 1. La redondance. 2. Plus important, la réduction du nombre de volumes requis pour faire une restauration en éliminant la nécessité de lire tous les volumes des précédentes incrémentales depuis la dernière full.

Pour un Job de type Restore, aucun niveau ne doit être spécifié.

Pour un Job de type Verify, le niveau peut être l'un des suivants :

InitCatalog
Examine le FileSet spécifié et stocke les attributs de fichiers dans le catalogue. Vous pouvez vous interroger sur l'intérêt d'un Job qui ne sauvegarde aucun fichier. La réponse est de pouvoir utiliser Bacula comme vous utiliseriez Tripwire, en d'autres termes, ce type de Jobs vous permet de sauvegarder l'état d'un ensemble de fichiers défini par un FileSet afin de pouvoir ultérieurement contrôler si rien n'a été modifié, supprimé ou ajouté. Ceci peut être utilisé pour détecter une intrusion. Typiquement, vous spécifiez un FileSet qui contient l'ensemble des fichiers qui ne devraient pas changer (par exemple /sbin, /boot, /lib, /bin, ...). Ensuite, vous exécutez le Job verify de niveau InitCatalog après l'installation de votre système, puis après chaque modification (mise à jour). Ensuite, lorsque vous souhaitez contrôler l'état de votre système de fichiers, vous utilisez un Job Verify, level = Catalog afin de comparer le résultat de votre InitCatalog avec l'état actuel de votre système de fichiers.

Catalog
Compare l'état actuel des fichiers et l'état précédemment sauvegardé lors d'un InitCatalog. Toutes les anomalies sont rapportées. Les objets du rapport sont déterminés par les options verify spécifiées dans la directive Include du FileSet spécifié (voyez la ressource FileSet ci-dessous pour plus de détails). Typiquement, cette commande sera exécutée quotidiennement pour contrôler toute modification de votre système de fichier.

Attention ! Si vous exécutez deux jobs Verify Catalog simultanément sur le même client, les résultats seront probablement erronnés. En effet, Verify Catalog modifie le catalogue lors de son exécution afin de détecter les nouveaux fichiers.

VolumeToCatalog
Ce niveau permet de lire les attributs de fichiers écrits sur le Volume lors du dernier Job. Les attributs de fichiers sont comparés aux valeurs sauvegardées dans le catalogue et toute différence est rapportée. Ceci est similaire au niveau Catalog, sauf que ce sont les attributs des fichiers du volume plutôt que ceux des fichiers du disque qui sont comparés aux attributs sauvegardés dans le catalogue. Bien que les attributs et signatures (MD5 ou SHA1) soient comparés, les données réelles ne le sont pas (elles ne figurent pas dans le catalogue).

Attention ! Si vous exécutez deux jobs Verify VolumeToCatalog simultanément sur le même client, les résultats seront probablement erronnés. En effet, Verify VolumeToCatalog modifie le catalogue lors de son exécution afin de détecter les nouveaux fichiers.

DiskToCatalog
Ce niveau permet de lire les fichiers tels qu'ils sont actuellement sur le disque et de comparer leurs attributs actuels avec ceux stockés dans le catalogue lors de la dernière sauvegarde pour le Job spécifié par la directive VerifyJob. Ce niveau diffère du niveau Catalog décrit plus haut en ce qu'il ne se réfère pas à un Job Verify antérieur, mais à la dernière sauvegarde. Lorsque vous utilisez ce niveau , vous devez renseigner les option Verify de la section Include. Ces options déterminent quels attributs seront comparés.

Cette commande peut se révéler très utile si vous avez des problèmes de disque car elle comparera l'état actuel de votre disque avec la dernière sauvegarde valide, qui peut remonter à plusieurs jobs.

Notez que l'implémentation actuelle (1.32c) n'identifie pas les fichiers qui ont été supprimés.

Verify Job = <Job-Resource-Name>
Si vous exécutez un job verify sans cette directive, le dernier job exécuté sera comparé avec le catalogue, ce qui signifie que votre commande verify doit succéder immédiatement à une sauvegarde. Si vous spécifiez un Verify Job, Bacula trouvera le dernier job exécuté avec ce nom. Ceci vous permet d'exécuter toutes vos sauvegardes, puis d'exécuter les jobs Verify sur les sauvegardes de votre choix (le plus souvent, un VolumeToCatalog de sorte que la cartouche qui vient juste d'être écrite est relue).

JobDefs = <JobDefs-Resource-Name>
Si un nom de JobDef est spécifié dans la définition d'un Job, toutes les valeurs définies dans la ressource JobDef concernée seront utilisées en tant que valeurs par défaut pour le Job. Toute valeur explicitement spécifiée dans la définition du Job outrepasse la valeur par défaut définie par le JobDef. L'utilisation de cette directive permet d'écrire des ressources Job plus compactes, où la majeure partie des directives sont définies dans un ou plusieurs JobDefs. C'est particulièrement pratique si vous avez de nombreux Jobs similaires avec des variations mineures telles que différents clients. Un exemple basique de l'utilisation d'un Jobdef est fourni dans le fichier bacula-dir.conf par défaut.

Bootstrap = <bootstrap-file>
La directive Bootstrap spécifie un fichier bootstrap qui, s'il est fourni, sera utilisé lors des restaurations et ignoré par tout les autres Jobs. Le fichier bootstrap contient la liste des cartouches nécessaires pour la restauration ainsi que les index des fichiers à restaurer (localisation sur la cartouche). Cette directive est optionnelle, et n'est utilisée que pour les restaurations. De plus, elle peut être modifiée lorsqu'une restauration est lancée depuis la console.

Si vous utilisez la commande Restore dans la console pour lancer une restauration, le fichier bootstrap sera créé automatiquement à partir des fichiers que vous avez sélectionnés pour la restauration.

Pour plus de détails concernant les fichiers bootstrap, veuillez consulter le chapitre Restaurer des fichiers avec le fichier Bootstrap de ce manuel.

Write Bootstrap = <bootstrap-file-specification>
La directive writebootstrap spécifie le de fichier Bootstrap où Bacula écrira lors de chaque sauvegarde. Ainsi, cette directive s'applique exclusivement aux jobs de type sauvegarde. Si la sauvegarde est une Full, Bacula écrase le contenu du fichier spécifié. Sinon, Bacula ajoute les nouveaux enregistrements Bootstrap à la fin du fichier.

En utilisant cette fonction, vous aurez constamment un fichier bootstrap capable de recouvrer l'état le plus récent de votre système. Le fichier bootstrap devrait être écrit sur un disque monté sur une autre machine, de sorte que vous puissiez en disposer immédiatement en cas de défaillance de votre disque dur. Une alternative consiste à copier le fichier sur une autre machine après chaque mise à jour.

Si la spécification de fichier bootstrap débute par une barre verticale (|), Bacula considère la spécification comme un nom de programme vers lequel les les enregistrement bootstrap seront redirigés. Ce peut être, par exemple, un script qui vous envoie par e-mail les enregistrements bootstrap.

A partir de la version 1.40, Bacula effectue des character substitution comme dans une directive RunScript. Pour gérer automatiquement vos fichiers bootstrap, vous pouvez utiliser ceci dans vos JobDefs : 

JobDefs {
   Write Bootstrap = "%c_%n.bsr"
   ...
}

Pour plus de détails sur l'utilisation de fichiers bootstrap, veuillez consulter le chapitre intitulé Le Fichier Bootstrap de ce manuel.

Client = <client-resource-name>
La directive Client spécifie le Client (File Daemon) à utiliser dans le Job. Le client est exécuté sur la machine à sauvegarder. Il expédie les fichiers requis au Storage Daemon lors des sauvegardes, et reçoit les fichiers du Storage Daemon lors des restaurations. Pour plus de détails, consultez la section Ressource Client de ce chapitre. Cette deirective est requise.

FileSet = <FileSet-resource-name>
La directive FileSet spécifie le FileSet à utiliser dans le Job concerné. Le FileSet définit les répertoires et fichiers à sauvegarder, ainsi que les options à utiliser pour les sauvegarder (par exemple la compression,...). Un Job ne peut contenir qu'un seul FileSet. Pour plus de détails, consultez la section Ressource FileSet de ce chapitre. Cette directive est requise.

Messages = <messages-resource-name>
La directive Messages définit la ressource Message qui doit être utilisée pour le job concerné. Ainsi, elle détermine le comment et où seront délivrés les différents messages de Bacula. Par exemple, vous pouvez diriger certains messages vers un fichier de logs, tandis que d'autres seront envoyés par e-mail. Pour plus de détails, consultez le chapitre Ressource Messages de ce manuel. Cette directive est requise.

Pool = <pool-resource-name>
La directive Pool spécifie le jeu de volumes qui doit être utilisé pour sauvegarder vos données. De nombreuses installations de Bacula n'utiliseront que le pool défini par défaut Default. Toutefois, si vous voulez spécifier différents jeux de volumes pou différents clients ou différents jobs, vous voudrez probablement utiliser les Pools. Pour plus de détails, consultez la section Ressource Pool de ce chapitre. Cette directive est requise

Full Backup Pool = <pool-resource-name>
La directive Full Backup Pool spécifie un Pool à utiliser pour les sauvegardes Full. Cette directive outrepasse toute autre spécification de Pool lors d'une sauvegarde Full. Cette directive est optionnelle.

Differential Backup Pool = <pool-resource-name>
La directive Differential Backup Pool spécifie un Pool à utiliser pour les sauvegardes Différentielles. Cette directive outrepasse toute autre spécification de Pool lors d'une sauvegarde Différentielle. Cette directive est optionnelle.

Incremental Backup Pool = <pool-resource-name>
La directive Incremental Backup Pool spécifie un Pool à utiliser pour les sauvegardes Incrémentales. Cette directive outrepasse toute autre spécification de Pool lors d'une sauvegarde Incrémentale. Cette directive est optionnelle.

Schedule = <schedule-name>
La directive Schedule définit la planification du job. Le schedule détermine la date et l'instant où le job doit être lancé automatiquement, et le niveau (Full, Différentiel, Incrémental...) du job en question. Cette directive est optionnelle. Si elle est omise, le job ne pourra être exécuté que manuellement via la Console. Bien que vous puissiez vous contenter d'une ressource Schedule simple pour tout job, vous pouvez aussi définir des ressources Schedule avec plusieurs directives Run, afin de lancer le job à différentes heures. Chacune de ces directives Run permet d'outrepasser les valeurs par défaut de Level, Pool, Storage et Messages ressources. Ceci autorise une grande souplesse d'utilisation d'un simple job. Pour plus de détails, consultez le chapitre. Ressource Schedule de ce manuel.

Storage = <storage-resource-name>
La directive Storage définit le nom du service storage que vous souhaitez utiliser pour sauvegarder les données du FileSet. Pour plus de détails, consultez le chapitre Ressource Storage de ce manuel. Cette directive est requise.

Max Start Delay = <time>
La directive Max Start Delay spécifie le délai maximal entre l'horaire planifié (dans le schedule) et l'horaire effectif de démarrage du job. Par exemple, un job peut être programmé pour démarrer à 1h, mais être mis en attente à cause d'autres jobs en cours d'exécution. Si le Max Start Delay a été réglé à 3600, le job sera supprimmé s'il n'a pas démarré à 2h. Ceci peut se révéler utile pour, par exemple, éviter qu'un job s'exécute duant les heures ouvrables. La valeur par défaut est 0 (pas de limite).

Max Run Time = <time>
La directive Max Run Time spécifie le délai alloué pour l'exécution complète d'un job depuis son lancement (pas nécessairement à l'heure de sa programmation) jusqu'à sa fin. Cette directive est implémentée depuis la version 1.33.

Max Wait Time = <time>
La directive Max Wait Time spécifie le délai maximum durant lequel un job peut rester bloqué en attente d'une ressource (par exemple, en attente du montage d'une cartouche ou encore en attente des Storage ou File Daemon occupés à d'autres tâches) depuis son lancement (pas nécessairement à l'heure de sa programmation) jusqu'à sa fin. Cette directive est implémentée depuis la version 1.33.

Incremental Max Wait Time = <time>
Cette directive spécifie le temps maximum durant lequel une sauvegarde incrémentale peut rester bloquée en attente d'une ressource (par exemple, en attente d'une cartouche ou des File ou Storage daemons), compté à partir du démarrage du job, (pas nécessairement l'heure à laquelle le job a été programmé). Notez que si un Max Wait Time a été spécifié, il peut aussi s'appliquer au job.

Differential Max Wait Time = <time>
Cette directive spécifie le temps maximum durant lequel une sauvegarde différentielle peut rester bloquée en attente d'une ressource (par exemple, en attente d'une cartouche ou des File ou Storage daemons), compté à partir du démarrage du job, (pas nécessairement l'heure à laquelle le job a été programmé). Notez que si un Max Wait Time a été spécifié, il peut aussi s'appliquer au job.

Prefer Mounted Volumes = <yes|no>
Si cette directive est activée (c'est le cas par défaut), le Director ordonne au Storage daemon de sélectionner de préférence soit une librairie, soit un lecteur avec un volume valide déjà monté, plutôt qu'un lecteur pas prèt. Si aucun lecteur n'est prèt, c'est le premier lecteur prèt qui sera sélectionné.

Si cette directive est désactivée, le Storage daemon privilégiera les lecteurs inutilisés. Ce mode de fonctionnement peut être très utile pour ces sites avec de nombreux lecteurs qui où il peut être préférable de maximiser le flux des sauvegardes au prix d'une utilisation d'un plus grand nombre de lecteurs et de cartouches. Afin d'optimiser l'utilisation de plusieurs lecteurs, vous voudrez probablement lancer chacun de vos jobs l'un après l'autre avec un intervalle de 5 secondes environ. Ceci aidera à assurer que chaque nuit, le même lecteur (volume) est sélectionné pour le même job. Autrement, lors d'une restauration, vous pourriez trouver vos fichiers dispersés sur beaucoup plus de volumes que nécessaire.

Prune Jobs = <yes|no>
En principe, l'élagage des jobs du catalogue est spécifié pour chaque client dans sa propre ressource Client par la directive AutoPrune. Si cette directive est spécifiée (normalement, non) et si la valeur est yes, elle outrepasse la valeur spécifiée dans la ressource Client. La valeur par défaut est no.

Prune Files = <yes|no>
En principe, l'élagage des fichiers du catalogue est spécifié pour chaque client dans sa propre ressource Client par la directive AutoPrune. Si cette directive est spécifiée (normalement, non) et si la valeur est yes, elle outrepasse la valeur spécifiée dans la ressource Client. La valeur par défaut est no.

Prune Volumes = <yes|no>
En principe, l'élagage des volumes du catalogue est spécifié pour chaque client dans sa propre ressource Client par la directive AutoPrune. Si cette directive est spécifiée (normalement, non) et si la valeur est yes, elle outrepasse la valeur spécifiée dans la ressource Client. La valeur par défaut est no.

RunScript {...}

La commande spécifiée est exécutée en tant que programme externe avant le lancement du job. Cette directive est optionnelle. Vous disposez des options suivantes :

Options Valeur Defaut Informations
Runs On Success Yes/No Yes La commande est exécutée si le job s'est terminé avec succès
Runs On Failure Yes/No No La commande est exécutée si le job a échoué
Runs On Client Yes/No Yes La commande est exécutée sur le client
Runs When Before|After|Always Never Le moment où la commande doit être exécutée
Abort Job On Error Yes/No Yes Abandonne le job si le script retourne un résultat non nul
Command     Le chemin vers votre script
Tout retour de la commande sur la sortie standard est incluse dans le rapport de job de Bacula. La chaîne bf command doit être un nom de programme valide ou un script shell

D'autre part, la chaîne bf command est parcourue puis envoyée vers la fonction execvp(), ce qui signifie que le chemin de la commande est recherché pour son exécution, mais qu'il n'y a aucune interprétation shell. Par conséquent, si vous voulez utiliser des commandes complexes ou toute fonctionnalité du shell telle que la redirection, vous devez appeler un script shell où vous mettrez vos commandes.

Avant de soumettre la commande spécifiée au système d'exploitation, Bacula effectue les substitutions suivantes : 

    %% = %
    %c = Nom du client
    %d = Nom du Director
    %e = Statut de sortie du job
    %i = JobId
    %j = Nom unique du job
    %l = Niveau du job
    %n = Nom du job
    %s = Temps Depuis (NDT : Since Time)
    %t = Type de job (Backup,...)
    %v = Nom de volume

Le code de statut de fin de job peut prendre les valeurs suivantes :

Aussi, si vous l'utilisez dans une ligne de commande, il vous faudra l'encadrer de quotes.

Vous disposez des raccourcis suivants :
Mot clef RunsOnSuccess RunsOnFailure AbortJobOnError Runs On Client RunsWhen
Run Before Job     Yes No Before
Run After Job Yes No   No After
Run After Failed Job No Yes   No After
Client Run Before Job     Yes Yes Before
Client Run After Job Yes No   Yes After
Client Run After Failed Job No Yes   Yes After

Exemple : 

RunScript {
    RunsWhen = Before
    AbortJobOnError = No
    Command = "/etc/init.d/apache stop"
}

RunScript {
    RunsWhen = After
    RunsOnFailure = yes
    Command = "/etc/init.d/apache start"
}

Considérations particulières à Windows D'autre part, pour les clients Windows à partir de la version 1.33, notez bien que vous devez fournir un chemin correct pour votre script, et que le script peut avoir l'extension .com, .exe, ou .bat. Si vous spécifiez un chemin, vous devez aussi spécifier l'extension complète. Les commandes à la façon d'Unix ne fonctionneront pas, à moins que vous n'ayez installé et correctement configuré Cygwin en plus (et séparément) de Bacula.

La commande peut être n'importe quel programme reconnu par cmd.exe ou command.com comme un fichier exécutable. Spécifier une extension de fichier exécutable est optionnel, à moins qu'il y ait une ambiguïté (par exemple ls.bat, ls.exe).

Bacula cherche la commande dans le répertoire "System %Path%" (Dans la boîte de dialogue des variables d'environnement vous avez les variables "système" et "utilisateurs". Si bacula-fd fonctionne en tant que service, seules les variables d'environnement systèmes sont accessibles.)

Les variables d'environnement système peuvent être invoquées avec la syntaxe %var% et utilisées comme portion du nom de la commande ou des arguments.

Lorsque la spécification du chemin absolu d'un exécutable ou le nom de l'exécutable contient des espaces ou des caractères spéciaux, ils doivent être quotés. Il en va de même pour les arguments. 

ClientRunBeforeJob = "\"C:/Program Files/Software
     Vendor/Executable\" /arg1 /arg2 \"foo bar\""

Les caractères spéciaux &()[]{}^=;!'+,`û devront être quotés s'ils font partie d'un nom de fichier ou d'un argument.

If someone is logged in a blank ``command'' window running the commands will be present during the execution of the command.

Quelques suggestions de Phil Stracchino pour l'exécution sur les machines Win32 avec le File Daemon Win32 natif :

  1. Vous pourriez utiliser la directive ClientRunBeforeJob pour spécifier un fichier .bat qui exécute les commandes coté client plutôt que d'essayer d'exécuter (par exemple) regedit /e directement.
  2. Le fichier batch devrait retourner explicitement 0 lors des exécutions correctes.
  3. Le chemin vers le fichier batch devrait être spécifié au format Unix :

    ClientRunBeforeJob = ``c:/bacula/bin/systemstate.bat''

    plutôt qu'au format DOS/Windows :

    ClientRunBeforeJob = ``c:\bacula\bin\systemstate.bat'' INCORRECT

L'exemple suivant d'utilisation de la directive Client Run Before Job a été soumis par un utilisateur :
Vous pourriez écrire un script shell pour sauvegarder une base DB2 dans un FIFO. Voici le script en question : 

 #!/bin/sh
 # ===== backupdb.sh
 DIR=/u01/mercuryd

 mkfifo $DIR/dbpipe
 db2 BACKUP DATABASE mercuryd TO $DIR/dbpipe WITHOUT PROMPTING &
 sleep 1

La ligne suivante dans la ressource Job du fichier bacula-dir.conf : 

 Client Run Before Job = "su - mercuryd -c \"/u01/mercuryd/backupdb.sh '%t'
'%l'\""

Lorsque le job est exécuté, vous obtiendrez un message de sortie du script annonçant que la sauvegarde a démarré. Même si la commande est exécutée en arrière plan avec &, le job bloquera jusqu'à la commande "db2 BACKUP DATABASE", et la sauvegarde se fige.

Pour remédier à cette situation, la ligne "db2 BACKUP DATABASE" devrait être modifiée en : 

 db2 BACKUP DATABASE mercuryd TO $DIR/dbpipe WITHOUT PROMPTING > $DIR/backup.log
2>&1 < /dev/null &

Il est important de rediriger l'entrée et la sortie d'une commande en arrière plan vers /dev/null pour éviter le bloquage du script.

Run Before Job = <command>
La commande spécifiée est exécutée en tant que programme externe avant le lancement du job. Cette directive n'est pas requise,mais si elle est définie, et si le code retour d'exécution du programme est différent de zéro, le job qui a lancé le programme est effacé. 

Run Before Job = "echo test"
est équivalent á : 
RunScript {
 Command = "echo test"
 RunsOnClient = No
 RunsWhen = Before
}

Lutz Kittler a fait remarquer que ceci peut être un moyen aisé pour modifier vos schedules pour les vacances. Par exemple, supposons que vous fassiez habituellement des sauvegardes Full le vendredi, mais que jeudi et vendredi soient fériés. Pour éviter d'avoir à changer les cartouches entre jeudi et vendredi alors que personne n'est au bureau, vous pouvez créer un RunBeforeJob qui retourne un statut non nul jeudi et zéro les autres jours. Ainsi, le job de jeudi ne sera pas exécuté, et la cartouche que vous avez inséré mercredi sera disponible pour la Full de vendredi.

Run After Job = <command>
La commande spécifiée est exécutée en tant que programme externe après la fin du job. La chaîne bf command doit être un nom de programme valide ou un script shell. Cette directive n'est pas requise. Si le code de sortie du programme est non nul, Bacula affiche un message d'avertissement (warning). Avant de soumettre la commande spécifiée au système d'exploitation, Bacula effectue les substitutions de caractères décrites au paragraphe RunScript

Un exemple d'utilisation de cette directive est donné au chapitre Astuces de ce manuel. Lisez le paragraphe Run After Failed Job si vous voulez exécuter une commande lorqu'un job se termine avec un statut anormal.

Run After Failed Job = <command>
La commande spécifiée est exécutée en tant que programme externe après la fin du job lorqu'il se termine avec un statut d'erreur. Cette directive est optionnelle. La chaîne command doit être le nom d'un programme ou d'un script shell. Si le code de sortie du programme est non nul, Bacula affiche un mesage d'avertissement (warning). Avant de soumettre la commande spécifiée au système d'exploitation, Bacula effectue les substitutions de caractères décrites au paragraphe RunScript. Notez que vous pouvez, si vous souhaitez que votre programme soit exécuté quel que soit l'issue du job, utiliser une définition telle que :

RunScript Command = "echo test" RunsWhen = After RunsOnFailure = yes RunsOnClient = no RunsOnSuccess = yes # default, you can drop this line

Le chapitre Trucs et astuces de ce manuel propose un exemple d'utilisation de cette directive.

Client Run Before Job = <command>
Cette directive est similaire à Run Before Job excepté que la commande est exécutée sur la machine cliente. Les mêmes restrictions s'appliquent aux sytèmes Unix que celles signalées pour Run Before Job.

Client Run After Job = <command>
Cette directive est similaire à Run After Job sauf qu'elle est exécutée sur la machine cliente. Veuillez consulter les notes concernant les clients Windows dans le paragraphe RunScript ci-dessus.

Rerun Failed Levels = <yes|no>
Si la valeur de cette directive est yes (no par défaut), et si Bacula détecte qu'un job antérieur d'un niveau plus élevé (Full ou différentiel), alors le job est élevé au niveau le plus haut. Ceci est particulièrement utile pour sauvegarder les pc portables qui peuvent être fréquemment inaccessibles. En effet, après l'échec d'une Full, vous souhaiterez probablement que la prochaine sauvegarde soit de niveau Full plutôt qu'Incremental ou Différentiel.

Spool Data = <yes|no>
Si la valeur de cette directive est yes (no par défaut), le Storage Daemon aura pour consigne de stocker les données dans un fichier spoule sur disque plutôt que de les écrire directement sur bande. Lorsque toutes les données sont dans le spoule ou lorsque la taille maximale fixée pour le fichier spoule est atteinte, les données sont déchargées du spoule vers les bandes. Lorsque la valeur de cette directive est yes, la directive Spool Attributes est aussi automatiquement mise à la valeur yes. L'utilisation de cette fonctionnalité prévient les arrêts et redémarrage incessants lors des incrémentales. Elle ne doit pas être utilisée si vous sauvegardez sur disque.

Spool Attributes = <yes|no>
La valeur par défaut est no, ce qui signifie que le Storage Daemon envoie les attributs de fichiers au Director au moment où ils (les fichiers) sont ecrits sur la bande. Cependant, si vous souhaitez éviter le risque de ralentissement dû aux mises à jour du catalogue, vous pouvez régler cette directive à yes, dans ce cas, le Storage Daemon stockera les attributs de fichiers dans un fichier tampon du Working Directory pour ne les transmettre au Director qu'à la fin de l'écriture sur bande des données du job.

Where = <directory>
Cette directive ne concerne que les jobs de type Restauration. Elle permet de spécifier un préfixe au nom du répertoire où tous les fichiers sont restaurés. Ceci permet de restaurer les fichiers en un emplacement différent de celui où ils ont été sauvegardés. Si Where n'est pas renseigné, ou si sa valeur est backslash (/), les fichiers sont restaurés à leur emplacement d'origine. Par défaut, nous avons donné à Where la valeur /tmp/bacula-restores dans les fichiers de configuration fournis en exemple, ceci afin d'éviter l'écrasement accidentel de vos fichiers.

Replace = <replace-option>
Cette directive ne concerne que les jobs de type Restauration. Elle précise la conduite à adopter dans l'éventualité où Bacula serait conduit à restaurer un fichier ou un répertoire qui existe déjà. Les options suivantes sont disponibles :

always
Lorsque le fichier à restaurer existe déjà, il est supprimé et remplacé par la copie sauvegardée.

ifnewer
Si le fichier sauvegardé (sur bande) est plus récent que le fichier existant, le fichier existant est supprimé et remplacé par la copie sauvegardée.

ifolder
Si le fichier sauvegardé (sur bande) est plus ancien que le fichier existant, le fichier existant est supprimé et remplacé par la copie sauvegardée.

never
Si le fichier sauvegardé existe déjà, Bacula renonce à restaurer ce fichier.

Prefix Links=<yes|no>
Si la valeur de cette directive est Yes et si un préfixe de chemin Where est spécifié, alors ce dernier s'applique aussi aux liens absolus. La valeur par défaut est No. Lorsque cette directive est à Yes, tous les liens absolus seront aussi modifiés pour pointer vers le nouveau répertoire. En principe, c'est ce qui est souhaité : l'ensemble du répertoire restauré conserve sa cohérence interne. Cependant, si vous voulez replacer les fichiers ultérieurement à leurs emplacements d'origine, tous les liens absolus seront brisés.

Maximum Concurrent Jobs = <number>
Où <number> est le nombre maximum de jobs de la ressource Job courrante qui peuvent être exécutés simultanément. Notez que cette directive ne limite que les jobs avec le même nom que la ressource dans laquelle elle figure. Toute autre restriction du nombre maximum de jobs simultanés, que ce soit au niveau du Director, du Client ou de la ressource Storage, s'applique en plus de de la limite stipulée ici. La valeur par défaut est 1, mais vous pouvez utiliser une valeur plus grande. Nous vous recommandons fortement de lire attentivement le paragraphe WARNING sous Maximum Concurrent Jobs dans la section concernant la ressource Director.

Reschedule On Error = <yes|no>
Si cette directive est activée, alors si le job se termine en erreur, il sera reprogrammé en accord avec les directives Reschedule Interval et Reschedule Times. Si vous supprimez le job, il ne sera pas reprogrammé. La valeur par défaut est no.

Cette spécification peut se révéler utile pour les pc portables ainsi que pour toutes les machines qui ne sont pas connectées au réseau en permanence.

Reschedule Interval = <time-specification>
Si cette directive est activée, alors si le job se termine en erreur, il sera reprogrammé après l'intervalle de temps stipulé par time-specification. Consultez la section the time specification formats du chapitre Configurer Bacula pour plus de détails sur les spécifications de temps. Si aucun intervalle n'est spécifié, le job ne sera pas reprogrammé en cas d'erreur.

Reschedule Times = <count>
Cette directive précise le nombre maximal de tentatives d'exécution du job. S'il est fixé à zéro (valeur par défaut), le job sera reprogrammé indéfiniment.

Run = <job-name>
La directive Run (à ne pas confondre avec l'option Run dans un Schedule) vous permet de démarrer ou de cloner des jobs. En utilisant les mots-clef de clonage (voir ci dessous), vous pouvez sauvegarder les mêmes données (ou presque les mêmes) vers deux (ou plus) lecteurs en même temps. Le nom de job job-name est en principe le même que celui de la ressource job courante (créant ainsi un clone). Cependant, ce peut être n'importe quel nom de job, de sorte qu'un job peut démarrer d'autre jobs liés. La partie après le signe égale doit être encadrée de double quotes, et peut contenir toute chaîne ou jeu d'options (surcharges) qui pourraient être spécifiées à l'utilisation de la commande Run dans la Console. Par exemple, storage=DDS-4 .... De plus, deux mots-clef spéciaux vous permettent de cloner le job courant : level=%l et since=%s. le %l du mot clef level permet d'entrer le niveau réel du job courant et le %s du mot clef since permet d'imposer la même date pour la comparaison que celle utilisée par le job courant.a Notez que dans le cas du mot-clef since, le %s doit être encadré de double quotes, qui doivent être elles mêmes précédées de barres obliques arrières puisque elles sont déjà entre double quotes. Par exemple : 

       run = "Nightly-backup level=%s since=\"%s\" storage=DDS-4"
Un job cloné ne démarrera pas de nouveaux clones, aussi il n'est pas possible de les cascader.

Priority = <number>
Cette directive vous permet de contrôler l'ordre d'exécution des jobs en spécifiant un entier positif non nul. Plus grand est ce nombre, plus basse est la priorité du job. En supposant que vous n'exécutiez pas de jobs simultanés, tous les jobs en file d'attente avec la priorité 1 seront exécutés avant ceux avec la priorité 2, et ainsi de suite, sans prise en compte de l'ordre original de planification.

La priorité affecte seulement les jobs en file d'attente, et non les jobs déja en cours d'exécution. Si un ou plusieurs jobs de priorité 2 sont déjà en cours d'exécution, et si un nouveau job est programmé avec la priorité 1, les jobs en cours d'exécution doivent se terminer pour que le job de priorité 1 puisse démarrer.

La priorité par défaut est 10.

Si vous voulez exécutez plusieurs jobs simultanés, vous devriez garder les points suivants à l'esprit :

Si vous avez plusieurs jobs de priorités différentes, il est préférable de ne pas les démarrer exactement à la même heure, car Bacula doit les examiner un à la fois. Si, par hazard, Bacula commence par traiter un job de priorité inférieure, il sera exécuté avant votre job de priorité élevé. Pour éviter cette situation, démarrez l'un quelconque des jobs de priorité élevée quelques secondes avant ceux de basse priorité. Ainsi, vous serez assuré que Bacula examine les jobs dans l'ordre voulu et que votre schéma de priorités sera respecté.

Write Part After Job = <yes|no>
Cette directive est implémentée depuis la version 1.37. Si la valeur de cette directive est yes (no par défaut), un nouveau "fichier partition" (ndt : part file) sera créé après la fin du job.

Cette directive devrait être activée lors de l'écriture sur des périphérique qui requièrent un montage (par exemple, les DVDs), afin de vous assurer que le fichier partition courant, celui qui contient les données de ce job, est envoyé vers le périphérique, et qu'aucune donnée n'est laissée dans le fichier temporaire sur le disque dur. Quoi qu'il en soit, avec certains supports tels que les DVD+R et DVD-R, beaucoup d'espace (environ 10 Mb) est perdu à chaque fois qu'un fichier partition est écrit. Aussi, si vous exécutez plusieurs jobs à la suite, vous devriez régler cette directive à no pour tous ces jobs sauf le dernier, pour éviter un gaspillage important d'espace, tout en ayant la certitude que les données sont bien écrites sur le médium lorsque tous les jobs sont achevés.

Cette directive est ignorée avec les bandes et les périphériques FIFO.

Voici un exemple de définition de ressource Job valide. 

Job {
  Name = "Minou"
  Type = Backup
  Level = Incremental                 # default
  Client = Minou
  FileSet="Minou Full Set"
  Storage = DLTDrive
  Pool = Default
  Schedule = "MinouWeeklyCycle"
  Messages = Standard
}


La ressource JobDefs

La ressource Jobdefs admet toutes les directives qui peuvent apparaître dans une ressource Job. Une ressource Jobdefs ne créé en aucun cas un Job, son rôle est de pouvoir être désignée dans une ressource Job comme un ensemble de paramètres par défaut. Ceci permet de définir plusieurs jobs similaires avec concision, en ne mentionnant, pour chaque job, que les différences avec les valeurs par défaut spécifiées dans la ressource Jobdefs.


La ressource Schedule

La ressource Schedule offre un moyen pour planifier automatiquement un Job, mais aussi la possibilité de surcharger les paramètres par défaut de Level, Pool, Storage, et Messages ressources. Si une ressource Schedule n'est pas spécifiée dans un job, ce job ne peut être exécuté que manuellement. En général, vous spécifierez une action et le moment de son lancement.

Schedule
Début des directives Schedule. La ressource Schedule n'est pas requise, mais il vous en faudra au moins une si vous souhaitez que vos jobs soient exécutés automatiquement.

Name = <name>
Le nom du Schedule défini. Cette directive est requise.

Run = <Job-overrides> <Date-time-specification>
La directive Run définit quand un job doit être exécuté, et les éventuelles surcharges à appliquer. Il est possible de spécifier plusieurs directives run au sein d'une ressource Schedule, elles seront toutes appliquées. Si vous avez deux directives Run qui démarrent au même moment, deux jobs seront lancés simultanément (en fait, avec une seconde d'écart).

La directive Job-overrides permet d'outrepasser les spécifications de Level, Storage, Messages et Pool écrites dans la ressource Job. De plus, les spécifications FullPool, DifferentialPool et IncrementalPool permettent de passer outre les spécification de Pool, en accord avec le niveau (level) effectif d'exécution du job.

L'utilisation de surcharges permet de peaufiner le paramétrage d'un job particulier. Par exemple, vous pourriez surcharger une spécification Messages qui enverrait vos logs de backups vers un fichier, de façon à ce qu'ils vous soient envoyés par mails pour les Fulls hebdomadaires ou mensuelles.

Les directives Job-overrides sont spécifiées en tant que mot-clef=valeur où le mot-clef est l'un des suivants : Level, Storage, Messages, Pool, FullPool, DifferentialPool ou IncrementalPool, et la valeur est définie selon le format adapté à la directive. Vous pouvez spécifier plusieurs surcharges Job-overrides en une seule directive Run en les séparant par des espaces ou des trailing comas (traduction ?). Par exemple :

Level=Full
Tous les fichiers du FileSet qu'ils aient ou non changé.

Level=Incremental
Tous les fichiers qui ont changé depuis la dernière sauvegarde.

Pool=Weekly
Spécifie l'utilisation du Pool nommé Weekly.

Storage=DLT_Drive
Spécifie l'utilisation du lecteur DLT_Drive pour périphérique de stockage.

Messages=Verbose
Spécifie l'utilisation de la ressource messages Verbose pour le job.

FullPool=Full

Spécifie l'utilisation du Pool nommé Full si le job est une sauvegarde Full, ou s'il a été élevé en Full bien qu'ayant été lancé en tant que différentiel ou incrémental.

DifferentialPool=Differential
Spécifie l'utilisation du Pool nommé Differential si le job est une sauvegarde différentielle.

IncrementalPool=Incremental
Spécifie l'utilisation du Pool nommé Incremental si le job est une sauvegarde incrémentale.

SpoolData=yes|no
Indique à Bacula d'ordonner au Storage Daemon de placer les données sur un spool disque avant de les envoyer vers les cartouches.

WritePartAfterJob=yes|no
Indique à Bacula d'ordonner au Storage Daemon d'écrire le fichier partition courant vers le périphérique lorsque le job s'achève (voir la directive Write Part After Job dans la ressource Job).

Date-time-specification Détermine la planification d'exécution du job. La spécification est une répétition, et, par défaut, Bacula est paramétré pour exécuter un job au début de chaque heure de chaque jour de chaque semaine de chaque mois de chaque année. Ce n'est probablement pas ce que vous souhaitez, aussi vous devez préciser ou limiter les moments où vous souhaitez voir vos jobs exécutés. Toute spécification est supposée cyclique et servira à limiter le cycle par défaut. Ceci se fait en spécifiant des masques ou des horaires, jours de la semaine, jours du mois, semaines du mois, semaines de l'année et mois de l'année où vous voulez exécuter le job. En combinant ces possibilités, vous pouvez définir une planification qui se répète à presque n'importe quelle fréquence.

Concrètement, vous devez définir les mois, jour, heure et minute où le job est à exécuter. Parmis ces quatre objets, le jour est particulier en ce qu'il peut spécifier un jour du mois (1,2,...31) ou de la semaine (Monday, Tuesday,...Sunday). Enfin, vous pouvez aussi spécifier un jour de la semaine pour restreindre la planification à la première, deuxième, troisième, quatrième ou cinquième semaine du mois.

Par exemple, si vous spécifiez seulement un jour de la semaine, disons Mardi, le job sera exécuté toutes les heures de chaque mardi de chaque mois. La raison en est que les paramètres Mois et Heure sont restés à leurs valeurs par défaut : chaque mois et chaque heure.

Notez que, par défaut, sans autre spécification, votre job s'exécutera au début de chaque heure. Si vous souhaitez que votre job s'exécute plus souvent qu'une fois par heure, il vous faudra définir plusieurs spécifications run avec pour chacune une minut différente.

Les dates et horaires d'exécutions des jobs peuvent être spécifiés comme suit, en pseudo-BNF : 

<void-keyword>    = on
<at-keyword>      = at
<week-keyword>    = 1st | 2nd | 3rd | 4th | 5th | first |
                    second | third | forth | fifth
<wday-keyword>    = sun | mon | tue | wed | thu | fri | sat |
                    sunday | monday | tuesday | wednesday |
                    thursday | friday | saturday
<week-of-year-keyword> = w00 | w01 | ... w52 | w53
<month-keyword>   = jan | feb | mar | apr | may | jun | jul |
                    aug | sep | oct | nov | dec | january |
                    february | ... | december
<daily-keyword>   = daily
<weekly-keyword>  = weekly
<monthly-keyword> = monthly
<hourly-keyword>  = hourly
<digit>           = 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 0
<number>          = <digit> | <digit><number>
<12hour>          = 0 | 1 | 2 | ... 12
<hour>            = 0 | 1 | 2 | ... 23
<minute>          = 0 | 1 | 2 | ... 59
<day>             = 1 | 2 | ... 31
<time>            = <hour>:<minute> |
                    <12hour>:<minute>am |
                    <12hour>:<minute>pm
<time-spec>       = <at-keyword> <time> |
                    <hourly-keyword>
<date-keyword>    = <void-keyword>  <weekly-keyword>
<day-range>       = <day>-<day>
<month-range>     = <month-keyword>-<month-keyword>
<wday-range>      = <wday-keyword>-<wday-keyword>
<range>           = <day-range> | <month-range> |
                          <wday-range>
<date>            = <date-keyword> | <day> | <range>
<date-spec>       = <date> | <date-spec>
<day-spec>        = <day> | <wday-keyword> |
                    <day-range> | <wday-range> |
                    <week-keyword> <wday-keyword>
                    <day-range> | <wday-range> |
                    <daily-keyword>
<month-spec>      = <month-keyword> | <month-range> |
                    <monthly-keyword>
<date-time-spec>  = <month-spec> <day-spec> <time-spec>

Notez que les spécifications de semaine et d'année suivent les définitions ISO standard de semaine et année, où la semaine 1 est la semaine qui contient le premier jeudi de l'année, ou alternativement, la semaine qui contient le quatrième jour de janvier. Les semaines sont numérotées w01 à w53. w00 est pour Bacula la semaine qui précède la première semaine ISO (c'est à dire celle qui contient les quelques premiers jours de l'année si aucun n'est un jeudi). w00 n'est pas définie dans les spécifications ISO. Une semaine commence le Lundi et se termine le Dimanche.

Voici un exemple de ressource Schedule nommée WeeklyCycle qui exécute un job de niveau Full chaque Dimanche à 1h05 et un job de niveau incrémental du Lundi au Samedi à 1h05 : 

Schedule {
  Name = "WeeklyCycle"
  Run = Level=Full sun at 1:05
  Run = Level=Incremental mon-sat at 1:05
}

Voici un exemple de cycle mensuel : 

Schedule {
  Name = "MonthlyCycle"
  Run = Level=Full Pool=Monthly 1st sun at 1:05
  Run = Level=Differential 2nd-5th sun at 1:05
  Run = Level=Incremental Pool=Daily mon-sat at 1:05
}

Le premier de chaque mois : 

Schedule {
  Name = "First"
  Run = Level=Full on 1 at 1:05
  Run = Level=Incremental on 2-31 at 1:05
}

Toutes les dix minutes : 

Schedule {
  Name = "TenMinutes"
  Run = Level=Full hourly at 0:05
  Run = Level=Full hourly at 0:15
  Run = Level=Full hourly at 0:25
  Run = Level=Full hourly at 0:35
  Run = Level=Full hourly at 0:45
  Run = Level=Full hourly at 0:55
}

Notes techniques sur les Schedules

Au niveau interne, Bacula considère un schedule en tant que bit masque. Il y a six masques et un champ minute pour chaque schedule. Les masques sont heure, jour du mois (mday), jour de la semaine (wday), semaine du mois (wom), et semaine de l'année (woy). Le schedule est initialisé de façon à avoir les bits de chacun de ces masques positionnés, ce qui signifie qu'au début de chaque heure, le job sera exécuté. Quand vous spécifiez un mois pour la première fois, le masque est effacé et le bit correspondant au mois sélectionné est ajouté au masque. Si vous spécifiez un second mois, le bit correspondant est aussi ajouté. Ainsi, lorsque Bacula examine le masque pour voir si les bits placés correspondent à la date courante, votre job ne sera exécuté que pendant les deux mois que vous avez spécifiés. De même, si vous spécifiez un horaire, le masque Heure est effacé et le bit correspondant à l'heure que vous avez spécifiée est placé, les minutes sont quant à elles stockées dans le champ Minutes.

Pour chacun de vos schedules, vous pouvez visualiser le masque associé grâce à la commande show schedules du programme Console. Notez que le bit masque est "zero based", et que Dimanche est le premier jour de la semaine (bit 0)


La ressource FileSet

La ressource FileSet définit les fichiers à inclure dans une sauvegarde. Pour chaque job de type sauvegarde, il est nécessaire de définir au moins une ressource FileSet. Un FileSet consiste en une liste de fichiers ou répertoires à inclure, une liste de fichiers ou répertoires à exclure, et diverses options de sauvegardes telles que compression, chiffrement et signatures qui doivent être appliquées à chaque fichier.

Toute modification de la liste des fichiers inclus provoque la création par Bacula d'un nouveau FileSet (défini par le nom et la somme de contrôle MD5 du contenu du paragraphe Include). Chaque fois qu'un nouveau FileSet est créé, Bacula s'assure que la première sauvegarde est une Full.

FileSet
Début de la ressource FileSet. Au moins une ressource FileSet doit être définie.

Name = <name>
Le nom de la ressource FileSet. Cette directive est requise.

Ignore FileSet Changes = <yes|no>
Si cette directive est activée (yes), toute modification des listes d'inclusion ou d'exclusion du FileSet sera ignorée et Bacula n'élèvera pas la prochaine sauvegarde en Full. La valeur par défaut est no, ainsi, si vous modifiez une des listes d'inclusion ou d'exclusion du FileSet, Bacula forcera une sauvegarde Full pour assurer que tout soit bien sauvegardé proprement. Il n'est pas recommandé d'activer cette directive. Cette directive est disponible à partir de Bacula 1.35.4.

Include { [ Options {<file-options>} ...] <file-list> }

Options { <file-options> }

Exclude { <file-list> }
La ressource Include doit contenir une liste de répertoires et/ou fichiers à traiter lors de la sauvegarde. Normalement, tous les fichiers trouvés dans tous les sous-répertoires de tout répertoire de la liste d'inclusion des fichiers seront sauvegardés. La ressource Include peut aussi comporter une ou plusieurs ressources Options qui spécifient des paramètres tels que la compression à appliquer à tous les fichiers ou à n'importe quel sous ensemble de fichiers à sauvegarder.

Le nombre de ressources Include par FileSet n'est pas limité, chacune ayant sa propre liste de répertoires et/ou fichiers à sauvegarder et ses propres paramètres définis par une ou plusieurs ressources Options. La liste de fichiers file-list consiste en un nom de fichier ou répertoire par ligne. Les noms de répertoire doivent être spécifiés sans slash final.

Vous devez toujours spécifier des chemins absolus pour tout fichier ou répertoire que vous placez dans un FileSet. De plus, sur les machines Windows, vous devez toujours préfixer le répertoire ou nom de fichier d'une spécification de disque (par exemple : c:/xxx) en utilisant le séparateur de répertoire Unix (slash /).

Le comportement par défaut de Bacula en ce qui concerne le traitement des répertoires est de descendre récursivement dans chaque répertoire et de sauvegarder tous les fichiers et sous-répertoires. Par défaut, Bacula ne suit pas les systèmes de fichiers transverses (en terminologie Unix, les points de montage). Ceci signifie que si vous spécifiez la partition racine ( par exemple /), Bacula sauvegardera seulement la partition racine, et aucun des systèmes de fichiers montés. De façon analogue, sur les systèmes Windows, vous devez expliciter chacun des disques que vous souhaitez sauvegarder (par exemple c:/ et d:/...). De plus, au moins pour les systèmes Windows, il sera la plupart du temps nécessaire d'encadrer chaque spécification de doubles quotes, particulièrement si le nom du répertoire (ou du fichier) comporte des espaces. La commande df des systèmes Unix vous fournira la liste des répertoires qu'il vous faudra spécifier pour tout sauvegarder. Voyez ci-dessous pour un exemple.

Soyez attentif à ne pas inclure un répertoire deux fois, car il serait sauvegardé deux fois, ce qui gaspillerait l'espace sur votre périphérique de sauvegarde. Cette erreur est facile à commettre. Par exemple : 

  Include {
    File = /
    File = /usr
    Options { compression=GZIP }
  }

Sur un système Unix où /usr est un sous répertoire (plutôt qu'un système de fichiers monté), cette ressource Include sauvegarderait /usr deux fois. Dans ce cas, sur les versions antérieures à 1.32f-5-09Mar04, en raison d'un bug, vous ne pourriez restaurer les fichiers liés physiquement sauvegardés deux fois.

Si vous avez utilisé des versions de Bacula antérieures à 1.34.3, vous noterez ces modifications dans la syntaxe des FileSets :

  1. il n'y a pas de signe égale (=) après le "include" et avant l'accolade ouvrante ({) ;
  2. chaque répertoire (ou nom de fichier) à sauvegarder est précédé de "File =" ;
  3. les options qui apparaissaient précédemmant sur la ligne Include doivent désormais être spécifiées dans leur propre ressource Options.

La ressource Options est optionnelle, mais lorsqu'elle est spécifiée, elle doit contenir une liste de lignes "mot-clef=valeur" relatives aux options à appliquer à la liste de fichiers/répertoires. Plusieurs ressources Options peuvent être spécifiées l'une après l'autre. Lorsqu'un fichier se trouve dans un dossier spécifié, les options sont appliquées au nom de fichier pour savoir s'il doit être sauvegardé, et comment. Les ressources Options sont appliquées dans l'ordre où elles apparaîssent dans le FileSet jusqu'à ce qu'il y en ait une qui corresponde. Une ressource Options qui ne contient pas de directive wild (spécification de caractère joker, voir ci-dessous) est considérée comme concernant tous les fichiers. Il est important de bien comprendre ceci, car une fois que Bacula a déterminé que des Options s'appliquent à un fichier donné, ce fichier sera sauvegardé sans tenir compte d'aucunes des éventuelles autres ressources Options. Ceci signifie que toute ressource Options avec caractères joker doit apparaître avant une ressource Options sans caractères joker.

Si, pour quelque raison, Bacula applique toutes les ressources Options à un fichier sans qu'aucune ne corresponde (en général à cause de caractères joker qui ne correspondent pas), par défaut Bacula sauvegardera le fichier. Ceci est assez logique si vous considérez la situation sans options, où vous souhaitez que tout soit sauvegardé. De plus, dans le cas ou aucune correspondance n'est trouvée, Bacula utilise les options de la dernière ressource Options. Par conséquent, si vous souhaitez définir un jeu d'options par défaut, vous devriez les placer dans la dernière ressource Options.

Les directives disponibles pour les ressources Options sont les suivantes :

compression=GZIP
Tous les fichiers sauvegardés sont compressés (NDT : compression logicielle, par opposition à la compression matérielle effectuée par le lecteur) au format GNU ZIP. Chaque fichier est compressé individuellement par le File Daemon. S'il y a un problème à la lecture d'une cartouche au niveau de l'enregistrement d'un fichier, il affectera tout au plus ce fichier et aucun des autres fichiers de la cartouche. La plupart du temps, cette option n'est pas nécessaire si vous avez un lecteur de bandes moderne qui applique sa propre compression. En fait, si vous activez les deux compressions simultanément, il se peut que vos fichiers occupent plus d'espace sur le volume qu'avec une seule.

La compression logicielle est particulièrement intéressante lorsque vous sauvegardez sur disque, et peut être d'un grand secours si vous avez un ordinateur rapide mais un réseau lent.

La spécification GZIP utilise le niveau de compression six par défaut (i.e. GZIP est équivalent à GZIP6). Si vous voulez utiliser un niveau différent (de 1 à 9), vous pouvez le spécifier en ajoutant le numéro du niveau voulu à la fin du mot GZIP, sans espace. Ainsi, compression=GZIP1 désigne la compression la moins efficace, mais l'algorithme le plus rapide, tandis que compression=GZIP9 est le niveau de compression le plus élevé, mais requière plus de puissance de calcul. Selon la documentation GZIP, les niveaux de compression supérieurs à 6 ne procurent généralement que peu de compression supplémentaire alors qu'ils sont plutôt exigeants en puissance de calcul.

signature=SHA1
La signature SHA1 est calculée pour tous les fichiers sauvegardés. L'algorithme SHA1 est réputé plus lent que MD5, mais bien meilleur d'un point de vue cryptographique (i.e. beaucoup moins de collisions et probabilité de piratage bien inférieure.). Nous recommandons fortement d'activer l'une ou l'autre des options SHA1 ou MD5 par défaut pour tous les fichiers. Notez que seule l'une de ces deux options peut être activée pour tout fichier.

signature=MD5
La signature MD5 est calculée pour tous les fichiers sauvegardés. Activer cette option résulte en une charge CPU supplémentaire de l'ordre de 5% pour chaque fichier sauvegardé. D'autre part, la signature MD5 ajoute 16 octets supplémentaires au catalogue pour chaque fichier sauvegardé. Nous recommandons fortement d'activer l'une ou l'autre des options SHA1 ou MD5 par défaut pour tous les fichiers.

verify=<options>
Les "options-lettres" sont utilisées lors de l'exécution de jobs de type Verify de niveau Level=Catalog et de niveau Level=DiskToCatalog. Les options peuvent être n'importe quelle combinaison de ces lettres.

i
compare les inodes

p
compare bits de permissions

n
compare le nombre de liens

u
compare les user ids

g
compare les group ids

s
compare les tailles

a
compare les date d'accès (access time)

m
compare les dates de modification (st_mtime)

c
compare les dates de changement (st_ctime)

s
signale tout fichier dont la taille a diminué

5
compare les signatures MD5

1
compare les signatures SHA1

Le jeu d'options pins5 (qui compare les bits de permissions, les inodes, les nombres de liens, la taille des fichiers et les signatures MD5) est très utile pour des jobs de type verify de niveaux Level=Catalog ou Level=DiskToCatalog.

onefs=yes|no
Si cette option est activée (valeur yes, par défaut), Bacula ne changera pas de système de fichiers. Autrement dit, il ne sauvegardera pas les systèmes de fichiers montés sur des sous-répertoires. Si vous souhaitez sauvegarder plusieurs systèmes de fichiers, vous pouvez les énumérer explicitement. Une autre possibilité consiste à désactiver l'option onefs (onefs=no) afin que Bacula sauvegarde les systèmes de fichiers montés trouvés dans les répertoires listés dans votre FileSet. Ainsi, si vous avez des systèmes de fichiers NFS ou Samba montés sur un répertoire listé dans le FileSet, ils seront aussi sauvegardés. En principe, il est préférable d'activer cette option et de nommer explicitement chaque système de fichier que vous voulez sauvegarder. Ce nommage explicite évite le risque de tomber dans une boucle infinie de systèmes de fichiers. Voyez l'exemple ci-dessous pour plus de détails.

portable=yes|no
Si cette option est activée (la valeur par défaut est no), le File Daemon sauvegarde les fichiers win32 dans un format portable, mais tous les attributs de fichiers win32 ne seront pas sauvegardés ni restaurables. La valeur par défaut est no, ce qui signifie que sur les systèmes Win32, les données sont sauvegardées en utilisant les appels Windows API et sur les WinNT/2k/XP, tous les attributs de sécurité et de propriété sont correctement sauvegardés et restaurés. Cependant, ce format n'est pas portable aux autres systèmes -- par exemple UNIX, Win95/98/Me. Lors de la sauvegarde de systèmes Unix, cette option est ignorée, et à moins que vous n'ayez un besoin spécifique de portabilité de vos sauvegardes, nous recommandons d'accepter la valeur par défaut (no) de sorte qu'un maximum d'informations concernant vos fichiers soit sauvegardé.

recurse=yes|no
Si cette option est activée (la valeur par défaut est yes), Bacula descend récursivement dans tout sous-répertoire trouvé, à moins qu'il ne soit explicitement exclu par une définition exclude. Si vous désactivez cette option (recurse=no), Bacula sauvegardera toutes les entrées de sous- répertoires, mais n'entrera pas dans ces sous-répertoires, et ainsi ne sauvegardera pas les fichiers ou épertoires contenus dans ces sous-répertoires. En principe, vous préfèrerez la valeur par défaut (yes).

sparse=yes|no
Cette option active un code spécial qui détecte les fichiers clairsemés tels ceux créés par ndbm. Elle est désactivée par défaut (sparse=no), de sorte qu'aucun contrôle n'est fait pour rechercher les fichiers clairsemés. Vous pouvez l'activer sans danger sur des fichiers non clairsemés, cependant elle entraîne une légère charge supplémentaire pour la détection de tampons remplis de zéros (buffers of all zero), et un léger surplus d'espace sur l'archive de sortie sera utilisé pour ssauver les adresses de recherche de chaque enregistrement non-nul trouvé.

Restrictions: Bacula lit les fichiers dans des tampons de 32K. Si le tampon entier est rempli de zéros, il sera traité en tant que bloc clairsemé, et ne sera pas écrit sur la cartouche. En revanche, si une partie quelconque du tampon est non-nulle, le tampon sera intégralement copié sur la cartouche, avec éventuellement des secteurs de disque (généralement 4098 octets) entièrement nuls. La détection par Bacula des blocs clairsemés a lieu sur des blocs de 32K plutôt que sur des blocs de taille déterminée par le système. Si quelqu'un considère ceci comme un réelle problème, merci d'envoyer une demande de modification en exposant les raisons. Ce code est apparu avec la version 1.27 de Bacula.

Si vous n'êtes pas familier avec les notions de fichiers clairsemés, prenons pour exemple un fichier où vous écrivez 512 octets à l'adresse 0, puis 512 octets à l'adresse 1 million. Le système d'exploitation n'allouera que deux blocs, et rien n'est alloué pour l'espace vide. Pourtant, lorsque vous lisez le fichier clairsemé, le système retourne tous les zéros comme si l'espace était alloué, et si vous sauvegardez un tel fichier, vous utiliserez beaucoup d'espace sur le volume pour écrire des zéros. Pire encore, lorsque vous restaurez ce fichier à son emplacement initial, tous les emplacements précédemment vides seront cette fois alloués, occupant ainsi beaucoup plus d'espace disque. En activant l'option sparse, Bacula recherchera spécifiquement l'espace vide dans les fichiers afin d'éviter ces inconvénients. Le prix à payer est que Bacula doit d'abord examiner chaque bloc lu avant de l'écrire. Sur un système lent, ceci peut-être important. Si vous suspectez certains de vos fichiers d'être clairsemés, vous devriez mesurer les performances et gains d'espace avec et sans l'options, ou ne l'activer que pour les fichiers effectivement clairsemés.

readfifo=yes|no
Cette option, si elle est activée, indique au client de lire les données (lors d'une sauvegarde) et de les écrire (lors d'une restauration) sur un FIFO (pipe) explicitement explicitement mentionné dans le FileSet. Dans ce cas, vous devez avoir un programme actif qui écrit sur ce FIFO dans le cas d'une sauvegarde, ou qui le lit dans le cas d'une restauration. (Ceci peut être accompli par la directive RunBeforeJob). Si cette condition n'est pas satisfaite, Bacula demeurera en suspens indéfiniment en lecture/écriture du FIFO. Lorsque cette option est désactivée (par défaut), le Client sauvegarde simplement l'entrée du répertoire pour le FIFO.

mtimeonly=yes|no
Cette option, si elle est activée, indique au client que la sélection de fichiers lors d'une sauvegarde incrémentale ou différentielle ne doit se référer qu'aux valeurs de st_mtime du paquet stat(). La valeur par défaut est no, ce qui signifie que la sélection de fichiers à sauvegarder se base sur les deux valeurs st_mtime et st_ctime. En général, il n'est pas recommandé d'activer cette option.

keepatime=yes|no
Avec cette option activée, Bacula rétablit le champ st_atime (date d'accès) des fichiers qu'il sauvegarde à leur valeur d'avant la sauvegarde. Cette option n'est généralement pas recommandée car il existe peu de programmes qui utilisent st_atime, et la charge de la sauvegarde se trouve augmentée par les appels systèmes nécessaires pour rétablir les dates. (Je ne suis pas sur que ceci fonctionne sous Win32).

wild=<string>
Spécifie une chaîne de caractères jokers à appliquer aux fichiers. Notez que si Exclude n'est pas activée, cette chaîne sélectionnera les fichiers à sauvegarder. Si au contraire Exclude=yes est spécifié, la chaîne sélectionnera les fichiers à exclure de la sauvegarde. Plusieurs directives wild-card peuvent être spécifiées et sont appliquées séquentiellement jusqu'à ce que l'une d'elles corresponde.

regex=<string>
Spécifie une expression régulière étendue POSIX à appliquer aux fichiers. Cette directive est disponible à partir de Bacula 1.35. Si Exclude n'est pas activée, cette expression régulière sélectionnera les fichiers à sauvegarder. Si au contraire Exclude=yes est spécifié, elle sélectionnera les fichiers à exclure de la sauvegarde. Plusieurs directives regex peuvent être spécifiées et sont appliquées séquentiellement jusqu'à ce que l'une d'elles corresponde.

exclude=yes|no
Lorsque cette option est activée, tout fichier qui correspond aux options est exclu de la sauvegarde. La valeur par défaut est no.

aclsupport=yes|no
Si cette option est activée, et si vous avez installé la librarie POSIX libacl sur votre système, Bacula sauvegardera Listes de Contrôles d'Accès (ACL) UNIX des fichiers et répertoires telles que définies dans IEEE Std 1003.1e version 17 et "POSIX.1e" (abandonné). Cette fonction n'est disponible que sur UNIX et dépend de la librairie ACL. Bacula est automatiquement compilé avec le support ACL si la librairie libacl est installée sur votre système (ceci est reporté dans le fichier config.out). Lors de la restauration, Bacula tentera de restaurer les ACLs. S'il n'y a pas de support ACL sur le système cible, Bacula ne restaurera que les fichiers et répertoires sans les informations ACL. Veuillez noter que si vous sauvegardez un système de fichiers EXT3 ou XFS avec le support des ACLs, et que vous restaurez vers un système de fichiers sans ACLs (tel , peut-être reiserfs), les ACLs seront ignorées.

<file-list> est une liste de répertoires et/ou noms de fichiers spécifiés avec la directive File =. Pour inclure des noms contenant des espaces, entourez-les de guillemets (doubles quotes).

Il existe quelques notations particulières pour spécifier des fichiers et répertoires dans une liste de fichiers file-list. Les voici :

Voici un exemple de définition de ressource FileSet valide. Notez que le premier Include insère le contenu du fichier /etc/backup.list lors du démarrage de Bacula (i.e. le @). 

FileSet {
  Name = "Full Set"
  Include {
    Options {
      Compression=GZIP
      signature=SHA1
      Sparse = yes
    }
    File = @/etc/backup.list
  }
  Include {
     Options {
        wild = *.o
        Exclude = yes
     }
     File = /root/myfile
     File = /usr/lib/another_file
  }
}

Notez que dans l'exemple ci-dessus, tous les fichiers mentionnés dans /etc/backup.list seront compressé avec GZIP, qu'une signature SHA1 sera calculée sur le contenu des fichiers (leurs données), et que la prise en charge particulière des fichiers clairsemés (sparse) s'appliquera.

Les deux répertoires /root/myfile et /usr/lib/another_file seront aussi sauvegardés sans aucune option, mais tous les fichiers à extension .o de ces répertoires seront exlus de la sauvegarde.

Supposons que vous vouliez sauvegarder tout sauf /tmp sur votre système. La commande df vous fournit le résultat suivant : 

[kern@rufus k]$ df
Filesystem      1k-blocks      Used Available Use% Mounted on
/dev/hda5         5044156    439232   4348692  10% /
/dev/hda1           62193      4935     54047   9% /boot
/dev/hda9        20161172   5524660  13612372  29% /home
/dev/hda2           62217      6843     52161  12% /rescue
/dev/hda8         5044156     42548   4745376   1% /tmp
/dev/hda6         5044156   2613132   2174792  55% /usr
none               127708         0    127708   0% /dev/shm
//minimatou/c$   14099200   9895424   4203776  71% /mnt/mmatou
lmatou:/          1554264    215884   1258056  15% /mnt/matou
lmatou:/home      2478140   1589952    760072  68% /mnt/matou/home
lmatou:/usr       1981000   1199960    678628  64% /mnt/matou/usr
lpmatou:/          995116    484112    459596  52% /mnt/pmatou
lpmatou:/home    19222656   2787880  15458228  16% /mnt/pmatou/home
lpmatou:/usr      2478140   2038764    311260  87% /mnt/pmatou/usr
deuter:/          4806936     97684   4465064   3% /mnt/deuter
deuter:/home      4806904    280100   4282620   7% /mnt/deuter/home
deuter:/files    44133352  27652876  14238608  67% /mnt/deuter/files

Si vous vous contentez de spécifier / dans votre liste d'inclusions, Bacula ne sauvegardera que le système de fichiers /dev/hda5. Pour sauvegarder tous vos systèmes de fichiers sans inclure les systèmes de fichiers montés Samba ou NFS et en excluant /tmp, /proc, .journal, et .autofsck, que vous ne voulez ni sauvegarder ni restaurer, vous pouvez utiliser ce qui suit : 

FileSet {
  Name = Include_example
  Include {
    Options {
       wild = /proc
       wild = /tmp
       wild = \.journal
       wild = \.autofsck
       exclude = yes
    }
    File = /
    File = /boot
    File = /home
    File = /rescue
    File = /usr
  }
}

/tmp étant sur son propre système de fichiers et n'étant pas explicitement nommé dans la liste d'inclusion, il n'est pas nécessaire de le spécifier dans la liste d'exclusion. Cependant, il peut être préférable de le faire malgré tout par souci de clarté et au cas où il ne serait plus sur sa propre partition après un remplacement de disques.

Ayez conscience qu'il peut être très dangereux de permettre à Bacula de traverser ou changer de système de fichiers au gré des ppoints de montage. Par exemple, avec ce qui suit : 

FileSet {
  Name = "Bad example"
  Include {
    Options { onefs=no }
    File = /mnt/matou
  }
}

vous sauvegardez une partition NFS montée (/mnt/matou), et puisque onefs est désactivée, Bacula traverse les systèmes de fichiers. Si jamais /mnt/matou contient lui même un point de montage où le système de fichiers de la machine sauvegardée est monté, ce qui est souvent le cas, vous vous retrouvez pris dans un boucle récursive, et la sauvegarde ne se terminera jamais.

Le FileSet suivant sauvegarde une partition raw : 

FileSet {
  Name = "RawPartition"
  Include {
    Options { sparse=yes }
    File = /dev/hda2
  }
}

Lorsque vous sauvegardez et restaurez une partition raw, vous devriez vous assurer qu'aucun autre processus, y compris le système, n'écrit sur cette partition. En guise de précaution, nous recommandons ardemment de ne sauvegarder en mode raw que des partitions non montées, ou montées en lecture seule. Ceci peut être fait si nécessaire avec la directive RunBeforeJob.

Considérations sur les FileSets Windows

Si vous saisissez des noms de fichiers Windows, les chemins des répertoires devraient être précédés de double-points (comme dans "c:"). Cependant, les séparateurs de champs doivent être spécifiés selon la convention Unix (c'est à dire, la barre oblique avant : "/"). Si vous souhaitez inclure une apostrophe dans un nom de fichier, précédez-la d'une barre oblique arrière (\\). Par exemple, vous pourriez utiliser ce qui suit pour sauvegarder le répertoire "My Documents" d'une machine Windows : 

FileSet {
  Name = "Windows Set"
  Include {
    Options {
       wild = *.obj
       wild = *.exe
       exclude = yes
     }
     File = "c:/My Documents"
  }
}

Pour que les listes d'exclusion fonctionnent correctement sous Windows, vous devez observer les règles suivante :

Merci à Thiago Lima pour nous avoir résumé les points ci-dessus. Si vous rencontrez des difficultés pour faire fonctionner vos listes d'inclusion ou d'exclusion, songez à utiliser la commande estimate job=xxx listing documentée dans le chapitre Console chapter de ce manuel.

Sur les systèmes Win32, si vous déplacez un répertoire ou si vous renommez un fichier de la liste à sauvegarder, et si une Full a déjà eu lieu, Bacula ne saura reconnaître qu'il existe de nouveaux fichiers à sauvegarder lors d'une incrémentale ou d'une différentielle (faites-en le reproche à Microsoft, pas à moi !). Pour pallier à ce problème, veuillez copier tout répertoire ou fichier de la zone sauvegardée. Si vous ne disposez pas de suffisamment d'espace disque, déplacez-les, mais lancez alors une sauvegarde Full.

Exclusion de fichiers et répertoires

Vous pouvez aussi inclure des noms de fichiers ou chemins absolus, en plus de l'utilisation de caractères jokers et de la directive Exclude=yes dans les ressources Options comme exposé ci-dessus, en ajoutant simplement les fichiers à exclure dans une ressource Exclude du FileSet. Par exemple : 

FileSet {
  Name = Exclusion_example
  Include {
    Options {
      Signature = SHA1
    }
    File = /
    File = /boot
    File = /home
    File = /rescue
    File = /usr
  }
  Exclude {
    File = /proc
    File = /tmp
    File = .journal
    File = .autofsck
  }
}

Un exemple de FileSet Windows

Cet exemple est une contribution de Phil Stracchino : 

This is my Windows 2000 fileset:
FileSet {
  Name = "Windows 2000 Full Set"
  Include {
    Options {
       signature=MD5
    }
    File = c:/
  }
  Exclude {
# Most of these files are excluded not because we don't want
#  them, but because Win2K won't allow them to be backed up
#  except via proprietary Win32 API calls.
    File = "/Documents and Settings/*/Application Data/*/Profiles/
           */*/Cache/*"
    File = "/Documents and Settings/*/Local Settings/Application Data/
           Microsoft/Windows/[Uu][Ss][Rr][Cc][Ll][Aa][Ss][Ss].*"
    File = "/Documents and Settings/*/[Nn][Tt][Uu][Ss][Ee][Rr].*"
    File = "/Documents and Settings/*/Cookies/*"
    File = "/Documents and Settings/*/Local Settings/History/*"
    File = "/Documents and Settings/*/Local Settings/
           Temporary Internet Files/*"
    File = "/Documents and Settings/*/Local Settings/Temp/*"
    File = "/WINNT/CSC"
    File = "/WINNT/security/logs/scepol.log"
    File = "/WINNT/system32/config/*"
    File = "/WINNT/msdownld.tmp/*"
    File = "/WINNT/Internet Logs/*"
    File = "/WINNT/$Nt*Uninstall*"
    File = "/WINNT/Temp/*"
    File = "/temp/*"
    File = "/tmp/*"
    File = "/pagefile.sys"
  }
}

Remarque : les trois lignes coupées de cette liste d'exclusion ne l'ont été que pour des motifs de mise en page, elles doivent en réalité être écrites sur une seule ligne.

L'ancienne ressource FileSet

L'ancienne Ressource FileSet des versions antérieures à 1.34.3 est obsolète, mais fonctionne encore. Nous vous encourageons à utiliser la nouvelle forme, car le code correspondant sera supprimé à partir de la version 1.37.

Tester vos FileSets

Si vous voulez vous faire une idée précise de ce qui sera effectivement sauvegardé par un FileSet, ou si vous voulez vous assurer de l'efficacité d'une liste d'exclusion, vous pouvez utiliser la commande estimate du programme Console. Voyez la commande estimate dans le chapitre Console de ce manuel.

Considerations sur le nommage Windows NTFS

Les noms de fichiers NTFS contenant des caractères Unicode (i.e. > 0xFF) ne peuvent, pour le moment, être nommé eplicitement. Vous devez inclure de tels fichiers en désignant un répertoire de niveau supérieur ou une lettre de disque ne contenant pas de caractère Unicode.


La ressource Client

La ressource Client définit les attributs des clients sauvegardés par ce Director. Il faut une ressource Client par machine sauvegardée.

Client (ou FileDaemon)
Début des directives Client.

Name = <name>
Le nom du client qui sera utilisé dans la directive Job de la ressource ou dans une commande run de la Console. Cette directive est requise.

Address = <address>
L'adresse d'un File Daemon Bacula est un nom d'hôte, un nom pleinement qualifié ou une adresse réseau au format quatre octets pointés. Cette directive est requise.

FD Port = <port-number>
Où le port est le numéro de port auquel le le File Daemon peut être contacté. La valeur par défaut est 9102.

Catalog = <Catalog-resource-name>
Cette directive spécifie le nom de la ressource catalog à utiliser pour ce client. Cette directive est requise.

Password = <password>
Il s'agit ici du mot de passe à utiliser lors de la connection avec le File Daemon, aussi le fichier de configuration de la machine à sauvegarder doit définir le même mot de passe pour être connecté par ce Director. Cette directive est requise. Si vous disposez de /dev/random ou de bc sur votre machine, Bacula génère des mots de passe aléatoires lors du processus de configuration. Dans le cas contraire, le mot de passe est laissé blanc.

File Retention = <time-period-specification>
La directive File Retention définit la période pendant laquelle Bacula conservera les enregistrements File dans le catalogue. Lors de l'expiration de cette période, si la directive AutoPrune est active (yes), Bacula élague le catalogue des enregistrements File dont l'âge est supérieur à la période de rétention. Notez que ceci n'affecte que les enregistrements du catalogue, et non vos sauvegardes archivées.

Les enregistrements File peuvent en fait être conservés pour une période inférieure à celle affectée à cette directive dans les cas où vous avez spécifié des périodes plus courtes pour les directives Job Retention ou Volume Retention. La plus courte des trois prend le pas sur les autres. Les durées peuvent être exprimées en secondes, minutes, heures, jours, semaines, mois, trimestres ou années. Consultez le chapitre Adapter les fichiers de configuration de ce manuel pour plus de détails sur les spécifications de durées.

La valeur par défaut est de 60 jours.

Job Retention = <time-period-specification>
La directive Job Retention définit la période pendant laquelle Bacula conservera les enregistrements Job dans le catalogue. Lors de l'expiration de cette période, si la directive AutoPrune est active (yes), Bacula élague le catalogue des enregistrements File dont l'âge est supérieur à la période de rétention. Notez que ceci n'affecte que les enregistrements du catalogue, et non vos sauvegardes archivées.

Si un enregistrement de Job est sélectionné pour élagage, tous les enregistrements File et JobMedia associés seront aussi élagués du catalogue, sans qu'il ne soit tenu compte de la période File Retention définie. Par conséquent, vous utiliserez, en principe, une période File Retention inférieure à la période Job retention. La période Job retention peut en fait s'avérer inférieure à la valeur que vous avez spécifiée si vous avez affecté une valeur inférieure à la directive Volume Retention dans la ressource Pool. Les périodes Job retention et Volume retention sont appliquées indépendamment, la plus petite prend le pas sur l'autre.

Les durées peuvent être exprimées en secondes, minutes, heures, jours, semaines, mois, trimestres ou années. Consultez le chapitre Adapter les fichiers de configuration de ce manuel pour plus de détails sur les spécifications de durées.

La valeur par défaut est 180 jours.

AutoPrune = <yes|no>
Si AutoPrune est réglé à yes (valeur par défaut), Bacula (dans les versions au delà de 1.20) applique automatiquement les périodes File retention et Job retention pour le client à la fin du job. Si vous spécifiez AutoPrune = no, l'élagage ne se fera pas et votre catalogue grossira à chaque job. L'élagage n'affecte que les données du catalogue, et non les données stockées sur les volumes.

Maximum Concurrent Jobs = <number>
<number> désigne le nombre maximum de jobs qui peuvent être lancés simultanément sur le client concerné. Notez que cette directive ne limite que les jobs pour les clients qui ont le même nom que la ressource dans laquelle elle apparaît. Toutes les autres restrictions du nombre maximum de jobs simultanés telles que celles spécifiées dans les ressources Director, Job, ou Storage s'appliquent aussi en plus de toute limite fixée ici. La valeur par défaut est 1, mais vous pouvez spécifier une valeur plus grande. Nous recommandons fortement de lire les MISES EN GARDE de la section Maximum Concurrent Jobs du chapitre Configurer le Director.

Priority = <number>
<number> spécifie la priorité de ce client par rapport aux autres clients que le Director sauvegarde simultanément. La priorité admet une valeur entre 1 et 1000. Les clients sont ordonnés de sorte que ceux dont la valeur de priorité sont les plus petites sont traités les premiers (Ceci n'est pas encore implémenté).

Voici un exemple d'une définition de ressource Client valide : 

Client {
  Name = Minimatou
  FDAddress = minimatou
  Catalog = MySQL
  Password = very_good
}


La ressource Storage

La ressource Storage définit les Storage Daemons disponibles pour le Director.

Storage
Début des ressources Storage. Il faut en spécifier au moins une.

Name = <name>
Le nom de la ressource Storage. Ce nom apparaît au niveau de la directive Storage spécifiée dans la ressource Job et est requise.

Address = <address>
Où l'adresse est un nom d'hôte, une adresse pleinement qualifiée, ou une adresse IP. Notez bien que l'adresse spécifiée ici sera transmise au File Daemon qui l'utilisera alors pour contacter le Storage Daemon. Aussi, ce n'est pas une bonne idée d'utiliser localhost en tant que nom, il vaut mieux utiliser un nom de machine pleinement qualifié, ou une adresse IP. Cette directive est requise.

SD Port = <port>
Où "port" est le port à utiliser pour contacter le Storage Daemon pour les informations et pour exécuter les jobs. Ce même numéro de port doit apparaître dans la ressource Storage du fichier de configuration du Storage Daemon. Le port par défaut est 9103.

Password = <password>
Il s'agit du mot de passe à utiliser lors de l'établissement de la connection avec les services Storage. Ce même mot de passe doit aussi apparaître dans la ressource Director du fichier de configuration du Storage Daemon. Cette directive est requise. Si vous avez soit /dev/random, soit bc sur votre machine, Bacula génèrera un mot de passe aléatoire lors du processus de configuration. Dans le cas contraire, ce champ sera laissé blanc.

Device = <device-name>
Cette directive spécifie le nom (pour le Storage Daemon) du périphérique à utiliser pour le stockage. Ce nom n'est pas le nom de périphérique physique, mais le nom de périphérique logique qui a été défini par la directive Name de la ressource Device du fichier de configuration du Storage Daemon. Si le périphérique est une librairie, vous devez utiliser le nom défini au niveau de la directive Name défini dans la définition de la ressource Autochanger du Storage Daemon. Vous pouvez utiliser le nom de votre choix (y compris le nom de périphérique physique) à concurrence de 127 caractères. Le nom de périphérique physique associé à ce périphérique est spécifié dans le fichier de configuration du Storage Daemon (en tant qu'Archive Device). Prenez garde à ne pas définir deux directives Storage Resource dans le Director qui pointent vers le même périphérique du Storage Daemon. Il pourrait en résulter un blocage du Storage Daemon si celui-ci tente d'utiliser le même périphérique deux fois. Cette directive est requise.

Media Type = <MediaType>
Cette directive spécifie le type de média à utiliser pour stocker les données. Il s'agit d'une chaîne de caractères arbitraire n'excédant pas 127 caractères. Ce peut être ce que vous voulez, cependant, il est préférable de la choisir de manière à décrire le médium de stockage utilisé (par exemple : Fichier, DAT, ''HP DLT8000``, 8mm,...). D'autre part, il est esentiel d'avoir une spécification Media Type unique pour chaque type de média de stockage. Si vous avez deux lecteurs DDS-4 avec des formats incompatibles et une librairie DDS-4, vous devriez certainement spécifier des Media Types distincts. Lors d'une restauration, supposons qu'un Media Type DDS-4 est associé avec le le job, Bacula peut décider d'utiliser tout Storage Daemon qui supporte le Media Type DDS-4 sur tout lecteur qui le supporte.

Actuellement, Bacula n'autorise qu'un seul type de media. Par conséquent, si vous disposez d'un lecteur qui en supporte plusieurs, vous pouvez utiliser une chaîne unique pour désigner les volumes de l'un ou l'autre type, par exemple Media Type = DDS-3-4 pour les types DDS-3 et DDS-4, mais ces volumes ne seront montés que sur les lecteurs spécifiés comme acceptant les deux types : DDS-3-4

Si vous voulez contraindre Bacula à utiliser un seul Storage Daemon ou un seul lecteur, vous devez spécifier un Media Type unique pour ce lecteur. C'est un point important qui devrait être bien compris. Notez que ceci s'applique également aux volumes disque. Si vous définissez plus d'une ressource Device disque dans votre fichier de configuration du Storage Daemon, les volumes sur ces deux devices seront en fait incompatibles car l'un ne pourra être monté sur l'autre puisqu'ils se trouvent dans des répertoires différents. C'est pourquoi vous devriez probablement plutôt utiliser deux Media Types distincts pour vos deux devices disque (même si vous pensez à eux comme ayant l'un et l'autre le type File).

Vous trouverez pus de détails à ce sujet dans le chapitre Gestion des volumes : fondements (NDT:basic volumes management) de ce manuel.

Le MediaType spécifié ici doit correspondre au MediaType spécifié dans la ressource Device du fichier de configuration du Storage Daemon. Cette directive est requise, et est utilisée par le Director et le Storage Daemon pour s'assurer qu'un volume sélectionné automatiquement dans un Pool correspond à un périphérique physique. Si un Storage Daemon gère plusieurs périphériques (par exemple, s'il écrit sur plusieurs volumes de type File sur différentes partitions), cette directive vous permet de préciser exactement quel périphérique utiliser.

Comme mentionné ci-dessus, la valeur spécifiée dans la ressource Storage du Director doit s'accorder avec celle spécifiée dans la ressource Device du fichier de configuration du Storage Daemon. Ceci représente aussi un contrôle supplémentaire pour assurer que vous n'essayez pas d'écrire les données destinées à un lecteur DLT sur un lecteur 8mm.

Autochanger = <yes|no>
Si vous spécifiez yes pour cette commande (la valeur par défaut est no), alors Bacula requérira un numéro de Slot lorsque vous utiliserez les commandes label et add pour créer un nouveau volume. Ceci simplifie la création des enregistrements de Volumes dans le catalogue si vous disposez d'une librairie. Si vous omettez de spécifier le Slot, la robotique ne sera pas utilisée. Cependant, vous pouvez modifier le Slot associé à un volume à tout moment grâce à la commande update volume du programme Console. Lorqu'autochanger est activée, l'algorithme utilisé par Bacula pour rechercher des volumes utilisables est modifié de façon à prendre en compte tout volume supposé contenu dans la librairie. Si aucun volume in changer n'est trouvé, Bacula tente de recycler, élaguer..., et s'il ne trouve toujours aucun volume, Bacula recherche un volume présent ou non dans la librairie. Privilégier les volumes présents dans la librairie permet de minimiser les interventions d'un opérateur.

Pour que la robotique soit utilisée, vous devez aussi spécifier Autochanger = yes dans la ressource La Ressource Device du fichier de configuration du Storage Daemon, ainsi que d'autres paramètres importants du Storage Daemon. Vous trouverez plus d'information à ce sujet dans le chapitre Utiliser une librairie de ce manuel.

Maximum Concurrent Jobs = <number>
Où <number> est le nombre maximum de jobs utilisant la ressource Storage courante qui peuvent être exécutés simultanément. Notez que cette directive ne limite que les jobs qui utilisent ce Storage Daemon. Toute autre limitation du nombre maximum de jobs simultanés au niveau des ressources Director, Job ou Client est aussi appliquée en plus de celle fixée ici. La valeur par défaut est 1, mais vous pouvez utiliser une valeur plus importante. Nous vous recommandons fortement de lire les MISES EN GARDE de la section Maximum Concurrent Jobs du chapitre Configurer le Director.

Alors qu'il est possible de définir des nombres maximum de jobs simultanés supérieurs à 1 dans les ressource Director, Job et Client, vous devriez porter une attention particulière au paramétrage de cette directive pour le Storage Daemon. En conservant la valeur 1, vous évitez que deux jobs écrivent simultanément sur le même volume ce qui, quoique supporté, n'est pas recommandé actuellement.

Voici un exemple de ressource Storage valide : 

# Definition of tape storage device
Storage {
  Name = DLTDrive
  Address = lpmatou
  Password = storage_password # password for Storage daemon
  Device = "HP DLT 80"    # same as Device in Storage daemon
  Media Type = DLT8000    # same as MediaType in Storage daemon
}


La ressource Pool

La ressource Pool définit l'ensemble des volumes de stockage (cartouches ou fichiers) à la disposition de Bacula pour écrire les données. En configurant différents Pools, vous pouvez déterminer quel ensemble de volumes (ou média) reçoit les données sauvegardées. Ceci permet, par exemple, de stocker toutes les sauvegardes Full sur un ensemble de volumes, et les sauvegardes différentielles et incrémentales sur un autre. De même, vous pouvez assigner un ensemble de volumes à chaque machine sauvegardée. Tout ceci peut être réalisé aisément en définissant plusieurs pools.

Un autre aspect important d'un pool est qu'il contient des attributs par défaut (Nombre maximum de jobs, période de rétention, drapeau de recyclage,...) qui sont conférés à tout volume lui appartenant lors de sa création. Ceci vous évite d'avoir à répondre à un grand nombre de questions lorsque vous étiquettez (label) un nouveau volume. Chacun de ces attributs peut ensuite être modifié sur chaque volume individuellement avec la commande update du programme Console. Notez que vous devez préciser explicitement quel pool est à utiliser avec chaque job. Bacula ne recherche pas automatiquement le pool correct.

Dans la plupart des installations de Bacula, toutes les sauvegardes de toutes les machines vont vers un unique jeu de volumes. Dans ce cas, vous n'utiliserez probablement que le pool par défaut Default. Si votre stratégie de sauvegarde vous impose à monter chaque jour une cartouche différente, vous voudrez probablement définir des pools distincts pour chaque jour. Pour plus d'informations à ce sujet, consultez le chapitre Stratégies de sauvegarde de ce manuel.

Pour utiliser un pool, vous devez suivre trois étapes :

D'abord, le pool doit être défini dans le fichier de configuration du Director. Ensuite le pool doit être enregistré dans le catalogue. Ceci est fait automatiquement par le Director à chaque fois qu'il démarre, ou peut être réalisé manuellement à l'aide de la commande create du programme Console. Enfin, si vous modifiez la définition du pool dans le fichier de configuration du Director et redémarrez Bacula, le pool sera mis à jour automatiquement, ce qui peut aussi être réalisé manuellement avec la commande update pool du programme Console pour rafraichir l'image du catalogue. C'est cette image du catalogue plutôt que l'image de la ressource du Director qui est utilisée pour les attributs de volume par défaut. Notez que pour que le pool soit automatiquement créé ou mis à jour, il doit être référencé explicitement par une ressource Job.

Ensuite le médium physique doit être étiquetté. L'étiquettage peut être réalisé soit par la commande label du programme Console, soit en utilisant le programme btape. La méthode à privilégier est la première.

Finallement, vous devez ajouter des noms de volumes (et leurs attributs) au pool. Pour que les volumes soient utilisés par Bacula, ils doivent être du même Media Type que l'Archive Device spécifiée pour le job. (Autrement dit, si vous vous apprétez à sauvegarder vers un lecteur DLT, le pool doit contenir des volumes DLT, puisque des volumes 8mm ne peuvent être montés sur un lecteur DLT). Le Media Type revêt une importance particulière si vous sauvegardez vers des fichiers. Lorsque vous exécutez un job, vous devez explicitement préciser le pool. Bacula sélectionne dès lors automatiquement le prochain volume du pool à utiliser, en s'assurant que le Media Type de tout volume sélectionné est bien celui requis par la ressource Storage spécifiée pour le job.

Si vous utilisez la commande label du programme Console pour étiquetter les volumes, il sont automatiquement ajoutés au pool, aussi cette dernière étape n'est généralement pas requise.

Il est aussi possible d'ajouter des volumes au catalogue sans avoir explicitement étiquetté les volumes physiques. Ceci s'effectue avec la commande add du programme Console.

Comme mentionné plus haut, à chaque démarrage, Bacula examine tous les pools associés à chaque catalogue, et si un enregistrement n'existe pas encore, il est créé à partir de la définition du pool dans la ressource. Bacula devrait probablement effectuer un update pool si vous modifiez la définition du pool mais, actuellement, vous devez le faire manuellement avec la commande update pool du programme Console.

La ressource Pool définie dans le fichier de configuration du Director peut contenir les directives suivantes :

Pool
Début de la ressource Pool. Il faut définir au moins une ressource Pool.

Name = <name>
Le nom du pool. Pour la plupart des applications, vous utiliserez le pool par défaut nommé Default. Cette directive est requise.

Number of Volumes = <number>
Cette directive spécifie le nombre de volumes (cartouches ou fichiers) contenus dans le pool. En principe, il est défini et mis à jour automatiquement par la routine de maintenance du catalogue de Bacula.

Maximum Volumes = <number>
Cette directive spécifie le nombre maximum de volumes contenus dans le pool. Cette directive est optionnelle. Si elle est omise ou réglée à 0, tout nombre de volumes est permis. En général, cette directive est utile pour les librairies, où il y a un nombre fixé de volumes, ou pour le stockage sur fichier si vous voulez vous assurer que les sauvegardes sur disque ne deviennent pas trop nombreuses ou ne consomment pas trop d'espace.

Pool Type = <type>
Cette directive définit le type du pool, qui correspond au type du job exécuté. Cette directive est requise et peut prendre l'une des valeurs suivantes :

Backup
*Archive
*Cloned
*Migration
*Copy
*Save

Use Volume Once = <yes|no>
Cette directive, si elle est active (valeur yes) stipule que chaque volume ne doit être utilisé qu'une seule fois. C'est particulièrement utile si le volume est un fichier et si vous voulez un nouveau fichier pour chaque nouvelle sauvegarde. La valeur par défaut est no (autrement dit, les volumes peuvent être utilisés plusieurs fois). Cette directive sera très certainement bientôt obsolète, aussi nous vous recommandons d'utiliser Maximum Volume Jobs = 1 à la place.

La valeur définie par cette directive dans le fichier de configuration du Director est la valeur par défaut utilisée lorsqu'un nouveau volume est créé. Modifier la valeur dans le fichier de configuration ne changera pas ce qui est stocké sur le volume. Pour changer cette valeur pour un volume existant, vous devez utiliser la commande update du programme Console.

Maximum Volume Jobs = <positive-integer>
Cette directive spécifie le nombre maximum de jobs qui peuvent être écrits sur le volume. La valeur par défaut est zéro, ce qui signifie que le nombre de jobs sur un volume n'est pas limité. Sinon, lorsque le nombre de jobs sauvegardés sur le volume atteint la valeur positive-integer spécifiée, le volume est marqué Used. Dès lors, il ne peut plus être utilisé pour y ajouter des jobs, tout comme dans le cas d'un volume avec le statut Full, mais il peut être recyclé si le recyclage est activé. En spécifiant MaximumVolumeJobs = 1 vous obtenez le même effet que celui que vous obtiendriez avec UseVolumeOnce = yes.

Notez que la valeur définie par cette directive dans le fichier de configuration du Director est la valeur par défaut utilisée lors de la création d'un volume. Une fois le volumes créé, modifier la valeur dans le fichier de configuration ne changera pas ce qui est stocké sur le volume. Pour changer cette valeur pour un volume existant, vous devez utiliser la commande update du programme Console.

Maximum Volume Files = <positive-integer>
Cette directive spécifie le nombre maximum de fichiers qui peuvent être écrits sur le volume. La valeur par défaut est zéro, ce qui signifie que le nombre de fichiers sur un volume n'est pas limité. Sinon, lorsque le nombre de fichiers sauvegardés sur le volume atteint la valeur positive-integer spécifiée, le volume est marqué Used. Dès lors, il ne peut plus être utilisé pour y ajouter des jobs, tout comme dans le cas d'un volume avec le statut Full, mais il peut être recyclé si le recyclage est activé. Ce n'est qu'à la fin d'un job que Cette valeur est controlée, et que le statut du volume est éventuellement changé en Used.

La valeur définie par cette directive dans le fichier de configuration du Director est la valeur par défaut utilisée lors de la création d'un volume. Une fois le volumes créé, modifier la valeur dans le fichier de configuration ne changera pas ce qui est stocké sur le volume. Pour changer cette valeur pour un volume existant, vous devez utiliser la commande update du programme Console.

Maximum Volume Bytes = <size>
Cette directive spécifie le nombre maximum d'octets qui peuvent être écrits sur le volume. La valeur par défaut est zéro, ce qui signifie qu'il n'y a d'autre limite que la capacité physique du volume. Sinon, lorsque le nombre d'octets sauvegardés sur le volume atteint la valeur size spécifiée, le volume est marqué Used. Dès lors, il ne peut plus être utilisé pour y ajouter des jobs, tout comme dans le cas d'un volume avec le statut Full, mais il peut être recyclé si le recyclage est activé. Ce n'est qu'à la fin d'un job que Cette valeur est controlée, et que le statut du volume est éventuellement changé en Used.

La valeur définie par cette directive dans le fichier de configuration du Director est la valeur par défaut utilisée lors de la création d'un volume. Une fois le volumes créé, modifier la valeur dans le fichier de configuration ne changera pas ce qui est stocké sur le volume. Pour changer cette valeur pour un volume existant, vous devez utiliser la commande update du programme Console.

Volume Use Duration = <time-period-specification>
Cette directive définit la période durant laquelle le volume peut être utilisé en écriture, à compter de la première opération d'écriture de données. La valeur par défaut est zéro, ce qui signifie que le volume peut être écrit indéfiniment . Sinon, lorsque la durée depuis la première écriture excède la période time-period-specification spécifiée, le volume est marqué Used. Dès lors, il ne peut plus être utilisé pour y ajouter des jobs, tout comme dans le cas d'un volume avec le statut Full, mais il peut être recyclé si le recyclage est activé. L'usage de la commande status dir applique des algorithmes similaires à l'éxecution de jobs, aussi lors d'une telle commande, le statut du volume peut être modifié. Lorsque le volume est recyclé, il peut à nouveau être utilisé.

Vous pourriez utiliser cette directive, par exemple, si vous avez un volume dédié aux sauvegardes incrémentales, et un volume dédié aux Fulls hebdomadaires. Une fois que la Full est passée, vous pouvez préférer utiliser un autre volume pour les incrémentales. Ceci peut être accompli en règlant la période Volume Use Duration à six jours pour les volumes des incrémentales. Autrement dit, celui-ci sera utilisé durant les six jours qui suivent une full, puis un autre volume d'incrémentales sera utilisé. Veillez à utiliser des périodes relativement courtes telles que 23 heures, ou vous pourriez placer Bacula en situation de devoir attendre tout un week-end le montage d'une cartouche par l'opérateur pour pouvoir terminer une sauvegarde.

Ce n'est qu'à la fin d'un job que Cette valeur est controlée, et que le statut du volume est éventuellement changé en Used, ce qui signifie que bien que la période Volume Use Duration puisse avoir expiré, l'entrée correspondante du catalogue ne sera pas mise à jour jusqu'à ce que le prochain job utilisant ce volume soit exécuté.

La valeur définie par cette directive dans le fichier de configuration du Director est la valeur par défaut utilisée lors de la création d'un volume. Une fois le volumes créé, modifier la valeur dans le fichier de configuration ne changera pas ce qui est stocké sur le volume. Pour changer cette valeur pour un volume existant, vous devez utiliser la commande update volume du programme Console.

Catalog Files = <yes|no>
Cette directive précise si les noms des fichiers sauvegardés doivent ou non être enregistrés dans le catalogue. La valeur par défaut est yes. L'avantage de désactiver cette option (Catalog Files = No) est d'avoir un catalogue significativement plus petit. L'inconvénient est de ne pas pouvoir produire de liste des fichiers sauvegardés pour chaque job à partir du catalogue (autrement dit, vous ne pourrez naviguer dans les fichiers sauvegardés). Ainsi, sans les enregistrements de fichiers, vous ne pourrez utiliser la commande restore, ni aucune des autres commandes du programme Console qui se réfèrent aux enregistrements de fichiers.

AutoPrune = <yes|no>
Si AutoPrune est activée (yes), ce qui est le cas par défaut, Bacula (depuis la version 1.20) applique automatiquement la période de rétention des volumes lorsqu'un nouveau volumes est requis ou lorsqu'il n'existe aucun volume utilisable dans le pool. L'élagage des volumes consiste à supprimer du catalogue les jobs expirés (ceux qui sont plus anciens que la période de rétention), et rend possible le recyclage de ces volumes

Volume Retention = <time-period-specification>
La directive Volume Retention définit la période durant laquelle Bacula conserve les enregistrements Job associés au volume dans le catalogue. Lors de l'expiration de cette période, si AutoPrune est activée, Bacula peut supprimer les enregistrements Job plus anciens que la période time-period-specification spécifiée s'il est nécessaire de libérer un volume. Tous les enregistrements de fichiers associés à des jobs supprimés sont aussi supprimés. Les durées peuvent être exprimées en secondes, minutes, heures, jours, semaines, mois, trimestres ou années. La période Volume Retention s'applique indépendamment des périodes Job Retention et File Retention définies dans la ressource Client. Ceci signifie que la période la plus courte est celle qui s'applique.Notez bien que lorsque la période Volume Retention a été atteinte les enregistrements de Job et ceux de fichiers sont supprimmés les uns et les autres. Cet élagage peut aussi se produire à l'exécution de la commande status dir car elle applique des algorithmes similaires à ceux utilisés pour déterminer le prochain volume disponible.

Il est important de savoir que lorsque la période Volume Retention expire, Bacula ne recycle pas systématiquement le volume concerné. Il tente de conserver les données intactes aussi longtemps que possible avant d'écrire sur ce volume.

La valeur par défaut est 365 jours. Notez que cette directive règle la valeur par défaut pour chaque enregistrement de volume du catalogue lorsque le volume est créé. Cette valeur du catalogue peut ensuite être modifiée avec la commande update du programme Console.

En définissant plusieurs pools avec différentes périodes de rétention (volume retention), vous pouvez efficacement gérer vos cartouches avec, par exemple un pool de cartouches recyclé chaque semaine, un autre recyclé chaque mois, et ainsi de suite. Cependant, il faut bien garder à l'esprit que si votre période de rétention Volume Retention est trop courte, il peut arriver que votre dernière sauvegarde Full valide soit supprimée, de sorte que vous n'ayez plus une sauvegarde complète de votre système, et que votre prochaine incrémentale soit élevée en une Full. Par conséquent, la valeur minimum de la période Volume Retention devrait être au moins le double de l'intervalle séparant vos Fulls. Autrement dit, pour des Fulls mensuelles, la période Volume Retention devrait être supérieure ou égale à deux mois.

Notez que la valeur définie par cette directive dans le fichier de configuration du Director est la valeur par défaut utilisée lors de la création d'un volume. Une fois le volumes créé, modifier la valeur dans le fichier de configuration ne changera pas ce qui est stocké sur le volume. Pour changer cette valeur pour un volume existant, vous devez utiliser la commande update du programme Console.

Recycle = <yes|no>
Cette directive spécifie la valeur par défaut pour le recyclage des volumes purgés. Si elle est activée (yes) et si Bacula a besoin d'un volume mais n'en trouve aucun utilisable, il recherche alors les volumes purgés (c'est à dire ceux dont tous les jobs et fichiers ont expiré et ont, de fait, été supprimés du catalogue). Si un volume est recyclé, toutes les données précedemment écrites sur ce volumes seront écrasées. Si le recyclage est désactivé (no), le volume ne sera pas recyclé, et ainsi les données resteront valides. Si vous souhaitez réutiliser un volume dont le drapeau de recyclage est no (0 dans le catalogue), vous devez manuellement le changer en yes (commande update).

Notez que la valeur définie par cette directive dans le fichier de configuration du Director est la valeur par défaut utilisée lors de la création d'un volume. Une fois le volumes créé, modifier la valeur dans le fichier de configuration ne changera pas ce qui est stocké sur le volume. Pour changer cette valeur pour un volume existant, vous devez utiliser la commande update du programme Console.

Recycle Oldest Volume = <yes|no>
Cette directive indique au Director de rechercher le volume le plus ancien du pool lorsq'un nouveau est requis par le Storage Daemon et qu'aucun autre n'est disponible. Le catalog est alors élagué dans le respect des périodes Job, File et Volume Retention, c'est pourquoi cette directive est, de très loin, préférable à directive Purge Oldest Volume.

Cette directive peut être utile si vous avez un nombre fixe de volumes dans un pool et que vous voulez cycler sur ces volumes après avoir spécifié les périodes de rétention qui conviennent.

Recycle Current Volume = <yes|no>
Si Bacula a besoin d'un nouveau volume, cette directive lui indique d'élaguer le volume dans le respect des périodes Job, File et Volume Retention. Si tous les jobs sont élagués, (c'est à dire si le volume est purgé), alors le volume est recyclé et sera utilisé pour la prochaine opération d'écriture. Cette directive respecte toutes les périodes Job, File et Volume Retention, c'est pourquoi elle est , de très loin, préférable à la directive Purge Oldest Volume.

Cette directive peut être utile si vous avez un nombre fixe de volumes dans un pool et que vous voulez cycler sur ces volumes après avoir spécifié les périodes de rétention qui élaguent les volumes avant que vous n'ayez terminé le cycle sur les volumes.

Purge Oldest Volume = <yes|no>
Cette directive indique au Director de rechercher le volume utilisé le plus ancien dans le pool lorsqu'un nouveau volume est requis par le Storage Daemon et qu'aucun n'est disponible. Le catalogue est alors purgé sans égards pour les périodes de rétention des fichiers et jobs écrits sur ce volume. Le volume est alors recyclé pour être utilisé pour la prochaine opération d'écriture. Cette directive outrepasse toute période de rétention (Job, File, ou Volume) que vous avez pu spécifier par ailleurs.

Cette directive peut être utile si vous avez un nombre fixe de volumes dans un pool et que vous voulez cycler sur ces volumes lorsque tous les volumes sont pleins, sans avoir à vous soucier de paramétrer les périodes de rétentions qui conviendraient. Cependant, en l'utilisant, vous courrez le risque de perdre toutes vos données.

Soyez conscient que Purge Oldest Volume ne fait aucun cas d'aucune période de rétention. Si vous activez cette directive alors que vous ne possédez qu'un seul volume, ce volume sera systématiquement écrasé tout de suite après avoir été rempli ! Aussi, assurez vous au moins d'avoir un nombre décent de volumes dans votre pool avant d'exécuter un job. Si vous voulez que les périodes de rétention soient prises en compte, n'utilisez pas cette directive. Pour spécifier une période de rétention, utilisez la directive Volume Retention (voir ci dessus).

Je recommande fortement de ne pas utiliser cette directive, car il est certain que tôt ou tard, Bacula recyclera un volume contenant des données valides et récentes. La valeur par défaut est no

Cleaning Prefix = <string>
Cette directive définit un préfixe qui, s'il correspond au début du nom d'un volume lors de son étiquettage, indique à Bacula que le volume en question est une cartouche de nettoyage, qui aura le statut VolStatus = Cleaning. Ainsi Bacula ne tentera jamais d'utiliser cette cartouche. Cette option est particulièrement utile avec les librairies équipées de lecteurs de codes barres où, conventionnellement, les codes barres commençnt par CLN sont traités en tant que cartouches de nettoyage.

Label Format = <format>
Cette directive précise le format des étiquettes des volumes de ce pool. La directive Format est utilisée comme un patron pour créer de nouveaux noms de volumes lors de l'étiquettage automatique.

Le format devrait être spécifié entre guillemets, et consiste en une chaîne de lettres, chiffres et caractères spéciaux tiret (-), souligné (_), double point (:) et point (.), qui sont considérés valides pour un nom de volume.

De plus, le format peut comporter des caractères variables qui seront substituées par un algorithme complexe, ce qui permet de créer des noms de volumes avec plusieurs formats différents. En tous les cas, le processus d'expansion des variables doit aboutir au jeu de caractères définis comme légaux dans le dernier paragraphe. Généralement, ces caractères variables commencent par un signe dollar ($) ou un crochet droit ([). Si vous spécifiez des caractères variables vous devriez toujours les encadrer de guillemets. Pour plus de détails sur ce sujet, veuillez consulter le chapitre Variable Expansion de ce manuel.

Si aucun caractère variable n'est découvert dans la chaîne, le nom de volume sera constitué de la chaîne format suffixée du nombre de volumes dans le pool plus un, au format 4 chiffres et avec des zéros en tête. Par exemple, avec Label Format = ''File-``, les volumes seront nommés File-0001, File-0002, ...

Exception faite des variables spécifiques aux jobs, vous pouvez tester votre LabelFormat en utilisant la section var command du chapitre Console de ce manuel.

Dans la plupart des cas, vous devriez encadrer la spécification de format (la partie à droite du signe égale) entre guillemets. Notez que cette directive est obsolète et qu'elle est remplacée, à partir de la version 1.37 par un script Python pour la création des noms de volumes.

Pour qu'un pool puisse être utilisé lors d'une sauvegarde, il faut qu'il lui soit associé au moins un volume. Les volumes sont créés et affectés aux pools avec les commandes label ou add du programme Bacula Console. Outre l'affectation du volume au pool (c'est à dire son référencement dans le catalogue), le volume physique doit recevoir une étiquette logicielle valide pour que Bacula l'accepte. Ceci peut être réalisé automatiquement grâce à la commande label. D'autre part, Bacula peut effectuer cette opération automatiquement si l'instruction lui en est donné, mais cette fonctionnalité n'est pas encore pleinement implémentée.

Voici un exemple d'une définition de ressource Pool valide : 

 
Pool {
  Name = Default
  Pool Type = Backup
}

Le Scratch Pool

En général, vous pouvez nommer vos pool à votre guise, il existe cependant une importante restriction : le pool nommé Scratch, s'il existe, se comporte comme une réserve de volumes où Bacula pourra puiser s'il ne trouve aucun volume utilisable dans le pool normalement utilisé par le job. Le volume est alors déplacé du pool Scratch vers le pool en défaut.


La ressource Catalog

La ressource Catalog précise quel catalogue utiliser pour le job courant. Actuellement, Bacula ne peut utiliser qu'un type de serveur de bases de données défini lors de sa configuration : SQLite, MySQL, PostgreSQL. En revanche, vous pouvez utiliser autant de catalogues que vous le souhaitez. Par exemple, vous pouvez avoir un catalogue par client, ou encore un catalogue pour les sauvegardes, un autre pour les jobs de type Verify et un troisième pour les restaurations.

Catalog
Début de la ressource Catalog. Il faut au moins une ressource Catalogue.

Name = <name>
Le nom du Catalog. Il n'a pas besoin d'être en relation avec le nom sur le serveur de base de données. Ce nom sera repris dans la ressource Client, indiquant ainsi que toutes les données relatives à ce client sont maintenues dans ce catalogue. Cette directive est requise.*

password = <password>
Cette directive spécifie le mot de passe à utiliser pour se connecter au catalogue. Cette directive est requise.

DB Name = <name>
Cette directive spécifie le nom de la base de données. Si vous utilisez plusieurs catalogues, vous spécifiez lequel ici. Si vous utilisez un serveur de bases de données externe plutôt que l'intégré, vous devez spécifier un nom connu du serveur (autrement dit, le nom que vous avez utilisé lorsque vous avez créé les tables Bacula.). Cette directive est requise.

user = <user>
L'utilisateur habilité à se connecter au catalogue. Cette directive est requise.

DB Socket = <socket-name>
Il s'agit du nom d'un socket à utiliser sur la machine locale pour se connecter au catalogue. Cette directive n'est utilisée que par MySQL, elle est ignorée par SQLite. Normalement, si ni DB Socket, ni DB Address ne sont spécifiées, MySQL utilise le socket par défaut.

DB Address = <address>
Il s'agit de l'adresse du serveur de bases de données. En principe, vous utiliserez cette directive plutôt que DB Socket si le serveur de bases de données est une autre machine. Dans ce cas, vous spécifierez aussi le port DB Port. Cette directive n'est utilisée que par MySQL, et ignorée par SQLite. Elle est optionnelle.

DB Port = <port>
Cette directive définit le port à utiliser en conjonction avec DB Address pour accéder au catalogue s'il est hébergé sur une autre machine. Elle n'est utilisée que par MySQL, et ignorée par SQLite. Elle est optionnelle.

Voici un exemple d'une définition de ressource Catalog valide : 

Catalog
{
  Name = SQLite
  dbname = bacula;
  user = bacula;
  password = ""                       # no password = no security
}

en voici une deuxième pour un catalogue sur une autre machine : 

Catalog
{
  Name = MySQL
  dbname = bacula
  user = bacula
  password = ""
  DB Address = remote.acme.com
  DB Port = 1234
}


La ressource Messages

Pour les détails sur la ressource Messages, veuillez consulter le chapitre La ressource Messages de ce manuel.


La ressource Console

A partir de la version 1.33 de Bacula, l'administrateur dispose de trois sortes de consoles différentes pour interagir avec le Director. Ces trois types de consoles comportent trois niveaux de sécurité différents.

La ressource Console est optionnelle. Les directives suivantes sont permises dans le fichier de configuration du Director.

Name = <name>
Le nom de la console. Ce nom doit être en conjonction avec celui spécifié dans le fichier de configuration de la Console (comme c'est le cas pour les définitions de clients).

Password = <password>
Spécifie le mot de passe qu'une console nommée doit fournir pour être autorisée. Le même mot de passe doit apparaître dans la ressource Console du fichier de configuration de la Console. Pour plus de sécurité, le mot de passe n'est jamais réellement transmis à travers le réseau, mais plutôt un code de hachage de type challenge response créé à partir du mot de passe. Cette directive est requise. Si vous disposez de /dev/random ou bc sur votre machine, Bacula génèrera aléatoirement ce mot de passe lors du processus de configuration, autrement, il sera laissé blanc.

JobACL = <name-list>
Cette directive est utilisée pour spécifier une liste de noms de ressources Job qui peuvent être accédés par la console. Sans cette directive, la console ne peut accéder à aucune des ressources Job définies dans le fichier de configuration du Director. Plusieurs ressources Job peuvent être spécifiées en les séparant par des virgules, et/ou en spécifiant plusieurs directives JobACL. Par exemple, la directive peut être spécifiée ainsi : 

    JobACL = kernsave, "Backup client 1", "Backup client 2"
    JobACL = "RestoreFiles"

Avec cette spécificaton, la console peut accéder aux ressources du Director pour les quatre jobs désignés par la directive JobACL, et uniquement à eux.

ClientACL = <name-list>
Cette directive est utilisée pour spécifier une liste de noms de ressources Client iaccessibles par la console.

StorageACL = <name-list>
Cette directive est utilisée pour spécifier une liste de noms de ressources Storage accessibles par la console.

ScheduleACL = <name-list>
Cette directive est utilisée pour spécifier une liste de noms de ressources Schedule accessibles par la console.

PoolACL = <name-list>
Cette directive est utilisée pour spécifier une liste de noms de ressources Pool accesibles ar la console.

FileSetACL = <name-list>
Cette directive est utilisée pour spécifier une liste de noms de ressources FileSet accessibles par la console.

CatalogACL = <name-list>
Cette directive est utilisée pour spécifier une liste de noms de ressources Catalog accessibles par la console.

CommandACL = <name-list>
Cette directive est utilisée pour spécifier une liste de commandes de la console qui peuvent être exécutées par la console.

En plus des différents noms de ressources du Director et de commandes, le mot-clef spécial *all* peut être spécifié dans chacune des directives ACL ci-dessus. Sa présence signifie que toute ressource ou commande (pourvu qu'elle soit appropriée à la directive) est acceptée. Pour un exemple de fichier de configuration, voyez le chapitre Configuration de la console de ce manuel


La ressource Counter

La ressource Counter définit une variable-compteur qui peut être accédée par le processus d'expansion de variables utilisé pour la création de d'étiquettes (labels) de volumes avec la directive LabelFormat. Consultez le paragraphe sur la directive LabelFormat de ce chapitre pour plus de détails.

Counter
Début de la ressource Counter. les directives Counter sont optionnelles.

Name = <name>
iLe nom de la variable-compteur. Il s'agit du nom que vous utiliserez pour vous référer à cette variable et accéder à sa valeur.

Minimum = <integer>
Spécifie la valeur minimale de la variable-compteur. Cette valeur devient celle par défaut. Si elle n'est pas fournie, sa valeur est zéro.

Maximum = <integer>
Spécifie la valeur maximale de la variable-compteur. Si elle n'est pas fournie, ou si elles est réglée à zéro, la variable compteur peut prendre une valeur maximale de 2 147 483 648 ($2^{31}$). Au delà de cette valeur, le compteur est remis au minimum.

*WrapCounter = <counter-name>
Si cette valeur est spécifiée, lorsque la variable-compteur dépasse le maximum et est remise au minimum, le compteur spécifié par la directive WrapCounter est incrémenté. (Ceci n'est, pour le moment, pas implémenté.)

Catalog = <catalog-name>
Si cette directive est spécifiée, le compteur et sa valeur sont sauvegardés dans le catalogue spécifié. Dans le cas contraire, le compteur est redéfini à chaque démarrage de Bacula.


Voici un exemple complet de fichier de configuration du Director.

Un exemple de fichier de configuration du Director pourrait être le suivant : 

#
# Default Bacula Director Configuration file
#
#  The only thing that MUST be changed is to add one or more
#   file or directory names in the Include directive of the
#   FileSet resource.
#
#  For Bacula release 1.15 (5 March 2002) -- redhat
#
#  You might also want to change the default email address
#   from root to your address.  See the "mail" and "operator"
#   directives in the Messages resource.
#
Director {                            # define myself
  Name = rufus-dir
  QueryFile = "/home/kern/bacula/bin/query.sql"
  WorkingDirectory = "/home/kern/bacula/bin/working"
  PidDirectory = "/home/kern/bacula/bin/working"
  Password = "XkSfzu/Cf/wX4L8Zh4G4/yhCbpLcz3YVdmVoQvU3EyF/"
}
# Define the backup Job
Job {
  Name = "NightlySave"
  Type = Backup
  Level = Incremental                 # default
  Client=rufus-fd
  FileSet="Full Set"
  Schedule = "WeeklyCycle"
  Storage = DLTDrive
  Messages = Standard
  Pool = Default
}
Job {
  Name = "Restore"
  Type = Restore
  Client=rufus-fd
  FileSet="Full Set"
  Where = /tmp/bacula-restores
  Storage = DLTDrive
  Messages = Standard
  Pool = Default
}
   
# List of files to be backed up
FileSet {
  Name = "Full Set"
  Include {
    Options { signature=SHA1 }
#
#  Put your list of files here, one per line or include an
#    external list with:
#
#    @file-name
#
#  Note: / backs up everything
  File = /
  }
  Exclude { }
}
# When to do the backups
Schedule {
  Name = "WeeklyCycle"
  Run = Full sun at 1:05
  Run = Incremental mon-sat at 1:05
}
# Client (File Services) to backup
Client {
  Name = rufus-fd
  Address = rufus
  Catalog = MyCatalog
  Password = "MQk6lVinz4GG2hdIZk1dsKE/LxMZGo6znMHiD7t7vzF+"
  File Retention = 60d      # sixty day file retention
  Job Retention = 1y        # 1 year Job retention
  AutoPrune = yes           # Auto apply retention periods
}
# Definition of DLT tape storage device
Storage {
  Name = DLTDrive
  Address = rufus
  Password = "jMeWZvfikUHvt3kzKVVPpQ0ccmV6emPnF2cPYFdhLApQ"
  Device = "HP DLT 80"      # same as Device in Storage daemon
  Media Type = DLT8000      # same as MediaType in Storage daemon
}
# Definition for a DLT autochanger device
Storage {
  Name = Autochanger
  Address = rufus
  Password = "jMeWZvfikUHvt3kzKVVPpQ0ccmV6emPnF2cPYFdhLApQ"
  Device = "Autochanger"    # same as Device in Storage daemon
  Media Type = DLT-8000     # Different from DLTDrive
  Autochanger = yes
}
# Definition of DDS tape storage device
Storage {
  Name = SDT-10000
  Address = rufus
  Password = "jMeWZvfikUHvt3kzKVVPpQ0ccmV6emPnF2cPYFdhLApQ"
  Device = SDT-10000        # same as Device in Storage daemon
  Media Type = DDS-4        # same as MediaType in Storage daemon
}
# Definition of 8mm tape storage device
Storage {
  Name = "8mmDrive"
  Address = rufus
  Password = "jMeWZvfikUHvt3kzKVVPpQ0ccmV6emPnF2cPYFdhLApQ"
  Device = "Exabyte 8mm"
  MediaType = "8mm"
}
# Definition of file storage device
Storage {
  Name = File
  Address = rufus
  Password = "jMeWZvfikUHvt3kzKVVPpQ0ccmV6emPnF2cPYFdhLApQ"
  Device = FileStorage
  Media Type = File
}
# Generic catalog service
Catalog {
  Name = MyCatalog
  dbname = bacula; user = bacula; password = ""
}
# Reasonable message delivery -- send most everything to
#   the email address and to the console
Messages {
  Name = Standard
  mail = root@localhost = all, !skipped, !terminate
  operator = root@localhost = mount
  console = all, !skipped, !saved
}
    
# Default pool definition
Pool {
  Name = Default
  Pool Type = Backup
  AutoPrune = yes
  Recycle = yes
}
#
# Restricted console used by tray-monitor to get the status of the director
#
Console {
  Name = Monitor
  Password = "GN0uRo7PTUmlMbqrJ2Gr1p0fk0HQJTxwnFyE4WSST3MWZseR"
  CommandACL = status, .status
}

next up previous contents index
suivant: Configuration du Client/File Daemon monter: Adapter les fichiers de précédent: Informations détaillées sur chaque   Table des matières   Index
Kern Sibbald 2007-11-03