Mises a jour.

[bacula/docs] / docs / manual-fr / dirdconf.tex

%%
%%

\section*{Configurer le Director}
\label{_ChapterStart40}
\index[general]{Director!Configurer le}
\index[general]{Configurer le Director}
\addcontentsline{toc}{section}{Configurer le Director}

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

Pour une discussion g\'en\'erale concernant les fichiers et ressources ainsi
que les types de donn\'ees reconnus par {\bf Bacula}, veuillez consulter le
chapitre 
\ilink{Configuration}{_ChapterStart16} de ce manuel. 

\subsection*{Les types de ressources du Director}
\index[general]{Les types de ressources du Director}
\index[general]{Director!Les types de ressources du}
\addcontentsline{toc}{subsection}{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\'esentons ici dans l'ordre le plus logique (relativement
au fichier de configuration du Director) : 

\begin{itemize}
\item 
   \ilink{Director}{DirectorResource4} -- Pour d\'efinir le nom du
   Director et son  mot de passe pour l'authentification du programme Console. Il
   ne doit y avoir qu'une seule  d\'efinition de ressource Director dans le
   fichier de configuration.  Si vous avez soit {\bf /dev/random} soit {\bf bc}
   sur votre machine, Bacula g\'en\`erera  un mot de passe al\'eatoire lors du
   processus de configuration, sinon, il sera laiss\'e blanc. 
\item 
   \ilink{Job}{JobResource} -- Pour d\'efinir les Jobs de types
   sauvegarde et restauration,  et pour lier les ressources Client, FileSet et
Schedules \`a utiliser conjointement pour chaque Job. 
\item 
   \ilink{JobDefs}{JobDefsResource} -- Ressource optionnelle destin\'ee \`a
   fournir des valeurs par d\'efaut  pour les ressources Job. 
\item 
   \ilink{Schedule}{ScheduleResource} -- Pour d\'efinir le moment
   o\`u un Job doit \^etre lanc\'e  automatiquement par le {\it scheduler}
interne de Bacula. 
\item 
   \ilink{FileSet}{FileSetResource} -- Pour d\'efinir l'ensemble des
   fichiers \`a sauvegarder  pour chaque client. 
\item 
   \ilink{Client}{ClientResource2} -- Pour d\'efinir quel Client est
   \`a sauvegarder. 
\item 
   \ilink{Storage}{StorageResource2} -- Pour d\'efinir sur quel
   p\'eriph\'erique physique les  volumes seront mont\'es.  
\item 
   \ilink{Pool}{PoolResource} -- Pour d\'efinir quel le pool de volumes
   qui peut \^etre  utilis\'e pour un Job donn\'e 
\item 
   \ilink{Catalog}{CatalogResource} -- Pour d\'efinir la base de
   donn\'ees o\`u conserver les listes  des fichiers sauvegard\'es et des volumes
o\`u ils ont \'et\'e sauvegard\'es.  
\item 
   \ilink{Messages}{_ChapterStart15} -- Pour d\'efinir les
   destinataires (ou les fichiers de logs) des messages d'erreur et 
d'information.  
\end{itemize}
 
\subsection*{La ressource Director}
\label{DirectorResource4}
\index[general]{Director!La ressource}
\index[general]{La ressource Director}
\addcontentsline{toc}{subsection}{La ressource Director}

La ressource Director d\'efinit les attributs du Director ex\'ecut\'e sur le
r\'eseau. Dans l'impl\'ementation actuelle, il n'y a qu'une ressource
Director, mais la r\'ealisation finale contiendra plusieurs Directors pour
maintenir la redondance de la base des indexes et m\'edia. 

\begin{description}

\item [Director]
   \index[dir]{Director}
   D\'ebut de la ressource Director. Une ressource Director et une seule doit
\^etre d\'efinie. 
 
\item [Name = \lt{}nom\gt{}]
   \index[dir]{Name}
   \index[dir]{Directive!Name}
   Le nom du Director utilis\'e par l'administrateur syst\`eme. Cette directive
est requise  
  
\item [Description = \lt{ }texte\gt{}]
   \index[dir]{Description}
   \index[dir]{Directive!Description}
   Le champ texte contient une description du Director qui sera affich\'ee  dans
l'interface graphique. Cette directive est optionnelle.  
 
\item [Password = \lt{}UA-password\gt{}]
   \index[dir]{Password}
   \index[dir]{Directive!Password}
   Sp\'ecifie le mot de passe qui doit \^etre fourni par la Console Bacula par
d\'efaut  pour \^etre autoris\'ee. Le m\^eme mot de passe doit appara{\^\i}tre
dans la ressource {\bf Director} du fichier de  configuration de la console.
Pour plus de s\'ecurit\'e, le mot de passe ne transite jamais sur le r\'eseau,
l'authentification se fait via un \'echange de type {\it challenge-response}
d'un {\it hash code} cr\'e\'e avec le mot  de passe. Cette directive est
requise. Si vous disposez de {\bf /dev/random} ou {\bf bc} sur votre machine,
Bacula  g\'en\`erera un mot de passe al\'eatoire lors du processus
d'installation, sinon il sera laiss\'e blanc et vous devrez en d\'efinir  un
manuellement.  
 
\item [Messages = \lt{}Nom-de-ressource-Messages\gt{}]
   \index[dir]{Messages}
   \index[dir]{Directive!Messages}
   La ressource {\bf messages} sp\'ecifie o\`u doivent \^etre d\'elivr\'es les messages du Director 
 qui ne sont pas associ\'es \`a un job sp\'ecifique. La plupart des messages sont relatifs
 \`a un job et seront dirig\'es vers la ressource {\bf messages} sp\'ecifi\'ee par le job. 
 Cependant, quelques messages peuvent \^etre g\'en\'er\'es lorsque aucun job n'est actif. 
 Cette directive est requise.

\item [Working Directory = \lt{}R\'epertoire\gt{}]
   \index[dir]{Working Directory}
   \index[dir]{Directive!Working Directory}
   Cette directive sp\'ecifie un r\'epertoire o\`u le Director peut d\'eposer ses fichiers 
   d'\'etats. Ce r\'epertoire ne devrait \^etre utilis\'e que par Bacula, mais il peut \^etre 
   partag\'e par d'autres {\it daemons} Bacula. Notez cependant que si ce r\'epertoire est 
   partag\'e avec d'autres daemons Bacula, vous devez vous assurer que le nom {\bf Name} 
   donn\'e \`a chaque daemon est unique afin d'\'eviter des collisions entre les fichiers 
   temporaires utilis\'es. Par d\'efaut, le processus de configuration de Bacula cr\'e\'e des noms 
   de daemons uniques en les postfixant avec -dir, -fd et -sd.
   Les substitutions shell standard sont effectu\'ees \`a la lecture du fichier de 
   configuration, de sorte que des valeurs telles que {\bf \$HOME} seront correctement 
   substitu\'ees. Cette directive est requise.

   Si vous avez sp\'ecifi\'e un utilisateur et/ou un groupe pour le Director lors de la 
   configuration avec les options {\bf {-}{-}with-dir-user} et/ou {\bf {-}{-}with-dir-group} de 
   la commande ./configure, le r\'epertoire de travail Working Directory doit appartenir 
   doit appartenir \`a ce groupe et \`a cet utilisateur.

\item [Pid Directory = \lt{}R\'epertoire\gt{}]
   \index[dir]{Pid Directory}
   \index[dir]{Directive!Pid Directory}
    Cette directive sp\'ecifie un r\'epertoire o\`u le Director peut d\'eposer son fichier
d'Id de processus. Ce fichier est utilis\'e pour stopper Bacula et pr\'evenir l'ex\'ecution 
simultan\'ee de plusieurs copies de Bacula. Les substitutions shell standard sont
effectu\'ees \`a la lecture du fichier de configuration, de sorte que des valeurs
telles que {\bf \$HOME} seront correctement substitu\'ees.

Typiquement, sur les syst\`emes Linux, vous utiliserez ici {\bf /var/run}. Si vous 
n'installez pas Bacula dans les r\'epertoires syst\`eme, vous pouvez utiliser le 
r\'epertoire de travail {\bf Working Directory} d\'efini plus haut.
Cette directive est requise.

\item [Scripts Directory = \lt{}Directory\gt{}]
    \index[dir]{Scripts Directory}
    \index[dir]{Directive!Scripts Directory}
    Cette directive sp\'ecifie le r\'epertoire dans lequel le Director devra rechercher 
    le script Python de d\'emarrage {\bf DirStartup.py}. Ce r\'epertoire peut \^etre 
    partag\'e par d'autres daemons Bacula.Les substitutions shell standard sont effectu\'ees 
    \`a la lecture du fichier de configuration, de sorte que des valeurs telles que 
    {\bf \$HOME} seront correctement substitu\'ees. Cette directive est optionnelle.

\item [QueryFile = \lt{}Path\gt{}]
   \index[dir]{QueryFile}
   \index[dir]{Directive!QueryFile}
    Cette directive sp\'ecifie un r\'epertoire et un fichier dans lequel le 
Director peut trouver les requ\^etes SQL pr\'e\'etablies pour la commande 
{\bf Query} de la Console. Les substitutions shell standard sont
effectu\'ees \`a la lecture du fichier de configuration, de sorte que des valeurs
telles que {\bf \$HOME} seront correctement substitu\'ees. 
Cette directive est requise.

\label{DirMaxConJobs}

\item [Maximum Concurrent Jobs = \lt{}nombre\gt{}]
   \index[dir]{Maximum Concurrent Jobs}
   \index[dir]{Directive!Maximum Concurrent Jobs}
   \index[general]{Jobs Simultan\'es}
   \index[general]{Jobs Concurrents}
   
   O\`u \lt{}nombre\gt{} est le nombre maximal de jobs qui peuvent \^etre ex\'ecut\'es 
simultan\'ement par le Director. La valeur par d\'efaut est 1, mais vous pouvez utiliser 
une valeur plus grande.
Notez que le format des volumes devient beaucoup plus compliqu\'e avec plusieurs jobs 
ex\'ecut\'es simultan\'ement. De ce fait, les restaurations peuvent prendre beaucoup plus 
de temps si Bacula doit faire le tri parmi les segments entrem\'el\'es de ces jobs. Ceci 
peut \^etre \'evit\'e en s'arrangeant pour que chacun des jobs ex\'ecut\'es simultan\'ement 
\'ecrive sur un volume distinct. Une autre possibilit\'e consiste \`a utiliser le 
{\it data spooling} : les donn\'ees seront d'abord "spool\'ees" sur disque 
simultan\'ement, ensuite les fichiers "spool" seront \'ecrits s\'equentiellement 
sur le volume.   

Dans certains cas, des directives telles que {\bf Maximum Volume Jobs} ne sont pas 
correctement synchronis\'ees avec le nombre de jobs simultan\'es, et des probl\`emes 
de synchronisation subtils peuvent survenir, aussi des tests minutieux sont recommand\'es.

Actuellement, il n'y a aucun param\`etre de configuration pour r\'egler ou limiter 
le nombre de connections par console. Un maximum de cinq connection simultan\'ees 
est autoris\'e.

Pour plus de d\'etails concernant l'ex\'ecution simultan\'ee de plusieurs jobs, consultez la 
partie \ilink{Ex\'ecution simultan\'ee de plusieurs jobs}{ConcurrentJobs} du chapitre Astuces de ce manuel.


\item [FD Connect Timeout = \lt{}dur\'ee\gt{}]
   \index[dir]{FD Connect Timeout}
   \index[dir]{Directive!FD Connect Timeout}
   O\`u {\bf dur\'ee} est le d\'elai durant lequel le Director tente de contacter 
   le File Daemon pour d\'emarrer un job. Une fois ce d\'elai \'ecoul\'e, le Director supprimera le job.
   La valeur par d\'efaut est 30 minutes.
   
\item [SD Connect Timeout = \lt{}dur\'ee\gt{}]
   \index[dir]{SD Connect Timeout}
   \index[dir]{Directive!SD Connect Timeout}
   O\`u {\bf dur\'ee} est le d\'elai durant lequel le Director tente de contacter 
   le Storage Daemon pour d\'emarrer un job. Une fois ce d\'elai \'ecoul\'e, le Director supprimera le job.
   La valeur par d\'efaut est 30 minutes.

\item [DirAddresses = \lt{}Sp\'ecification-adresses-IP\gt{}]
   \index[dir]{DirAddresses}
   \index[dir]{Directive!DirAddresses}
   Sp\'ecifie 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 :

\footnotesize
\begin{verbatim}
 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
    }
 }
\end{verbatim}
\normalsize

o\`u "ip", "ip4", "ip6", "addr", et "port sont les mots clef. Notez que 
les adresses peuvent \^etre sp\'ecifi\'ees sous forme de quadruplets point\'es, ou 
suivant la notation \`a doubles points IPv6, ou encore sous forme de nom symbolique 
(seulement pour la sp\'ecification ip). D'autre part, le port peut \^etre sp\'ecifi\'e 
par un nombre, ou par une valeur mn\'emonique du fichier /etc/services. Si un port 
n'est pas pr\'ecis\'e, celui par d\'efaut sera utilis\'e. Si une section ip est sp\'ecifi\'ee, 
la r\'esolution peut \^etre faite soit par IPv4, soit par IPv6. Si ip4 est sp\'ecifi\'e, 
seules les r\'esolutions IPv4 seront permises. Il en va de m\^eme 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\^eme ressource.

\item [DIRport = \lt{}num\'ero-de-port\gt{}]
   \index[dir]{DIRport}
   \index[dir]{Directive!DIRport}
   Sp\'ecifie le port (un entier positif) sur lequel le Director est \`a l'\'ecoute 
de connections de Consoles Bacula. Ce m\^eme num\'ero de port doit \^etre sp\'ecifi\'e 
dans la ressource Director du fichier de configuration de la console. La 
valeur par d\'efaut est 9101, aussi, il n'est en principe pas n\'ecessaire 
de renseigner cette directive. Elle n'est pas requise si vous sp\'ecifiez des 
DirAdresses.

\item [DirAddress = \lt{}Adresse-IP\gt{}]
   \index[dir]{DirAddress}
   \index[dir]{Directive!DirAddress}
   Cette directive est optionnelle. Lorsqu'elle est sp\'ecifi\'ee, le Director n'accepte 
de connections Console que de l'adresse sp\'ecifi\'ee {\bf Adresse-IP}, qui peut \^etre 
soit un nom de domaine, soit une adresse IP au format quadruplet point\'e ou cha\^ine quot\'ee.  
Si cette directive n'est pas sp\'ecifi\'ee, le Director acceptera des connections de Console 
de toute adresse valide. Notez que contrairement \`a la sp\'ecification DirAdresses d\'ecrite 
plus haut, cette directive ne permet de sp\'ecifier qu'une seule adresse. Cette directive 
n'est pas requise si vous utilisez la directive DirAdresses.

\end{description}

Voici un exemple d'une ressource Director valide :

\footnotesize
\begin{verbatim}
Director {
  Name = HeadMan
  WorkingDirectory = "$HOME/bacula/bin/working"
  Password = UA_password
  PidDirectory = "$HOME/bacula/bin/working"
  QueryFile = "$HOME/bacula/bin/query.sql"
  Messages = Standard
}
\end{verbatim}
\normalsize

\subsection*{La ressource Job}
\label{JobResource}
\index[general]{Resource!Job }
\index[general]{Job Resource }
\addcontentsline{toc}{subsection}{Job Resource}

La ressource Job d\'efinit un Job (sauvegarde, restauration,...) que Bacula doit 
ex\'ecuter. Chaque d\'efinition de ressource Job contient le nom d'un client, la 
liste des \'el\'ements \`a sauvegarder (FileSet), la planification (Schedule) pour 
ce Job, le lieu o\`u sauvegarder ces donn\'ees (Storage Device) et quel groupe de 
media utiliser (Pool). En effet, chaque ressource Job doit r\'epondre aux questions : 
"Quoi ?", "O\`u ?", "Quand ?" et "Comment ?" soit, respectivement Fileset, Storage, 
Schedule, Type et Niveau (Sauvegarde/Restauration - Full/Differentielle/Incr\'ementale).
Notez que le FileSet doit \^etre sp\'ecifi\'e lors des restaurations pour des raisons 
historiques, mais il n'est plus utilis\'e.

Un seul type ({\bf Backup}, {\bf Restore}, ...) peut \^etre sp\'ecifi\'e pour un Job donn\'e. 
Si vous voulez sauvegarder plusieurs FileSets sur le m\^eme client, vous devez d\'efinir un 
Job pour chacun d'entre eux.

\begin{description}

\item [Job]
   \index[dir]{Job}
   \index[dir]{Directive!Job}
   D\'ebut de la ressource Job. Il faut d\'efinir au moins une ressource Job.

\item [Name = \lt{}name\gt{}]
   \index[dir]{Name}
    \index[dir]{Directive!Name}
   Le nom du Job. Ce nom peut \^etre utilis\'e avec la commande {\bf Run} du 
   programme Console pour lancer un Job. Si le nom contient des espaces, 
   il doit \^etre plac\'e entre quotes. C'est g\'en\'eralement une bonne id\'ee de 
   nommer vos Jobs du nom du Client qu'ils sauvegardent, afin de les 
   identifier ais\'ement.

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

\item [Enabled =  \lt{}yes|no\gt{}]
   \index[dir]{Enable}
   \index[dir]Directive!Enable}
   Cette directive permet d'activer ou d\'esactiver l'ex\'ecution automatique d'un job 
   par le planificateur.

\item [Type = \lt{}job-type\gt{}]
   \index[dir]{Type}
   \index[dir]{Directive!Type}
   La directive {\bf Type} sp\'ecifie le type de Job, qui peut \^etre l'un des 
   suivants : {\bf Backup},  {\bf Restore}, {\bf Verify}, ou {\bf Admin}. 
   Cette directive est requise. Pour chaque type de Job, il existe diff\'erents 
   niveaux, qui seront d\'ecrits dans les prochains paragraphes.

\begin{description}

\item [Backup]
   \index[dir]{Backup}
   D\'efinit une sauvegarde. En principe, vous aurez au moins un job de type Backup 
   par client sauvegard\'e. A moins que vous ne d\'esactiviez le catalogue, la 
   plupart des donn\'ees et statistiques concernant les fichiers sauvegard\'ees 
   seront \'ecrites dans le catalogue.

\item [Restore]
   \index[dir]{Restore}
   D\'efinit une restauration. En principe, vous ne cr\'eerez qu'un seul job de ce 
   type, que vous utiliserez comme un prototype  que vous modifierez \`a l'aide 
   de la console lorsque vous devrez restaurer. Bien que certaines informations 
   basiques soient conserv\'ees dans le catalogue lors de restaurations, leur 
   quantit\'e est infime en regard des informations stock\'ees pour une sauvegarde -- 
   par exemple, aucune entr\'ee de nom de fichier n'est g\'en\'er\'ee, puisqu'aucun fichier 
   n'est sauvegard\'e.

\item [Verify]
   \index[dir]{Verify}
   D\'efinit un Job de type Verify. Le Jobs de type {\bf verify}  permettent de 
   comparer le catalogue au syst\`eme de fichiers ou \`a ce qui a \'et\'e sauvegard\'e. 
   Vous pouvez l'utiliser pour vous assurer qu'une cartouche de donn\'ees est 
   lisible, mais aussi comme un syst\`eme de d\'etection d'intrusion \`a la fa\ccon de 
   Tripwire.

\item [Admin]
   \index[dir]{Admin}
   D\'efinit un Job de type Admin. Un  {\bf Admin} peut s'utiliser pour "\'elaguer" 
   p\'eriodiquement le catalogue, si vous ne souhaitez pas que ceci soit fait \`a la fin 
   de chaque sauvegarde. Bien que les Jobs de type admin soient enregistr\'es dans le 
   catalogue, la quantit\'e de donn\'ees g\'en\'er\'ee est infime.
   
\end{description}

\label{Level}

\item [Level = \lt{}job-level\gt{}]
   \index[dir]{Directive!Level}
   \index[dir]{Level}
   La directive Level sp\'ecifie le niveau d'ex\'ecutiondu job  par d\'efaut. 
   Chaque type de job a son propre jeu de niveaux qui peuvent \^etre sp\'ecifi\'es. 
   Le niveau d'ex\'ecution est en g\'en\'eral surcharg\'e par une valeur diff\'erente 
   sp\'ecifi\'ee dans la ressource {\bf Schedule}. Cette directive n'est pas 
   requise mais doit \^etre sp\'ecifi\'ee soit ici, soit en tant que surcharge 
   dans la ressource {\bf Schedule}.
   
Pour un job de type {\bf Backup} le niveau doit \^etre l'un des suivants : 

\begin{description}

\item [Full]
   \index[dir]{Full}
   Tous les fichiers du FileSet, qu'ils aient \'et\'e modifi\'es ou non.

\item [Incremental]
   \index[dir]{Incremental}
   Tous les fichiers modifi\'es depuis la derni\`ere sauvegarde valide du FileSet 
   sp\'ecifi\'e pour le m\^eme job. Si le Director ne peut trouver une sauvegarde Full ant\'erieure, 
   le niveau du job sera \'elev\'e en une sauvegarde Full. Lorsque le Director 
   recherche une Full valide dans le catalogue, il recherche un job avec 
   les caract\'eristiques suivantes :

\begin{itemize}
\item le m\^eme nom de job ; 
\item le m\^eme nom de client ;  
\item le m\^eme FileSet (toute modification de la d\'efinition du FileSet telle 
      que l'ajout ou la suppression de fichiers dans les sections Include ou 
      Exclude constitue un changement de FileSet).
\item le niveau requis (Full, Differential ou Incremental)
\item le job s'est termin\'e normalement, c'est \`a dire un qu'il ne s'est pas termin\'e 
      en \'echec, et n'a pas \'et\'e effac\'e.
\end{itemize}

Si toutes les conditions ci-dessus ne sont pas r\'ealis\'ees, le Director 
augmentera la sauvegarde incr\'ementale en une sauvegarde Full. Dans le cas 
contraire, la sauvegarde incr\'ementale sera effectu\'ee normalement.

Le File Daemon (Client) d\'etermine les fichiers \`a sauvegarder pour une 
incr\'ementale par comparaison de l'heure de d\'emarrage du Job pr\'ec\'edent 
(Full, Diff\'erentiel ou Incr\'emental) avec les dates de derni\`ere modification 
de chaque fichier (st\_mtime) et de ses attributs (st\_ctime). Si le fichier 
ou ses attributs ont chang\'es depuis cette date de d\'emarrage, alors le fichier 
sera sauvegard\'e.

Veuillez noter que certains logiciels anti-virus peuvent modifier la date 
st\_time lors de leurs op\'erations de scan. Ainsi, si l'antivirus modifie 
la date d'acc\`es (st\_atime), qui n'est pas utilis\'ee par Bacula, il 
provoquera une modification du st\_ctime et conduira Bacula \`a sauvegarder 
les fichiers concern\'es lors des incr\'ementales et diff\'erentielles. Dans le 
cas de l'antivirus Sophos, vous pouvez \'eviter cet inconv\'enient en utilisant 
l'option {\bf \verb{--{no-reset-atime}. Pour les autres logiciels, voyez 
leurs manuels.

Lorsque Bacula effectue une sauvegarde incr\'ementale, tous les fichiers modifi\'es 
pr\'esents sur le syst\`eme sont sauvegard\'es. Cependant, tout fichier supprim\'e depuis 
la derni\`ere Full demeure dans le catalogue, ce qui signifie que si vous effectuez 
une restauration \`a partir de sauvegardes incr\'ementales (et de la Full associ\'ee), 
les fichiers supprim\'es depuis la derni\`ere Full seront aussi restaur\'es. Ces fichiers 
n'appara\^itront plus dans le catalogue apr\`es avoir fait une nouvelle sauvegarde 
Full. Le processus pour supprimer ces fichiers du catalogue lors d'une 
incr\'ementale ralentirait fortement les sauvegardes incr\'ementales. Il n'est 
actuellement pas impl\'ement\'e dans Bacula.

De plus, si vous d\'eplacez un r\'epertoire plut\^ot que de le copier, les fichiers qu'il 
contient voient leurs dates de derni\`ere modification (st\_mtime) et de dernier acc\`es 
(st\_ctime) inchang\'es. Par cons\'equent, ces fichiers ne seront probablement 
sauvegard\'es par aucune incr\'ementale ou diff\'erentielle, puisque ces derni\`eres 
ne se r\'ef\`erent qu'\`a ces indicateurs. Aussi, il est pr\'ef\'erable de copier un dossier 
avant de supprimer l'original plut\^ot que de le d\'eplacer, si vous voulez qu'il soit 
correctement sauvegard\'e.

\item [Differential]
   \index[dir]{Differential}
   Tous les fichiers modifi\'es depuis la derni\`ere sauvegarde Full valide du FileSet
   sp\'ecifi\'e pour le m\^eme job. Si le Director ne peut trouver une sauvegarde Full 
   ant\'erieure, le niveau du job sera \'elev\'e en une sauvegarde Full. Lorsque le 
   Director recherche une Full valide dans le catalogue, il recherche un job avec 
   les caract\'eristiques suivantes :

\begin{itemize}
\item le m\^eme nom de job ;
\item le m\^eme nom de client ;
\item le m\^eme FileSet (toute modification de la d\'efinition du FileSet telle
      que l'ajout ou la suppression de fichiers dans les sections Include ou
      Exclude constitue un changement de FileSet).
\item le Job \'etait une sauvegarde FULL
\item le Job s'est termin\'e normalement, c'est \`a dire qu'il ne s'est pas termin\'e
      en \'echec, et n'a pas \'et\'e effac\'e.
\end{itemize}

Si toutes les conditions ci-dessus ne sont pas r\'ealis\'ees, le Director
augmentera la sauvegarde diff\'erentielle en une sauvegarde Full. Dans le cas
contraire, la sauvegarde diff\'erentielle sera effectu\'ee normalement.

Le File Daemon (Client) d\'etermine les fichiers \`a sauvegarder pour une
diff\'erentielle par comparaison de l'heure de d\'emarrage de la derni\`ere 
sauvegarde Full avec les dates de derni\`ere modification
de chaque fichier (st\_mtime) et de ses attributs (st\_ctime). Si le fichier
ou ses attributs ont chang\'es depuis cette date de d\'emarrage, alors le fichier
sera sauvegard\'e. La date de d\'emarrage utilis\'ee est affich\'e apr\`es le {\bf Since} 
du rapport de Job. Dans de rares cas, certains fichiers sont sauvegard\'es deux fois 
\`a cause de l'utilisation de la date de d\'emarrage de la sauvegarde pr\'ec\'edente, 
mais ceci assure qu'aucun changement n'est perdu. Comme pour les incr\'ementales, 
vous devriez vous assurer que les horloges de votre serveur Bacula et de vos clients 
sont synchronis\'ees, ou aussi proches que possible, pour \'eviter le risque d'omission 
d'un fichier. Notez qu'\`a partir de la version 1.33, Bacula effectue automatiquement 
ces ajustements de sorte que les horloges utilis\'ees par Bacula soient synchrones.

Veuillez noter que certains logiciels anti-virus peuvent modifier la date
st\_time lors de leurs op\'erations de scan. Ainsi, si l'antivirus modifie
la date d'acc\`es (st\_atime), qui n'est pas utilis\'ee par Bacula, il
provoquera une modification du st\_ctime et conduira Bacula \`a sauvegarder
les fichiers concern\'es lors des incr\'ementales et diff\'erentielles. Dans le
cas de l'antivirus Sophos, vous pouvez \'eviter cet inconv\'enient en utilisant
l'option {\bf \verb{--{no-reset-atime}. Pour les autres logiciels, voyez
leurs manuels.

Lorsque Bacula effectue une sauvegarde diff\'erentielle, tous les fichiers modifi\'es
pr\'esents sur le syst\`eme sont sauvegard\'es. Cependant, tout fichier supprim\'e depuis
la derni\`ere Full demeure dans le catalogue, ce qui signifie que si vous effectuez
une restauration \`a partir de sauvegardes diff\'erentielles (et de la Full associ\'ee),
les fichiers supprim\'es depuis la derni\`ere Full seront aussi restaur\'es. Ces fichiers
n'appara\^itront plus dans le catalogue apr\`es avoir fait une nouvelle sauvegarde
Full. Le processus pour supprimer ces fichiers du catalogue lors d'une
incr\'ementale ralentirait fortement les sauvegardes diff\'erentielles. Il n'est
actuellement pas impl\'ement\'e dans Bacula, mais plannifi\'e pour une future version 
de Bacula.

Comme not\'e ci-dessus, si vous d\'eplacez un r\'epertoire plut\^ot que de le copier, les fichiers 
qu'il contient voient leurs dates de derni\`ere modification (st\_mtime) et de dernier acc\`es
(st\_ctime) inchang\'es. Par cons\'equent, ces fichiers ne seront probablement
sauvegard\'es par aucune incr\'ementale ou diff\'erentielle, puisque ces derni\`eres
ne se r\'ef\`erent qu'\`a ces indicateurs. Aussi, il est pr\'ef\'erable de copier un dossier
avant de supprimer l'original plut\^ot que de le d\'eplacer, si vous voulez qu'il soit
correctement sauvegard\'e.

R\'eguli\`erement, quelqu'un demande \`a quoi servent les sauvegardes diff\'erentielles 
du moment que les incr\'ementales r\'ecup\`erent tous les fichiers modifi\'es. Il existe 
plusieurs r\'eponses \`a cette question, mais la plus importante \`a mes yeux est de 
combiner toutes les incr\'ementales et diff\'erentielles depuis la derni\`ere full en 
une seule diff\'erentielle. Ceci a deux effets : 1. La redondance. 2. Plus important, 
la r\'eduction du nombre de volumes requis pour faire une restauration en 
\'eliminant la n\'ecessit\'e de lire tous les volumes des pr\'ec\'edentes incr\'ementales 
depuis la derni\`ere full.

\end{description}

Pour un Job de type {\bf Restore}, aucun niveau ne doit \^etre sp\'ecifi\'e.  

Pour un Job de type {\bf Verify}, le niveau peut \^etre l'un des suivants :   

\begin{description}

\item [InitCatalog]
   \index[dir]{InitCatalog}
   Examine le {\bf FileSet} sp\'ecifi\'e et stocke les attributs de fichiers dans le 
   catalogue. Vous pouvez vous interroger sur l'int\'er\^et d'un Job qui ne 
   sauvegarde aucun fichier. La r\'eponse est de pouvoir utiliser Bacula comme 
   vous utiliseriez Tripwire, en d'autres termes, ce type de Jobs vous permet 
   de sauvegarder l'\'etat d'un ensemble de fichiers d\'efini par un {\bf FileSet} 
   afin de pouvoir ult\'erieurement contr\^oler si rien n'a \'et\'e modifi\'e, supprim\'e ou 
   ajout\'e. Ceci peut \^etre utilis\'e pour d\'etecter une intrusion. Typiquement, 
   vous sp\'ecifiez un {\bf FileSet} qui contient l'ensemble des fichiers qui ne 
   devraient pas changer (par exemple /sbin, /boot, /lib, /bin,  ...). Ensuite, 
   vous ex\'ecutez le Job verify de niveau {\bf InitCatalog} apr\`es l'installation 
   de votre syst\`eme, puis apr\`es chaque modification (mise \`a jour). Ensuite, 
   lorsque vous souhaitez contr\^oler l'\'etat de votre syst\`eme de fichiers, 
   vous utilisez un Job {\bf Verify}, {\bf level = Catalog} afin de comparer 
   le r\'esultat de votre {\bf InitCatalog} avec l'\'etat actuel de votre syst\`eme 
   de fichiers.

\item [Catalog]
   \index[dir]{Catalog}
   Compare l'\'etat actuel des fichiers et l'\'etat pr\'ec\'edemment sauvegard\'e 
   lors d'un {\bf InitCatalog}. Toutes les anomalies sont rapport\'ees. 
   Les objets du rapport sont d\'etermin\'es par les options {\bf verify} 
   sp\'ecifi\'ees dans la directive {\bf Include} du {\bf FileSet} sp\'ecifi\'e 
   (voyez la ressource {\bf FileSet} ci-dessous pour plus de d\'etails). 
   Typiquement, cette commande sera ex\'ecut\'ee quotidiennement pour 
   contr\^oler toute modification de votre syst\`eme de fichier.
   
Attention ! Si vous ex\'ecutez deux jobs Verify Catalog simultan\'ement sur le m\^eme client, 
les r\'esultats seront probablement erronn\'es. En effet, Verify Catalog modifie 
le catalogue lors de son ex\'ecution afin de d\'etecter les nouveaux fichiers.

\item [VolumeToCatalog]
   \index[dir]{VolumeToCatalog}
   Ce niveau permet de lire les attributs de fichiers \'ecrits sur le Volume 
   lors du dernier Job. Les attributs de fichiers sont compar\'es aux valeurs 
   sauvegard\'ees dans le catalogue et toute diff\'erence est rapport\'ee. Ceci 
   est similaire au niveau {\bf Catalog}, sauf que ce sont les 
   attributs des fichiers du volume plut\^ot que ceux des fichiers du disque 
   qui sont compar\'es aux attributs sauvegard\'es dans le catalogue. Bien que 
   les attributs et signatures (MD5 ou SHA1) soient compar\'es, les donn\'ees 
   r\'eelles ne le sont pas (elles ne figurent pas dans le catalogue).

Attention ! Si vous ex\'ecutez deux jobs Verify VolumeToCatalog simultan\'ement sur le m\^eme client,
les r\'esultats seront probablement erronn\'es. En effet, Verify VolumeToCatalog modifie
le catalogue lors de son ex\'ecution afin de d\'etecter les nouveaux fichiers.

\item [DiskToCatalog]
   \index[dir]{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\'es dans le 
   catalogue lors de la derni\`ere sauvegarde pour le Job sp\'ecifi\'e par la 
   directive {\bf VerifyJob}. Ce niveau diff\`ere du niveau {\bf Catalog} 
   d\'ecrit plus haut en ce qu'il ne se r\'ef\`ere pas \`a un Job Verify ant\'erieur, 
   mais \`a la derni\`ere sauvegarde. Lorsque vous utilisez ce niveau , vous devez 
   renseigner les option Verify de la section Include. Ces options d\'eterminent 
   quels attributs seront compar\'es.

Cette commande peut se r\'ev\'eler tr\`es utile si vous avez des probl\`emes de disque 
car elle comparera l'\'etat actuel de votre disque avec la derni\`ere sauvegarde 
valide, qui peut remonter \`a plusieurs jobs.

Notez que l'impl\'ementation actuelle (1.32c) n'identifie pas les fichiers qui 
ont \'et\'e supprim\'es.
\end{description}

\item {\bf Verify Job = \lt{}Job-Resource-Name\gt{}}
   \index[dir]{Verify Job}
   \index[dir]{Directive!Verify Job}
   Si vous ex\'ecutez un job verify sans cette directive, le dernier job 
   ex\'ecut\'e sera compar\'e avec le catalogue, ce qui signifie que votre commande 
   verify doit succ\'eder imm\'ediatement \`a une sauvegarde. Si vous sp\'ecifiez 
   un {\bf Verify Job}, Bacula trouvera le dernier job ex\'ecut\'e avec ce nom. 
   Ceci vous permet d'ex\'ecuter toutes vos sauvegardes, puis d'ex\'ecuter les jobs 
   Verify sur les sauvegardes de votre choix (le plus souvent, un {\bf VolumeToCatalog} 
   de sorte que la cartouche qui vient juste d'\^etre \'ecrite est relue).
   
\item {\bf JobDefs = \lt{}JobDefs-Resource-Name\gt{}}
   \index[dir]{JobDefs}
   \index[dir]{Directive!JobDefs}
   Si un nom de JobDef est sp\'ecifi\'e dans la d\'efinition d'un Job, toutes les valeurs 
   d\'efinies dans la ressource JobDef concern\'ee seront utilis\'ees en tant que valeurs 
   par d\'efaut pour le Job. Toute valeur explicitement sp\'ecifi\'ee dans la 
   d\'efinition du Job outrepasse la valeur par d\'efaut d\'efinie par le JobDef.
   L'utilisation de cette directive permet d'\'ecrire des ressources Job plus 
   compactes, o\`u la majeure partie des directives sont d\'efinies dans un ou 
   plusieurs JobDefs. C'est particuli\`erement pratique si vous avez de nombreux 
   Jobs similaires avec des variations mineures telles que diff\'erents clients.
   Un exemple basique de l'utilisation d'un Jobdef est fourni dans le fichier 
   bacula-dir.conf par d\'efaut.

\item {\bf Bootstrap = \lt{}bootstrap-file\gt{}}
   \index[dir]{Bootstrap}
   \index[dir]{Directive!Bootstrap}
   La directive Bootstrap sp\'ecifie un fichier bootstrap qui, s'il est fourni, 
   sera utilis\'e lors des restaurations et ignor\'e par tout les autres Jobs. 
   Le fichier {\bf bootstrap} contient la liste des cartouches n\'ecessaires 
   pour la restauration ainsi que les index des fichiers \`a restaurer 
   (localisation sur la cartouche). Cette directive 
   est optionnelle, et n'est utilis\'ee que pour les restaurations. De plus, 
   elle peut \^etre modifi\'ee lorsqu'une restauration est lanc\'ee depuis la console.
   
Si vous utilisez la commande {\bf Restore} dans la console pour lancer une 
restauration, le fichier {\bf bootstrap} sera cr\'e\'e automatiquement \`a partir des 
fichiers que vous avez s\'electionn\'es pour la restauration.

Pour plus de d\'etails concernant les fichiers {\bf bootstrap}, veuillez 
consulter le chapitre \ilink{Restaurer des fichiers avec le fichier Bootstrap}{_ChapterStart43} 
de ce manuel.

\label{writebootstrap}
\item {\bf Write Bootstrap =  \lt{}bootstrap-file-specification\gt{}}
   \index[dir]{Write Bootstrap}
   \index[dir]{Directive!Write Bootstrap}
   La directive {\bf writebootstrap} sp\'ecifie le de fichier Bootstrap o\`u Bacula 
   \'ecrira lors de chaque sauvegarde. Ainsi, cette directive s'applique 
   exclusivement aux jobs de type sauvegarde. Si la sauvegarde est une Full, 
   Bacula \'ecrase le contenu du fichier sp\'ecifi\'e. Sinon, Bacula ajoute les 
   nouveaux enregistrements Bootstrap \`a la fin du fichier.

En utilisant cette fonction, vous aurez constamment un fichier bootstrap 
capable de recouvrer l'\'etat le plus r\'ecent de votre syst\`eme. Le fichier 
bootstrap devrait \^etre \'ecrit sur un disque mont\'e sur une autre machine, de 
sorte que vous puissiez en disposer imm\'ediatement en cas de d\'efaillance 
de votre disque dur. Une alternative consiste \`a copier le fichier sur une autre 
machine apr\`es chaque mise \`a jour.

Si la {\bf sp\'ecification de fichier bootstrap} d\'ebute par une barre verticale (|), 
Bacula consid\`ere la sp\'ecification comme un nom de programme vers lequel les 
les enregistrement bootstrap seront redirig\'es. Ce peut \^etre, par exemple, un 
script qui vous envoie par e-mail les enregistrements bootstrap.

Pour plus de d\'etails sur l'utilisation de fichiers bootstrap, veuillez 
consulter le chapitre intitul\'e \ilink{Le Fichier Bootstrap}{_ChapterStart43} 
de ce manuel.


\item {\bf Client = \lt{}client-resource-name\gt{}}
   \index[dir]{Client}
   \index[dir]{Directive!Client}
   La directive Client sp\'ecifie le Client (File Daemon) \`a utiliser dans le Job.
   Le client est ex\'ecut\'e sur la machine \`a sauvegarder. Il exp\'edie les fichiers requis
   au Storage Daemon lors des sauvegardes, et re\\ 3oit les fichiers du Storage Daemon
   lors des restaurations. Pour plus de d\'etails, consultez la section
   \ilink{Ressource Client}{ClientResource2} de ce chapitre. Cette deirective est requise.


\item {\bf FileSet = \lt{}FileSet-resource-name\gt{}}
   \index[dir]{FileSet}
   \index[dir]{FileSet}
   La directive FileSet sp\'ecifie le FileSet \`a utiliser dans le Job concern\'e. Le
   FileSet d\'efinit les r\'epertoires et fichiers \`a sauvegarder, ainsi que les options
   \`a utiliser pour les sauvegarder (par exemple la compression,...). Un Job ne peut
   contenir qu'un seul FileSet. Pour plus de d\'etails, consultez la section
   \ilink{Ressource FileSet}{FileSetResource} de ce chapitre.
   Cette directive est requise.

\item {\bf Messages = \lt{}messages-resource-name\gt{}}
   \index[dir]{Messages}
   \index[dir]{Directive!Messages}
   La directive Messages d\'efinit la ressource Message qui doit \^etre utilis\'ee
   pour le job concern\'e. Ainsi, elle d\'etermine le comment et o\`u seront
   d\'elivr\'es les diff\'erents messages de Bacula. Par exemple, vous pouvez diriger
   certains messages vers un fichier de logs, tandis que d'autres seront
   envoy\'es par e-mail. Pour plus de d\'etails, consultez le chapitre
   \ilink{Ressource Messages}{_ChapterStart15} de ce manuel. Cette directive
   est requise.

\item {\bf Pool = \lt{}pool-resource-name\gt{}}
   \index[dir]{Pool}
   \index[dir]{Directive!Pool}
   La directive Pool sp\'ecifie le jeu de volumes qui doit \^etre utilis\'e pour
   sauvegarder vos donn\'ees. De nombreuses installations de Bacula
   n'utiliseront que le pool d\'efini par d\'efaut {\bf Default}. Toutefois,
   si vous voulez sp\'ecifier diff\'erents jeux de volumes pou diff\'erents clients
   ou diff\'erents jobs, vous voudrez probablement utiliser les Pools.
   Pour plus de d\'etails, consultez la section \ilink{Ressource Pool}{PoolResource}
   de ce chapitre. Cette directive est requise

\item {\bf Full Backup Pool = \lt{}pool-resource-name\gt{}  }
   \index[dir]{Full Backup Pool}
   \index[dir]{Directive!Full Backup Pool}
   La directive {\it Full Backup Pool} sp\'ecifie un Pool \`a utiliser pour les
   sauvegardes Full. Cette directive outrepasse toute autre sp\'ecification
   de Pool lors d'une sauvegarde Full. Cette directive est optionnelle.

\item {\bf Differential Backup Pool = \lt{}pool-resource-name\gt{}  }
   \index[dir]{Differential Backup Pool}
   \index[dir]{Directive!Differential Backup Pool}
   La directive {\it Differential Backup Pool} sp\'ecifie un Pool \`a utiliser pour les
   sauvegardes Diff\'erentielles. Cette directive outrepasse toute autre sp\'ecification
   de Pool lors d'une sauvegarde Diff\'erentielle. Cette directive est optionnelle.

\item {\bf Incremental Backup Pool = \lt{}pool-resource-name\gt{}  }
   \index[dir]{Incremental Backup Pool}
   \index[dir]{Directive!Differential Backup Pool}
   La directive {\it Incremental Backup Pool} sp\'ecifie un Pool \`a utiliser pour les
   sauvegardes Incr\'ementales. Cette directive outrepasse toute autre sp\'ecification
   de Pool lors d'une sauvegarde Incr\'ementale. Cette directive est optionnelle.

\item {\bf Schedule = \lt{}schedule-name\gt{}}
   \index[dir]{Schedule}
   \index[dir]{Directive!Schedule}
   La directive Schedule d\'efinit la planification du job. Le {\it schedule} d\'etermine 
   la date et l'instant o\`u le job doit \^etre lanc\'e automatiquement, et le niveau 
   (Full, Diff\'erentiel, Incr\'emental...) du job en question. Cette directive est 
   optionnelle. Si elle est omise, le job ne pourra \^etre ex\'ecut\'e que manuellement via 
   la Console. Bien que vous puissiez vous contenter d'une ressource Schedule simple
   pour tout job, vous pouvez aussi d\'efinir des ressources Schedule avec plusieurs 
   directives {\bf Run}, afin de lancer le job \`a diff\'erentes heures. Chacune de ces 
   directives {\bf Run} permet d'outrepasser les valeurs par d\'efaut de Level, Pool, 
   Storage et Messages ressources. Ceci autorise une grande souplesse d'utilisation 
   d'un simple job.
   Pour plus de d\'etails, consultez le chapitre. 
   \ilink{Ressource Schedule}{ScheduleResource} de ce manuel. 

\item {\bf Storage = \lt{}storage-resource-name\gt{}}
   \index[dir]{Storage}
   \index[dir]{Directive!Storage}
   La directive Storage d\'efinit le nom du service storage que vous souhaitez 
   utiliser pour sauvegarder les donn\'ees du FileSet. Pour plus de d\'etails, consultez le 
   chapitre \ilink{Ressource Storage}{StorageResource2} de ce manuel.
   Cette directive est requise.
   
\item {\bf Max Start Delay = \lt{}time\gt{}}
   \index[sd]{Max Start Delay}
    \index[dir]{Directive!Max Start Delay}
   La directive Max Start Delay sp\'ecifie le d\'elai maximal entre l'horaire 
   planifi\'e (dans le schedule) et l'horaire effectif de d\'emarrage du job. 
   Par exemple, un job peut \^etre programm\'e pour d\'emarrer \`a 1h, mais \^etre 
   mis en attente \`a cause d'autres jobs en cours d'ex\'ecution. Si le 
   Max Start Delay a \'et\'e r\'egl\'e \`a 3600, le job sera supprimm\'e s'il n'a pas 
   d\'emarr\'e \`a 2h. Ceci peut se r\'ev\'eler utile pour, par exemple, \'eviter qu'un job 
   s'ex\'ecute duant les heures ouvrables. La valeur par d\'efaut est 0 (pas de limite).

\item {\bf Max Run Time = \lt{}time\gt{}}
   \index[sd]{Max Run Time}
   \index[dir]{Directive!Max Run Time}
   La directive Max Run Time sp\'ecifie le d\'elai allou\'e pour l'ex\'ecution 
   compl\`ete d'un job depuis son lancement (pas n\'ecessairement \`a l'heure 
   de sa programmation) jusqu'\`a sa fin. Cette directive est impl\'ement\'ee 
   depuis la version 1.33.

\item {\bf Max Wait Time = \lt{}time\gt{}}
   \index[sd]{Max Wait Time}
   \index[dir]{Directive!Max Wait Time}
   La directive Max Wait Time sp\'ecifie le d\'elai maximum durant lequel un 
   job peut rester bloqu\'e en attente d'une ressource (par exemple, en attente du 
   montage d'une cartouche ou encore en attente des Storage ou File Daemon occup\'es 
   \`a d'autres tâches) depuis son lancement (pas n\'ecessairement \`a l'heure
   de sa programmation) jusqu'\`a sa fin. Cette directive est impl\'ement\'ee
   depuis la version 1.33. 
   
\item [Incremental Max Wait Time = \lt{}time\gt{}]
   \index[dir]{Incremental Max Wait Time}
   \index[dir]{Directive!Incremental Max Wait Time}
   Cette directive sp\'ecifie le temps maximum durant lequel une sauvegarde 
   incr\'ementale peut rester bloqu\'ee en attente d'une ressource (par exemple, en 
   attente d'une cartouche ou des File ou Storage daemons), compt\'e \`a partir 
   du d\'emarrage du job, ({\bf pas n\'ecessairement} l'heure \`a laquelle le job 
   a \'et\'e programm\'e). Notez que si un {\bf Max Wait Time} a \'et\'e sp\'ecifi\'e, 
   il peut aussi s'appliquer au job.

\item [Differential Max Wait Time = \lt{}time\gt{}]
   \index[dir]{Differential Max Wait Time}
   \index[dir]{Directive!Differential Max Wait Time}
   Cette directive sp\'ecifie le temps maximum durant lequel une sauvegarde
   diff\'erentielle peut rester bloqu\'ee en attente d'une ressource (par exemple, en
   attente d'une cartouche ou des File ou Storage daemons), compt\'e \`a partir
   du d\'emarrage du job, ({\bf pas n\'ecessairement} l'heure \`a laquelle le job
   a \'et\'e programm\'e). Notez que si un {\bf Max Wait Time} a \'et\'e sp\'ecifi\'e,
   il peut aussi s'appliquer au job.

\item [Prefer Mounted Volumes = \lt{}yes|no\gt{}]
    \index[dir]{Prefer Mounted Volumes}
    \index[dir]{Directive!Differential Max Wait Time}
    Si cette directive est activ\'ee (c'est le cas par d\'efaut), le Director 
    ordonne au Storage daemon de s\'electionner de pr\'ef\'erence soit une 
    librairie, soit un lecteur avec un volume valide d\'ej\`a mont\'e, plut\^ot qu'un 
    lecteur pas pr\`et. Si aucun lecteur n'est pr\`et, c'est le premier lecteur 
    pr\`et qui sera s\'electionn\'e.

    Si cette directive est d\'esactiv\'ee, le Storage daemon privil\'egiera 
    les lecteurs inutilis\'es. Ce mode de fonctionnement peut \^etre tr\`es utile 
    pour ces sites avec de nombreux lecteurs qui o\`u il peut \^etre pr\'ef\'erable 
    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\`es l'autre avec un intervalle de 5 secondes environ. Ceci 
    aidera \`a assurer que chaque nuit, le m\^eme lecteur (volume) est 
    s\'electionn\'e pour le m\^eme job. Autrement, lors d'une restauration, vous 
    pourriez trouver vos fichiers dispers\'es sur beaucoup plus de volumes que 
    n\'ecessaire.

\item {\bf Prune Jobs = \lt{}yes|no\gt{}}
   \index[dir]{Prune Jobs}
   \index[dir]{Directive!Prune Jobs}
   En principe, l'\'elagage des jobs du catalogue est sp\'ecifi\'e pour chaque client 
   dans sa propre ressource Client par la directive {\bf AutoPrune}. Si cette 
   directive est sp\'ecifi\'ee (normalement, non) et si la valeur est {\bf yes}, 
   elle outrepasse la valeur sp\'ecifi\'ee dans la ressource Client. La valeur 
   par d\'efaut est {\bf no}.

\item {\bf Prune Files = \lt{}yes|no\gt{}}
   \index[dir]{Prune Files}
   \index[dir]{Directive!Prune Jobs}
   En principe, l'\'elagage des fichiers du catalogue est sp\'ecifi\'e pour chaque client
   dans sa propre ressource Client par la directive {\bf AutoPrune}. Si cette
   directive est sp\'ecifi\'ee (normalement, non) et si la valeur est {\bf yes},
   elle outrepasse la valeur sp\'ecifi\'ee dans la ressource Client. La valeur
   par d\'efaut est {\bf no}.
 
\item {\bf Prune Volumes = \lt{}yes|no\gt{}}
   \index[dir]{Prune Volumes}
   \index[dir]{Directive!Prune Jobs}
   En principe, l'\'elagage des volumes du catalogue est sp\'ecifi\'e pour chaque client
   dans sa propre ressource Client par la directive {\bf AutoPrune}. Si cette
   directive est sp\'ecifi\'ee (normalement, non) et si la valeur est {\bf yes},
   elle outrepasse la valeur sp\'ecifi\'ee dans la ressource Client. La valeur
   par d\'efaut est {\bf no}.

\item {\bf Run Before Job = \lt{}command\gt{}}
   \index[dir]{Run Before Job}
   \index[dir]{Directive!Run Before Job}
   La commande sp\'ecifi\'ee est ex\'ecut\'ee en tant que programme externe avant le 
   lancement du job. Tout retour de la commande sur la sortie standard est 
   incluse dans le rapport de job de Bacula. La cha\^ine {bf command} doit \^etre 
   un nom de programme valide ou un script shell. Cette directive n'est pas requise, 
   mais si elle est d\'efinie, et si le code retour d'ex\'ecution du programme 
   est diff\'erent de z\'ero, le job qui a lanc\'e le programme est effac\'e. D'autre part, 
   la cha\^ine {bf command} est parcourue puis envoy\'ee vers la fonction execvp(), ce qui 
   signifie que le chemin de la commande est recherch\'e pour son ex\'ecution, mais 
   qu'il n'y a aucune interpr\'etation shell. Par cons\'equent, si vous voulez utiliser 
   des commandes complexes ou toute fonctionnalit\'e du shell telle que la 
   redirection, vous devez appeler un script shell o\`u vous mettrez vos commandes.
   Avant de soumettre la commande sp\'ecifi\'ee au syst\`eme d'exploitation, Bacula 
   effectue les substitutions suivantes :

\footnotesize
\begin{verbatim}
    %% = %
    %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
    
\end{verbatim}

\normalsize

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

\index[dir]{Exit Status}
\begin{itemize}
\item OK
\item Error
\item Fatal Error
\item Canceled
\item Differences
\item Unknown term code
\end{itemize}

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

Depuis la version 1.30, Bacula contr\^ole le statut de sortie du programme 
RunBeforeJob. S'il est diff\'erent de z\'ero, le job se termine en erreur. 
Lutz Kittler a fait remarquer que ceci peut \^etre un moyen ais\'e 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\'eri\'es. Pour \'eviter d'avoir \`a changer les cartouches entre jeudi et vendredi 
alors que personne n'est au bureau, vous pouvez cr\'eer un RunBeforeJob qui retourne 
un statut non nul jeudi et z\'ero les autres jours. Ainsi, le job de jeudi ne sera pas 
ex\'ecut\'e, et la cartouche que vous avez ins\'er\'e mercredi sera disponible pour la Full 
de vendredi.

\item {\bf Run After Job = \lt{}command\gt{}}
   \index[dir]{Run After Job}
   \index[dir]{Directive!Run After Job}
   La commande sp\'ecifi\'ee est ex\'ecut\'ee en tant que programme externe apr\`es la fin 
   du job. La cha\^ine {bf command} doit \^etre 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\'ecifi\'ee au syst\`eme d'exploitation, Bacula effectue les 
   substitutions de caract\`eres d\'ecrites au paragraphe {\bf Run Before Job}

Un exemple d'utilisation de cette directive est donn\'e au chapitre 
\ilink{Astuces}{JobNotification} de ce manuel. 
Lisez le paragraphe {\bf Run After Failed Job} si vous voulez ex\'ecuter 
une commande lorqu'un job se termine avec un statut anormal.

\item [Run After Failed Job = \lt{}command\gt{}]
   \index[dir]{Run After Job}
   \index[dir]{Directive!Run After Job}
   La commande sp\'ecifi\'ee est ex\'ecut\'ee en tant que programme externe apr\`es la fin 
   du job lorqu'il se termine avec un statut d'erreur. Cette directive est optionnelle. 
   La cha\^ine {\bf command} doit \^etre 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\'ecifi\'ee au syst\`eme d'exploitation, Bacula effectue les
   substitutions de caract\`eres d\'ecrites au paragraphe {\bf Run Before Job}. Notez que 
   vous pouvez, si vous le souhaitez, sp\'ecifier ici le m\^eme programme que 
   celui que vous avez utilis\'e pour la direcive {\bf Run After Job}, de sorte que 
   votre programme soit ex\'ecut\'e quel que soit l'issue du job.

   Le chapitre \ilink{Trucs et astuces}{JobNotification} de ce manuel propose un 
   exemple d'utilisation de cette directive.  

\item {\bf Client Run Before Job = \lt{}command\gt{}}
   \index[dir]{Client Run Before Job}
    \index[dir]{Directive!Client Run Before Job}
   Cette directive est similaire \`a {\bf Run Before Job} except\'e que la 
   commande est ex\'ecut\'ee sur la machine cliente. Les m\^emes restrictions
   s'appliquent aux syt\`emes Unix que celles signal\'ees pour {\bf Run Before Job}. 

   Lorsque vous sp\'ecifiez un chemin absolu vers un ex\'ecutable, si le chemin ou le nom 
   de l'ex\'ecutable contient des espaces ou des caract\`eres sp\'eciaux, il faut les 
   prot\'eger par des quotes. Il en va de m\^eme des \'eventuels arguments.


{\bf Consid\'erations particuli\`eres \`a Windows}
   D'autre part, pour les clients Windows \`a 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\'ecifiez un chemin, 
   vous devez aussi sp\'ecifier l'extension compl\`ete. Les commandes \`a la fa\c{c}on 
   d'Unix ne fonctionneront pas, \`a moins que vous n'ayez install\'e et 
   correctement configur\'e Cygwin en plus (et s\'epar\'ement) de Bacula.

La commande peut \^etre n'importe quel programme reconnu par cmd.exe ou command.com 
comme un fichier ex\'ecutable. Sp\'ecifier une extension de fichier ex\'ecutable 
est optionnel, \`a moins qu'il y ait une ambigu\"it\'e (par exemple ls.bat, ls.exe).

Bacula cherche la commande dans le r\'epertoire "System \%Path\%" (Dans la
bo\^ite de dialogue des variables d'environnement vous avez les variables
"syst\`eme" et "utilisateurs". Si bacula-fd fonctionne en tant que
service, seules les variables d'environnement syst\`emes sont accessibles.)

Les variables d'environnement syst\`eme peuvent \^etre invoqu\'ees avec la
syntaxe \%var\% et utilis\'ees comme portion du nom de la commande ou des
arguments.

Lorsque la sp\'ecification du chemin absolu d'un ex\'ecutable ou le nom de 
l'ex\'ecutable contient des espaces ou des caract\`eres sp\'eciaux, ils doivent 
\^etre quot\'es. Il en va de m\^eme pour les arguments.

\footnotesize
\begin{verbatim}
ClientRunBeforeJob = "\"C:/Program Files/Software
     Vendor/Executable\" /arg1 /arg2 \"foo bar\""
\end{verbatim}
\normalsize

Les caract\`eres sp\'eciaux \&()[]\{\}\^{}=;!'+,`\~{} devront \^etre quot\'es 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\'ecution sur les machines 
Win32 avec le File Daemon Win32 natif :

\begin{enumerate}
\item Vous pourriez utiliser la directive ClientRunBeforeJob pour sp\'ecifier 
      un fichier .bat qui ex\'ecute les commandes cot\'e client plut\^ot que 
      d'essayer d'ex\'ecuter (par exemple) regedit /e directement.
\item Le fichier batch devrait retourner explicitement 0 lors des ex\'ecutions correctes.
\item Le chemin vers le fichier batch devrait \^etre sp\'ecifi\'e au format Unix :

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

plut\^ot qu'au format DOS/Windows :  

ClientRunBeforeJob =
``c:\textbackslash{}bacula\textbackslash{}bin\textbackslash{}systemstate.bat''
INCORRECT 
\end{enumerate}

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

\footnotesize
\begin{verbatim}
 #!/bin/sh
 # ===== backupdb.sh
 DIR=/u01/mercuryd

 mkfifo $DIR/dbpipe
 db2 BACKUP DATABASE mercuryd TO $DIR/dbpipe WITHOUT PROMPTING &
 sleep 1
\end{verbatim}
\normalsize

La ligne suivante dans la ressource Job du fichier bacula-dir.conf :
\footnotesize
\begin{verbatim}
 Client Run Before Job = "su - mercuryd -c \"/u01/mercuryd/backupdb.sh '%t'
'%l'\""
\end{verbatim}
\normalsize
Lorsque le job est ex\'ecut\'e, vous obtiendrez un message de sortie du script 
anno\\ 3ant que la sauvegarde a d\'emarr\'e. M\^eme si la commande est ex\'ecut\'ee en 
arri\`ere plan avec \&, le job bloquera jusqu'\`a la commande "db2 BACKUP DATABASE", et 
la sauvegarde se fige. Pour rem\'edier \`a cette situation, la ligne "db2 BACKUP DATABASE" 
devrait \^etre modifi\'ee en :
\footnotesize
\begin{verbatim}
 db2 BACKUP DATABASE mercuryd TO $DIR/dbpipe WITHOUT PROMPTING > $DIR/backup.log
2>&1 < /dev/null &
\end{verbatim}
\normalsize
Il est important de rediriger l'entr\'ee et la sortie d'une commande en arri\`ere plan 
vers /dev/null pour \'eviter le bloquage du script.

\item {\bf Client Run After Job = \lt{}command\gt{}}
   \index[dir]{Client Run After Job}
   \index[dir]{Directive!Client Run After Job}
   Cette directive est similaire \`a {\bf Run After Job} sauf qu'elle est ex\'ecut\'ee 
   sur la machine cliente. Veuillez consulter les notes concernant les clients 
   Windows dans le paragraphe {\bf Client Run Before Job} ci-dessus.

\item {\bf Rerun Failed Levels = \lt{}yes|no\gt{}}
   \index[dir]{Rerun Failed Levels}
   \index[dir]{Directive!Rerun Failed Levels}
   Si la valeur de cette directive est {\bf yes} ({\bf no} par d\'efaut), et si 
   Bacula d\'etecte qu'un job ant\'erieur d'un niveau plus \'elev\'e (Full ou 
   diff\'erentiel), alors le job est \'elev\'e au niveau le plus haut. Ceci est 
   particuli\`erement utile pour sauvegarder les pc portables qui peuvent 
   \^etre fr\'equemment inaccessibles. En effet, apr\`es l'\'echec d'une Full, vous 
   souhaiterez probablement que la prochaine sauvegarde soit de niveau  Full 
   plut\^ot qu'Incremental ou Diff\'erentiel.

\item {\bf Spool Data = \lt{}yes|no\gt{}}
   \index[dir]{Spool Data}
   \index[dir]{Directive!Spool Data}
   Si la valeur de cette directive est {\bf yes} ({\bf no} par d\'efaut), le 
   Storage Daemon aura pour consigne de stocker les donn\'ees dans un  
   fichier spoule sur disque plut\^ot que de les \'ecrire directement sur bande.
   Lorsque toutes les donn\'ees sont dans le spoule ou lorsque la taille 
   maximale fix\'ee pour le fichier spoule est atteinte, les donn\'ees sont 
   d\'echarg\'ees du spoule vers les bandes. Lorsque la valeur de cette directive 
   est {\bf yes}, la directive Spool Attributes est aussi automatiquement 
   mise \`a la valeur {\bf yes}. L'utilisation de cette fonctionnalit\'e 
   pr\'evient les arr\^ets et red\'emarrage incessants lors des incr\'ementales.
   Elle ne doit pas \^etre utilis\'ee si vous sauvegardez sur disque.


\item {\bf Spool Attributes = \lt{}yes|no\gt{}}
   \index[dir]{Spool Attributes}
    \index[dir]{Directive!Spool Attributes}
   La valeur par d\'efaut est {\bf no}, ce qui signifie que le Storage Daemon 
   envoie les attributs de fichiers au Director au moment o\`u ils (les fichiers) 
   sont ecrits sur la bande. Cependant, si vous souhaitez \'eviter le risque 
   de ralentissement d\^u aux mises \`a jour du catalogue, vous pouvez r\'egler  
   cette directive \`a {\bf 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'\`a la fin de l'\'ecriture sur bande des donn\'ees du job.

\item {\bf Where = \lt{}directory\gt{}}
   \index[dir]{Where}
   \index[dir]{Directive!Where}
   Cette directive ne concerne que les jobs de type Restauration. Elle permet 
   de sp\'ecifier un pr\'efixe au nom du r\'epertoire o\`u tous les fichiers sont 
   restaur\'es. Ceci permet de restaurer les fichiers en un emplacement 
   diff\'erent de celui o\`u ils ont \'et\'e sauvegard\'es. Si {\bf Where} n'est pas 
   renseign\'e, ou si sa valeur est backslash ({\bf /}), les fichiers sont 
   restaur\'es \`a leur emplacement d'origine. Par d\'efaut, nous avons donn\'e \`a 
   {\bf Where} la valeur {\bf /tmp/bacula-restores} dans les fichiers de 
   configuration fournis en exemple, ceci afin d'\'eviter l'\'ecrasement 
   accidentel de vos fichiers.

\item {\bf Replace = \lt{}replace-option\gt{}}
   \index[dir]{Replace}
   \index[dir]{Directive!Replace}
   Cette directive ne concerne que les jobs de type Restauration. Elle pr\'ecise 
   la conduite \`a adopter dans l'\'eventualit\'e o\`u Bacula serait conduit \`a restaurer 
   un fichier ou un r\'epertoire qui existe d\'ej\`a. Les options suivantes sont 
   disponibles :

\begin{description}

\item [always]
   \index[dir]{always }
   Lorsque le fichier \`a restaurer existe d\'ej\`a, il est supprim\'e et remplac\'e par la 
   copie sauvegard\'ee.

\item [ifnewer]
   \index[dir]{ifnewer }
   Si le fichier sauvegard\'e (sur bande) est plus r\'ecent que le fichier existant, 
   le fichier existant est supprim\'e et remplac\'e par la copie sauvegard\'ee.

\item [ifolder]
   \index[dir]{ifolder }
   Si le fichier sauvegard\'e (sur bande) est plus ancien que le fichier existant,
      le fichier existant est supprim\'e et remplac\'e par la copie sauvegard\'ee.

\item [never]
   \index[dir]{never }
   Si le fichier sauvegard\'e existe d\'ej\`a, Bacula renonce \`a restaurer ce fichier.
\end{description}

\item {\bf Prefix Links=\lt{}yes|no\gt{}}
   \index[dir]{Prefix Links}
   \index[dir]{Directive!Prefix Links}
   Si la valeur de cette directive est {\bf Yes} et si un pr\'efixe de chemin 
   {\bf Where} est sp\'ecifi\'e, alors ce dernier s'applique aussi aux liens 
   absolus. La valeur par d\'efaut est {\bf No}. Lorsque cette directive est \`a 
   {\bf Yes}, tous les liens absolus seront aussi modifi\'es pour 
   pointer vers le nouveau r\'epertoire. En principe, c'est ce qui est souhait\'e : 
   l'ensemble du r\'epertoire restaur\'e conserve sa coh\'erence interne. Cependant, 
   si vous voulez replacer les fichiers ult\'erieurement \`a leurs emplacements 
   d'origine, tous les liens absolus seront bris\'es.

\item {\bf Maximum Concurrent Jobs = \lt{}number\gt{}}
   \index[dir]{Maximum Concurrent Jobs}
   \index[dir]{Directive!Maximum Concurrent Jobs}
   O\`u \lt{}number\gt{} est le nombre maximum de jobs de la ressource Job courrante 
   qui peuvent \^etre ex\'ecut\'es simultan\'ement. Notez que cette directive ne limite 
   que les jobs avec le m\^eme nom que la ressource dans laquelle elle 
   figure. Toute autre restriction du nombre maximum de jobs simultan\'es, que ce soit au 
   niveau du Director, du Client ou de la ressource Storage, s'applique en plus de 
   de la limite stipul\'ee ici. LA valeur par d\'efaut est 1, mais vous pouvez utiliser 
   une valeur plus grande. Nous vous recommandons fortement de lire 
   attentivement le paragraphe WARNING sous \ilink{ Maximum Concurrent Jobs}{DirMaxConJobs} 
   dans la section concernant la ressource Director.

\item {\bf Reschedule On Error = \lt{}yes|no\gt{}}
   \index[dir]{Reschedule On Error}
   \index[dir]{Directive!Reschedule On Error}
   Si cette directive est activ\'ee, alors si le job se termine en erreur, il sera 
   reprogramm\'e en accord avec les directives {\bf Reschedule Interval} et 
   {\bf Reschedule Times}. Si vous supprimez le job, il ne sera pas reprogramm\'e.
   La valeur par d\'efaut est {\bf no}.

Cette sp\'ecification peut se r\'ev\'eler utile pour les pc portables ainsi que pour toutes 
les machines qui ne sont pas connect\'ees au r\'eseau en permanence.

\item {\bf Reschedule Interval = \lt{}time-specification\gt{}}
   \index[dir]{Reschedule Interval}
    \index[dir]{Directive!Reschedule Interval}
   Si cette directive est activ\'ee, alors si le job se termine en erreur, il sera
   reprogramm\'e apr\`es l'intervalle de temps stipul\'e par {\bf time-specification}. 
   Consultez la section \ilink{ the time specification formats}{Time} du chapitre 
   Configurer Bacula pour plus de d\'etails sur les sp\'ecifications de temps. Si 
   aucun intervalle n'est sp\'ecifi\'e, le job ne sera pas reprogramm\'e en cas d'erreur.

\item {\bf Reschedule Times = \lt{}count\gt{}}
   \index[dir]{Reschedule Times}
   \index[dir]{Directive!Reschedule Times}
   Cette directive pr\'ecise le nombre maximal de tentatives d'ex\'ecution du job.
   S'il est fix\'e \`a z\'ero (valeur par d\'efaut), le job sera reprogramm\'e 
   ind\'efiniment.

\item [Run = \lt{}job-name\gt{}]
   \index[dir]{Run}
   \index[dir]{Directive!Run}
   \index[dir]{Cloner un Job}
    La directive Run (\`a ne pas confondre avec l'option Run dans un 
    Schedule) vous permet de d\'emarrer ou de cloner des jobs. En utilisant les 
    mots-clef de clonage (voir ci dessous), vous pouvez sauvegarder les m\^emes 
    donn\'ees (ou presque les m\^emes) vers deux (ou plus) lecteurs en m\^eme temps. 
    Le nom de job {\bf job-name} est en principe le m\^eme que celui de la 
    ressource job courante (cr\'eant ainsi un clone). Cependant, ce peut \^etre 
    n'importe quel nom de job, de sorte qu'un job peut d\'emarrer d'autre jobs li\'es. 
    La partie apr\`es le signe \'egale doit \^etre encadr\'ee de double quotes, et peut 
    contenir toute cha\^ine ou jeu d'options (surcharges) qui pourraient \^etre 
    sp\'ecifi\'ees \`a l'utilisation de la commande Run dans la Console. Par exemple, 
    {\bf storage=DDS-4 ...}. De plus, deux mots-clef sp\'eciaux vous permettent de 
    cloner le job courant : {\bf level=\%l} et {\bf since=\%s}. le \%l du mot clef 
    level permet d'entrer le niveau r\'eel du job courant et le \%s du mot clef since 
    permet d'imposer la m\^eme date pour la comparaison que celle utilis\'ee par le job courant.a
    Notez que dans le cas du mot-clef since, le \%s doit \^etre encadr\'e de double quotes, 
    qui doivent \^etre elles m\^emes pr\'ec\'ed\'ees de barres obliques arri\`eres puisque elles sont 
    d\'ej\`a entre double quotes. Par exemple :

    \begin{verbatim}
       run = "Nightly-backup level=%s since=\"%s\" storage=DDS-4"
    \end{verbatim}
    Un job clon\'e ne d\'emarrera pas de nouveaux clones, aussi il n'est pas possible de les cascader.
    
\label{Priority}
\item {\bf Priority = \lt{}number\gt{}}
   \index[dir]{Priority}
   \index[dir]{Directive!Priority}
   Cette directive vous permet de contr\^oler l'ordre d'ex\'ecution des jobs en 
   sp\'ecifiant un entier positif non nul. Plus grand est ce nombre, plus basse 
   est la priorit\'e du job. En supposant que vous n'ex\'ecutiez pas de jobs 
   simultan\'es, tous les jobs en file d'attente avec la priorit\'e 1 seront 
   ex\'ecut\'es avant ceux avec la priorit\'e 2, et ainsi de suite, sans prise en 
   compte de l'ordre original de planification.
   
   La priorit\'e affecte seulement les jobs en file d'attente, et non les jobs d\'eja 
   en cours d'ex\'ecution. Si un ou plusieurs jobs de priorit\'e 2 sont d\'ej\`a en cours 
   d'ex\'ecution, et si un nouveau job est programm\'e avec la priorit\'e 1, les jobs 
   en cours d'ex\'ecution doivent se terminer pour que le job de priorit\'e 1 puisse 
   d\'emarrer.

   La priorit\'e par d\'efaut est 10.

Si vous voulez ex\'ecutez plusieurs jobs simultan\'es, ce qui n'est pas recommand\'e, 
vous devriez garder les points suivants \`a l'esprit :

\begin{itemize}
\item Pour ex\'ecuter plusieurs jobs simultan\'es, vous devez ajuster la directive 
      {\bf Maximum Concurrent Jobs } en cinq ou six endroits diff\'erents : dans le 
      fichier bacula-dir.conf, les ressources {\bf Job}, {\bf Client}, {\bf Storage};
      dans le fichier bacula-fd, la ressource {\bf FileDaemon}; et dans le fichier 
      bacula-sd.conf, la ressource {\bf Storage}. Si vous omettez l'un d'entre eux, 
      les jobs seront ex\'ecut\'es un par un.
\item Bacula n'ex\'ecute pas simultan\'ement les jobs de priorit\'es distinctes. 
\item Si Bacula ex\'ecute un job de priorit\'e 2 et si un nouveau job de priorit\'e 
      1 est programm\'e, il attendra la fin du job de priorit\'e 1, m\^eme si les 
      param\`etres {\bf Maximum Concurrent Jobs} pourraient permettre l'ex\'ecution 
      simultan\'ee de deux jobs.
\item Supposons que Bacula soit en train d'ex\'ecuter un job de priorit\'e 2 et qu'un 
      job de priorit\'e 1 soit programm\'e et mis en queue en attente de la fin du 
      job de priorit\'e 2. Si vous d\'emarrez alors un second job de priorit\'e 2, le job 
      en attente de priorit\'e 1 emp\`echera le nouveau job de priorit\'e 2 de s'ex\'ecuter 
      en parall\`ele au premier. Ainsi : tant qu'il reste un job de priorit\'e sup\'erieure 
      \`a ex\'ecuter, aucun nouveau job de priorit\'e inf\'erieure ne pourra d\'emarrer, m\^eme si 
      les param\`etres {\bf Maximum Concurrent Jobs} devraient le permettre. Ceci permet 
      d'assurer que les jobs de priorit\'e sup\'erieure seront ex\'ecut\'es d\`es que possible.
\end{itemize}

Si vous avez plusieurs jobs de priorit\'es diff\'erentes, il est pr\'ef\'erable de ne pas les 
d\'emarrer exactement \`a la m\^eme heure, car Bacula doit les examiner un \`a la fois. Si, 
par hazard, Bacula commence par traiter un job de priorit\'e inf\'erieure, il sera 
ex\'ecut\'e avant votre job de priorit\'e \'elev\'e. Pour \'eviter cette situation, 
d\'emarrez l'un quelconque des jobs de priorit\'e \'elev\'ee quelques secondes avant 
ceux de basse priorit\'e. Ainsi, vous serez assur\'e que Bacula examine les jobs 
dans l'ordre voulu et que votre sch\'ema de priorit\'es sera respect\'e.

\label{WritePartAfterJob}

\item {\bf Write Part After Job = \lt{}yes|no\gt{}}
   \index[sd]{Write Part After Job}
   \index[dir]{Directive!Write Part After Job}
Cette directive est impl\'ement\'ee depuis la version 1.37.
Si la valeur de cette directive est {\bf yes} ({\bf no} par d\'efaut), un nouveau 
"fichier partition" (ndt : part file) sera cr\'e\'e apr\`es la fin du job. 

Cette directive devrait \^etre activ\'ee lors de l'\'ecriture sur des p\'eriph\'erique 
qui requi\`erent un montage (par exemple, les DVDs), afin de vous assurer que 
le fichier partition courant, celui qui contient les donn\'ees de ce job, est 
envoy\'e vers le p\'eriph\'erique, et qu'aucune donn\'ee n'est laiss\'ee 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 \`a chaque fois 
qu'un fichier partition est \'ecrit. Aussi, si vous ex\'ecutez plusieurs jobs \`a la 
suite, vous devriez r\'egler cette directive \`a {\bf no} pour tous ces jobs sauf 
le dernier, pour \'eviter un gaspillage important d'espace, tout en ayant la certitude 
que les donn\'ees sont bien \'ecrites sur le m\'edium lorsque tous les jobs sont 
achev\'es.

Cette directive est ignor\'ee avec les bandes et les p\'eriph\'eriques FIFO.
\end{description}

Voici un exemple de d\'efinition de ressource Job valide.

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

\subsection*{La ressource JobDefs}
\label{JobDefsResource}
\index[general]{JobDefs Resource }
\index[general]{Resource!JobDefs }
\addcontentsline{toc}{subsection}{JobDefs Resource}

La ressource Jobdefs admet toutes les directives qui peuvent appara\^itre dans 
une ressource Job. Une ressource Jobdefs ne cr\'e\'e en aucun cas un Job, son r\^ole 
est de pouvoir \^etre d\'esign\'ee dans une ressource Job comme un ensemble de 
param\`etres par d\'efaut. Ceci permet de d\'efinir plusieurs jobs similaires avec 
concision, en ne mentionnant, pour chaque job, que les diff\'erences avec les 
valeurs par d\'efaut sp\'ecifi\'ees dans la ressource Jobdefs.

\subsection*{La ressource Schedule}
\label{ScheduleResource}
\index[general]{Resource!Schedule }
\index[general]{Schedule Resource }
\addcontentsline{toc}{subsection}{Schedule Resource}

La ressource Schedule offre un moyen pour planifier automatiquement un Job, 
mais aussi la possibilit\'e de surcharger les param\`etres par d\'efaut de Level, 
Pool, Storage, et Messages ressources. Si une ressource Schedule n'est pas 
sp\'ecifi\'ee dans un job, ce job ne peut \^etre ex\'ecut\'e que manuellement. 
En g\'en\'eral, vous sp\'ecifierez une action et le moment de son lancement.

\begin{description}

\item [Schedule]
   \index[dir]{Schedule}
   \index[dir]{Directive!Schedule}
   D\'ebut des directives Schedule. La ressource {\bf Schedule} n'est pas requise, 
   mais il vous en faudra au moins une si vous souhaitez que vos jobs soient 
   ex\'ecut\'es automatiquement.
   
\item [Name = \lt{}name\gt{}]
   \index[dir]{Name}
   \index[dir]{Directive!Name}
   Le nom du Schedule d\'efini. Cette directive est requise.

\item [Run = \lt{}Job-overrides\gt{} \lt{}Date-time-specification\gt{}  ]
   \index[dir]{Run}
   \index[dir]{Directive!Run}
   La directive Run d\'efinit quand un job doit \^etre ex\'ecut\'e, et les \'eventuelles 
   surcharges \`a appliquer. Il est possible de sp\'ecifier plusieurs directives 
   {\bf run} au sein d'une ressource {\bf Schedule}, elles seront toutes 
   appliqu\'ees. Si vous avez deux directives {\bf Run} qui d\'emarrent au m\^eme 
   moment, deux jobs seront lanc\'es simultan\'ement (en fait, avec une seconde d'\'ecart).
   

La directive {\bf Job-overrides} permet d'outrepasser les sp\'ecifications de 
Level, Storage, Messages et Pool \'ecrites dans la ressource Job. De plus, 
les sp\'ecifications FullPool, DifferentialPool et IncrementalPool permettent 
de passer outre les sp\'ecification de Pool, en accord avec le niveau (level) 
effectif d'ex\'ecution du job.

L'utilisation de surcharges permet de peaufiner le param\'etrage d'un job 
particulier. Par exemple, vous pourriez surcharger une sp\'ecification 
Messages qui enverrait vos logs de backups vers un fichier, de fa\\ 3on \`a ce qu'ils 
vous soient envoy\'es par mails pour les Fulls hebdomadaires ou mensuelles.

Les directives {\bf Job-overrides} sont sp\'ecifi\'ees en tant que {\bf mot-clef=valeur} 
o\`u le mot-clef est l'un des suivants : Level, Storage,  Messages, Pool, FullPool, 
DifferentialPool ou IncrementalPool, et la {\bf valeur} est d\'efinie selon le format 
adapt\'e \`a la directive. Vous pouvez sp\'ecifier plusieurs surcharges {\bf Job-overrides} 
en une seule directive {\bf Run} en les s\'eparant par des espaces ou des 
trailing comas (traduction ?). Par exemple :

\begin{description}

\item [Level=Full]
   \index[dir]{Level}
   \index[dir]{Directive!Level}
   Tous les fichiers du FileSet qu'ils aient ou non chang\'e.

\item [Level=Incremental]
   \index[dir]{Level}
   \index[dir]{Directive!Level}
   Tous les fichiers qui ont chang\'e depuis la derni\`ere sauvegarde.

\item [Pool=Weekly]
   \index[dir]{Pool}
   \index[dir]{Directive!Pool}
   Sp\'ecifie l'utilisation du Pool nomm\'e {\bf Weekly}.

\item [Storage=DLT\_Drive]
   \index[dir]{Storage }
   \index[dir]{Directive!Storage}
   Sp\'ecifie l'utilisation du lecteur {\bf DLT\_Drive} pour p\'eriph\'erique de stockage.

\item [Messages=Verbose]
   \index[dir]{Messages }
   \index[dir]{Directive!Messages}
   Sp\'ecifie l'utilisation de la ressource messages {\bf Verbose} pour le job.

\item [FullPool=Full]
   \index[dir]{FullPool}
   \index[dir]{Directive!FullPool}

   Sp\'ecifie l'utilisation du Pool nomm\'e {\bf Full} si le job est une sauvegarde Full, 
   ou s'il a \'et\'e \'elev\'e en Full bien qu'ayant \'et\'e lanc\'e en tant que diff\'erentiel ou 
   incr\'emental.

\item [DifferentialPool=Differential]
   \index[dir]{DifferentialPool }
    \index[dir]{Directive!DifferentialPool}
    Sp\'ecifie l'utilisation du Pool nomm\'e {\bf Differential} si le job est une 
    sauvegarde diff\'erentielle.

\item [IncrementalPool=Incremental]
   \index[dir]{IncrementalPool}
   \index[dir]{Directive!IncrementalPool}
   Sp\'ecifie l'utilisation du Pool nomm\'e {\bf Incremental} si le job est une 
   sauvegarde incr\'ementale.

\item [SpoolData=yes|no]
   \index[dir]{SpoolData}
   \index[dir]{Directive!SpoolData}
   Indique \`a Bacula d'ordonner au Storage Daemon de placer les donn\'ees sur un 
   spool disque avant de les envoyer vers les cartouches.

\item [WritePartAfterJob=yes|no]
   \index[dir]{WritePartAfterJob}
   \index[dir]{Directive!WritePartAfterJob}
   Indique \`a Bacula d'ordonner au Storage Daemon d'\'ecrire le fichier partition 
   courant vers le p\'eriph\'erique lorsque le job s'ach\`eve (voir 
\ilink{la directive Write Part After Job dans la ressource Job}{WritePartAfterJob}).  
\end{description}

{\bf Date-time-specification} D\'etermine la planification d'ex\'ecution du job.
La sp\'ecification est une r\'ep\'etition, et, par d\'efaut, Bacula est param\'etr\'e 
pour ex\'ecuter un job au d\'ebut de chaque heure de chaque jour de chaque semaine 
de chaque mois de chaque ann\'ee. Ce n'est probablement pas ce que vous souhaitez, 
aussi vous devez pr\'eciser ou limiter les moments o\`u vous souhaitez voir vos jobs 
ex\'ecut\'es. Toute sp\'ecification est suppos\'ee cyclique et servira \`a limiter le 
cycle par d\'efaut. Ceci se fait en sp\'ecifiant des masques ou des horaires,  
jours de la semaine, jours du mois, semaines du mois, semaines de l'ann\'ee et 
mois de l'ann\'ee o\`u vous voulez ex\'ecuter le job. En combinant ces possibilit\'es, 
vous pouvez d\'efinir une planification qui se r\'ep\`ete \`a presque n'importe quelle 
fr\'equence.

Concr\`etement, vous devez d\'efinir les {\bf mois}, {\bf jour}, {\bf heure} et 
{\bf minute} o\`u le job est \`a ex\'ecuter. Parmis ces quatre objets, le {\bf jour} 
est particulier en ce qu'il peut sp\'ecifier un jour du mois (1,2,...31) ou de la 
semaine (Monday, Tuesday,...Sunday). Enfin, vous pouvez aussi sp\'ecifier un 
jour de la semaine pour restreindre la planification \`a la premi\`ere, deuxi\`eme, 
troisi\`eme, quatri\`eme ou cinqui\`eme semaine du mois.

Par exemple, si vous sp\'ecifiez seulement un jour de la semaine, disons {\bf Mardi}, 
le job sera ex\'ecut\'e toutes les heures de chaque mardi de chaque mois. La raison 
en est que les param\`etres {\bf Mois} et {\bf Heure} sont rest\'es \`a leurs valeurs 
par d\'efaut : chaque mois et chaque heure.

Notez que, par d\'efaut, sans autre sp\'ecification, votre job s'ex\'ecutera au 
d\'ebut de chaque heure. Si vous souhaitez que votre job s'ex\'ecute plus souvent 
qu'une fois par heure, il vous faudra d\'efinir plusieurs sp\'ecifications {\bf run} 
avec pour chacune une minut diff\'erente.

Les dates et horaires d'ex\'ecutions des jobs peuvent \^etre sp\'ecifi\'es comme suit, 
en pseudo-BNF :

\footnotesize
\begin{verbatim}
<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>
\end{verbatim}
\normalsize

\end{description}

Notez que les sp\'ecifications de semaine et d'ann\'ee suivent les d\'efinitions ISO 
standard de semaine et ann\'ee, o\`u la semaine 1 est la semaine qui contient le 
premier jeudi de l'ann\'ee, ou alternativement, la semaine qui contient le 
quatri\`eme jour de janvier. Les semaines sont num\'erot\'ees w01 \`a w53. w00 est 
pour Bacula la semaine qui pr\'ec\`ede la premi\`ere semaine ISO (c'est \`a dire celle 
qui contient les quelques premiers jours de l'ann\'ee si aucun n'est un jeudi). 
w00 n'est pas d\'efinie dans les sp\'ecifications ISO. Une semaine commence le Lundi 
et se termine le Dimanche.

Voici un exemple de ressource Schedule nomm\'ee {\bf WeeklyCycle} qui ex\'ecute 
un job de niveau Full chaque Dimanche \`a 1h05 et un job de niveau incr\'emental 
du Lundi au Samedi \`a 1h05 :

\footnotesize
\begin{verbatim}
Schedule {
  Name = "WeeklyCycle"
  Run = Level=Full sun at 1:05
  Run = Level=Incremental mon-sat at 1:05
}
\end{verbatim}
\normalsize

Voici un exemple de cycle mensuel :

\footnotesize
\begin{verbatim}
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
}
\end{verbatim}
\normalsize

Le premier de chaque mois :

\footnotesize
\begin{verbatim}
Schedule {
  Name = "First"
  Run = Level=Full on 1 at 1:05
  Run = Level=Incremental on 2-31 at 1:05
}
\end{verbatim}
\normalsize

Toutes les dix minutes :

\footnotesize
\begin{verbatim}
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
}
\end{verbatim}
\normalsize

\subsection*{Notes techniques sur les Schedules}
\index[general]{Schedules!Technical Notes on }
\index[general]{Technical Notes on Schedules }
\addcontentsline{toc}{subsection}{Notes techniques sur les Schedules}
Au niveau interne, Bacula consid\`ere 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\'ee (woy). Le schedule est initialis\'e de fa\\ 3on \`a avoir les 
bits de chacun de ces masques positionn\'es, ce qui signifie qu'au d\'ebut de chaque 
heure, le job sera ex\'ecut\'e. Quand vous sp\'ecifiez un mois pour la premi\`ere 
fois, le masque est effac\'e et le bit correspondant au mois s\'electionn\'e est 
ajout\'e au masque. Si vous sp\'ecifiez un second mois, le bit correspondant 
est aussi ajout\'e. Ainsi, lorsque Bacula examine le masque pour voir si 
les bits plac\'es correspondent \`a la date courante, votre job ne sera ex\'ecut\'e 
que pendant les deux mois que vous avez sp\'ecifi\'es. De m\^eme, si vous sp\'ecifiez 
un horaire, le masque Heure est effac\'e et le bit correspondant \`a l'heure que 
vous avez sp\'ecifi\'ee est plac\'e, les minutes sont quant \`a elles stock\'ees dans le 
champ Minutes.

Pour chacun de vos schedules, vous pouvez visualiser le masque associ\'e 
grâce \`a la commande  {\bf 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)

\subsection*{La ressource FileSet }
\label{FileSetResource}
\index[general]{Resource!FileSet }
\index[general]{FileSet Resource }
\addcontentsline{toc}{subsection}{FileSet Resource}

La ressource FileSet d\'efinit les fichiers \`a inclure dans une sauvegarde. Pour 
chaque job de type sauvegarde, il est n\'ecessaire de d\'efinir au moins une 
ressource {\bf FileSet}. Un {\bf FileSet} consiste en une liste de fichiers 
ou r\'epertoires \`a inclure, une liste de fichiers ou r\'epertoires \`a exclure, et 
diverses options de sauvegardes telles que compression, chiffrement et 
signatures qui doivent \^etre appliqu\'ees \`a chaque fichier.

Toute modification de la liste des fichiers inclus provoque la cr\'eation par Bacula 
d'un nouveau FileSet (d\'efini par le nom et la somme de contr\^ole MD5 du contenu 
du paragraphe Include). Chaque fois qu'un nouveau FileSet est cr\'e\'e, Bacula 
s'assure que la premi\`ere sauvegarde est une Full.

\begin{description}

\item [FileSet]
   \index[dir]{FileSet }
   D\'ebut de la ressource FileSet. Au moins une ressource {\bf FileSet} doit 
   \^etre d\'efinie.

\item [Name = \lt{}name\gt{}]
   \index[dir]{Name  }
   Le nom de la ressource FileSet. Cette directive est requise.

\item [Ignore FileSet Changes = \lt{}yes|no\gt{}]
   \index[dir]{Ignore FileSet Changes  }
Si cette directive est activ\'ee ({\bf yes}), toute modification des listes 
d'inclusion ou d'exclusion du FileSet sera ignor\'ee et Bacula n'\'el\`evera 
pas la prochaine sauvegarde en Full. La valeur par d\'efaut est {\bf 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\'e 
proprement. Il n'est pas recommand\'e d'activer cette directive. Cette directive 
est disponible \`a partir de Bacula 1.35.4.

\item [{Include \ \{ [ Options \{\lt{}file-options\gt{}\} ...]
   \lt{}file-list\gt{} \} 
   }]
\index[dir]{Include \  \{ [ Options \{\lt{}file-options\gt{}\} ...]
\lt{}file-list\gt{} \}  }

\item [Options \ \{ \lt{}file-options\gt{} \} 
   ]
   \index[dir]{Options \  \{ \lt{}file-options\gt{} \}  }

\item [Exclude \ \{ \lt{}file-list\gt{} \}]
   \index[dir]{Exclude \  \{ \lt{}file-list\gt{} \} }
\end{description}
La ressource Include doit contenir une liste de r\'epertoires et/ou fichiers 
\`a traiter lors de la sauvegarde. Normalement, tous les fichiers trouv\'es dans 
tous les sous-r\'epertoires de tout r\'epertoire de la liste d'inclusion des 
fichiers seront sauvegard\'es. La ressource Include peut aussi comporter une 
ou plusieurs ressources Options qui sp\'ecifient des param\`etres tels que 
la compression \`a appliquer \`a tous les fichiers ou \`a n'importe quel sous ensemble 
de fichiers \`a sauvegarder.

Le nombre de ressources {\bf Include} par FileSet n'est pas limit\'e, chacune ayant 
sa propre liste de r\'epertoires et/ou fichiers \`a sauvegarder et ses propres 
param\`etres d\'efinis par une ou plusieurs ressources Options. La liste de fichiers 
{\bf file-list} consiste en un nom de fichier ou r\'epertoire par ligne.
Les noms de r\'epertoire doivent \^etre sp\'ecifi\'es sans slash final.

Vous devez toujours sp\'ecifier des chemins absolus pour tout fichier ou 
r\'epertoire que vous placez dans un FileSet. De plus, sur les machines Windows, 
vous devez {\bf toujours} pr\'efixer le r\'epertoire ou nom de fichier d'une 
sp\'ecification de disque (par exemple : {\bf c:/xxx}) en utilisant le s\'eparateur 
de r\'epertoire Unix (slash /).

Le comportement par d\'efaut de Bacula en ce qui concerne le traitement des 
r\'epertoires est de descendre r\'ecursivement dans chaque r\'epertoire 
et de sauvegarder tous les fichiers et sous-r\'epertoires. Par d\'efaut, Bacula 
ne suit pas les syst\`emes de fichiers transverses (en terminologie Unix, les 
points de montage). Ceci signifie que si vous sp\'ecifiez la partition racine 
( par exemple /), Bacula sauvegardera seulement la partition racine, et aucun 
des syst\`emes de fichiers mont\'es. De fa\\ 3on analogue, sur les syst\`emes Windows, 
vous devez expliciter chacun des disques que vous souhaitez sauvegarder (par 
exemple {\bf c:/} et {\bf d:/}...). De plus, au moins pour les syst\`emes 
Windows, il sera la plupart du temps n\'ecessaire d'encadrer chaque sp\'ecification 
de doubles quotes, particuli\`erement si le nom du r\'epertoire (ou du fichier) 
comporte des espaces. La commande {\bf df} des syst\`emes Unix vous fournira 
la liste des r\'epertoires qu'il vous faudra sp\'ecifier pour tout sauvegarder.
Voyez ci-dessous pour un exemple.

Soyez attentif \`a ne pas inclure un r\'epertoire deux fois, car il serait 
sauvegard\'e deux fois, ce qui gaspillerait l'espace sur votre p\'eriph\'erique 
de sauvegarde. Cette erreur est facile \`a commettre. Par exemple :

\footnotesize
\begin{verbatim}
  Include {
    File = /
    File = /usr
    Options { compression=GZIP }
  }
\end{verbatim}
\normalsize

Sur un syst\`eme Unix o\`u /usr est un sous r\'epertoire (plut\^ot qu'un syst\`eme de 
fichiers mont\'e), cette ressource Include sauvegarderait /usr deux fois.
Dans ce cas, sur les versions ant\'erieures \`a 1.32f-5-09Mar04, en raison 
d'un bug, vous ne pourriez restaurer les fichiers li\'es physiquement sauvegard\'es 
deux fois.

Si vous avez utilis\'e des versions de Bacula ant\'erieures \`a 1.34.3, vous noterez 
ces modifications dans la syntaxe des FileSets :

\begin{enumerate}
\item il n'y a pas de signe \'egale (=) apr\`es le "include" et avant l'accolade 
ouvrante (\{) ;
\item chaque r\'epertoire (ou nom de fichier) \`a sauvegarder est pr\'ec\'ed\'e de 
"{\bf File =}" ;
\item les options qui apparaissaient pr\'ec\'edemmant sur la ligne Include doivent 
d\'esormais \^etre sp\'ecifi\'ees dans leur propre ressource Options.
\end{enumerate}

La ressource Options est optionnelle, mais lorsqu'elle est sp\'ecifi\'ee, elle doit 
contenir une liste de lignes "{\bf mot-clef=valeur}" relatives aux options \`a appliquer 
\`a la liste de fichiers/r\'epertoires. Plusieurs ressources Options peuvent \^etre 
sp\'ecifi\'ees l'une apr\`es l'autre. Lorsqu'un fichier se trouve dans un dossier 
sp\'ecifi\'e, les options sont appliqu\'ees au nom de fichier pour savoir s'il doit 
\^etre sauvegard\'e, et comment. Les ressources Options sont appliqu\'ees dans l'ordre 
o\`u elles appara\^issent dans le FileSet jusqu'\`a ce qu'il y en ait une qui corresponde. 
Une ressource Options qui ne contient pas de directive  {\bf wild} (sp\'ecification 
de caract\`ere joker, voir ci-dessous) est consid\'er\'ee comme concernant tous les 
fichiers. Il est important de bien comprendre ceci, car une fois que Bacula a 
d\'etermin\'e que des Options s'appliquent \`a un fichier donn\'e, ce fichier sera 
sauvegard\'e sans tenir compte d'aucunes des \'eventuelles autres ressources Options. 
Ceci signifie que toute ressource Options avec caract\`eres joker doit appara\^itre 
avant une ressource Options sans caract\`eres joker. 

Si, pour quelque raison, Bacula applique toutes les ressources Options \`a un 
fichier sans qu'aucune ne corresponde (en g\'en\'eral \`a cause de caract\`eres joker 
qui ne correspondent pas), par d\'efaut Bacula sauvegardera le fichier. Ceci est 
assez logique si vous consid\'erez la situation sans options, o\`u vous souhaitez 
que tout soit sauvegard\'e. De plus, dans le cas ou aucune correspondance n'est  
trouv\'ee, Bacula utilise les options de la derni\`ere ressource Options. Par cons\'equent, 
si vous souhaitez d\'efinir un jeu d'options par d\'efaut, vous devriez les placer 
dans la derni\`ere ressource Options.

Les directives disponibles pour les ressources Options sont les suivantes :

\begin{description}
   \item [compression=GZIP]
   \index[dir]{compression }
   Tous les fichiers sauvegard\'es sont compress\'es (NDT : compression logicielle, 
   par opposition \`a la compression mat\'erielle effectu\'ee par le lecteur) au 
   format GNU ZIP. Chaque fichier est compress\'e individuellement par le File 
   Daemon. S'il y a un probl\`eme \`a 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\'ecessaire si vous avez un lecteur de bandes moderne qui applique sa 
   propre compression. En fait, si vous activez les deux compressions 
   simultan\'ement, il se peut que vos fichiers occupent plus d'espace sur le 
   volume qu'avec une seule.

   La compression logicielle est particuli\`erement int\'eressante lorsque vous 
   sauvegardez sur disque, et peut \^etre d'un grand secours si vous avez un 
   ordinateur rapide mais un r\'eseau lent.

   La sp\'ecification {\bf GZIP}  utilise le niveau de compression six par d\'efaut 
   (i.e. {\bf GZIP} est \'equivalent \`a {\bf GZIP6}). Si vous voulez utiliser un 
   niveau diff\'erent (de 1 \`a 9), vous pouvez le sp\'ecifier en ajoutant le num\'ero 
   du niveau voulu \`a la fin du mot {\bf GZIP}, sans espace. Ainsi, {\bf compression=GZIP1} 
   d\'esigne la compression la moins efficace, mais l'algorithme le plus rapide, 
   tandis que {\bf compression=GZIP9} est le niveau de compression le plus \'elev\'e, 
   mais requi\`ere plus de puissance de calcul. Selon la documentation GZIP, les 
   niveaux de compression sup\'erieurs \`a 6 ne procurent g\'en\'eralement que peu 
   de compression suppl\'ementaire alors qu'ils sont plut\^ot exigeants en puissance 
   de calcul.

   \item [signature=SHA1]
   \index[dir]{signature }
   La signature SHA1 est calcul\'ee pour tous les fichiers sauvegard\'es. 
   L'algorithme SHA1 est 
   r\'eput\'e plus lent que MD5, mais bien meilleur d'un point de vue cryptographique 
   (i.e. beaucoup moins de collisions et probabilit\'e de piratage bien inf\'erieure.). 
   Nous recommandons fortement d'activer l'une ou l'autre des options SHA1 ou MD5 
   par d\'efaut pour tous les fichiers. Notez que seule l'une de ces deux options 
   peut \^etre activ\'ee pour tout fichier.
   
   \item [signature=MD5]
   \index[dir]{signature }
   La signature MD5 est calcul\'ee pour tous les fichiers sauvegard\'es. Activer cette 
   option r\'esulte en une charge CPU suppl\'ementaire de l'ordre de 5\% pour chaque 
   fichier sauvegard\'e. D'autre part, la signature MD5 ajoute 16 octets 
   suppl\'ementaires au catalogue pour chaque fichier sauvegard\'e. Nous recommandons 
   fortement d'activer l'une ou l'autre des options SHA1 ou MD5 par d\'efaut pour tous
   les fichiers. 

   \item [verify=\lt{}options\gt{}]
   \index[dir]{verify }
   Les "options-lettres" sont utilis\'ees lors de l'ex\'ecution de jobs de type {\bf Verify}
   de niveau {\bf Level=Catalog} et de niveau {\bf Level=DiskToCatalog}. Les options
   peuvent \^etre n'importe quelle combinaison de ces lettres.

\begin{description}

\item [i]
   compare les inodes  

\item [p]
   compare bits de permissions  

\item [n]
   compare le nombre de liens  

\item [u]
   compare les user ids  

\item [g]
   compare les group ids  

\item [s]
   compare les tailles  

\item [a]
   compare les date d'acc\`es (access time)  

\item [m]
   compare les dates de modification (st\_mtime)  

\item [c]
   compare les dates de changement (st\_ctime)  

\item [s]
   signale tout fichier dont la taille a diminu\'e  

\item [5]
   compare les signatures MD5  

\item [1]
   compare les signatures SHA1  
\end{description}

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

\item [{\bf onefs=yes|no}]
   \index[dir]{onefs }
   Si cette option est activ\'ee (valeur {\bf yes}, par d\'efaut), Bacula ne 
   changera pas de syst\`eme de fichiers. Autrement dit, il ne sauvegardera pas 
   les syst\`emes de fichiers mont\'es sur des sous-r\'epertoires. Si vous souhaitez 
   sauvegarder plusieurs syst\`emes de fichiers, vous pouvez les \'enum\'erer 
   explicitement. Une autre possibilit\'e consiste \`a d\'esactiver l'option onefs 
   ({\bf onefs=no}) afin que Bacula sauvegarde les syst\`emes de fichiers mont\'es 
   trouv\'es dans les r\'epertoires list\'es dans votre FileSet. Ainsi, si vous avez 
   des syst\`emes de fichiers NFS ou Samba mont\'es sur un r\'epertoire list\'e dans le 
   FileSet, ils seront aussi sauvegard\'es. En principe, il est pr\'ef\'erable 
   d'activer cette option et de nommer explicitement chaque syst\`eme de fichier 
   que vous voulez sauvegarder. Ce nommage explicite \'evite le risque de tomber 
   dans une boucle infinie de syst\`emes de fichiers. Voyez l'exemple ci-dessous 
   pour plus de d\'etails.

\label{portable}

\item [{\bf portable=yes|no}]
   \index[dir]{portable }
   Si cette option est activ\'ee (la valeur par d\'efaut est {\bf no}), le File Daemon 
   sauvegarde les fichiers win32 dans un format portable, mais tous les attributs 
   de fichiers win32 ne seront pas sauvegard\'es ni restaurables. La valeur par 
   d\'efaut est {\bf no}, ce qui signifie que sur les syst\`emes Win32, les donn\'ees 
   sont sauvegard\'ees en utilisant les appels Windows API et sur les WinNT/2k/XP, 
   tous les attributs de s\'ecurit\'e et de propri\'et\'e sont correctement sauvegard\'es 
   et restaur\'es. Cependant, ce format n'est pas portable aux autres syst\`emes 
   -- par exemple UNIX, Win95/98/Me. Lors de la sauvegarde de syst\`emes Unix, 
   cette option est ignor\'ee, et \`a moins que vous n'ayez un besoin sp\'ecifique de 
   portabilit\'e de vos sauvegardes, nous recommandons d'accepter la valeur par 
   d\'efaut ({\bf no}) de sorte qu'un maximum d'informations concernant vos 
   fichiers soit sauvegard\'e.

\item [{\bf recurse=yes|no}]
   \index[dir]{recurse }
   Si cette option est activ\'ee (la valeur par d\'efaut est {\bf yes}), Bacula 
   descend r\'ecursivement dans tout sous-r\'epertoire trouv\'e, \`a moins qu'il ne soit 
   explicitement exclu par une d\'efinition {\bf exclude}. Si vous d\'esactivez cette 
   option ({\bf recurse=no}), Bacula sauvegardera toutes les entr\'ees de sous-
   r\'epertoires, mais n'entrera pas dans ces sous-r\'epertoires, et ainsi ne 
   sauvegardera pas les fichiers ou \'epertoires contenus dans ces sous-r\'epertoires.
   En principe, vous pr\'ef\`ererez la valeur par d\'efaut ({\bf yes}).

\item [{\bf sparse=yes|no}]
   \index[dir]{sparse }
   Cette option active un code sp\'ecial qui d\'etecte les fichiers clairsem\'es tels 
   ceux cr\'e\'es par ndbm. Elle est d\'esactiv\'ee par d\'efaut ({\bf sparse=no}), de sorte 
   qu'aucun contr\^ole n'est fait pour rechercher les fichiers clairsem\'es. Vous 
   pouvez l'activer sans danger sur des fichiers non clairsem\'es, cependant elle 
   entra\^ine une l\'eg\`ere charge suppl\'ementaire pour la d\'etection de tampons remplis 
   de z\'eros (buffers of all zero), et un l\'eger surplus d'espace sur l'archive 
   de sortie sera utilis\'e pour ssauver les adresses de recherche de chaque 
   enregistrement non-nul trouv\'e.

{\bf Restrictions:} Bacula lit les fichiers dans des tampons de 32K. Si le tampon 
entier est rempli de z\'eros, il sera trait\'e en tant que bloc clairsem\'e, et ne sera pas 
\'ecrit sur la cartouche. En revanche, si une partie quelconque du tampon est 
non-nulle, le tampon sera int\'egralement copi\'e sur la cartouche, avec \'eventuellement 
des secteurs de disque (g\'en\'eralement 4098 octets) enti\`erement nuls. La d\'etection par 
Bacula des blocs clairsem\'es a lieu sur des blocs de 32K plut\^ot que sur des blocs de 
taille d\'etermin\'ee par le syst\`eme. Si quelqu'un consid\`ere ceci comme un r\'eelle 
probl\`eme, 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'\^etes pas familier avec les notions de fichiers clairsem\'es, prenons 
pour exemple un fichier o\`u vous \'ecrivez 512 octets \`a l'adresse 0, puis 512 octets 
\`a l'adresse 1 million. Le syst\`eme d'exploitation n'allouera que deux blocs, et 
rien n'est allou\'e pour l'espace vide. Pourtant, lorsque vous lisez le fichier 
clairsem\'e, le syst\`eme retourne tous les z\'eros comme si l'espace \'etait allou\'e, 
et si vous sauvegardez un tel fichier, vous utiliserez beaucoup d'espace 
sur le volume pour \'ecrire des z\'eros. Pire encore, lorsque vous restaurez ce 
fichier \`a son emplacement initial, tous les emplacements pr\'ec\'edemment vides 
seront cette fois allou\'es, occupant ainsi beaucoup plus d'espace disque.
En activant l'option {\bf sparse}, Bacula recherchera sp\'ecifiquement l'espace 
vide dans les fichiers afin d'\'eviter ces inconv\'enients. Le prix \`a payer est que 
Bacula doit d'abord examiner chaque bloc lu avant de l'\'ecrire. Sur un syst\`eme lent, 
ceci peut-\^etre important. Si vous suspectez certains de vos fichiers d'\^etre 
clairsem\'es, vous devriez mesurer les performances et gains d'espace avec et 
sans l'options, ou ne l'activer que pour les fichiers effectivement 
clairsem\'es.

\label{readfifo}

\item [{\bf readfifo=yes|no}]
   \index[dir]{readfifo }
Cette option, si elle est activ\'ee, indique au client de lire les donn\'ees 
(lors d'une sauvegarde) et de les \'ecrire (lors d'une restauration) sur 
un FIFO (pipe) explicitement explicitement mentionn\'e dans le FileSet.
Dans ce cas, vous devez avoir un programme actif qui \'ecrit sur ce FIFO 
dans le cas d'une sauvegarde, ou qui le lit dans le cas d'une restauration.
(Ceci peut \^etre accompli par la directive {\bf RunBeforeJob}). Si cette 
condition n'est pas satisfaite, Bacula demeurera en suspens ind\'efiniment 
en lecture/\'ecriture du FIFO. Lorsque cette option est d\'esactiv\'ee (par d\'efaut), 
le Client sauvegarde simplement l'entr\'ee du r\'epertoire pour le FIFO.

\item [{\bf mtimeonly=yes|no}]
   \index[dir]{mtimeonly }
Cette option, si elle est activ\'ee, indique au client que la s\'election de fichiers 
lors d'une sauvegarde incr\'ementale ou diff\'erentielle ne doit se r\'ef\'erer qu'aux valeurs 
de  st\_mtime du paquet stat(). La valeur par d\'efaut est {\bf no}, ce qui signifie 
que la s\'election de fichiers \`a sauvegarder se base sur les deux valeurs st\_mtime et 
st\_ctime. En g\'en\'eral, il n'est pas recommand\'e d'activer cette option.
   
\item [{\bf keepatime=yes|no}]
   \index[dir]{keepatime }
Avec cette option activ\'ee, Bacula r\'etablit le champ st\_atime (date d'acc\`es) des 
fichiers qu'il sauvegarde \`a leur valeur d'avant la sauvegarde. Cette option 
n'est g\'en\'eralement pas recommand\'ee car il existe peu de programmes qui utilisent 
st\_atime, et la charge de la sauvegarde se trouve augment\'ee par les appels 
syst\`emes n\'ecessaires pour r\'etablir les dates. (Je ne suis pas sur que ceci 
fonctionne sous Win32).

\item [{\bf wild=\lt{}string\gt{}}]
   \index[dir]{wild }
Sp\'ecifie une cha\^ine de caract\`eres jokers \`a appliquer aux fichiers. Notez 
que si {\bf Exclude} n'est pas activ\'ee, cette cha\^ine s\'electionnera les fichiers 
\`a sauvegarder. Si au contraire {\bf Exclude=yes} est sp\'ecifi\'e, la cha\^ine 
s\'electionnera les fichiers \`a exclure de la sauvegarde. Plusieurs directives 
wild-card peuvent \^etre sp\'ecifi\'ees et sont appliqu\'ees s\'equentiellement 
jusqu'\`a ce que l'une d'elles corresponde.

\item [{\bf regex=\lt{}string\gt{}}]
   \index[dir]{regex }
Sp\'ecifie une expression r\'eguli\`ere \'etendue POSIX \`a appliquer aux fichiers.
Cette directive est disponible \`a partir de Bacula 1.35. Si {\bf Exclude} n'est 
 pas activ\'ee, cette expression r\'eguli\`ere s\'electionnera les fichiers \`a 
 sauvegarder. Si au contraire {\bf Exclude=yes} est sp\'ecifi\'e, elle s\'electionnera 
 les fichiers \`a exclure de la sauvegarde. Plusieurs directives regex  peuvent \^etre 
 sp\'ecifi\'ees et sont appliqu\'ees s\'equentiellement jusqu'\`a ce que l'une d'elles corresponde.

\item [{\bf exclude=yes|no}]
   \index[dir]{exclude }
Lorsque cette option est activ\'ee, tout fichier qui correspond aux options est exclu de 
la sauvegarde. La valeur par d\'efaut est {\bf no}.

\label{ACLSupport}

\item [{\bf aclsupport=yes|no}]
   \index[dir]{aclsupport }
   Si cette option est activ\'ee, et si vous avez install\'e la librarie POSIX {\bf libacl} 
   sur votre syst\`eme, Bacula sauvegardera Listes de Contr\^oles d'Acc\`es (ACL) UNIX des 
   fichiers et r\'epertoires telles que d\'efinies dans IEEE Std 1003.1e version 17 et 
   "POSIX.1e" (abandonn\'e). Cette fonction n'est disponible que sur UNIX et d\'epend de 
   la librairie ACL. Bacula est automatiquement compil\'e avec le support ACL si la 
   librairie {\bf libacl} est install\'ee sur votre syst\`eme (ceci est report\'e 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\`eme cible, Bacula ne restaurera que les 
   fichiers et r\'epertoires sans les informations ACL. Veuillez noter que si vous 
   sauvegardez un syst\`eme de fichiers EXT3 ou XFS avec le support des ACLs, et que vous 
   restaurez vers un syst\`eme de fichiers sans ACLs (tel , peut-\^etre reiserfs), les 
   ACLs seront ignor\'ees.

\end{description}

{\bf \lt{}file-list\gt{}} est une liste de r\'epertoires et/ou noms de fichiers sp\'ecifi\'es 
avec la directive  {\bf File =}. Pour inclure des noms contenant des espaces, 
entourez-les de guillemets (doubles quotes).

Il existe quelques notations particuli\`eres pour sp\'ecifier des fichiers et r\'epertoires 
dans une liste de fichiers {\bf file-list}. Les voici :

\begin{itemize}
\item Tout nom pr\'ec\'ed\'e d'un signe "at" (@) est compris comme le nom d'un fichier, 
   lequel contient une liste de fichiers, chacun pr\'ec\'ed\'e d'une directive "File=". 
   Ce fichier est lu lorsque le fichier de configuration est parcouru au d\'emarrage 
   du Director. Notez bien que le fichier est lu sur sur la machine qui h\'eberge le 
   Director (autrement dit, le serveur de sauvegardes) et non sur le Client.
   En fait, le "@NomDeFichier" peut appara\^itre n'importe o\`u dans le fichier de 
   configuration o\`u un objet pourrait \^etre lu, le contenu du fichier d\'esign\'e sera 
   logiquement ins\'er\'e \`a l'emplacement du "@NomDeFichier". Ce qui doit figurer dans le 
   fichier d\'epend de l'emplacement du "@NomDeFichier" au sein du fichier de 
   configuration.
\item Tout nom pr\'ec\'ed\'e d'une barre verticale (|) est compris comme le nom d'un 
   programme. Ce programme sera ex\'ecut\'e sur la machine qui h\'eberge le Director au 
   moment o\`u le job d\'emarre (et non lorsque le Director lit son fichier de 
   configuration), et toute sortie de ce programme sera per\\ 3u en tant que liste 
   de fichiers ou r\'epertoires, un par ligne, \`a inclure. Ceci vous permet d'avoir un 
   job qui, par exemple, inclue toutes les partitions locales m\^eme si vous changez le 
   partitionnement en ajoutant des disques. En g\'en\'eral, il vous faudra pr\'ec\'eder 
   votre commande d'un "{\bf sh -c}" afin qu'elle soit invoqu\'ee 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'\'echapper (pr\'ec\'eder d'un \textbackslash{}) 
   les caract\`eres jokers, les caract\`eres 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\'ecessaire d'\'echapper les espaces. En g\'en\'eral, parvenir \`a avoir 
   toutes les quotes et \'echappements corrects est un calvaire, comme vous pouvez 
   le constater dans le prochain exemple. Par cons\'equent, 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 "{\bf sh -c}" ne sera plus n\'ecessaire, pourvu que la 
   premi\`ere ligne du fichier soit {\bf \#!/bin/sh}.


Par exemple : 

\footnotesize
\begin{verbatim}
 
Include {
   Options { signature = SHA1 }
   File = "|sh -c 'df -l | grep \"^/dev/hd[ab]\" | grep -v \".*/tmp\" \
      | awk \"{print \\$6}\"'"
}
\end{verbatim}
\normalsize

produira une liste de toutes les partitions locales sur un syst\`eme RedHat Linux. 
Notez que la ligne si dessus a \'et\'e coup\'ee, mais devrait normalement \^etre \'ecrite 
sur une seule ligne. Quoter est un r\'eel probl\`eme car vous devez d'une part le faire 
pour Bacula - ce qui consiste \`a pr\'ec\'eder tout \textbackslash{} et tout '' avec un 
\textbackslash{} - et d'autre part pour les commandes shell. En d\'efinitive, il est 
probablement plus ais\'e d'ex\'ecuter un petit fichier tel que :

\footnotesize
\begin{verbatim}
Include {
  Options {
    signature=MD5
  }
  File = "|my_partitions"
}
\end{verbatim}
\normalsize

o\`u le fichier my\_partitions contient :

\footnotesize
\begin{verbatim}
#!/bin/sh
df -l | grep "^/dev/hd[ab]" | grep -v ".*/tmp" \
      | awk "{print \$6}"
\end{verbatim}
\normalsize

Si la barre verticale (|) devant "my\_partitions" est pr\'ec\'ed\'ee d'une barre oblique 
(\textbackslash{}), le programme sera ex\'ecut\'e sur la machine cliente plut\^ot que sur 
la machine h\'ebergeant le Director -- (ceci est impl\'ement\'e, mais n'est pas compl\`etement 
test\'e, et a \'et\'e rapport\'e fonctionner sous Windows). Veuillez noter que si le nom de 
fichier est donn\'e 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\`eme distant :

\footnotesize
\begin{verbatim}
FileSet {
  Name = "All local partitions"
  Include {
    Options { signature=SHA1; onefs=yes; }
    File = "\\|bash -c \"df -klF ufs | tail +2 | awk '{print \$6}'\""
  }
}
\end{verbatim}
\normalsize

Notez que deux barres obliques \textbackslash{} sont requises apr\`es les doubles quotes 
(l'une pr\'eserve l'autre). Si vous utilisez Linux, changez simplement {\bf ufs} en {\bf ext3} 
(ou votre syst\`eme de fichiers pr\'ef\'er\'e) et l'affaire sera dans le sac.

\item Tout \'el\'ement de la liste de fichiers file-list pr\'ec\'ed\'e par un signe "inf\'erieur" (\lt{}) 
est interpr\'et\'e comme un fichier qui sera lu sur la machine qui h\'eberge le Director 
au moment o\`u le job d\'emarre. Son contenu est suppos\'e \^etre une liste de r\'epertoires ou 
fichiers, un par ligne, \`a inclure dans la sauvegarde. Les noms ne doivent pas \^etre quot\'es, m\^eme 
s'ils comportent des espaces. Cette fonction vous permet de modifier le fichier externe, 
et ainsi ce qui est sauvegard\'e sans avoir \`a red\'emarrer Bacula comme il le faudrait avec 
le modificateur @ d\'ecrit plus haut.

Si vous pr\'ec\'edez le signe "inf\'erieur" (\lt{}) d'une barre oblique \textbackslash{}\lt{}, le 
fichier mentionn\'e sera lu sur la machine cliente au lieu de celle h\'ebergeant le Director. 
Veullez noter que si le nom de fichier est donn\'e entre quotes, il vous faudra utiliser deux 
barres obliques.

\item Si vous sp\'ecifiez explicitement un block device (NDT ?) tel que {\bf /dev/hda1}, alors 
Bacula consid\`erera ceci comme une partition raw \`a sauvegarder. Dans ce cas, vous \^etes 
fortement invit\'e \`a utiliser l'option {\bf sparse=yes}, faute de quoi vous sauvegarderez 
la partition enti\`ere plut\^ot que seulement les donn\'ees r\'eellement contenues dans la 
partition. Par exemple :

\footnotesize
\begin{verbatim}
Include {
  Options { signature=MD5; sparse=yes }
  File = /dev/hd6
}
\end{verbatim}
\normalsize

va sauvegarder les donn\'ees de la partition /dev/hd6.

will backup the data in device /dev/hd6.  

Ludovic Strappazon a fait remarquer que cette fonction pouvait servir \`a sauvegarder 
un disque Microsoft Windows. Il suffit de booter avec un Linux Rescue Disk, puis de 
charger un client Bacula statiquement li\'e comme d\'ecrit dans le chapitre 
\ilink{ Disaster Recovery avec Bacula}{_ChapterStart38} de ce manuel. Sauvegardez alors 
la partition compl\`ete. En cas de d\'esastre, vous pouvez alors restaurer la partition 
d\'esir\'ee en bootant une fois encore sur le Linux Rescue Disk et en utilisant le 
client Bacula  statiquement li\'e.


\item Si vous sp\'ecifiez explicitement un p\'eriph\'erique FIFO nomm\'e (cr\'e\'e avec mkfifo), 
ets si vous ajoutez l'option {\bf readfifo=yes}, Bacula lira le FIFO et sauvegardera ses 
donn\'ees sur le volume. Par exemple :

\footnotesize
\begin{verbatim}
Include {
  Options {
    signature=SHA1
    readfifo=yes
  }
  File = /home/abc/fifo
}
\end{verbatim}
\normalsize

si {\bf /home/abc/fifo} est un FIFO, Bacula va l'ouvrir, le lire, et stocker 
toutes les donn\'ees ainsi obtenues sur le volume. Notez qu'il faut que vous ayez 
un processus qui \'ecrit sur le FIFO, faute de quoi Bacula restera en suspens, et 
abandonnera au bout d'une minute pour passer au fichier suivant. Les donn\'ees 
lues peuvent \^etre de nature quelconque puisque Bacula les traite comme un flux.

Cette fonction est un excellent moyen de faire une sauvegarde "\`a chaud" d'une 
tr\`es grosse base de donn\'ees. Vous pouvez utiliser la directive {\bf RunBeforeJob} 
pour cr\'eer le FIFO et d\'emarrer un programme qui lit dynamiquement votre base de 
donn\'ees et l'\'ecrit sur le FIFO. Bacula l'\'ecrira alors sur le volume.

Lors de l'op\'eration de restauration, l'inverse se produit : apr\`es que Bacula ait cr\'e\'e 
le FIFO, s'il y avait des donn\'ees stock\'ees par son biais (inutile de les lister 
explicitement ni d'ajouter aucune option), elles seront renvoy\'ees vers le FIFO. 
Par cons\'equent, s'il existe un tel FIFO \`a restaurer, vous devez vous assurer 
qu'il y a un programme lecteur ou Bacula se bloquera et passera au fichier suivant 
apr\`es une minute.

\end{itemize}

\end{description}

Voici un exemple de d\'efinition de ressource FileSet valide. Notez que le premier 
Include  ins\`ere le contenu du fichier {\bf /etc/backup.list} lors du d\'emarrage 
de Bacula (i.e. le @). 

\footnotesize
\begin{verbatim}
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
  }
}
\end{verbatim}
\normalsize

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

Les deux r\'epertoires /root/myfile et /usr/lib/another\_file seront aussi 
sauvegard\'es sans aucune option, mais tous les fichiers \`a extension  {\bf .o} 
de ces r\'epertoires seront exlus de la sauvegarde.  

Supposons que vous vouliez sauvegarder tout sauf {\bf /tmp} sur votre syst\`eme.
La commande {\bf df} vous fournit le r\'esultat suivant :

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

Si vous vous contentez de sp\'ecifier {\bf /} dans votre liste d'inclusions, 
Bacula ne sauvegardera que le syst\`eme de fichiers {\bf /dev/hda5}. Pour 
sauvegarder tous vos syst\`emes de fichiers sans inclure les syst\`emes de fichiers 
mont\'es Samba ou NFS et en excluant /tmp, /proc, .journal, et .autofsck, que 
vous ne voulez ni sauvegarder ni restaurer, vous pouvez utiliser ce qui suit :

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

/tmp \'etant sur son propre syst\`eme de fichiers et n'\'etant pas explicitement nomm\'e 
dans la liste d'inclusion, il n'est pas n\'ecessaire de le sp\'ecifier dans la liste 
d'exclusion. Cependant, il peut \^etre pr\'ef\'erable de le faire malgr\'e tout par 
souci de clart\'e et au cas o\`u il ne serait plus sur sa propre partition apr\`es un 
remplacement de disques.

Ayez conscience qu'il peut \^etre {\bf tr\`es} dangereux de permettre \`a Bacula de traverser ou 
changer de syst\`eme de fichiers au gr\'e des ppoints de montage. Par exemple, avec ce qui suit : 

\footnotesize
\begin{verbatim}
FileSet {
  Name = "Bad example"
  Include {
    Options { onefs=no }
    File = /mnt/matou
  }
}
\end{verbatim}
\normalsize

vous sauvegardez une partition NFS mont\'ee ({\bf /mnt/matou}), et puisque 
{\bf onefs} est d\'esactiv\'ee, Bacula traverse les syst\`emes de fichiers. 
Si jamais {\bf /mnt/matou} contient lui m\^eme un point de montage o\`u le syst\`eme 
de fichiers de la machine sauvegard\'ee est mont\'e, ce qui est souvent le cas, 
vous vous retrouvez pris dans un boucle r\'ecursive, et la sauvegarde ne se 
terminera jamais.

Le FileSet suivant sauvegarde une partition raw :

\footnotesize
\begin{verbatim}
FileSet {
  Name = "RawPartition"
  Include {
    Options { sparse=yes }
    File = /dev/hda2
  }
}
\end{verbatim}
\normalsize

Lorsque vous sauvegardez et restaurez une partition raw, vous devriez vous 
assurer qu'aucun autre processus, y compris le syst\`eme, n'\'ecrit sur cette 
partition. En guise de pr\'ecaution, nous recommandons ardemment de ne sauvegarder 
en mode raw que des partitions non mont\'ees, ou mont\'ees en lecture seule. Ceci peut 
\^etre fait si n\'ecessaire avec la directive {\bf RunBeforeJob}.

\label{win32}

\subsection*{Consid\'erations sur les FileSets Windows}
\index[general]{FileSets!Windows Considerations for }
\index[general]{Windows Considerations for FileSets }
\addcontentsline{toc}{subsection}{Windows Considerations for FileSets}

Si vous saisissez des noms de fichiers Windows, les chemins des r\'epertoires devraient 
\^etre pr\'ec\'ed\'es de double-points (comme dans "c:"). Cependant, les s\'eparateurs de 
champs doivent \^etre sp\'ecifi\'es selon la convention Unix (c'est \`a dire, la barre oblique 
avant : "/"). Si vous souhaitez inclure une apostrophe dans un nom de fichier, pr\'ec\'edez-la 
d'une barre oblique arri\`ere (\textbackslash{}\textbackslash{}). Par exemple, vous pourriez 
utiliser ce qui suit pour sauvegarder le r\'epertoire "My Documents" d'une machine Windows :

\footnotesize
\begin{verbatim}
FileSet {
  Name = "Windows Set"
  Include {
    Options {
       wild = *.obj
       wild = *.exe
       exclude = yes
     }
     File = "c:/My Documents"
  }
}
\end{verbatim}
\normalsize

Pour que les listes d'exclusion fonctionnent correctement sous Windows, vous devez 
observer les r\`egles suivante :

\begin{itemize}
\item les noms de fichiers sont sensibles \`a la casse, aussi vous devez utilise la 
casse correcte ;
\item vous ne devez pas sp\'ecifier de barre oblique finale pour exclure un r\'epertoire ;
\item si vos noms de fichiers comportent des espaces, vous devez les encadrer de 
quillemets. Les barres obliques arri\`eres (\textbackslash{}\textbackslash{}) ne 
fonctionnent pas ;
\item si vous utilisez l'ancienne syntaxe des listes d'exclusion (mentionn\'ee ci-dessous), 
vous ne devriez pas sp\'ecifier la lettre r\'ef\'eren\\ 3ant le disque dans une liste d'exclusion. 
La nouvelle syntaxe d\'ecrite ci-dessus devrait fonctionner correctement en incluant la lettre 
du disque.
\end{itemize}

Merci \`a Thiago Lima pour nous avoir r\'esum\'e les points ci-dessus. Si vous rencontrez 
des difficult\'es pour faire fonctionner vos listes d'inclusion ou d'exclusion, 
songez \`a utiliser la commande {\bf estimate job=xxx listing} document\'ee 
dans le chapitre \ilink{Console chapter}{estimate} de ce manuel.

Sur les syst\`emes Win32, si vous d\'eplacez un r\'epertoire ou si vous renommez 
un fichier de la liste \`a sauvegarder, et si une Full a d\'ej\`a eu lieu, Bacula 
ne saura reconna\^itre qu'il existe de nouveaux fichiers \`a sauvegarder lors d'une 
incr\'ementale ou d'une diff\'erentielle (faites-en le reproche \`a Microsoft, pas \`a moi !). 
Pour pallier \`a ce probl\`eme, veuillez copier tout r\'epertoire ou fichier de la 
zone sauvegard\'ee. Si vous ne disposez pas de suffisamment d'espace disque, 
d\'eplacez-les, mais lancez alors une sauvegarde Full.

\subsubsection*{Exclusion de fichiers et r\'epertoires}
\index[general]{Directories!Excluding Files and }
\index[general]{Excluding Files and Directories }
\addcontentsline{toc}{subsubsection}{Exclusion de fichiers et r\'epertoires}

Vous pouvez aussi inclure des noms de fichiers ou chemins absolus, en plus 
de l'utilisation de caract\`eres jokers et de la directive {\bf Exclude=yes} dans 
les ressources Options comme expos\'e ci-dessus, en ajoutant simplement 
les fichiers \`a exclure dans une ressource Exclude du FileSet. Par exemple :

\footnotesize
\begin{verbatim}
FileSet {
  Name = Exclusion_example
  Include {
    Options {
      Signature = SHA1
    }
    File = /
    File = /boot
    File = /home
    File = /rescue
    File = /usr
  }
  Exclude {
    File = /proc
    File = /tmp
    File = .journal
    File = .autofsck
  }
}
\end{verbatim}
\normalsize

\subsection*{Un exemple de FileSet Windows}
\index[general]{FileSet!Windows Example }
\index[general]{Un exemple de FileSet Windows}
\addcontentsline{toc}{subsection}{Un exemple de FileSet Windows}

Cet exemple est une contribution de Phil Stracchino :

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

Remarque : les trois lignes coup\'ees de cette liste d'exclusion ne l'ont \'et\'e 
que pour des motifs de mise en page, elles doivent en r\'ealit\'e \^etre \'ecrites 
sur une seule ligne.

\subsection*{L'ancienne ressource FileSet}
\index[general]{Resource!Old FileSet }
\index[general]{L'ancienne ressource FileSet}
\addcontentsline{toc}{subsection}{L'ancienne ressource FileSet}

L'ancienne Ressource FileSet des versions ant\'erieures \`a 1.34.3 est obsol\`ete, 
mais fonctionne encore. Nous vous encourageons \`a utiliser la nouvelle forme, 
car le code correspondant sera supprim\'e \`a partir de la version 1.37.

\subsection*{Tester vos FileSets}
\index[general]{FileSet!Testing Your }
\index[general]{Tester vos FileSets }
\addcontentsline{toc}{subsection}{Tester vos FileSets}

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

\subsection*{Considerations sur le nommage Windows NTFS}
\index[general]{Considerations sur le nommage Windows NTFS}
\index[general]{Considerations!Windows NTFS Naming }
\addcontentsline{toc}{subsection}{Considerations sur le nommage Windows NTFS}

Les noms de fichiers NTFS contenant des caract\`eres Unicode (i.e. \gt{} 0xFF) ne 
peuvent, pour le moment, \^etre nomm\'e eplicitement. Vous devez inclure de tels 
fichiers en d\'esignant un r\'epertoire de niveau sup\'erieur ou une lettre de disque 
ne contenant pas de caract\`ere Unicode.

\subsection*{La ressource Client}
\label{ClientResource2}
\index[general]{Resource!Client }
\index[general]{La ressource Client}
\addcontentsline{toc}{subsection}{La ressource Client} 

La ressource Client d\'efinit les attributs des clients servis (sauvegard\'es) 
par ce Director. Il faut une ressource Client par machine sauvegard\'ee.

\begin{description}

\item [Client (ou FileDaemon)]
   \index[dir]{Client (ou FileDaemon)}
   \index[dir]{Directive!Client (or FileDaemon)}
   D\'ebut des directives Client.

\item [Name = \lt{}name\gt{}]
   \index[dir]{Name}
   \index[dir]{Directive!Name}
Le nom du client qui sera utilis\'e dans la directive Job de la ressource ou 
dans une commande run de la Console. Cette directive est requise.

\item [Address = \lt{}address\gt{}]
   \index[dir]{Address}
   \index[dir]{Directive!Address}
L'adresse d'un File Daemon Bacula est un nom d'h\^ote, un nom pleinement qualifi\'e 
ou une adresse r\'eseau au format quatre octets point\'es. Cette directive est requise.

\item [FD Port = \lt{}port-number\gt{}]
   \index[dir]{FD Port}
   \index[dir]{Directive!FD Port}
O\`u le port est le num\'ero de port auquel le le File Daemon peut \^etre contact\'e. 
La valeur par d\'efaut est 9102.


\item [Catalog = \lt{}Catalog-resource-name\gt{}]
   \index[dir]{Catalog}
   \index[dir]{Directive!Catalog}
Cette directive sp\'ecifie le nom de la ressource catalog \`a utiliser pour ce 
client. Cette directive est requise.

\item [Password = \lt{}password\gt{}]
   \index[dir]{Password}
   \index[dir]{Directive!Password}
Il s'agit ici du mot de passe \`a utiliser lors de la connection avec le 
File Daemon, aussi le fichier de configuration de la machine \`a sauvegarder 
doit d\'efinir le m\^eme mot de passe pour \^etre connect\'e par ce Director. 
Cette directive est requise. Si vous disposez de {\bf /dev/random} ou de {\bf bc} 
sur votre machine, Bacula g\'en\`ere des mots de passe al\'eatoires lors du processus 
de configuration. Dans le cas contraire, le mot de passe est laiss\'e blanc.

\label{FileRetention}

\item [File Retention = \lt{}time-period-specification\gt{}  ]
   \index[dir]{File Retention  }
   \index[dir]{Directive!Password}
La directive File Retention d\'efinit la p\'eriode pendant laquelle Bacula conservera 
les enregistrements File dans le catalogue. Lors de l'expiration de cette p\'eriode, 
si la directive {\bf AutoPrune} est active ({\bf yes}), Bacula \'elague le catalogue 
des enregistrements File dont l'âge est sup\'erieur \`a la p\'eriode de r\'etention. 
Notez que ceci n'affecte que les enregistrements du catalogue, et non vos 
sauvegardes archiv\'ees.

Les enregistrements File peuvent en fait \^etre conserv\'es pour une p\'eriode inf\'erieure 
\`a celle affect\'ee \`a cette directive dans les cas o\`u vous avez sp\'ecifi\'e des p\'eriodes 
plus courtes pour les directives  {\bf Job Retention} ou {\bf Volume Retention}. 
La plus courte des trois prend le pas sur les autres. Les dur\'ees peuvent \^etre exprim\'ees 
en secondes, minutes, heures, jours, semaines, mois, trimestres ou ann\'ees. Consultez 
le chapitre \ilink{Adapter les fichiers de configuration}{Time} de ce manuel pour plus de d\'etails sur les 
sp\'ecifications de dur\'ees.

La valeur par d\'efaut est de 60 jours.
\label{JobRetention}

\item [Job Retention = \lt{}time-period-specification\gt{}  ]
   \index[dir]{Job Retention}
   \index[dir]{Directive!Job Retention}
La directive Job Retention d\'efinit la p\'eriode pendant laquelle Bacula conservera
les enregistrements Job dans le catalogue. Lors de l'expiration de cette p\'eriode,
si la directive {\bf AutoPrune} est active ({\bf yes}), Bacula \'elague le catalogue
des enregistrements File dont l'âge est sup\'erieur \`a la p\'eriode de r\'etention.
Notez que ceci n'affecte que les enregistrements du catalogue, et non vos
sauvegardes archiv\'ees.
   
Si un enregistrement de Job est s\'electionn\'e pour \'elagage, tous les enregistrements File 
et JobMedia associ\'es seront aussi \'elagu\'es du catalogue, sans qu'il ne soit tenu compte 
de la p\'eriode File Retention d\'efinie. Par cons\'equent, vous utiliserez, en principe, 
une p\'eriode File Retention inf\'erieure \`a la p\'eriode Job retention. La p\'eriode 
Job retention peut en fait s'av\'erer inf\'erieure \`a la valeur que vous avez sp\'ecifi\'ee 
si vous avez affect\'e une valeur inf\'erieure \`a la directive {\bf Volume Retention} dans 
la ressource Pool. Les p\'eriodes Job retention et  Volume retention sont appliqu\'ees 
ind\'ependamment, la plus petite prend le pas sur l'autre.

Les dur\'ees peuvent \^etre exprim\'ees
en secondes, minutes, heures, jours, semaines, mois, trimestres ou ann\'ees. Consultez
le chapitre \ilink{Adapter les fichiers de configuration}{Time} de ce manuel pour plus de d\'etails sur les
sp\'ecifications de dur\'ees.

La valeur par d\'efaut est 180 jours.  
\label{AutoPrune}

\item [AutoPrune = \lt{}yes|no\gt{}]
   \index[dir]{AutoPrune}
   \index[dir]{Directive!AutoPrune}
Si AutoPrune est r\'egl\'e \`a {\bf yes} (valeur par d\'efaut), Bacula (dans les versions au del\`a 
de 1.20) applique automatiquement les p\'eriodes File retention et Job  retention pour le 
client \`a la fin du job. Si vous sp\'ecifiez {\bf AutoPrune = no}, l'\'elagage ne se fera pas 
et votre catalogue grossira \`a chaque job. L'\'elagage n'affecte que les donn\'ees du catalogue, 
et non les donn\'ees stock\'ees sur les volumes.

\item [Maximum Concurrent Jobs = \lt{}number\gt{}]
   \index[dir]{Maximum Concurrent Jobs}
   \index[dir]{Directive!Maximum Concurrent Jobs}
\lt{}number\gt{} d\'esigne le nombre maximum de jobs qui peuvent \^etre lanc\'es simultan\'ement 
sur le client concern\'e. Notez que cette directive ne limite que les jobs pour les clients 
qui ont le m\^eme nom que la ressource dans laquelle elle appara\^it. Toutes les autres restrictions 
du nombre maximum de jobs simultan\'es telles que celles sp\'ecifi\'ees dans les ressources 
Director, Job, ou Storage s'appliquent aussi en plus de toute limite fix\'ee ici. La valeur 
par d\'efaut est 1, mais vous pouvez sp\'ecifier une valeur plus grande. Nous recommandons 
fortement de lire les MISES EN GARDE de la section \ilink{ Maximum Concurrent 
Jobs}{DirMaxConJobs} du chapitre Configurer le Director.


\item [Priority = \lt{}number\gt{}]
   \index[dir]{Priority}
   \index[dir]{Directive!Priority}
\lt{}number\gt{} sp\'ecifie la priorit\'e de ce client par rapport aux autres clients 
que le Director sauvegarde simultan\'ement. La priorit\'e admet une valeur entre 1 et 1000.
Les clients sont ordonn\'es de sorte que ceux dont la valeur de priorit\'e sont les plus petites 
sont trait\'es les premiers (Ceci n'est pas encore impl\'ement\'e).
\end{description}

Voici un exemple d'une d\'efinition de ressource Client valide :

\footnotesize
\begin{verbatim}
Client {
  Name = Minimatou
  Address = minimatou
  Catalog = MySQL
  Password = very_good
}
\end{verbatim}
\normalsize

\subsection*{La ressource Storage}
\label{StorageResource2}
\index[general]{Resource!Storage }
\index[general]{Storage Resource }
\addcontentsline{toc}{subsection}{Storage Resource}

La ressource Storage d\'efinit les Storage Daemons disponibles pour le Director.

\begin{description}

\item [Storage]
   \index[dir]{Storage}
   \index[dir]{Directive!Storage}
D\'ebut des ressources Storage. Il faut en sp\'ecifier au moins une.

\item [Name = \lt{}name\gt{}]
   \index[dir]{Name}
   \index[dir]{Directive!Name}
Le nom de la ressource Storage. Ce nom appara\^it au niveau de la directive 
Storage sp\'ecifi\'ee dans la ressource Job et est requise.

\item [Address = \lt{}address\gt{}]
   \index[dir]{Address}
   \index[dir]{Directive!Address}
O\`u l'adresse est un nom d'h\^ote, une {\bf adresse pleinement qualifi\'ee}, ou une 
{\bf adresse IP}. Notez bien que l'adresse sp\'ecifi\'ee ici sera transmise au 
File Daemon qui l'utilisera alors pour contacter le Storage Daemon. Aussi, ce 
n'est {\bf pas} une bonne id\'ee d'utiliser {\bf localhost} en tant que nom, 
il vaut mieux utiliser un nom de machine pleinement qualifi\'e, ou une adresse IP.
Cette directive est requise.

\item [SD Port = \lt{}port\gt{}]
   \index[dir]{SD Port}
   \index[dir]{Directive!SD Port}
O\`u "port" est le port \`a utiliser pour contacter le Storage Daemon pour les 
informations et pour ex\'ecuter les jobs. Ce m\^eme num\'ero de port doit 
appara\^itre dans la ressource Storage du fichier de configuration du 
Storage Daemon. Le port par d\'efaut est 9103.

\item [Password = \lt{}password\gt{}]
   \index[dir]{Password}
   \index[dir]{Directive!Password}
Il s'agit du mot de passe \`a utiliser lors de l'\'etablissement de la connection 
avec les services Storage. Ce m\^eme mot de passe doit aussi appara\^itre dans la 
ressource Director du fichier de configuration du Storage Daemon. Cette 
directive est requise. Si vous avez soit {\bf /dev/random}, soit {\bf bc} 
sur votre machine, Bacula g\'en\`erera un mot de passe al\'eatoire lors du processus 
de configuration. Dans le cas contraire, ce champ sera laiss\'e blanc.

\item [Device = \lt{}device-name\gt{}]
   \index[dir]{Device}
   \index[dir]{Directive!Device}
Cette directive sp\'ecifie le nom (pour le Storage Daemon) du p\'eriph\'erique \`a 
utiliser pour le stockage. 
Ce nom n'est pas le nom de p\'eriph\'erique physique, mais le nom de p\'eriph\'erique 
logique qui a \'et\'e d\'efini par la directive {\bf Name} de la ressource {\bf Device} 
du fichier de configuration du Storage Daemon. Si le p\'eriph\'erique est une librairie, vous 
devez utiliser le nom d\'efini au niveau de la directive {\bf Name} d\'efini dans la d\'efinition 
de la ressource  {\bf Autochanger} du Storage Daemon. Vous pouvez utiliser le nom de 
votre choix (y compris le nom de p\'eriph\'erique physique) \`a concurrence de 
127 caract\`eres. Le nom de p\'eriph\'erique physique associ\'e \`a ce p\'eriph\'erique est 
sp\'ecifi\'e dans le fichier de configuration du Storage Daemon 
(en tant qu'{\bf Archive  Device}). Prenez garde \`a ne pas d\'efinir deux directives 
Storage Resource dans le Director qui pointent vers le m\^eme p\'eriph\'erique du 
Storage Daemon. Il pourrait en r\'esulter un blocage du Storage Daemon si celui-ci 
tente d'utiliser le m\^eme p\'eriph\'erique deux fois. Cette directive est requise.

\item [Media Type = \lt{}MediaType\gt{}]
   \index[dir]{Media Type}
   \index[dir]{Directive!Media Type}
Cette directive sp\'ecifie le type de m\'edia \`a utiliser pour stocker les donn\'ees. 
Il s'agit d'une cha\^ine de caract\`eres arbitraire n'exc\'edant pas 127 caract\`eres. 
Ce peut \^etre ce que vous voulez, cependant, il est pr\'ef\'erable de la choisir de 
mani\`ere \`a d\'ecrire le m\'edium de stockage utilis\'e (par exemple : Fichier, DAT, 
''HP  DLT8000``, 8mm,...). D'autre part, il est esentiel d'avoir une sp\'ecification 
{\bf Media Type} unique pour chaque type de m\'edia de stockage. Si vous avez deux 
lecteurs DDS-4 avec des formats incompatibles et une librairie DDS-4, vous devriez 
certainement sp\'ecifier des {\bf Media Types} distincts. Lors d'une restauration, 
supposons qu'un Media Type {\bf DDS-4} est associ\'e avec le le job, Bacula peut 
d\'ecider d'utiliser tout Storage Daemon qui supporte le Media Type {\bf DDS-4} sur 
tout lecteur qui le supporte. 

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

Si vous voulez contraindre Bacula \`a utiliser un 
seul Storage Daemon ou un seul lecteur, vous devez sp\'ecifier un Media Type unique 
pour ce lecteur. C'est un point important qui devrait \^etre bien compris. Notez que 
ceci s'applique \'egalement aux volumes disque. Si vous d\'efinissez plus d'une ressource 
Device disque dans votre fichier de configuration du Storage Daemon, les volumes sur ces 
deux devices seront en fait incompatibles car l'un ne pourra \^etre mont\'e sur l'autre 
puisqu'ils se trouvent dans des r\'epertoires diff\'erents. C'est pourquoi vous devriez 
probablement plut\^ot utiliser deux Media Types distincts pour vos deux devices disque 
(m\^eme si vous pensez \`a eux comme ayant l'un et l'autre le type File).

Vous trouverez pus de d\'etails \`a ce sujet dans le chapitre 
\ilink{Gestion des volumes : fondements (NDT:basic volumes management)}
{_ChapterStart39} de ce manuel.

Le {\bf MediaType} sp\'ecifi\'e ici {\bf doit} correspondre au {\bf MediaType} 
sp\'ecifi\'e dans la ressource {\bf Device} du fichier de configuration du 
Storage Daemon. Cette directive est requise, et est utilis\'ee par le Director 
et le Storage Daemon pour s'assurer qu'un volume s\'electionn\'e automatiquement 
dans un Pool correspond \`a un p\'eriph\'erique physique. Si un Storage Daemon 
g\`ere plusieurs p\'eriph\'eriques (par exemple, s'il \'ecrit sur plusieurs volumes 
de type File sur diff\'erentes partitions), cette directive vous permet de 
pr\'eciser exactement quel p\'eriph\'erique utiliser.

Comme mentionn\'e ci-dessus, la valeur sp\'ecifi\'ee dans la ressource Storage du 
Director doit s'accorder avec celle sp\'ecifi\'ee dans la ressource Device du 
fichier de configuration du Storage Daemon. Ceci repr\'esente aussi un contr\^ole 
suppl\'ementaire pour assurer que vous n'essayez pas d'\'ecrire les donn\'ees destin\'ees 
\`a un lecteur DLT sur un lecteur 8mm.

\label{Autochanger1}

\item [Autochanger = \lt{}yes|no\gt{}  ]
   \index[dir]{Autochanger  }
   \index[dir]{Directive!Autochanger}
Si vous sp\'ecifiez {\bf yes} pour cette commande (la valeur par d\'efaut est {\bf no}), 
alors Bacula requ\'erira un num\'ero de Slot lorsque vous utiliserez les commandes 
{\bf label} et {\bf add} pour cr\'eer un nouveau volume. Ceci simplifie la cr\'eation 
des enregistrements de Volumes dans le catalogue si vous disposez d'une librairie. 
Si vous omettez de sp\'ecifier le Slot, la robotique ne sera pas utilis\'ee. Cependant, 
vous pouvez modifier le Slot associ\'e \`a un volume \`a tout moment grâce \`a la commande 
{\bf update volume} du programme Console. Lorqu'{\bf autochanger} est activ\'ee, 
l'algorithme utilis\'e par Bacula pour rechercher des volumes utilisables est 
modifi\'e de fa\\ 3on \`a prendre en compte tout volume suppos\'e contenu dans la librairie. 
Si aucun volume {\bf in changer} n'est trouv\'e, Bacula tente de recycler, \'elaguer..., 
et s'il ne trouve toujours aucun volume, Bacula recherche un volume pr\'esent ou non 
dans la librairie. Privil\'egier les volumes pr\'esents dans la librairie permet de 
minimiser les interventions d'un op\'erateur. 

Pour que la robotique soit utilis\'ee, vous devez aussi sp\'ecifier {\bf Autochanger = yes} 
dans la ressource \ilink{La Ressource Device}{Autochanger} du fichier de configuration du 
Storage Daemon, ainsi que d'autres param\`etres importants du Storage Daemon. Vous 
trouverez plus d'information \`a ce sujet dans le chapitre 
\ilink{ Utiliser une librairie}{_ChapterStart18} de ce manuel.

\item [Maximum Concurrent Jobs = \lt{}number\gt{}]
   \index[dir]{Maximum Concurrent Jobs}
   \index[dir]{Directive!Maximum Concurrent Jobs}
O\`u \lt{}number\gt{} est le nombre maximum de jobs utilisant la 
ressource Storage courante qui peuvent \^etre ex\'ecut\'es simultan\'ement. Notez que cette 
directive ne limite que les jobs qui utilisent ce Storage Daemon. Toute autre 
limitation du nombre maximum de jobs simultan\'es au niveau des ressources 
Director, Job ou Client est aussi appliqu\'ee en plus de celle fix\'ee ici. La valeur 
par d\'efaut est 1, mais vous pouvez utiliser une valeur plus importante. Nous vous 
recommandons fortement de lire les MISES EN GARDE de la section \ilink{ Maximum Concurrent
Jobs}{DirMaxConJobs} du chapitre Configurer le Director.

Alors qu'il est possible de d\'efinir des nombres maximum de jobs simultan\'es sup\'erieurs 
\`a 1 dans les ressource Director, Job et Client, vous devriez porter une attention 
particuli\`ere au param\'etrage de cette directive pour le Storage Daemon. En conservant 
la valeur 1, vous \'evitez que deux jobs \'ecrivent simultan\'ement sur le m\^eme volume ce qui, 
quoique support\'e, n'est pas recommand\'e actuellement.
\end{description}

Voici un exemple de ressource Storage valide :

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

\subsection*{La ressource Pool}
\label{PoolResource}
\index[general]{Resource!Pool }
\index[general]{Pool Resource }
\addcontentsline{toc}{subsection}{Pool Resource}
La ressource Pool d\'efinit l'ensemble des volumes de stockage (cartouches ou fichiers) 
\`a la disposition de Bacula pour \'ecrire les donn\'ees. En configurant diff\'erents 
Pools, vous pouvez d\'eterminer quel ensemble de volumes (ou m\'edia) re\\ 3oit les 
donn\'ees sauvegard\'ees. Ceci permet, par exemple, de stocker toutes les sauvegardes 
Full sur un ensemble de volumes, et les sauvegardes diff\'erentielles et 
incr\'ementales sur un autre. De m\^eme, vous pouvez assigner un ensemble de volumes 
\`a chaque machine sauvegard\'ee. Tout ceci peut \^etre r\'ealis\'e ais\'ement en d\'efinissant 
plusieurs pools.

Un autre aspect important d'un pool est qu'il contient des attributs par d\'efaut 
(Nombre maximum de jobs, p\'eriode de r\'etention, drapeau de recyclage,...) qui sont 
conf\'er\'es \`a tout volume lui appartenant lors de sa cr\'eation. Ceci vous \'evite d'avoir 
\`a r\'epondre \`a un grand nombre de questions lorsque vous \'etiquettez (label) un nouveau 
volume. Chacun de ces attributs peut ensuite \^etre modifi\'e sur chaque volume 
individuellement avec la commande {\bf update} du programme Console. Notez que 
vous devez pr\'eciser explicitement quel pool est \`a utiliser avec chaque job. Bacula 
ne recherche pas automatiquement le pool correct.

Dans la plupart des installations de Bacula, toutes les sauvegardes de toutes 
les machines vont vers un unique jeu de volumes. Dans ce cas, vous n'utiliserez 
probablement que le pool par d\'efaut {\bf Default}. Si votre strat\'egie de 
sauvegarde vous impose \`a monter chaque jour une cartouche diff\'erente, vous voudrez 
probablement d\'efinir des pools distincts pour chaque jour. Pour plus d'informations 
\`a ce sujet, consultez le chapitre \ilink{Strat\'egies de sauvegarde}{_ChapterStart3} 
de ce manuel.

Pour utiliser un pool, vous devez suivre trois \'etapes :

D'abord, le pool doit 
\^etre d\'efini dans le fichier de configuration du Director. Ensuite le pool doit 
\^etre enregistr\'e dans le catalogue. Ceci est fait automatiquement par le Director 
\`a chaque fois qu'il d\'emarre, ou peut \^etre r\'ealis\'e manuellement \`a l'aide de la 
commande {\bf create} du programme Console. Enfin, si vous modifiez la d\'efinition 
du pool dans le fichier de configuration du Director et red\'emarrez Bacula, 
le pool sera mis \`a jour automatiquement, ce qui peut aussi \^etre r\'ealis\'e 
manuellement avec la commande {\bf update pool} du programme Console pour 
rafraichir l'image du catalogue. C'est cette image du catalogue plut\^ot 
que l'image de la ressource du Director qui est utilis\'ee pour les attributs 
de volume par d\'efaut. Notez que pour que le pool soit automatiquement 
cr\'e\'e ou mis \`a jour, il doit \^etre r\'ef\'erenc\'e explicitement par une ressource Job.

Ensuite le m\'edium physique doit \^etre \'etiquett\'e. L'\'etiquettage peut \^etre r\'ealis\'e 
soit par la commande {\bf label} du programme Console, soit en utilisant le 
programme {\bf btape}. La m\'ethode \`a privil\'egier est la premi\`ere.

Finallement, vous devez ajouter des noms de volumes (et leurs attributs) au 
pool. Pour que les volumes soient utilis\'es par Bacula, ils doivent \^etre 
du m\^eme {\bf Media Type} que l'Archive Device sp\'ecifi\'ee pour le job. 
(Autrement dit, si vous vous appr\'etez \`a sauvegarder vers un lecteur DLT, 
le pool doit contenir des volumes DLT, puisque des volumes 8mm ne peuvent 
\^etre mont\'es sur un lecteur DLT). Le {\bf Media Type} rev\^et une importance 
particuli\`ere si vous sauvegardez vers des fichiers. Lorsque vous ex\'ecutez 
un job, vous devez explicitement pr\'eciser le pool. Bacula s\'electionne d\`es lors 
automatiquement le prochain volume du pool \`a utiliser, en s'assurant que le 
{\bf Media Type} de tout volume s\'electionn\'e est bien celui requis par la 
ressource Storage sp\'ecifi\'ee pour le job.

Si vous utilisez la commande {\bf label} du programme Console pour 
\'etiquetter les volumes, il sont automatiquement ajout\'es au pool, aussi cette 
derni\`ere \'etape n'est g\'en\'eralement pas requise.

Il est aussi possible d'ajouter des volumes au catalogue sans avoir 
explicitement \'etiquett\'e les volumes physiques. Ceci s'effectue avec la commande 
{\bf add} du programme Console.

Comme mentionn\'e plus haut, \`a chaque d\'emarrage, Bacula examine tous les pools 
associ\'es \`a chaque catalogue, et si un enregistrement n'existe pas encore, il 
est cr\'e\'e \`a partir de la d\'efinition du pool dans la ressource. Bacula devrait 
probablement effectuer un {\bf update pool} si vous modifiez la d\'efinition 
du pool mais, actuellement, vous devez le faire manuellement avec la 
commande {\bf update pool} du programme Console.

La ressource Pool d\'efinie dans le fichier de configuration du Director peut 
contenir les directives suivantes :


\begin{description}

\item [Pool]
   \index[dir]{Pool}
   \index[dir]{Directive!Pool}
D\'ebut de la ressource Pool. Il faut d\'efinir au moins une ressource Pool.

\item [Name = \lt{}name\gt{}]
   \index[dir]{Name}
   \index[dir]{Directive!Name}
Le nom du pool. Pour la plupart des applications, vous utiliserez le pool 
par d\'efaut nomm\'e {\bf Default}. Cette directive est requise.

\item [Number of Volumes = \lt{}number\gt{}]
   \index[dir]{Number of Volumes  }
Cette directive sp\'ecifie le nombre de volumes (cartouches ou fichiers) contenus 
dans le pool. En principe, il est d\'efini et mis \`a jour automatiquement par la 
routine de maintenance du catalogue de Bacula.
\label{MaxVolumes}

\item [Maximum Volumes = \lt{}number\gt{}]
   \index[dir]{Maximum Volumes}
    \index[dir]{Directive!Maximum Volumes}
Cette directive sp\'ecifie le nombre maximum de volumes contenus dans le pool.
Cette directive est optionnelle. Si elle est omise ou r\'egl\'ee \`a 0, tout nombre 
de volumes est permis. En g\'en\'eral, cette directive est utile pour les librairies, 
o\`u il y a un nombre fix\'e de volumes, ou pour le stockage sur fichier si vous voulez 
vous assurer que les sauvegardes sur disque ne deviennent pas trop nombreuses ou ne 
consomment pas trop d'espace.

\item [Pool Type = \lt{}type\gt{}]
   \index[dir]{Pool Type  }
   \index[dir]{Directive!Pool Type}
Cette directive d\'efinit le type du pool, qui correspond au type du job 
ex\'ecut\'e. Cette directive est requise et peut prendre l'une des valeurs suivantes :

\begin{itemize}
\item [Backup]  
\item [*Archive]  
\item [*Cloned]  
\item [*Migration]  
\item [*Copy]  
\item [*Save]  
   \end{itemize}

\item [Use Volume Once = \lt{}yes|no\gt{}]
   \index[dir]{Use Volume Once}
   \index[dir]{Directive!Use Volume Once}
Cette directive, si elle est active (valeur {\bf yes}) stipule que chaque volume 
ne doit \^etre utilis\'e qu'une seule fois. C'est particuli\`erement utile si le 
volume est un fichier et si vous voulez un nouveau fichier pour chaque nouvelle 
sauvegarde. La valeur par d\'efaut est {\bf no} (autrement dit, les volumes peuvent 
\^etre utilis\'es plusieurs fois). Cette directive sera tr\`es certainement bient\^ot 
obsol\`ete, aussi nous vous recommandons d'utiliser {\bf Maximum Volume Jobs = 1} 
\`a la place.
   
La valeur d\'efinie par cette directive dans le fichier de 
configuration du Director est la valeur par d\'efaut utilis\'ee lorsqu'un nouveau 
volume est cr\'e\'e. Modifier la valeur dans le fichier de configuration ne changera 
pas ce qui est stock\'e sur le volume. Pour changer cette valeur pour un volume 
existant, vous devez utiliser la commande {\bf update} du programme Console.

\item [Maximum Volume Jobs = \lt{}positive-integer\gt{}]
   \index[dir]{Maximum Volume Jobs}
   \index[dir]{Directive!Maximum Volume Jobs}
Cette directive sp\'ecifie le nombre maximum de jobs qui peuvent \^etre \'ecrits sur le volume. 
La valeur par d\'efaut est z\'ero, ce qui signifie que le nombre de jobs sur un volume 
n'est pas limit\'e. Sinon, lorsque le nombre de jobs sauvegard\'es sur le volume atteint 
la valeur {\bf positive-integer} sp\'ecifi\'ee, le volume est marqu\'e {\bf Used}. D\`es lors, 
il ne peut plus \^etre utilis\'e pour y ajouter des jobs, tout comme dans le cas d'un volume 
avec le statut {\bf Full}, mais il peut \^etre recycl\'e si le recyclage est activ\'e. En 
sp\'ecifiant {\bf MaximumVolumeJobs = 1} vous obtenez le m\^eme effet que celui que vous 
obtiendriez avec {\bf UseVolumeOnce = yes}.

Notez que la valeur d\'efinie par cette directive dans le fichier de configuration du 
Director est la valeur par d\'efaut utilis\'ee lors de la cr\'eation d'un volume. Une fois 
le volumes cr\'e\'e, modifier la valeur dans le fichier de configuration ne changera
pas ce qui est stock\'e sur le volume. Pour changer cette valeur pour un volume
existant, vous devez utiliser la commande {\bf update} du programme Console.

\item [Maximum Volume Files = \lt{}positive-integer\gt{}]
   \index[dir]{Maximum Volume Files}
   \index[dir]{Directive!Maximum Volume Files}
Cette directive sp\'ecifie le nombre maximum de fichiers qui peuvent \^etre \'ecrits sur 
le volume. La valeur par d\'efaut est z\'ero, ce qui signifie que le nombre de fichiers 
sur un volume n'est pas limit\'e. Sinon, lorsque le nombre de fichiers sauvegard\'es sur 
le volume atteint la valeur {\bf positive-integer} sp\'ecifi\'ee, le volume est marqu\'e 
{\bf Used}. D\`es lors, il ne peut plus \^etre utilis\'e pour y ajouter des jobs, tout comme 
dans le cas d'un volume avec le statut {\bf Full}, mais il peut \^etre recycl\'e si le 
recyclage est activ\'e. Ce n'est qu'\`a la fin d'un job que Cette valeur est control\'ee, 
et que le statut du volume est \'eventuellement chang\'e en {\bf Used}.

La valeur d\'efinie par cette directive dans le fichier de configuration du
Director est la valeur par d\'efaut utilis\'ee lors de la cr\'eation d'un volume. Une fois
le volumes cr\'e\'e, modifier la valeur dans le fichier de configuration ne changera
pas ce qui est stock\'e sur le volume. Pour changer cette valeur pour un volume
existant, vous devez utiliser la commande {\bf update} du programme Console.

\item [Maximum Volume Bytes = \lt{}size\gt{}]
   \index[dir]{Maximum Volume Bytes}
   \index[dir]{Directive!Maximum Volume Bytes}
Cette directive sp\'ecifie le nombre maximum d'octets qui peuvent \^etre \'ecrits sur le 
volume. La valeur par d\'efaut est z\'ero, ce qui signifie qu'il n'y a d'autre limite 
que la capacit\'e physique du volume. Sinon, lorsque le nombre d'octets sauvegard\'es sur 
le volume atteint la valeur {\bf size} sp\'ecifi\'ee, le volume est marqu\'e 
{\bf Used}. D\`es lors, il ne peut plus \^etre utilis\'e pour y ajouter des jobs, tout comme 
dans le cas d'un volume avec le statut {\bf Full}, mais il peut \^etre recycl\'e si le 
recyclage est activ\'e. Ce n'est qu'\`a la fin d'un job que Cette valeur est control\'ee,
et que le statut du volume est \'eventuellement chang\'e en {\bf Used}.

La valeur d\'efinie par cette directive dans le fichier de configuration du
Director est la valeur par d\'efaut utilis\'ee lors de la cr\'eation d'un volume. Une fois
le volumes cr\'e\'e, modifier la valeur dans le fichier de configuration ne changera
pas ce qui est stock\'e sur le volume. Pour changer cette valeur pour un volume
existant, vous devez utiliser la commande {\bf update} du programme Console.

\item [Volume Use Duration = \lt{}time-period-specification\gt{}]
   \index[dir]{Volume Use Duration}
   \index[dir]{Directive!Volume Use Duration}
Cette directive d\'efinit la p\'eriode durant laquelle le volume peut \^etre utilis\'e en 
\'ecriture, \`a compter de la premi\`ere op\'eration d'\'ecriture de donn\'ees. 
La valeur par d\'efaut est z\'ero, ce qui signifie que le volume peut \^etre \'ecrit 
ind\'efiniment . Sinon, lorsque la dur\'ee depuis la premi\`ere \'ecriture exc\`ede la p\'eriode 
{\bf time-period-specification} sp\'ecifi\'ee, le volume est marqu\'e
{\bf Used}. D\`es lors, il ne peut plus \^etre utilis\'e pour y ajouter des jobs, tout comme
dans le cas d'un volume avec le statut {\bf Full}, mais il peut \^etre recycl\'e si le
recyclage est activ\'e. L'usage de la commande {\bf status dir} applique des algorithmes 
similaires \`a l'\'execution de jobs, aussi lors d'une telle commande, le statut du volume 
peut \^etre modifi\'e. Lorsque le volume est recycl\'e, il peut \`a nouveau \^etre utilis\'e.

Vous pourriez utiliser cette directive, par exemple, si vous avez un volume d\'edi\'e 
aux sauvegardes incr\'ementales, et un volume d\'edi\'e aux Fulls hebdomadaires. Une fois que 
la Full est pass\'ee, vous pouvez pr\'ef\'erer utiliser un autre volume pour les incr\'ementales. 
Ceci peut \^etre accompli en r\`eglant la p\'eriode {\bf Volume Use Duration} \`a six jours pour 
les volumes des incr\'ementales. Autrement dit, celui-ci sera utilis\'e durant les six jours 
qui suivent une full, puis un autre volume d'incr\'ementales sera utilis\'e. Veillez \`a utiliser 
des p\'eriodes relativement courtes telles que 23 heures, ou vous pourriez placer Bacula en situation 
de devoir attendre tout un week-end le montage d'une cartouche par l'op\'erateur pour pouvoir terminer 
une sauvegarde.

Ce n'est qu'\`a la fin d'un job que Cette valeur est control\'ee,
et que le statut du volume est \'eventuellement chang\'e en {\bf Used}, ce qui signifie que 
bien que la p\'eriode {\bf Volume Use Duration} puisse avoir expir\'e, l'entr\'ee correspondante 
du catalogue ne sera pas mise \`a jour jusqu'\`a ce que le prochain job utilisant ce 
volume soit ex\'ecut\'e.

La valeur d\'efinie par cette directive dans le fichier de configuration du
Director est la valeur par d\'efaut utilis\'ee lors de la cr\'eation d'un volume. Une fois
le volumes cr\'e\'e, modifier la valeur dans le fichier de configuration ne changera
pas ce qui est stock\'e sur le volume. Pour changer cette valeur pour un volume
existant, vous devez utiliser la commande \ilink{\bf update volume}{UpdateCommand} du 
programme Console.

\item [Catalog Files = \lt{}yes|no\gt{}]
   \index[dir]{Catalog Files}
   \index[dir]{Directive!Catalog Files}
Cette directive pr\'ecise si les noms des fichiers sauvegard\'es doivent ou non \^etre 
enregistr\'es dans le catalogue. La valeur par d\'efaut est {\bf yes}. L'avantage de 
d\'esactiver cette option ({\bf Catalog Files = No}) est d'avoir un catalogue 
significativement plus petit. L'inconv\'enient est de ne pas pouvoir produire de 
liste des fichiers sauvegard\'es pour chaque job \`a partir du catalogue (autrement 
dit, vous ne pourrez naviguer dans les fichiers sauvegard\'es). Ainsi, sans les 
enregistrements de fichiers, vous ne pourrez utiliser la commande {\bf restore}, 
ni aucune des autres commandes du programme Console qui se r\'ef\`erent aux 
enregistrements de fichiers.

\label{PoolAutoPrune}

\item [AutoPrune = \lt{}yes|no\gt{}]
   \index[dir]{AutoPrune}
   \index[dir]{Directive!AutoPrune}
Si AutoPrune est activ\'ee ({\bf yes}), ce qui est le cas par d\'efaut, Bacula 
(depuis la version 1.20) applique automatiquement la p\'eriode de r\'etention des 
volumes lorsqu'un nouveau volumes est requis ou lorsqu'il n'existe aucun volume 
utilisable dans le pool. L'\'elagage des volumes consiste \`a supprimer du catalogue 
les jobs expir\'es (ceux qui sont plus anciens que la p\'eriode de r\'etention), et rend 
possible le recyclage de ces volumes

\label{VolRetention}

\item [Volume Retention = \lt{}time-period-specification\gt{}]
   \index[dir]{Volume Retention}
   \index[dir]{Directive!Volume Retention}
La directive Volume Retention d\'efinit la p\'eriode durant laquelle {\bf Bacula} 
conserve les enregistrements Job associ\'es au volume dans le catalogue. 
Lors de l'expiration de cette p\'eriode, si {\bf AutoPrune} est activ\'ee, Bacula 
peut supprimer les enregistrements Job plus anciens que la p\'eriode {\bf time-period-specification} 
sp\'ecifi\'ee s'il est n\'ecessaire de lib\'erer un volume. Tous les enregistrements de fichiers 
associ\'es \`a des jobs supprim\'es sont aussi supprim\'es. Les dur\'ees peuvent \^etre exprim\'ees 
en secondes, minutes, heures, jours, semaines, mois, trimestres ou ann\'ees. 
La p\'eriode {\bf Volume Retention} s'applique ind\'ependamment des p\'eriodes {\bf Job Retention} 
et {\bf File Retention} d\'efinies dans la ressource Client. Ceci signifie que la 
p\'eriode la plus courte est celle qui s'applique.Notez bien que lorsque la p\'eriode 
{\bf Volume Retention} a \'et\'e atteinte les enregistrements de Job et ceux de fichiers 
sont supprimm\'es les uns et les autres.
Cet \'elagage peut aussi se produire \`a l'ex\'ecution de la commande {\bf status dir} car elle 
applique des algorithmes similaires \`a ceux utilis\'es pour d\'eterminer le prochain volume 
disponible.

Il est important de savoir que lorsque la p\'eriode Volume Retention expire, 
Bacula ne recycle pas syst\'ematiquement le volume concern\'e. Il tente de conserver 
les donn\'ees intactes aussi longtemps que possible avant d'\'ecrire sur ce volume.

La valeur par d\'efaut est 365 jours. Notez que cette directive r\`egle la valeur par 
d\'efaut pour chaque enregistrement de volume du catalogue lorsque le volume 
est cr\'e\'e. Cette valeur du catalogue peut ensuite \^etre modifi\'ee avec la commande 
{\bf update } du programme Console.

En d\'efinissant plusieurs pools avec diff\'erentes p\'eriodes de r\'etention (volume 
retention), vous pouvez efficacement g\'erer vos cartouches avec, par exemple 
un pool de cartouches recycl\'e chaque semaine, un autre recycl\'e chaque mois, et 
ainsi de suite. Cependant, il faut bien garder \`a l'esprit que si votre p\'eriode 
de r\'etention {\bf Volume Retention} est trop courte, il peut arriver que votre 
derni\`ere sauvegarde Full valide soit supprim\'ee, de sorte que vous n'ayez plus 
une sauvegarde compl\`ete de votre syst\`eme, et que votre prochaine incr\'ementale 
soit \'elev\'ee en une Full. Par cons\'equent, la valeur minimum de la p\'eriode 
{\bf Volume Retention} devrait \^etre au moins le double de l'intervalle 
s\'eparant vos Fulls. Autrement dit, pour des Fulls mensuelles, la p\'eriode 
{\bf Volume Retention} devrait \^etre sup\'erieure ou \'egale \`a deux mois.

Notez que la valeur d\'efinie par cette directive dans le fichier de configuration du
Director est la valeur par d\'efaut utilis\'ee lors de la cr\'eation d'un volume. Une fois
le volumes cr\'e\'e, modifier la valeur dans le fichier de configuration ne changera
pas ce qui est stock\'e sur le volume. Pour changer cette valeur pour un volume
existant, vous devez utiliser la commande {\bf update} du programme Console.

\label{PoolRecycle}

\item [Recycle = \lt{}yes|no\gt{}]
   \index[dir]{Recycle}
   \index[dir]{Directive!Recycle}
Cette directive sp\'ecifie la valeur par d\'efaut pour le recyclage des volumes purg\'es.
Si elle est activ\'ee ({\bf yes}) et si Bacula a besoin d'un volume mais n'en trouve 
aucun utilisable, il recherche alors les volumes purg\'es (c'est \`a dire ceux dont tous 
les jobs et fichiers ont expir\'e et ont, de fait, \'et\'e supprim\'es du catalogue). Si un 
volume est recycl\'e, toutes les donn\'ees pr\'ecedemment \'ecrites sur ce volumes seront 
\'ecras\'ees. Si le recyclage est d\'esactiv\'e ({\bf no}), le volume ne sera pas recycl\'e, et ainsi 
les donn\'ees resteront valides. Si vous souhaitez r\'eutiliser un volume dont le drapeau de 
recyclage est no (0 dans le catalogue), vous devez manuellement le changer en yes (commande 
update).

Notez que la valeur d\'efinie par cette directive dans le fichier de configuration du
Director est la valeur par d\'efaut utilis\'ee lors de la cr\'eation d'un volume. Une fois
le volumes cr\'e\'e, modifier la valeur dans le fichier de configuration ne changera
pas ce qui est stock\'e sur le volume. Pour changer cette valeur pour un volume
existant, vous devez utiliser la commande {\bf update} du programme Console.

\label{RecycleOldest}

\item [Recycle Oldest Volume = \lt{}yes|no\gt{}]
   \index[dir]{Recycle Oldest Volume}
   \index[dir]{Directive!Recycle Oldest Volume}
Cette directive indique au Director de rechercher le volume le plus ancien 
du pool lorsq'un nouveau est requis par le Storage Daemon et qu'aucun autre 
n'est disponible. Le catalog est alors {\bf \'elagu\'e} dans le respect des 
p\'eriodes {\bf Job}, {\bf File} et {\bf Volume Retention}, c'est pourquoi cette 
directive est, de {\bf tr\`es} loin, pr\'ef\'erable \`a directive Purge Oldest Volume. 

Cette directive peut \^etre utile si vous avez un nombre fixe de volumes dans 
un pool et que vous voulez cycler sur ces volumes apr\`es avoir sp\'ecifi\'e 
les p\'eriodes de r\'etention qui conviennent.  

\label{RecycleCurrent}

\item [Recycle Current Volume = \lt{}yes|no\gt{}]
   \index[dir]{Recycle Current Volume}
   \index[dir]{Directive!Recycle Current Volume}
Si Bacula a besoin d'un nouveau volume, cette directive lui indique d'\'elaguer 
le volume dans le respect des p\'eriodes {\bf Job}, {\bf File} et 
{\bf Volume Retention}. Si tous les jobs sont \'elagu\'es, (c'est \`a dire si le 
volume est purg\'e), alors le volume est recycl\'e et sera utilis\'e pour la 
prochaine op\'eration d'\'ecriture. Cette directive respecte toutes les 
p\'eriodes {\bf Job}, {\bf File} et {\bf Volume Retention}, c'est pourquoi 
elle est , de {\bf tr\`es} loin, pr\'ef\'erable \`a la directive Purge Oldest Volume.

Cette directive peut \^etre utile si vous avez un nombre fixe de volumes dans
un pool et que vous voulez cycler sur ces volumes apr\`es avoir sp\'ecifi\'e
les p\'eriodes de r\'etention qui \'elaguent les volumes avant que vous n'ayez 
termin\'e le cycle sur les volumes.

\label{PurgeOldest}

\item [Purge Oldest Volume = \lt{}yes|no\gt{}]
   \index[dir]{Purge Oldest Volume}
   \index[dir]{Directive!Purge Oldest Volume}
Cette directive indique au Director de rechercher le volume utilis\'e le plus 
ancien dans le pool lorsqu'un nouveau volume est requis par le Storage 
Daemon et qu'aucun n'est disponible. Le catalogue est alors purg\'e sans 
\'egards pour les p\'eriodes de r\'etention des fichiers et jobs \'ecrits sur ce 
volume. Le volume est alors recycl\'e pour \^etre utilis\'e pour la prochaine 
op\'eration d'\'ecriture. Cette directive outrepasse toute p\'eriode de r\'etention 
(Job,  File, ou Volume) que vous avez pu sp\'ecifier par ailleurs.

Cette directive peut \^etre utile si vous avez un nombre fixe de volumes dans
un pool et que vous voulez cycler sur ces volumes lorsque tous les volumes 
sont pleins, sans avoir \`a vous soucier de param\'etrer les p\'eriodes de 
r\'etentions qui conviendraient. Cependant, en l'utilisant, vous courrez le 
risque de perdre toutes vos donn\'ees.

{\bf Soyez conscient que {\bf Purge Oldest Volume} ne fait aucun cas d'aucune 
p\'eriode de r\'etention.} Si vous activez cette directive alors que vous ne poss\'edez 
qu'un seul volume, ce volume sera syst\'ematiquement \'ecras\'e tout de suite apr\`es 
avoir \'et\'e rempli ! Aussi, assurez vous au moins d'avoir un nombre d\'ecent de 
volumes dans votre pool avant d'ex\'ecuter un job. Si vous voulez que les p\'eriodes 
de r\'etention soient prises en compte, n'utilisez pas cette directive. Pour 
sp\'ecifier une p\'eriode de r\'etention, utilisez la directive {\bf Volume Retention} 
(voir ci dessus).

Je recommande fortement de ne pas utiliser cette directive, car il est certain que 
t\^ot ou tard, Bacula recyclera un volume contenant des donn\'ees valides et r\'ecentes.
La valeur par d\'efaut est {\bf no}

\item [Cleaning Prefix = \lt{}string\gt{}]
   \index[dir]{Cleaning Prefix}
   \index[dir]{Directive!Cleaning Prefix}
Cette directive d\'efinit un pr\'efixe qui, s'il correspond au d\'ebut du nom d'un 
volume lors de son \'etiquettage, indique \`a Bacula que le volume en question est 
une cartouche de nettoyage, qui aura le statut {\bf VolStatus = Cleaning}. 
Ainsi Bacula ne tentera jamais d'utiliser cette cartouche. Cette option est 
particuli\`erement utile avec les librairies \'equip\'ees de lecteurs de codes barres o\`u, 
conventionnellement, les codes barres commen\\ 3ant par {\bf CLN} sont trait\'es en 
tant que cartouches de nettoyage.

\label{Label}

\item [Label Format = \lt{}format\gt{}]
   \index[dir]{Label Format}
   \index[dir]{Directive!Label Format}
Cette directive pr\'ecise le format des \'etiquettes des volumes de ce pool. 
La directive {\bf Format} est utilis\'ee comme un patron pour cr\'eer de nouveaux 
noms de volumes lors de l'\'etiquettage automatique.

Le {\bf format} devrait \^etre sp\'ecifi\'e entre guillemets, et consiste en une 
cha\^ine de lettres, chiffres et caract\`eres sp\'eciaux tiret  ({\bf -}), soulign\'e 
({\bf \_}), double point ({\bf :}) et point ({\bf .}), qui sont consid\'er\'es valides 
pour un nom de volume.

De plus, le {\bf format} peut comporter des caract\`eres variables qui seront 
substitu\'ees par un algorithme complexe, ce qui permet de cr\'eer des noms de volumes 
avec plusieurs formats diff\'erents. En tous les cas, le processus d'expansion des 
variables doit aboutir au jeu de caract\`eres d\'efinis comme l\'egaux dans le 
dernier paragraphe. G\'en\'eralement, ces caract\`eres variables commencent par 
un signe dollar ({\bf \$}) ou un crochet droit  ({\bf [}). Si vous sp\'ecifiez 
des caract\`eres variables vous devriez toujours les encadrer de guillemets. 
Pour plus de d\'etails sur ce sujet, veuillez consulter le chapitre 
\ilink{Variable Expansion}{_ChapterStart50} de ce manuel.

Si aucun caract\`ere variable n'est d\'ecouvert dans la cha\^ine, le nom de volume 
sera constitu\'e de la cha\^ine {\bf format} suffix\'ee du nombre de volumes dans le 
pool plus un, au format 4 chiffres et avec des z\'eros en t\^ete. Par exemple, 
avec {\bf Label Format = ''File-``}, les volumes seront nomm\'es 
{\bf File-0001}, {\bf File-0002}, ...

Exception faite des variables sp\'ecifiques aux jobs, vous pouvez tester votre 
{\bf LabelFormat} en utilisant la section \ilink{ var command}{var} du 
chapitre Console de ce manuel.

Dans la plupart des cas, vous devriez encadrer la sp\'ecification de format (la 
partie \`a droite du signe \'egale) entre guillemets. Notez que cette directive est 
obsol\`ete et qu'elle est remplac\'ee, \`a partir de la version 1.37 par un script Python 
pour la cr\'eation des noms de volumes.

\end{description}

Pour qu'un pool puisse \^etre utilis\'e lors d'une sauvegarde, il faut qu'il lui soit 
associ\'e au moins un volume. Les volumes sont cr\'e\'es et affect\'es aux pools avec les 
commandes {\bf label} ou {\bf add} du programme {\bf Bacula Console}. Outre 
l'affectation du volume au pool (c'est \`a dire son r\'ef\'erencement 
dans le catalogue), le volume physique doit recevoir une \'etiquette logicielle 
valide pour que Bacula l'accepte. Ceci peut \^etre r\'ealis\'e automatiquement grâce 
\`a la commande {\bf label}. D'autre part, Bacula peut effectuer cette op\'eration 
automatiquement si l'instruction lui en est donn\'e, mais cette fonctionnalit\'e 
n'est pas encore pleinement impl\'ement\'ee.

Voici un exemple d'une d\'efinition de ressource Pool valide :

\footnotesize
\begin{verbatim}
 
Pool {
  Name = Default
  Pool Type = Backup
}
\end{verbatim}
\normalsize

\subsubsection*{The Scratch Pool}
\addcontentsline{toc}{subsection}{Scratch Pool}
\index[general]{Scratch Pool}
En g\'en\'eral, vous pouvez nommer vos pool \`a votre guise, il existe cependant 
une importante restriction : le pool nomm\'e {\bf Scratch}, s'il existe, 
se comporte comme une r\'eserve de volumes o\`u Bacula pourra puiser s'il ne trouve 
aucun volume utilisable dans le pool normalement utilis\'e par le job. Le volume 
est alors d\'eplac\'e du pool Scratch vers le pool en d\'efaut.

\subsection*{La ressource Catalog}
\label{CatalogResource}
\index[general]{Resource!Catalog }
\index[general]{Ressource Catalog}
\addcontentsline{toc}{subsection}{La ressource Catalog}

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

\begin{description}

\item [Catalog]
   \index[dir]{Catalog}
   \index[dir]{Directive!Catalog}
D\'ebut de la ressource Catalog. Il faut au moins une ressource Catalogue.

\item [Name = \lt{}name\gt{}]
   \index[dir]{Name}
   \index[dir]{Directive!Name}
Le nom du Catalog. Il n'a pas besoin d'\^etre en relation avec le nom sur le serveur 
de base de donn\'ees. Ce nom sera repris dans la ressource Client, indiquant ainsi 
que toutes les donn\'ees relatives \`a ce client sont maintenues dans ce catalogue.
Cette directive est requise.*


\item [password = \lt{}password\gt{}]
   \index[dir]{password}
   \index[dir]{Directive!password}
Cette directive sp\'ecifie le mot de passe \`a utiliser pour se connecter au 
catalogue. Cette directive est requise.

\item [DB Name = \lt{}name\gt{}]
   \index[dir]{DB Name}
   \index[dir]{Directive!DB Name}
Cette directive sp\'ecifie le nom de la base de donn\'ees. Si vous utilisez plusieurs 
catalogues, vous sp\'ecifiez lequel ici. Si vous utilisez un serveur de bases de 
donn\'ees externe plut\^ot que l'int\'egr\'e, vous devez sp\'ecifier un nom connu du 
serveur (autrement dit, le nom que vous avez utilis\'e lorsque vous avez cr\'e\'e les 
tables Bacula.). Cette directive est requise.

\item [user = \lt{}user\gt{}]
   \index[dir]{user}
   \index[dir]{Directive!user}
L'utilisateur habilit\'e \`a se connecter au catalogue.  Cette directive est requise.

\item [DB Socket = \lt{}socket-name\gt{}]
   \index[dir]{DB Socket}
   \index[dir]{Directive!DB Socket}
Il s'agit du nom d'un {\it socket} \`a utiliser sur la machine locale pour se 
connecter au catalogue. Cette directive n'est utilis\'ee que par MySQL, elle est 
ignor\'ee par SQLite. Normalement, si ni {\bf DB Socket}, ni {\bf DB Address} ne sont 
sp\'ecifi\'ees, MySQL utilise le socket par d\'efaut.

\item [DB Address = \lt{}address\gt{}]
   \index[dir]{DB Address}
   \index[dir]{Directive!DB Address}
Il s'agit de l'adresse du serveur de bases de donn\'ees. En principe, vous  
utiliserez cette directive plut\^ot que {\bf DB Socket} si le serveur de bases de 
donn\'ees est une autre machine. Dans ce cas, vous sp\'ecifierez aussi le port {\bf DB Port}. 
Cette directive n'est utilis\'ee que par MySQL, et ignor\'ee par SQLite. Elle est 
optionnelle.

\item [DB Port = \lt{}port\gt{}]
   \index[dir]{DB Port}
   \index[dir]{Directive!DB Port}
Cette directive d\'efinit le port \`a utiliser en conjonction avec {\bf DB Address} pour 
acc\'eder au catalogue s'il est h\'eberg\'e sur une autre machine. Elle n'est utilis\'ee que par 
 MySQL, et ignor\'ee par SQLite. Elle est optionnelle.

%% \item [Multiple Connections = \lt{}yes|no\gt{}]
%%   \index[dir]{Multiple Connections}
%%   \index[dir]{Directive!Multiple Connections}
%% Par d\'efaut, cette directive est d\'esactiv\'ee, ce qui implique que tous les jobs utilisant  
%% le m\^eme catalogue se partagent une m\^eme  connection au catalogue, et que Bacula n'autorise 
%% qu'un job \`a la fois \`a communiquer. Si vous activez cette directive ({\bf yes}), Bacula 
%% permettra les connection multiples au catalogue, c'est pourquoi la base de donn\'ees 
%% doit supporter le {\it multi thread}. Pour SQLite et PostgreSQL, ce n'est pas un probl\`eme. 
%% Pour MySQL, vous devez vous assurer {\bf attentivement} d'avoir la version {\it multi thread} 
%% de la librairie cliente sur votre syst\`eme. Une fois cette directive activ\'ee, chaque job 
%% disposera de sa propre connection au catalogue, la base de donn\'ees contr\^olant les interactions 
%% entre les diff\'erents jobs. Ceci peut accro\^itre significativement les op\'erations de la 
%% base de donn\'ees si vous ex\'ecutez plusieurs jobs simultan\'es. De plus, pour SQLite et PostgreSQL, 
%% Bacula activera automatiquement les transactions dans la base de donn\'ees. Ceci peut accro\^itre 
%% significativement les insertions d'attributs dans le catalogue, que ce soit pour un job unique 
%% ou pour plusieurs jobs simultan\'es.

%% Cette directive n'a pas \'et\'e test\'ee. Veuillez, s'il vous pla\^it, la tester scrupuleusement avant 
%% de l'activer en production, et nous fournir un retour de vos tests.

\end{description}

Voici un exemple d'une d\'efinition de ressource Catalog valide :

\footnotesize
\begin{verbatim}
Catalog
{
  Name = SQLite
  dbname = bacula;
  user = bacula;
  password = ""                       # no password = no security
}
\end{verbatim}
\normalsize

en voici une deuxi\`eme pour un catalogue sur une autre machine :

\footnotesize
\begin{verbatim}
Catalog
{
  Name = MySQL
  dbname = bacula
  user = bacula
  password = ""
  DB Address = remote.acme.com
  DB Port = 1234
}
\end{verbatim}
\normalsize

\subection*{La ressource Messages}
\label{MessagesResource2}
\index[general]{Resource!Messages }
\index[general]{Messages Ressource }
\addcontentsline{toc}{subsection}{Messages Resource}

Pour les d\'etails sur la ressource Messages, veuillez consulter 
le chapitre \ilink{La ressource Messages}{_ChapterStart15} de ce manuel.

\subsection*{La ressource Console}
\label{ConsoleResource1}
\index[general]{Console Resource }
\index[general]{Resource!Console }
\addcontentsline{toc}{subsection}{Console Resource}

A partir de la version 1.33 de Bacula, l'administrateur dispose de trois sortes de 
consoles diff\'erentes pour interagir avec le Director. Ces trois types de consoles 
comportent trois niveaux de s\'ecurit\'e diff\'erents.

\begin{itemize}
\item Le premier type de console est une console {\bf anonyme} ou {\bf par d\'efaut}, 
  qui d\'etient tous les privil\`eges. La ressource Console n'est pas requise pour 
  ce type puisque le mot de passe est sp\'ecifi\'e dans la ressource Director et par 
  cons\'equent, de telles consoles n'ont pas de nom d\'efini par une directive {\bf Name =}. 
  C'est le premier type de console impl\'ement\'e dans les versions ant\'erieures \`a 1.33, il 
  demeure valide. Sont usage est typiquement r\'eserv\'e aux administrateurs.
\item Le second type de console, apparu avec la version 1.33 est une console "nomm\'ee" 
  d\'efinie dans une ressource Console simultan\'ement dans le fichier de configuration du 
  Director et dans le fichier de configuration de la Console, les noms et mots de passe 
  devant \^etre en conjonction dans ces deux fichiers. 
  Ce type de console ne d\'etient absolument aucun privil\`ege, except\'es ceux explicitement 
  sp\'ecifi\'es dans la ressource Console du fichier de configuration du Director. 
  Ainsi, vous pouvez d\'efinir plusieurs consoles avec des noms et mots de passe distincts 
  destin\'ees \`a diff\'erents utilisateurs avec diff\'erents privil\`eges. Par d\'efaut ces consoles 
  ne peuvent absolument rien faire. Il vous revient de leur accorder des privil\`eges 
  ou plut\^ot des acc\`es aux commandes et ressources en sp\'ecifiant des listes de 
  contr\^ole d'acc\`es (ACL) dans la ressource Console du fichier de configuration du 
  Director. Les ACLs sont sp\'ecifi\'ees par une directive suivie d'une liste de noms 
  d'acc\`es. Vous trouverez des exemples ci-dessous. 
\item Le troisi\`eme type de console est similaire au second en ce qu'il requiert 
  une d\'efinition de ressource Console dans le fichier de configuration du
  Director et dans le fichier de configuration de la Console. De plus, si le nom de 
  la console sp\'ecifi\'e par la directive {\bf Name =} est le m\^eme que le nom du client, 
  cette console est autoris\'ee \`a utiliser la commande {\bf SetIP} pour modifier la 
  directive Address dans la ressource client du fichier de configuration du
  Director en l'adresse IP de la console. Ceci permet aux portables et autres machines 
  utilisant DHCP (adresses IP dynamiques) de "notifier" le Director de leur adresse 
  IP courante.
\end{itemize}

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

\begin{description}

\item [Name = \lt{}name\gt{}]
   \index[dir]{Name}
   \index[dir]{Directive!Name}
Le nom de la console. Ce nom doit \^etre en conjonction avec celui sp\'ecifi\'e 
dans le fichier de configuration de la Console (comme c'est le cas pour les 
d\'efinitions de clients).

\item [Password = \lt{}password\gt{}]
   \index[dir]{Password}
   \index[dir]{Directive!Password}
Sp\'ecifie le mot de passe qu'une console nomm\'ee doit fournir pour \^etre autoris\'ee. 
Le m\^eme mot de passe doit appara\^itre dans la ressource Console du fichier 
de configuration de la Console. Pour plus de s\'ecurit\'e, le mot de passe n'est 
jamais r\'eellement transmis \`a travers le r\'eseau, mais plut\^ot un code de 
hachage de type {\it challenge response} cr\'e\'e \`a partir du mot de passe. 
Cette directive est requise. Si vous disposez de {\bf /dev/random} ou  {\bf bc} 
sur votre machine, Bacula g\'en\`erera al\'eatoirement ce mot de passe lors du 
processus de configuration, autrement, il sera laiss\'e blanc.

\item [JobACL = \lt{}name-list\gt{}]
   \index[dir]{JobACL}
   \index[dir]{Directive!JobACL}
Cette directive est utilis\'ee pour sp\'ecifier une liste de noms de ressources Job 
qui peuvent \^etre acc\'ed\'es par la console. Sans cette directive, la console ne peut 
acc\'eder \`a aucune des ressources Job d\'efinies dans le fichier de configuration 
du Director. Plusieurs ressources Job peuvent \^etre sp\'ecifi\'ees en les s\'eparant par 
des virgules, et/ou en sp\'ecifiant plusieurs directives JobACL. Par exemple, la 
directive peut \^etre sp\'ecifi\'ee ainsi :

\footnotesize
\begin{verbatim}
    JobACL = kernsave, "Backup client 1", "Backup client 2"
    JobACL = "RestoreFiles"
    
\end{verbatim}
\normalsize

Avec cette sp\'ecificaton, la console peut acc\'eder aux ressources du Director pour 
les quatre jobs d\'esign\'es par la directive JobACL, et uniquement \`a eux.

\item [ClientACL = \lt{}name-list\gt{}]
   \index[dir]{ClientACL}
   \index[dir]{Directive!ClientACL}
Cette directive est utilis\'ee pour sp\'ecifier une liste de noms de ressources Client 
iaccessibles par la console.

\item [StorageACL = \lt{}name-list\gt{}]
   \index[dir]{StorageACL}
   \index[dir]{Directive!StorageACL}
Cette directive est utilis\'ee pour sp\'ecifier une liste de noms de ressources Storage 
accessibles par la console.

\item [ScheduleACL = \lt{}name-list\gt{}]
   \index[dir]{ScheduleACL}
   \index[dir]{Directive!ScheduleACL}
Cette directive est utilis\'ee pour sp\'ecifier une liste de noms de ressources Schedule
accessibles par la console.

\item [PoolACL = \lt{}name-list\gt{}]
   \index[dir]{PoolACL}
   \index[dir]{Directive!PoolACL}
Cette directive est utilis\'ee pour sp\'ecifier une liste de noms de ressources Pool
accesibles ar la console.

\item [FileSetACL = \lt{}name-list\gt{}]
   \index[dir]{FileSetACL}
   \index[dir]{Directive!FileSetACL}
Cette directive est utilis\'ee pour sp\'ecifier une liste de noms de ressources FileSet
accessibles par la console.

\item [CatalogACL = \lt{}name-list\gt{}]
   \index[dir]{CatalogACL}
   \index[dir]{Directive!CatalogACL}
Cette directive est utilis\'ee pour sp\'ecifier une liste de noms de ressources Catalog
accessibles par la console.

\item [CommandACL = \lt{}name-list\gt{}]
   \index[dir]{CommandACL}
   \index[dir]{Directive!CommandACL}
Cette directive est utilis\'ee pour sp\'ecifier une liste de commandes de la console
qui peuvent \^etre ex\'ecut\'ees par la console.

\end{description}

En plus des diff\'erents noms de ressources du Director et de commandes, le mot-clef 
sp\'ecial {\bf *all*} peut \^etre sp\'ecifi\'e dans chacune des directives ACL ci-dessus.
Sa pr\'esence signifie que toute ressource ou commande (pourvu qu'elle soit appropri\'ee 
\`a la directive) est accept\'ee. Pour un exemple de fichier de configuration, voyez le 
chapitre \ilink{Configuration de la console}{_ChapterStart36} de ce manuel

\subsection*{La ressource Counter}
\label{CounterResource}
\index[general]{Ressource!Counter }
\index[general]{Ressource Counter }
\addcontentsline{toc}{subsection}{Ressource Counter}
La ressource Counter d\'efinit une variable-compteur qui peut \^etre acc\'ed\'ee par le 
processus d'expansion de variables utilis\'e pour la cr\'eation de d'\'etiquettes (labels) 
de volumes avec la directive {\bf LabelFormat}. Consultez le paragraphe sur la directive 
\ilink{LabelFormat}{Label} de ce chapitre pour plus de d\'etails.

\begin{description}

\item [Counter]
   \index[dir]{Counter}
   \index[dir]{Directive!Counter}
D\'ebut de la ressource Counter. les directives Counter sont optionnelles.

\item [Name = \lt{}name\gt{}]
   \index[dir]{Name}
   \index[dir]{Directive!Name}
iLe nom de la variable-compteur. Il s'agit du nom que vous utiliserez pour vous r\'ef\'erer 
\`a cette variable et acc\'eder \`a sa valeur.

\item [Minimum = \lt{}integer\gt{}]
   \index[dir]{Minimum}
    \index[dir]{Directive!Minimum}
Sp\'ecifie la valeur minimale de la variable-compteur. Cette valeur devient celle par d\'efaut. 
Si elle n'est pas fournie, sa valeur est z\'ero.

\item [Maximum = \lt{}integer\gt{}]
   \index[dir]{Maximum}
    \index[dir]{Directive!Maximum}
Sp\'ecifie la valeur maximale de la variable-compteur. Si elle n'est pas fournie, ou si elles 
est r\'egl\'ee \`a z\'ero, la variable compteur peut prendre une valeur maximale de 2 147 483 648 
($2^{31}$). Au del\`a de cette valeur, le compteur est remis au minimum.

\item [*WrapCounter = \lt{}counter-name\gt{}]
   \index[dir]{*WrapCounter}
   \index[dir]{Directive!*WrapCounter}
Si cette valeur est sp\'ecifi\'ee, lorsque la variable-compteur d\'epasse le maximum et 
est remise au minimum, le compteur sp\'ecifi\'e par la directive {\bf WrapCounter} est 
incr\'ement\'e. (Ceci n'est, pour le moment, pas impl\'ement\'e.)

\item [Catalog = \lt{}catalog-name\gt{}]
   \index[dir]{Catalog}
   \index[dir]{Directive!Catalog}
Si cette directive est sp\'ecifi\'ee, le compteur et sa valeur sont sauvegard\'es dans le 
catalogue sp\'ecifi\'e. Dans le cas contraire, le compteur est red\'efini \`a chaque 
d\'emarrage de Bacula.

\end{description}

\subsection*{ Voici un exemple complet de fichier de configuration du Director.}
\label{SampleDirectorConfiguration}
\index[general]{File!Exemple Complet Director Configuration }
\index[general]{Exemple Complet Fichier Configuration Director}
\addcontentsline{toc}{subsection}{Exemple Complet Fichier Configuration Directo}
Un exemple de fichier de configuration du Director pourrait \^etre le suivant :


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