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) :

Director -- Pour définir le nom du Director et son mot de passe pour l'authentification du programme Console. Il ne doit y avoir qu'une seule définition de ressource Director dans le fichier de configuration. 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, sinon, il sera laissé blanc.
Job -- Pour définir les Jobs de types sauvegarde et restauration, et pour lier les ressources Client, FileSet et Schedules à utiliser conjointement pour chaque Job.
JobDefs -- Ressource optionnelle destinée à fournir des valeurs par défaut pour les ressources Job.
Schedule -- Pour définir le moment où un Job doit être lancé automatiquement par le scheduler interne de Bacula.
FileSet -- Pour définir l'ensemble des fichiers à sauvegarder pour chaque client.
Client -- Pour définir quel Client est à sauvegarder.
Storage -- Pour définir sur quel périphérique physique les volumes seront montés.
Pool -- Pour définir quel le pool de volumes qui peut être utilisé pour un Job donné
Catalog -- Pour définir la base de données où conserver les listes des fichiers sauvegardés et des volumes où ils ont été sauvegardés.
Messages -- Pour définir les destinataires (ou les fichiers de logs) des messages d'erreur et d'information.

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.

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 :

OK
Error
Fatal Error
Canceled
Differences
Unknown term code

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 :

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.
Le fichier batch devrait retourner explicitement 0 lors des exécutions correctes.
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 :

Pour exécuter plusieurs jobs simultanés, vous devez ajuster la directive Maximum Concurrent Jobs (utiliser une valeur supérieure á 1) en cinq ou six endroits différents : dans le fichier bacula-dir.conf, les ressources Job, Client, Storage; dans le fichier bacula-fd, la ressource FileDaemon; et dans le fichier bacula-sd.conf, la ressource Storage. Si vous omettez l'un d'entre eux, les jobs seront exécutés un par un.
Bacula n'exécute pas simultanément les jobs de priorités distinctes.
Si Bacula exécute un job de priorité 2 et si un nouveau job de priorité 1 est programmé, il attendra la fin du job de priorité 1, même si les paramètres Maximum Concurrent Jobs pourraient permettre l'exécution simultanée de deux jobs.
Supposons que Bacula soit en train d'exécuter un job de priorité 2 et qu'un job de priorité 1 soit programmé et mis en queue en attente de la fin du job de priorité 2. Si vous démarrez alors un second job de priorité 2, le job en attente de priorité 1 empèchera le nouveau job de priorité 2 de s'exécuter en parallèle au premier. Ainsi : tant qu'il reste un job de priorité supérieure à exécuter, aucun nouveau job de priorité inférieure ne pourra démarrer, même si les paramètres Maximum Concurrent Jobs devraient le permettre. Ceci permet d'assurer que les jobs de priorité supérieure seront exécutés dès que possible.

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 :

il n'y a pas de signe égale (=) après le "include" et avant l'accolade ouvrante ({) ;
chaque répertoire (ou nom de fichier) à sauvegarder est précédé de "File =" ;
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 :

Tout nom précédé d'un signe "at" (@) est compris comme le nom d'un fichier, lequel contient une liste de fichiers, chacun précédé d'une directive "File=". Ce fichier est lu lorsque le fichier de configuration est parcouru au démarrage du Director. Notez bien que le fichier est lu sur sur la machine qui héberge le Director (autrement dit, le serveur de sauvegardes) et non sur le Client. En fait, le "@NomDeFichier" peut apparaître n'importe où dans le fichier de configuration où un objet pourrait être lu, le contenu du fichier désigné sera logiquement inséré à l'emplacement du "@NomDeFichier". Ce qui doit figurer dans le fichier dépend de l'emplacement du "@NomDeFichier" au sein du fichier de configuration.
Tout nom précédé d'une barre verticale (|) est compris comme le nom d'un programme. Ce programme sera exécuté sur la machine qui héberge le Director au moment où le job démarre (et non lorsque le Director lit son fichier de configuration), et toute sortie de ce programme sera perçu en tant que liste de fichiers ou répertoires, un par ligne, à inclure. Ceci vous permet d'avoir un job qui, par exemple, inclue toutes les partitions locales même si vous changez le partitionnement en ajoutant des disques. En général, il vous faudra précéder votre commande d'un "sh -c" afin qu'elle soit invoquée par un shell. Ce ne sera pas le cas si vous invoquez un script comme dans le second exemple ci-dessous. Vous devez aussi prendre soin d'échapper (précéder d'un \) les caractères jokers, les caractères du shell, ainsi que toute espace dans votre commande. Si vous utilisez des simples quotes (') dans des doubles quotes (``), Bacula traitera tout ce qui est entre simples quotes comme un seul champ, et il ne dera donc pas nécessaire d'échapper les espaces. En général, parvenir à avoir toutes les quotes et échappements corrects est un calvaire, comme vous pouvez le constater dans le prochain exemple. Par conséquent, il est souvent plus facile de tout mettre dans un fichier et d'utiliser simplement le nom de fichier dans Bacula. Dans ce cas le "sh -c" ne sera plus nécessaire, pourvu que la première ligne du fichier soit #!/bin/sh.
Par exemple :
```
 
Include {
   Options { signature = SHA1 }
   File = "|sh -c 'df -l | grep \"^/dev/hd[ab]\" | grep -v \".*/tmp\" \
      | awk \"{print \\$6}\"'"
}
```
produira une liste de toutes les partitions locales sur un système RedHat Linux. Notez que la ligne si dessus a été coupée, mais devrait normalement être écrite sur une seule ligne. Quoter est un réel problème car vous devez d'une part le faire pour Bacula - ce qui consiste à précéder tout \ et tout '' avec un \ - et d'autre part pour les commandes shell. En définitive, il est probablement plus aisé d'exécuter un petit fichier tel que :
```
Include {
  Options {
    signature=MD5
  }
  File = "|my_partitions"
}
```
où le fichier my_partitions contient :
```
#!/bin/sh
df -l | grep "^/dev/hd[ab]" | grep -v ".*/tmp" \
      | awk "{print \$6}"
```
Si la barre verticale (|) devant "my_partitions" est précédée d'une barre oblique (\), le programme sera exécuté sur la machine cliente plutôt que sur la machine hébergeant le Director -- (ceci est implémenté, mais n'est pas complètement testé, et a été rapporté fonctionner sous Windows). Veuillez noter que si le nom de fichier est donné entre quotes, vous devrez utiliser deux barres obliques. Voci un exemple, fourni par John Donagher, qui sauvegarde toutes les partitions UFS locales sur un système distant :
```
FileSet {
  Name = "All local partitions"
  Include {
    Options { signature=SHA1; onefs=yes; }
    File = "\\|bash -c \"df -klF ufs | tail +2 | awk '{print \$6}'\""
  }
}
```
Notez que deux barres obliques \ sont requises après les doubles quotes (l'une préserve l'autre). Si vous utilisez Linux, changez simplement ufs en ext3 (ou votre système de fichiers préféré) et l'affaire sera dans le sac.
Tout élément de la liste de fichiers file-list précédé par un signe "inférieur" (<) est interprété comme un fichier qui sera lu sur la machine qui héberge le Director au moment où le job démarre. Son contenu est supposé être une liste de répertoires ou fichiers, un par ligne, à inclure dans la sauvegarde. Les noms ne doivent pas être quotés, même s'ils comportent des espaces. Cette fonction vous permet de modifier le fichier externe, et ainsi ce qui est sauvegardé sans avoir à redémarrer Bacula comme il le faudrait avec le modificateur @ décrit plus haut.
Si vous précédez le signe "inférieur" (<) d'une barre oblique \<, le fichier mentionné sera lu sur la machine cliente au lieu de celle hébergeant le Director. Veullez noter que si le nom de fichier est donné entre quotes, il vous faudra utiliser deux barres obliques.
Si vous spécifiez explicitement un block device (NDT ?) tel que /dev/hda1, alors Bacula considèrera ceci comme une partition raw à sauvegarder. Dans ce cas, vous êtes fortement invité à utiliser l'option sparse=yes, faute de quoi vous sauvegarderez la partition entière plutôt que seulement les données réellement contenues dans la partition. Par exemple :
```
Include {
  Options { signature=MD5; sparse=yes }
  File = /dev/hd6
}
```
va sauvegarder les données de la partition /dev/hd6.
will backup the data in device /dev/hd6.
Ludovic Strappazon a fait remarquer que cette fonction pouvait servir à sauvegarder un disque Microsoft Windows. Il suffit de booter avec un Linux Rescue Disk, puis de charger un client Bacula statiquement lié comme décrit dans le chapitre Disaster Recovery avec Bacula de ce manuel. Sauvegardez alors la partition complète. En cas de désastre, vous pouvez alors restaurer la partition désirée en bootant une fois encore sur le Linux Rescue Disk et en utilisant le client Bacula statiquement lié.
Si vous spécifiez explicitement un périphérique FIFO nommé (créé avec mkfifo), ets si vous ajoutez l'option readfifo=yes, Bacula lira le FIFO et sauvegardera ses données sur le volume. Par exemple :
```
Include {
  Options {
    signature=SHA1
    readfifo=yes
  }
  File = /home/abc/fifo
}
```
si /home/abc/fifo est un FIFO, Bacula va l'ouvrir, le lire, et stocker toutes les données ainsi obtenues sur le volume. Notez qu'il faut que vous ayez un processus qui écrit sur le FIFO, faute de quoi Bacula restera en suspens, et abandonnera au bout d'une minute pour passer au fichier suivant. Les données lues peuvent être de nature quelconque puisque Bacula les traite comme un flux.
Cette fonction est un excellent moyen de faire une sauvegarde "à chaud" d'une très grosse base de données. Vous pouvez utiliser la directive RunBeforeJob pour créer le FIFO et démarrer un programme qui lit dynamiquement votre base de données et l'écrit sur le FIFO. Bacula l'écrira alors sur le volume.
Lors de l'opération de restauration, l'inverse se produit : après que Bacula ait créé le FIFO, s'il y avait des données stockées par son biais (inutile de les lister explicitement ni d'ajouter aucune option), elles seront renvoyées vers le FIFO. Par conséquent, s'il existe un tel FIFO à restaurer, vous devez vous assurer qu'il y a un programme lecteur ou Bacula se bloquera et passera au fichier suivant après une minute.

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

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

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