Suite de dirdconf.tex.

[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 vouc 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
Sc hedules \`a utiliser conjointement pour chaque Job. 
\item 
   \ilink{JobDefs}{JobDefsResource} -- Ressource optionnelle pour
   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 pool de volumes
   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}
 
\section*{La ressource Director}
\label{DirectorResource4}
\index[general]{Director!La ressource }
\index[general]{La ressource Director }
\addcontentsline{toc}{section}{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  }
   Le nom du Director utilis\'e par l'administrateur syst\`eme. Cette directive
est requise  
  
\item [Description = \lt{ }texte\gt{}]
   \index[dir]{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  }
   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[console]{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, il 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[console]{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. 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.
 
\item [Pid Directory = \lt{}R\'epertoire\gt{}]
   \index[fd]{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 [QueryFile = \lt{}Chemin\gt{}]
   \index[dir]{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[fd]{Maximum Concurrent Jobs  }
   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 blocs 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[console]{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[console]{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[console]{DirAddresses  }
   Sp\'ecifie les ports et adresses sur lesquels le Director sera 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.

\item [DIRport = \lt{}num\'ero-de-port\gt{}]
   \index[console]{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[console]{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

\section*{La ressource Job}
\label{JobResource}
\index[general]{Resource!Job }
\index[general]{Job Resource }
\addcontentsline{toc}{section}{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).

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[console]{Job }
   D\'ebut de la ressource Job. Il faut d\'efinir au moins une ressource Job.

\item [Name = \lt{}name\gt{}]
   \index[console]{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 [Type = \lt{}job-type\gt{}]
   \index[console]{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 des 
   niveaux, qui seront d\'ecrits dans les prochains paragraphes.

\item [Backup]
   \index[console]{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[console]{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[console]{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[fd]{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 {\bf Level = \lt{}job-level\gt{}}
   \index[fd]{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[fd]{Full }
   Tous les fichiers du FileSet, qu'ils aient \'et\'e modifi\'es ou non.

\item [Incremental]
   \index[fd]{Incremental }
   Tous les fichiers modifi\'es depuis la derni\`ere sauvegarde valide du FileSet 
   sp\'ecifi\'e. 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îtront 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.

\item [Differential]
   \index[fd]{Differential }
   Tous les fichiers modifi\'es depuis la derni\`ere sauvegarde Full valide du FileSet
   sp\'ecifi\'e. 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îtront 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.

\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[fd]{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[fd]{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[fd]{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[fd]{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[fd]{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[fd]{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  }
   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.

\item {\bf \label{writebootstrap} Write Bootstrap =  \lt{}bootstrap-file-specification\gt{}}
\index[fd]{a name }

   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[fd]{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[fd]{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  }
   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  }
   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  }
   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  }
   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  }
   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  }
   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  }
   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  }
   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  }
   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  }
   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 {\bf Prune Jobs = \lt{}yes|no\gt{}}
   \index[fd]{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[fd]{Prune Files  }
   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[fd]{Prune Volumes  }
   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[fd]{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îne {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îne {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
    %i = JobId
    %e = Statut de sortie du job
    %j = Nom unique du job
    %l = Niveau du job
    %n = Nom du job
    %t = Type de job
    %v = Nom de volume
    
\end{verbatim}
\normalsize
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[fd]{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îne {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, le job se termine en erreur. 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. depuis la version 1.30, 
Bacula contr\^ole le statut de sortie du program RunAfter. S'il est 
non nul, le job se termine en erreur.

\item {\bf Client Run Before Job = \lt{}command\gt{}}
   \index[fd]{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}. 
   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.


{\bf Considerations particuli\`eres \`a Windows}
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îte 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}

\item {\bf Client Run After Job = \lt{}command\gt{}}
   \index[fd]{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[fd]{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[fd]{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[fd]{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  }
   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  }
   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[fd]{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[fd]{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[fd]{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[fd]{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  }
   where \lt{}number\gt{}  is the maximum number of Jobs from the current Job
resource that  can run concurrently. Note, this directive limits only Jobs 
with the same name as the resource in which it appears. Any  other
restrictions on the maximum concurrent jobs such as in  the Director, Client,
or Storage resources will also apply in addition to  the limit specified here.
The  default is set to 1, but you may set it to a larger number.  We strongly
recommend that you read the WARNING documented under  
\ilink{ Maximum Concurrent Jobs}{DirMaxConJobs} in the Director's
resource.  

\item {\bf Reschedule On Error = \lt{}yes|no\gt{}}
   \index[dir]{Reschedule On Error  }
   If this directive is enabled,  and the job terminates in error, the job will
be rescheduled as determined  by the {\bf Reschedule Interval} and {\bf
Reschedule Times} directives.  If you cancel the job, it will not be
rescheduled. The default is  {\bf no} (i.e. the job will not be rescheduled). 


This specification can be useful for portables, laptops, or other  machines
that are not always connected to the network or switched on.  

\item {\bf Reschedule Interval = \lt{}time-specification\gt{}}
   \index[dir]{Reschedule Interval  }
   If you have  specified {\bf Reschedule On Error = yes} and the job terminates
in  error, it will be rescheduled after the interval of time specified  by
{\bf time-specification}. See 
\ilink{ the time specification formats}{Time} in the Configure
chapter for  details of time specifications. If no interval is specified, the 
job will not be rescheduled on error. 

\item {\bf Reschedule Times = \lt{}count\gt{}}
   \index[dir]{Reschedule Times  }
   This directive specifies the  maximum number of times to reschedule the job.
If it is set to zero  (the default) the job will be rescheduled an indefinite
number of times.  
\label{Priority}

\item {\bf Priority = \lt{}number\gt{}}
   \index[dir]{Priority  }
   This directive permits you  to control the order in which your jobs run by
specifying a positive  non-zero number. The higher the number, the lower the
job priority.  Assuming you are not running concurrent jobs, all queued jobs
of  priority 1 will run before queued jobs of priority 2 and so on, 
regardless of the original scheduling order.  

The priority only affects waiting jobs that are queued to run, not jobs  that
are already running. If one or more jobs of priority 2 are already  running,
and a new job is scheduled with priority 1, the currently  running priority 2
jobs must complete before the priority 1 job is run.  

The default priority is 10.  

If you want to run concurrent jobs, which is not recommended, you should  keep
these points in mind:  

\begin{itemize}
\item To run concurrent jobs,  you must set Maximum Concurrent Jobs = 2 in 5
   or 6 distinct places:  in bacula-dir.conf in the Director, the Job, the
   Client, the Storage  resources; in bacula-fd in the FileDaemon (or Client)
resource,  and in bacula-sd.conf in the Storage resource. If any one  is
missing, it will throttle the jobs to one at a time.  
\item Bacula concurrently runs jobs of only one priority at a time. It will 
   not simultaneously run a priority 1 and a priority 2 job.  
\item If Bacula is running a priority 2 job and a new priority 1  job is
   scheduled, it will wait until the running priority 2 job  terminates even if
   the Maximum Concurrent Jobs settings  would otherwise allow two jobs to run
simultaneously.  
\item Suppose that bacula is running a priority 2 job and new priority 1  job
   is scheduled and queued waiting for the running priority  2 job to terminate.
   If you then start a second priority 2 job,  the waiting priority 1 job  will
prevent the new priority 2 job from running concurrently  with the running
priority 2 job.  That is: as long as there is a higher priority job waiting to
run, no new lower priority jobs will start even if  the Maximum Concurrent
Jobs settings would normally allow  them to run. This ensures that higher
priority jobs will  be run as soon as possible. 
\end{itemize}

If you have several jobs of different priority, it is best  not to start them
at exactly the same time, because Bacula  must examine them one at a time. If
by chance Bacula treats  a lower priority first, then it will run before your
high  priority jobs. To avoid this, start any higher priority  a few seconds
before lower ones. This insures that Bacula  will examine the jobs in the
correct order, and that your  priority scheme will be respected.  
\label{WritePartAfterJob}

\item {\bf Write Part After Job = \lt{}yes|no\gt{}}
   \index[sd]{Write Part After Job  }
   If this directive is  set to {\bf yes} (default {\bf no}), a new part file
will be created  after the job is finished.  

It should be set to {\bf yes} when writing to devices that require mount  (for
example DVD), so you are sure that the current part, containing this job's
data,  is written to the device, and that no data is left in the temporary
file on the hard disk.  However, on some media, like DVD+R and DVD-R, a lot of
space (about 10Mb) is lost  everytime a part is written. So, if you run
several jobs each after another, you could  set this directive to {\bf no} for
all jobs, except the last one, to avoid wasting too much  space, but to ensure
that the data is written to the medium when all jobs are finished.  

It is ignored with tape and FIFO devices.  
\end{description}

The following is an example of a valid Job resource definition: 

\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

\section*{The JobDefs Resource}
\label{JobDefsResource}
\index[general]{JobDefs Resource }
\index[general]{Resource!JobDefs }
\addcontentsline{toc}{section}{JobDefs Resource}

The JobDefs resource permits all the same directives that can appear in a Job
resource. However, a JobDefs resource does not create a Job, rather it can be
referenced within a Job to provide defaults for that Job. This permits you to
concisely define several nearly identical Jobs, each one referencing a JobDefs
resource which contains the defaults. Only the changes from the defaults need
be mentioned in each Job. 

\section*{The Schedule Resource}
\label{ScheduleResource}
\index[general]{Resource!Schedule }
\index[general]{Schedule Resource }
\addcontentsline{toc}{section}{Schedule Resource}

The Schedule resource provides a means of automatically scheduling a Job as
well as the ability to override the default Level, Pool, Storage and Messages
resources. If a Schedule resource is not referenced in a Job, the Job may only
be run manually. In general, you specify an action to be taken and when. 

\begin{description}

\item [Schedule]
   \index[sd]{Schedule }
   Start of the Schedule directives. No {\bf Schedule}  resource is required, but
you will need at least one if you want  Jobs to be automatically started. 

\item [Name = \lt{}name\gt{}]
   \index[sd]{Name  }
   The name of the schedule being defined.  The Name directive is required. 

\item [Run = \lt{}Job-overrides\gt{} \lt{}Date-time-specification\gt{}  ]
   \index[sd]{Run  }
   The Run directive defines when a Job is to be run,  and what overrides if any
to apply. You may specify multiple  {\bf run} directives within a {\bf
Schedule} resource. If you  do, they will all be applied (i.e. multiple
schedules). If you  have two {\bf Run} directives that start at the same time,
two  Jobs will start at the same time (well, within one second of  each
other).  

The {\bf Job-overrides} permit overriding the Level, the  Storage, the
Messages, and the Pool specifications  provided in the Job resource. In
addition, the  FullPool, the IncrementalPool, and the  DifferentialPool
specifications permit overriding the  Pool specification according to what
backup Job Level is  in effect.  

By the use of overrides, you  may customize a particular Job. For example, you
may specify a  Messages override for your Incremental backups that  outputs
messages to a log file, but for your weekly or monthly  Full backups, you may
send the output by email by using  a different Messages override.  

{\bf Job-overrides} are specified as:  {\bf keyword=value} where the keyword
is Level, Storage,  Messages, Pool, FullPool, DifferentialPool, or
IncrementalPool, and  the {\bf value} is as defined on the respective
directive formats for  the Job resource. You may specify multiple {\bf
Job-overrides} on  one {\bf Run} directive by separating them with one or more
spaces or  by separating them with a trailing comma.  For example:  

\begin{description}

\item [Level=Full]
   \index[sd]{Level }
   is all files in the FileSet whether or not  they have changed.  

\item [Level=Incremental]
   \index[sd]{Level }
   is all files that have changed since  the last backup.  

\item [Pool=Weekly]
   \index[sd]{Pool }
   specifies to use the Pool named {\bf Weekly}.  

\item [Storage=DLT\_Drive]
   \index[sd]{Storage }
   specifies to use {\bf DLT\_Drive} for  the storage device.  

\item [Messages=Verbose]
   \index[sd]{Messages }
   specifies to use the {\bf Verbose}  message resource for the Job.  

\item [FullPool=Full]
   \index[sd]{FullPool }
   specifies to use the Pool named {\bf Full}  if the job is a full backup, or is
upgraded from another type  to a full backup.  

\item [DifferentialPool=Differential]
   \index[sd]{DifferentialPool }
   specifies to use the Pool  named {\bf Differential} if the job is a
differential  backup.  

\item [IncrementalPool=Incremental]
   \index[sd]{IncrementalPool }
   specifies to use the Pool  named {\bf Incremental} if the job is an
incremental  backup.  

\item [SpoolData=yes|no]
   \index[sd]{SpoolData }
   tells Bacula to request the Storage  daemon to spool data to a disk file
before putting it on  tape.  

\item [WritePartAfterJob=yes|no]
   \index[sd]{WritePartAfterJob }
   tells Bacula to request the Storage  daemon to write the current part file to
the device when the job  is finished (see 
\ilink{Write Part After Job directive in the Job
resource}{WritePartAfterJob}).  
\end{description}

{\bf Date-time-specification} determines when the  Job is to be run. The
specification is a repetition, and as  a default Bacula is set to run a job at
the beginning of the  hour of every hour of every day of every week of every
month  of every year. This is not normally what you want, so you  must specify
or limit when you want the job to run. Any  specification given is assumed to
be repetitive in nature and  will serve to override or limit the default
repetition. This  is done by specifing masks or times for the hour, day of the
month, day of the week, week of the month, week of the year,  and month when
you want the job to run. By specifying one or  more of the above, you can
define a schedule to repeat at  almost any frequency you want.  

Basically, you must supply a {\bf month}, {\bf day}, {\bf hour}, and  {\bf
minute} the Job is to be run. Of these four items to be specified,  {\bf day}
is special in that you may either specify a day of the month  such as 1, 2,
... 31, or you may specify a day of the week such  as Monday, Tuesday, ...
Sunday. Finally, you may also specify a  week qualifier to restrict the
schedule to the first, second, third,  fourth, or fifth week of the month.  

For example, if you specify only a day of the week, such as {\bf Tuesday}  the
Job will be run every hour of every Tuesday of every Month. That  is the {\bf
month} and {\bf hour} remain set to the defaults of  every month and all
hours.  

Note, by default with no other specification, your job will run  at the
beginning of every hour. If you wish your job to run more than  once in any
given hour, you will need to specify multiple {\bf run}  specifications each
with a different minute.  

The date/time to run the Job can be specified in the following way  in
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
<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> |
                    <daily-keyword>
<day-spec>        = <day> | <wday-keyword> |
                    <week-keyword> <wday-keyword>
<month-spec>      = <month-keyword> | <month-range> |
                    <monthly-keyword>
<date-time-spec>  = <month-spec> <day-spec> <time-spec>
\end{verbatim}
\normalsize

\end{description}

Note, the Week of Year specification wnn follows the ISO standard definition
of the week of the year, where Week 1 is the week in which the first Thursday
of the year occurs, or alternatively, the week which contains the 4th of
January. Weeks are numbered w01 to w53. w00 for Bacula is the week that
precedes the first ISO week (i.e. has the first few days of the year if any
occur before Thursday). w00 is not defined by the ISO specification. A week
starts with Monday and ends with Sunday. 

An example schedule resource that is named {\bf WeeklyCycle} and runs a job
with level full each Sunday at 1:05am and an incremental job Monday through
Saturday at 1:05am is: 

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

An example of a possible monthly cycle is as follows: 

\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

The first of every month: 

\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

Every 10 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*{Technical Notes on Schedules}
\index[general]{Schedules!Technical Notes on }
\index[general]{Technical Notes on Schedules }
\addcontentsline{toc}{subsection}{Technical Notes on Schedules}

Internally Bacula keeps a schedule as a bit mask. There are six masks and a
minute field to each schedule. The masks are hour, day of the month (mday),
month, day of the week (wday), week of the month (wom), and week of the year
(woy). The schedule is initialized to have the bits of each of these masks
set, which means that at the beginning of every hour, the job will run. When
you specify a month for the first time, the mask will be cleared and the bit
corresponding to your selected month will be selected. If you specify a second
month, the bit corresponding to it will also be added to the mask. Thus when
Bacula checks the masks to see if the bits are set corresponding to the
current time, your job will run only in the two months you have set. Likewise,
if you set a time (hour), the hour mask will be cleared, and the hour you
specify will be set in the bit mask and the minutes will be stored in the
minute field. 

For any schedule you have defined, you can see how these bits are set by doing
a {\bf show schedules} command in the Console program. Please note that the
bit mask is zero based, and Sunday is the first day of the week (bit zero). 

\section*{The FileSet Resource}
\label{FileSetResource}
\index[general]{Resource!FileSet }
\index[general]{FileSet Resource }
\addcontentsline{toc}{section}{FileSet Resource}

The FileSet resource defines what files are to be included in a backup job. At
least one {\bf FileSet} resource is required for each backup Job. It consists
of a list of files or directories to be included, a list of files or
directories to be excluded and the various backup options such as compression,
encryption, and signatures that are to be applied to each file. 

Any change to the list of the included files will cause Bacula to
automatically create a new FileSet (defined by the name and an MD5 checksum of
the Include contents). Each time a new FileSet is created, Bacula will ensure
that the first backup is always a Full save. 

\begin{description}

\item [FileSet]
   \index[dir]{FileSet }
   Start of the FileSet resource. At least one {\bf FileSet}  resource must be
defined. 

\item [Name = \lt{}name\gt{}]
   \index[dir]{Name  }
   The name of the FileSet resource.  This directive is required. 

\item [Ignore FileSet Changes = \lt{}yes|no\gt{}
   ]
   \index[dir]{Ignore FileSet Changes  }
If this directive is set to {\bf yes}, any changes you make to the  FileSet
Include or Exclude lists will be ignored and not cause Bacula  to immediately
perform a Full backup. The default is {\bf no}, in which  case, if you change
the Include or Exclude, Bacula will force a Full  backup to ensure that
everything is properly backed up. It is not recommended  to set this directive
to yes. This directive is available in Bacula  version 1.35.4 or later. 

\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{} \} }

The Include resource must contain a list of directories and/or files to be
processed in the backup job. Normally, all files found in all subdirectories
of any directory in the Include File list will be backed up. The Include
resource may also oner more Options resources that specify options such as
compression to be applied to all or any subset of the files found for backup. 

There can be any number of {\bf Include} resources within the FileSet, each
having its own list of directories or files to be backed up and the backup
options defined by one or more Options resources. The {\bf file-list} consists
of one file or directory name per line. Directory names should be specified
without a trailing slash. 

You should always specify a full path for every directory and file that you
list in the FileSet. In addition, on Windows machines, you should {\bf always}
prefix the directory or filename with the drive specification (e.g. {\bf
c:/xxx}) using Unix directory name separators (forward slash). 

Bacula's default for processing directories is to recursively descend in the
directory saving all files and subdirectories. Bacula will not by default
cross filesystems (or mount points in Unix parlance). This means that if you
specify the root partition (e.g. {\bf /}), Bacula will save only the root
partition and not any of the other mounted filesystems. Similarly on Windows
systems, you must explicitly specify each of the drives you want saved (e.g.
{\bf c:/} and {\bf d:/} ...). In addition, at least for Windows systems, you
will most likely want to enclose each specification within double quotes
particularly if the directory (or file) name contains spaces. The {\bf df}
command on Unix systems will show you which mount points you must specify to
save everything. See below for an example. 

Take special care not to include a directory twice or Bacula will backup the
same files two times wasting a lot of space on your archive device. Including
a directory twice is very easy to do. For example: 

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

on a Unix system where /usr is a subdirectory (rather than a mounted
filesystem) will cause /usr to be backed up twice. In this case, on Bacula
versions prior to 1.32f-5-09Mar04 due to a bug, you will not be able to
restore hard linked files that were backed up twice. 

If you have used Bacula prior to version 1.34.3, you will note three things in
the new FileSet syntax: 

\begin{enumerate}
\item There is no equal sign (=) after the include and before  the opening
   brace (\{). 
\item Each directory (or filename) to be backed up is preceded by a {\bf File
   =}.  Previously they were simply listed on separate lines. 
\item The options that previously appeared on the Include line now  must be
   specified within their own Options resource. 
   \end{enumerate}

The Options resource is optional, but when specified, it will contain a list
of {\bf keyword=value} options to be applied to the file-list. Multiple
Options resources may be specified one after another. As the files are found
in the specified directories, the Options will applied to the filenames to
determine if and how the file should be backed up. The Options resources are
applied in the order they are specified in the FileSet until the first one
that matches. An Options resource that does not contain a {\bf wild} directive
(wild-card specification, see below) is assumed to match any filename. This is
important to understand, because once Bacula determine that the Options
matches the file under consideration, that file will be saved without looking
at any other Options resources that may be present. This means that any wild
cards must appear before an Option resource without wild cards. 

If for some reason, Bacula applies all the Options resources to a file under
consideration for backup, but there are no matches (generally because of wild
cards that don't match), Bacula as a default will then backup the file. This
is quite logical if you consider the case of no Options, where you want
everything to be backed up. However, one additional point is that in the case
that no match was found, Bacula will use the options found in the last Options
resource. As a consequence, if you want a particular set of ``default''
options, you should put them in an Options resource after any other Options. 

The directives within an Options resource may be one of the following: 

\begin{description}

\item [compression=GZIP]
   \index[fd]{compression }
   All files saved will be software  compressed using the GNU ZIP compression
format. The  compression is done on a file by file basis by the File daemon. 
If there is a problem reading the tape in a  single record of a file, it will
at most affect that file and none  of the other files on the tape. Normally
this option is {\bf not} needed  if you have a modern tape drive as the drive
will do its own  compression. In fact, if you specify software compression at
the  same time you have hardware compression turned on, your files  may
actually take more space on the volume.  

Software compression is very important if you are writing  your Volumes to a
file, and it can also be helpful if you have a  fast computer but a slow
network.  

Specifying {\bf GZIP} uses the default compression level six  (i.e. {\bf GZIP}
is identical to {\bf GZIP6}). If you  want a different compression level (1
through 9), you can specify  it by appending the level number with no
intervening spaces  to {\bf GZIP}. Thus {\bf compression=GZIP1} would give
minimum  compression but the fastest algorithm, and {\bf compression=GZIP9} 
would give the highest level of compression, but requires more  computation.
According to the GZIP documentation, compression levels  greater than 6
generally give very little extra compression and are  rather CPU intensive. 

\item [signature=SHA1]
   \index[fd]{signature }
   An SHA1 signature will be computed for all  The SHA1 algorithm is purported to
be some  what slower than the MD5 algorithm, but at the same time is 
significantly better from a cryptographic point of view (i.e.  much fewer
collisions, much lower probability of being hacked.)  It adds four more bytes
than the MD5 signature.  We strongly recommend that either this option  or MD5
be specified as a default for all files. Note, only  one of the two options
MD5 or SHA1 can be computed for any  file. 

\item [signature=MD5]
   \index[fd]{signature }
   An MD5 signature will be computed for all  files saved. Adding this option
generates about 5\% extra overhead  for each file saved. In addition to the
additional CPU time,  the MD5 signature adds 16 more bytes per file to your
catalog.  We strongly recommend that this option or the SHA1 option  be
specified as a default for all files. 

\item [verify=\lt{}options\gt{}]
   \index[fd]{verify }
   The options letters specified are used  when running a {\bf Verify
Level=Catalog} as well as the  {\bf DiskToCatalog} level job. The options
letters may be any  combination of the following:  

\begin{description}

\item [i]
   compare the inodes  

\item [p]
   compare the permission bits  

\item [n]
   compare the number of links  

\item [u]
   compare the user id  

\item [g]
   compare the group id  

\item [s]
   compare the size  

\item [a]
   compare the access time  

\item [m]
   compare the modification time (st\_mtime)  

\item [c]
   compare the change time (st\_ctime)  

\item [s]
   report file size decreases  

\item [5]
   compare the MD5 signature  

\item [1]
   compare the SHA1 signature  
   \end{description}

A useful set of general options on the {\bf Level=Catalog}  or {\bf
Level=DiskToCatalog}  verify is {\bf pins5} i.e. compare permission bits,
inodes, number  of links, size, and MD5 changes. 

\item {\bf onefs=yes|no}
   \index[fd]{onefs }
   If set to {\bf yes} (the default), {\bf Bacula}  will remain on a single file
system. That is it will not backup  file systems that are mounted on a
subdirectory.  If you wish to backup multiple filesystems, you can  explicitly
list each file system you want saved.  Otherwise, if you set the onefs option
to {\bf no}, Bacula will backup  all mounted file systems (i.e. traverse mount
points) that  are found within the {\bf FileSet}. Thus if  you have NFS or
Samba file systems mounted on a directory listed  in your FileSet, they will
also be backed up. Normally, it is  preferable to set {\bf onefs=yes} and to
explicitly name  each filesystem you want backed up. Explicitly naming  the
filesystems you want backed up avoids the possibility  of getting into a
infinite loop recursing filesystems.  See the example below for more details. 
\label{portable}

\item {\bf portable=yes|no}
   \index[dir]{portable }
   If set to {\bf yes} (default is  {\bf no}), the Bacula File daemon will backup
Win32 files  in a portable format, but not all Win32 file attributes  will be
saved and restored. By default, this option is set to  {\bf no}, which means
that on Win32 systems, the data will  be backed up using Windows API calls and
on WinNT/2K/XP,  all the security and ownership attributes will be properly
backed up  (and restored). However this format is not portable to other 
systems -- e.g. Unix, Win95/98/Me. When backing up Unix systems, this  option
is ignored, and unless you have a specific need to  have portable backups, we
recommend accept the default  ({\bf no}) so that the maximum information
concerning  your files is saved. 

\item {\bf recurse=yes|no}
   \index[fd]{recurse }
   If set to {\bf yes} (the default),  Bacula will recurse (or descend) into all
subdirectories  found unless the directory is explicitly excluded  using an
{\bf exclude} definition.  If you set {\bf recurse=no}, Bacula will save the 
subdirectory entries, but not descend into the  subdirectories, and thus will
not save the files or  directories contained in the subdirectories. Normally,
you  will want the default ({\bf yes}). 

\item {\bf sparse=yes|no}
   \index[dir]{sparse }
   Enable special code that checks for sparse files  such as created by ndbm. The
default is {\bf no}, so no checks  are made for sparse files. You may specify
{\bf sparse=yes} even  on files that are not sparse file. No harm will be
done, but there  will be a small additional overhead to check for buffers of 
all zero, and a small additional amount of space on the output  archive will
be used to save the seek address of each non-zero  record read.  

{\bf Restrictions:} Bacula reads files in 32K buffers.  If the whole buffer is
zero, it will be treated as a sparse  block and not written to tape. However,
if any part of the buffer  is non-zero, the whole buffer will be written to
tape, possibly  including some disk sectors (generally 4098 bytes) that are
all  zero. As a consequence, Bacula's detection of sparse blocks is in  32K
increments rather than the system block size. If anyone  considers this to be
a real problem, please send in a request  for change with the reason. The
sparse code was first  implemented in version 1.27.  

If you are not familiar with sparse files, an example is  say a file where you
wrote 512 bytes at address zero, then  512 bytes at address 1 million. The
operating system will  allocate only two blocks, and the empty space or hole 
will have nothing allocated. However, when you read the  sparse file and read
the addresses where nothing was written,  the OS will return all zeros as if
the space were allocated,  and if you backup such a file, a lot of space will
be used  to write zeros to the volume. Worse yet, when you restore  the file,
all the previously empty space will now be allocated  using much more disk
space. By turning on the {\bf sparse}  option, Bacula will specifically look
for empty space in  the file, and any empty space will not be written to the
Volume,  nor will it be restored. The price to pay for this is that  Bacula
must search each block it reads before writing it.  On a slow system, this may
be important. If you suspect  you have sparse files, you should benchmark the
difference  or set sparse for only those files that are really sparse. 
\label{readfifo}

\item {\bf readfifo=yes|no}
   \index[fd]{readfifo }
   If enabled, tells the Client to  read the data on a backup and write the data
on a restore  to any FIFO (pipe) that is explicitly mentioned  in the FileSet.
In this case, you must have a program already  running that writes into the
FIFO for a backup or reads  from the FIFO on a restore. This can be
accomplished with  the {\bf RunBeforeJob} directive. If this is not the case, 
Bacula will hang indefinitely on reading/writing the FIFO.  When this is not
enabled (default), the Client simply  saves the directory entry for the FIFO. 

\item {\bf mtimeonly=yes|no}
   \index[dir]{mtimeonly }
   If enabled, tells the Client that  the selection of files during Incremental
and Differential  backups should based only on the st\_mtime value in the
stat()  packet. The default is {\bf no} which means that the  selection of
files to be backed up will be based on both the  st\_mtime and the st\_ctime
values. In general, it is not  recommended to use this option. 

\item {\bf keepatime=yes|no}
   \index[dir]{keepatime }
   The default is {\bf no}. When  enabled, Bacula will reset the st\_atime
(access time) field  of files that it backs up to their value prior to the 
backup. This option is not generally recommended as there  are very few
programs that use st\_atime, and the backup  overhead is increased because of
the additional system  call necessary to reset the times. (I'm not sure this 
works on Win32). 

\item {\bf wild=\lt{}string\gt{}}
   \index[dir]{wild }
   Specifies a wild-card string  to be applied to the Files. Note, if {\bf
Exclude} is  not enabled, the wild-card will select which files are to  be
included. If {\bf Exclude=yes} is specified, the wild-card  will select which
files are to be excluded. Multiple wild-card  directives may be specified, and
they will be applied in turn  until the first one that matches. 

\item {\bf regex=\lt{}string\gt{}}
   \index[dir]{regex }
   Specifies a POSIX extended  regular expression to be applied to the Files.
This  directive is available in version 1.35 and later. If  {\bf Exclude} is
not enabled, the regex will select which  files are to be included. If {\bf
Exclude=yes} is  specified, the regex will select which files are to be 
excluded. Multiple regex directives may be specified  within an Options
resource, and  they will be applied in turn until the first one that  matches.


\item {\bf exclude=yes|no}
   \index[dir]{exclude }
   The default is {\bf no}. When  enabled, any files matched within the Options
will be  excluded from the backup. 
\label{ACLSupport}

\item {\bf aclsupport=yes|no}
   \index[dir]{aclsupport }
   The default is {\bf no}.  If this option is set to yes, and you have the POSIX
{\bf libacl} installed on your system, Bacula will backup the  file and
directory UNIX Access Control Lists (ACL) as defined  in IEEE Std 1003.1e
draft 17 and ``POSIX.1e''  (abandoned). This feature is available on UNIX only
and  depends on the ACL library. Bacula is automatically compiled  with ACL
support if the {\bf libacl} library is installed on  your system (shown in
config.out). While restoring the files  Bacula will try to restore the ACLs,
if there is no ACL  support available on the system, Bacula restores the files
and  directories but not the ACL information. Please note, if you  backup an
EXT3 or XFS filesystem with ACLs, then you restore  them to a different
filesystem (perhaps reiserfs) that does  not have ACLs, the ACLs will be
ignored. 
\end{description}

{\bf \lt{}file-list\gt{}} is a list of directory and/or filename names
specified with a {\bf File =} directive. To include names containing spaces,
enclose the name between double-quotes. 

There are a number of special cases when specifying directories and files in a
{\bf file-list}. They are: 

\begin{itemize}
\item Any name preceded by an at-sign (@) is assumed to be the  name of a
   file, which contains a list of files each preceded by a  ``File =''. The named
   file is read once when  the configuration file is parsed during the Director
startup.  Note, that the file is read on the Director's machine  and not on
the Client's. In fact, the @filename can  appear anywhere within the conf file
where a token  would be read, and the contents of the named file will be 
logically inserted in the place of the @filename. What  must be in the file
depends on the location the @filename  is specified in the conf file.  
\item Any name beginning with a vertical bar (|) is  assumed to be the name of
   a program. This program will be executed  on the Director's machine at the
   time the Job starts (not  when the Director reads the configuration file), and
any output  from that program will be assumed to be a list of files or 
directories, one per line, to be included. This allows you to  have a job that
for example includes all the local partitions even  if you change the
partitioning by adding a disk. In general, you will  need to prefix your
command or commands with a {\bf sh -c} so that  they are invoked by a shell.
This will not be the case if you are  invoking a script as in the second
example below. Also, you must  take care to escape (precede with a
\textbackslash{}) wild-cards, shell character, and to  ensure that any spaces
in your command are escaped as well.  If you use a single quotes (') within a
double quote  (``), Bacula will treat everything between the single  quotes as
one field so it will not be necessary to escape  the spaces. In general,
getting all the quotes and escapes  correct is a real pain as you can see by
the next example.  As a consequence, it is often easier to put everything in a
file and simply use the file name within Bacula. In that  case the {\bf sh
-c} will not be necessary providing the  first line of the file is {\bf
\#!/bin/sh}. 

As an  example: 

\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

will produce a list of all the local partitions on a RedHat Linux  system.
Note, the above line was split, but should normally  be written on one line. 
Quoting is a real problem because you must quote for Bacula  which consists of
preceding every \textbackslash{} and every '' with a \textbackslash{}, and 
you must also quote for the shell command. In the end, it is probably  easier
just to execute a small file with: 

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

where my\_partitions has: 

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

If the vertical bar (|) in front of my\_partitions  is preceded by a backslash
as in \textbackslash{}|,  the program will be executed on the Client's machine
instead  of on the Director's machine -- (this is implemented but  not
thoroughly tested, and is reported to work on Windows). Please  note that if
the filename is given within quotes, you will need to  use two slashes. An
example, provided by John Donagher, that backs  up all the local UFS
partitions on a remote system is: 

\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

Note, it requires two backslash characters after the double quote (one
preserves  the next one). If you are a Linux user, just change the {\bf ufs}
to  {\bf ext3} (or your preferred filesystem type) and you will be in 
business.  
\item Any file-list item preceded by a less-than sign (\lt{})  will be taken
   to be a file. This file will be read on the  Director's machine at the time
   the Job starts, and the  data will be assumed to be a list of directories or
files,  one per line, to be included. The names should not be  quoted even if
they contain spaces. This feature allows you to  modify the external file and
change what will be saved  without stopping and restarting Bacula as would be 
necessary if using the @ modifier noted above. 

If you  precede the less-than sign (\lt{}) with a backslash as in 
\textbackslash{}\lt{}, the file-list will be read on the Client machine 
instead of on the Director's machine. Please note that if  the filename is
given within quotes, you will need to use  two slashes.  
\item If you explicitly specify a block device such as {\bf /dev/hda1},  then
   Bacula (starting with version 1.28) will assume that this  is a raw partition
   to be backed up. In this case, you are strongly  urged to specify a {\bf
sparse=yes} include option, otherwise, you  will save the whole partition
rather than just the actual data that  the partition contains. For example: 

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

will backup the data in device /dev/hd6.  

Ludovic Strappazon has pointed out that this feature can be  used to backup a
full Microsoft Windows disk. Simply boot into  the system using a Linux Rescue
disk, then load a statically  linked Bacula as described in the 
\ilink{ Disaster Recovery Using Bacula}{_ChapterStart38} chapter of
this manual. Then  save the whole disk partition. In the case of a disaster,
you  can then restore the desired partition by again booting with  the rescue
disk and doing a restore of the partition. 
\item If you explicitly specify a FIFO device name (created with mkfifo),  and
   you add the option {\bf readfifo=yes} as an option, Bacula  will read the FIFO
   and back its data up to the Volume. For  example: 

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

if {\bf /home/abc/fifo} is a fifo device, Bacula will  open the fifo, read it,
and store all data thus obtained  on the Volume. Please note, you must have a
process on  the system that is writing into the fifo, or Bacula will  hang,
and after one minute of waiting, Bacula will give up  and go on to the next
file. The data read can be anything  since Bacula treats it as a stream.  

This feature can be an excellent way to do a  ``hot'' backup of a very large
database. You can  use the {\bf RunBeforeJob} to create the fifo and to  start
a program that dynamically reads your database and  writes it to the fifo.
Bacula will then write it to the  Volume.  

During the restore operation, the inverse is true,  after Bacula creates the
fifo if there was any data stored  with it (no need to explicitly list it or
add any  options), that data will be written back to the fifo. As  a
consequence, if any such FIFOs exist in the fileset to  be restored, you must
ensure that there is a reader  program or Bacula will block, and after one
minute, Bacula  will time out the write to the fifo and move on to the  next
file. 
\end{itemize}

\end{description}

The following is an example of a valid FileSet resource definition. Note, the
first Include pulls in the contents of the file {\bf /etc/backup.list} when
Bacula is started (i.e. the @). 

\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

Note, in the above example, all the files contained in /etc/backup.list will
be compressed with GZIP compression, an SHA1 signature will be computed on the
file's contents (its data), and sparse file handling will apply. 

The two directories /root/myfile and /usr/lib/another\_file will also be saved
without any options, but all files in those directories with the extension
{\bf .o} will be excluded. 

Suppose you want to save everything except {\bf /tmp} on your system. Doing a
{\bf df} command, you get the following output: 

\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

If you specify only {\bf /} in your Include list, Bacula will only save the
Filesystem {\bf /dev/hda5}. To save all file systems except {\bf /tmp} with
out including any of the Samba or NFS mounted systems, and explicitly
excluding a /tmp, /proc, .journal, and .autofsck, which you will not want to
be saved and restored, you can use the following: 

\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

Since /tmp is on its own filesystem and it was not explicitly named in the
Include list, it is not really needed in the exclude list. It is better to
list it in the Exclude list for clarity, and in case the disks are changed so
that it is no longer in its own partition. 

Please be aware that allowing Bacula to traverse or change file systems can be
{\bf very} dangerous. For example, with the following: 

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

you will be backing up an NFS mounted partition ({\bf /mnt/matou}), and since
{\bf onefs} is set to {\bf no}, Bacula will traverse file systems. Now if {\bf
/mnt/matou} has the current machine's file systems mounted, as is often the
case, you will get yourself into a recursive loop and the backup will never
end. 

The following FileSet definition will backup a raw partition: 

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

While backing up and restoring a raw partition, you should ensure that no
other process including the system is writing to that partition. As a
precaution, you are strongly urged to ensure that the raw partition is not
mounted or is mounted read-only. If necessary, this can be done using the {\bf
RunBeforeJob} directive. 
\label{win32}

\subsection*{Windows Considerations for FileSets}
\index[general]{FileSets!Windows Considerations for }
\index[general]{Windows Considerations for FileSets }
\addcontentsline{toc}{subsection}{Windows Considerations for FileSets}

If you are entering Windows file names, the directory path may be preceded by
the drive and a colon (as in c:). However, the path separators must be
specified in Unix convention (i.e. forward slash (/)). If you wish to include
a quote in a file name, precede the quote with a backslash
(\textbackslash{}\textbackslash{}). For example you might use the following
for a Windows machine to backup the ``My Documents'' directory: 

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

For exclude lists to work correctly on Windows, you must observe the following
rules: 

\begin{itemize}
\item Filenames are case sensitive, so you must use the correct case.  
\item To exclude a directory, you must not have a trailing slash on the 
   directory name.  
\item If you have spaces in your filename, you must enclose the entire name 
   in double-quote characters (``). Trying to use a backslash before  the space
   will not work.  
\item If you are using the old Exclude syntax (noted below), you may  not
   specify a drive letter in the exclude. The new syntax noted  above should work
   fine including driver letters. 
\end{itemize}

Thanks to Thiago Lima for summarizing the above items for us. If you are
having difficulties getting includes or excludes to work, you might want to
try using the {\bf estimate job=xxx listing} command documented in the 
\ilink{Console chapter}{estimate} of this manual. 

On Win32 systems, if you move a directory or file or rename a file into the
set of files being backed up, and a Full backup has already been made, Bacula
will not know there are new files to be saved during an Incremental or
Differential backup (blame Microsoft, not me). To avoid this problem, please
{\bf copy} any new directory or files into the backup area. If you do not have
enough disk to copy the directory or files, move them, but then initiate a
Full backup. 

\subsubsection*{Excluding Files and Directories}
\index[general]{Directories!Excluding Files and }
\index[general]{Excluding Files and Directories }
\addcontentsline{toc}{subsubsection}{Excluding Files and Directories}

You may also include full filenames or directory names in addition to using
wild-cards and {\bf Exclude=yes} in the Options resource as specified above by
simply including the files to be excluded in an Exclude resource within the
FileSet. For example: 

\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*{A Windows Example FileSet}
\index[general]{FileSet!Windows Example }
\index[general]{Windows Example FileSet }
\addcontentsline{toc}{subsection}{Windows Example FileSet}

The following example was contributed by 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

Note, the three line of the above Exclude were split to fit on the document
page, they should be written on a single line in real use. 

\subsection*{The Old FileSet Resource}
\index[general]{Resource!Old FileSet }
\index[general]{Old FileSet Resource }
\addcontentsline{toc}{subsection}{Old FileSet Resource}

The old pre-version 1.34.3 FileSet Resource has been deprecated but will still
work. You are encouraged to convert to using the new form since the old code
will be removed in version 1.37. 

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

If you wish to get an idea of what your FileSet will really backup or if your
exclusion rules will work correctly, you can test it by using the {\bf
estimate} command in the Console program. See the 
\ilink{estimate command}{estimate} in the Console chapter of this
manual. 

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

NTFS filenames containing Unicode characters (i.e. \gt{} 0xFF) cannot be
explicitly named at the moment. You must include such names by naming a higher
level directory or a drive letter that does not contain Unicode characters. 

\section*{The Client Resource}
\label{ClientResource2}
\index[general]{Resource!Client }
\index[general]{Client Resource }
\addcontentsline{toc}{section}{Client Resource}

The Client resource defines the attributes of the Clients that are served by
this Director; that is the machines that are to be backed up. You will need
one Client resource definition for each machine to be backed up. 

\begin{description}

\item [Client (or FileDaemon)]
   \index[dir]{Client (or FileDaemon) }
   Start of the Client directives.  

\item [Name = \lt{}name\gt{}]
   \index[dir]{Name  }
   The client name which will be used in the  Job resource directive or in the
console run command.  This directive is required.  

\item [Address = \lt{}address\gt{}]
   \index[console]{Address  }
   Where the address is a host  name, a fully qualified domain name, or a network
address in  dotted quad notation for a Bacula File server daemon.  This
directive is required. 

\item [FD Port = \lt{}port-number\gt{}]
   \index[console]{FD Port  }
   Where the port is a port  number at which the Bacula File server daemon can be
contacted.  The default is 9102. 

\item [Catalog = \lt{}Catalog-resource-name\gt{}]
   \index[console]{Catalog  }
   This specifies the  name of the catalog resource to be used for this Client. 
This directive is required.  

\item [Password = \lt{}password\gt{}]
   \index[console]{Password  }
   This is the password to be  used when establishing a connection with the File
services, so  the Client configuration file on the machine to be backed up
must  have the same password defined for this Director. This directive is 
required.  If you have either {\bf /dev/random}  {\bf bc} on your machine,
Bacula will generate a random  password during the configuration process,
otherwise it will  be left blank. 
\label{FileRetention}

\item [File Retention = \lt{}time-period-specification\gt{}  ]
   \index[fd]{File Retention  }
   The File Retention directive defines the length of time that  Bacula will keep
File records in the Catalog database.  When this time period expires, and if
{\bf AutoPrune} is set to  {\bf yes} Bacula will prune (remove) File records
that  are older than the specified File Retention period. Note, this  affects
only records in the catalog database. It does not  effect your archive
backups.  

File records  may actually be retained for a shorter period than you specify
on  this directive if you specify either a shorter {\bf Job Retention}  or
shorter {\bf Volume Retention} period. The shortest  retention period of the
three takes precedence.  The time may be expressed in seconds, minutes, 
hours, days, weeks, months, quarters, or years. See the 
\ilink{ Configuration chapter}{Time} of this  manual for
additional details of time specification. 

The  default is 60 days. 
\label{JobRetention}

\item [Job Retention = \lt{}time-period-specification\gt{}  ]
   \index[fd]{Job Retention  }
   The Job Retention directive defines the length of time that  Bacula will keep
Job records in the Catalog database.  When this time period expires, and if
{\bf AutoPrune} is set to  {\bf yes} Bacula will prune (remove) Job records
that are  older than the specified File Retention period. As with the other 
retention periods, this affects only records in the catalog and  not data in
your archive backup.  

If a Job  record is selected for pruning, all associated File and JobMedia 
records will also be pruned regardless of the File Retention  period set. As a
consequence, you normally will set the File  retention period to be less than
the Job retention period. The  Job retention period can actually be less than
the value you  specify here if you set the {\bf Volume Retention} directive in
the  Pool resource to a smaller duration. This is because the Job  retention
period and the Volume retention period are  independently applied, so the
smaller of the two takes  precedence.  

The Job retention period is specified as seconds,  minutes, hours, days,
weeks, months,  quarters, or years.  See the 
\ilink{ Configuration chapter}{Time} of this manual for
additional details of  time specification.  

The default is 180 days.  
\label{AutoPrune}

\item [AutoPrune = \lt{}yes|no\gt{}]
   \index[fd]{AutoPrune  }
   If AutoPrune is set to  {\bf yes} (default), Bacula (version 1.20 or greater)
will  automatically apply the File retention period and the Job  retention
period for the Client at the end of the Job.  If you set {\bf AutoPrune = no},
pruning will not be done,  and your Catalog will grow in size each time you
run a Job.  Pruning affects only information in the catalog and not data 
stored in the backup archives (on Volumes).  

\item [Maximum Concurrent Jobs = \lt{}number\gt{}]
   \index[fd]{Maximum Concurrent Jobs  }
   where \lt{}number\gt{}  is the maximum number of Jobs with the current Client
that  can run concurrently. Note, this directive limits only Jobs  for Clients
with the same name as the resource in which it appears. Any  other
restrictions on the maximum concurrent jobs such as in  the Director, Job, or
Storage resources will also apply in addition to  any limit specified here.
The  default is set to 1, but you may set it to a larger number.  We strongly
recommend that you read the WARNING documented under  
\ilink{ Maximum Concurrent Jobs}{DirMaxConJobs} in the Director's
resource.  

\item [*Priority = \lt{}number\gt{}]
   \index[fd]{*Priority  }
   The number specifies the  priority of this client relative to other clients
that the  Director is processing simultaneously. The priority can range  from
1 to 1000. The clients are ordered such that the smaller  number priorities
are performed first (not currently  implemented). 
\end{description}

The following is an example of a valid Client resource definition: 

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

\section*{The Storage Resource}
\label{StorageResource2}
\index[general]{Resource!Storage }
\index[general]{Storage Resource }
\addcontentsline{toc}{section}{Storage Resource}

The Storage resource defines which Storage daemons are available for use by
the Director. 

\begin{description}

\item [Storage]
   \index[fd]{Storage }
   Start of the Storage resources. At least one  storage resource must be
specified. 

\item [Name = \lt{}name\gt{}]
   \index[sd]{Name  }
   The name of the storage resource. This  name appears on the Storage directive
specified in the Job directive and  is required. 

\item [Address = \lt{}address\gt{}]
   \index[sd]{Address  }
   Where the address is a host name,  a {\bf fully qualified domain name}, or an
{\bf IP address}. Please note  that the \lt{}address\gt{} as specified here
will be transmitted to  the File daemon who will then use it to contact the
Storage daemon. Hence,  it is {\bf not}, a good idea to use {\bf localhost} as
the  name but rather a fully qualified machine name or an IP address.  This
directive is required. 

\item [SD Port = \lt{}port\gt{}]
   \index[sd]{SD Port  }
   Where port is the port to use to  contact the storage daemon for information
and to start jobs.  This same port number must appear in the Storage resource
of the  Storage daemon's configuration file. The default is 9103. 

\item [Password = \lt{}password\gt{}]
   \index[sd]{Password  }
   This is the password to be used  when establishing a connection with the
Storage services. This  same password also must appear in the Director
resource of the Storage  daemon's configuration file. This directive is
required.  If you have either {\bf /dev/random}  {\bf bc} on your machine,
Bacula will generate a random  password during the configuration process,
otherwise it will  be left blank. 

\item [Device = \lt{}device-name\gt{}]
   \index[sd]{Device  }
   This directive specifies the name  of the device to be used to for the
storage. This name is not the  physical device name, but the logical device
name as defined on the  {\bf Name} directive contained in the {\bf Device}
resource  definition of the {\bf Storage daemon} configuration file.  You can
specify any name you would like (even the device name if  you prefer) up to a
maximum of 127 characters in length.  The physical device name associated with
this device is specified in  the {\bf Storage daemon} configuration file (as
{\bf Archive  Device}). Please take care not to define two different  Storage
resource directives in the Director that point to the  same Device in the
Storage daemon. Doing so may cause the  Storage daemon to block (or hang)
attempting to open the  same device that is already open. This directive is
required. 

\item [Media Type = \lt{}MediaType\gt{}]
   \index[fd]{Media Type  }
   This directive specifies the  Media Type to be used to store the data. This is
an arbitrary  string of characters up to 127 maximum that you define. It can 
be anything you want. However, it is best to  make it descriptive of the
storage media (e.g. File, DAT, ''HP  DLT8000``, 8mm, ...). In addition, it is
essential that you  make the {\bf Media Type} specification unique for each
storage  media type. If you have two DDS-4 drives that have incompatible 
formats, or if you have a DDS-4 drive and a DDS-4 autochanger,  you almost
certainly should specify different {\bf Media Types}.  During a restore,
assuming a {\bf DDS-4} Media Type is associated  with the Job, Bacula can
decide to use any Storage  daemon that support Media Type {\bf DDS-4} and on
any drive  supports it. If you want to tie Bacula to using a single Storage 
daemon or drive, you must specify a unique Media Type for that drive.  This is
an important point that should be carefully understood. You  can find more on
this subject in the 
\ilink{Basic Volume Management}{_ChapterStart39} chapter of this
manual.  

The {\bf MediaType} specified here, {\bf must}  correspond to the {\bf Media
Type} specified in the {\bf Device}  resource of the {\bf Storage daemon}
configuration file.  This directive is required, and it is used by the
Director and the  Storage daemon to ensure that a Volume automatically
selected from  the Pool corresponds to the physical device. If a Storage
daemon  handles multiple devices (e.g. will write to various file Volumes  on
different partitions), this directive allows you to specify exactly  which
device.  

As mentioned above, the value specified in the Director's Storage  resource
must agree with the value specified in the Device resource in  the {\bf
Storage daemon's} configuration file. It is also an  additional check so  that
you don't try to write data for a DLT onto an 8mm device. 
\label{Autochanger1}

\item [Autochanger = \lt{}yes|no\gt{}  ]
   \index[fd]{Autochanger  }
   If you specify {\bf yes}  for this command (the default is {\bf no}), when you
use the {\bf label}  command or the {\bf add} command to create a new Volume,
{\bf Bacula}  will also request the Autochanger Slot number. This simplifies 
creating database entries for Volumes in an autochanger. If you forget  to
specify the Slot, the autochanger will not be used. However, you  may modify
the Slot associated with a Volume at any time  by using the {\bf update
volume} command in the console program.  When {\bf autochanger} is enabled,
the algorithm used by  Bacula to search for available volumes will be modified
to  consider only Volumes that are known to be in the autochanger's  magazine.
If no {\bf in changer} volume is found, Bacula will  attempt recycling,
pruning, ..., and if still no volume is found,  Bacula will search for any
volume whether or not in the magazine.  By privileging in changer volumes,
this procedure minimizes  operator intervention.  The default is {\bf no}.  

For the autochanger to be  used, you must also specify {\bf Autochanger = yes}
in the  
\ilink{Device Resource}{Autochanger}  in the Storage daemon's
configuration file as well as other  important Storage daemon configuration
information.  Please consult the 
\ilink{ Using Autochangers}{_ChapterStart18} manual of this
chapter for the details of  using autochangers. 

\item [Maximum Concurrent Jobs = \lt{}number\gt{}]
   \index[fd]{Maximum Concurrent Jobs  }
   where \lt{}number\gt{}  is the maximum number of Jobs with the current Storage
resource that  can run concurrently. Note, this directive limits only Jobs 
for Jobs using this Storage daemon. Any  other restrictions on the maximum
concurrent jobs such as in  the Director, Job, or Client resources will also
apply in addition to  any limit specified here. The  default is set to 1, but
you may set it to a larger number.  We strongly recommend that you read the
WARNING documented under  
\ilink{ Maximum Concurrent Jobs}{DirMaxConJobs} in the Director's
resource.  

While it is possible to set the Director's, Job's, or Client's  maximum
concurrent jobs greater than one, you should take great  care in setting the
Storage daemon's greater than one. By keeping  this directive set to one, you
will avoid having two jobs simultaneously  write to the same Volume. Although
this is supported, it is not  currently recommended.  
\end{description}

The following is an example of a valid Storage resource definition: 

\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

\section*{The Pool Resource}
\label{PoolResource}
\index[general]{Resource!Pool }
\index[general]{Pool Resource }
\addcontentsline{toc}{section}{Pool Resource}

The Pool resource defines the set of storage Volumes (tapes or files) to be
used by Bacula to write the data. By configuring different Pools, you can
determine which set of Volumes (media) receives the backup data. This permits,
for example, to store all full backup data on one set of Volumes and all
incremental backups on another set of Volumes. Alternatively, you could assign
a different set of Volumes to each machine that you backup. This is most
easily done by defining multiple Pools. 

Another important aspect of a Pool is that it contains the default attributes
(Maximum Jobs, Retention Period, Recycle flag, ...) that will be given to a
Volume when it is created. This avoids the need for you to answer a large
number of questions when labeling a new Volume. Each of these attributes can
later be changed on a Volume by Volume basis using the {\bf update} command in
the console program. Note that you must explicitly specify which Pool Bacula
is to use with each Job. Bacula will not automatically search for the correct
Pool. 

Most often in Bacula installations all backups for all machines (Clients) go
to a single set of Volumes. In this case, you will probably only use the {\bf
Default} Pool. If your backup strategy calls for you to mount a different tape
each day, you will probably want to define a separate Pool for each day. For
more information on this subject, please see the 
\ilink{Backup Strategies}{_ChapterStart3} chapter of this
manual. 

To use a Pool, there are three distinct steps. First the Pool must be defined
in the Director's configuration file. Then the Pool must be written to the
Catalog database. This is done automatically by the Director each time that it
starts, or alternatively can be done using the {\bf create} command in the
console program. Finally, if you change the Pool definition in the Director's
configuration file and restart Bacula, the pool will be updated alternatively
you can use the {\bf update pool} console command to refresh the database
image. It is this database image rather than the Director's resource image
that is used for the default Volume attributes. Note, for the pool to be
automatically created or updated, it must be explicitly referenced by a Job
resource. 

Next the physical media must be labeled. The labeling can either be done with
the {\bf label} command in the {\bf console} program or using the {\bf btape}
program. The preferred method is to use the {\bf label} command in the {\bf
console} program. 

Finally, you must add Volume names (and their attributes) to the Pool. For
Volumes to be used by Bacula they must be of the same {\bf Media Type} as the
archive device specified for the job (i.e. if you are going to back up to a
DLT device, the Pool must have DLT volumes defined since 8mm volumes cannot be
mounted on a DLT drive). The {\bf Media Type} has particular importance if you
are backing up to files. When running a Job, you must explicitly specify which
Pool to use. Bacula will then automatically select the next Volume to use from
the Pool, but it will ensure that the {\bf Media Type} of any Volume selected
from the Pool is identical to that required by the Storage resource you have
specified for the Job. 

If you use the {\bf label} command in the console program to label the
Volumes, they will automatically be added to the Pool, so this last step is
not normally required. 

It is also possible to add Volumes to the database without explicitly labeling
the physical volume. This is done with the {\bf add} console command. 

As previously mentioned, each time Bacula starts, it scans all the Pools
associated with each Catalog, and if the database record does not already
exist, it will be created from the Pool Resource definition. {\bf Bacula}
probably should do an {\bf update pool} if you change the Pool definition, but
currently, you must do this manually using the {\bf update pool} command in
the Console program. 

The Pool Resource defined in the Director's configuration file
(bacula-dir.conf) may contain the following directives: 

\begin{description}

\item [Pool]
   \index[dir]{Pool }
   Start of the Pool resource. There must  be at least one Pool resource defined.


\item [Name = \lt{}name\gt{}]
   \index[dir]{Name  }
   The name of the pool.  For most applications, you will use the default pool 
name {\bf Default}. This directive is required.  

\item [Number of Volumes = \lt{}number\gt{}]
   \index[dir]{Number of Volumes  }
   This directive specifies  the number of volumes (tapes or files) contained in
the pool.  Normally, it is defined and updated automatically by the  Bacula
catalog handling routines. 
\label{MaxVolumes}

\item [Maximum Volumes = \lt{}number\gt{}]
   \index[dir]{Maximum Volumes  }
   This directive specifies the  maximum number of volumes (tapes or files)
contained in the pool.  This directive is optional, if omitted or set to zero,
any number  of volumes will be permitted. In general, this directive is useful
for Autochangers where there is a fixed number of Volumes, or  for File
storage where you wish to ensure that the backups made to  disk files do not
become too numerous or consume too much space.  

\item [Pool Type = \lt{}type\gt{}]
   \index[dir]{Pool Type  }
   This directive defines the pool  type, which corresponds to the type of Job
being run. It is  required and may be one of the following:  

\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  }
   This directive  if set to {\bf yes} specifies that each volume is to be  used
only once. This is most useful when the Media is a  file and you want a new
file for each backup that is  done. The default is {\bf no} (i.e. use volume
any  number of times). This directive will most likely be phased out 
(deprecated), so you are recommended to use {\bf Maximum Volume Jobs = 1} 
instead.  

Please note that the value defined by this directive in the  bacula-dir.conf
file is the default value used when a Volume  is created. Once the volume is
created, changing the value  in the bacula-dir.conf file will not change what
is stored  for the Volume. To change the value for an existing Volume  you
must use the {\bf update} command in the Console.  

\item [Maximum Volume Jobs = \lt{}positive-integer\gt{}]
   \index[fd]{Maximum Volume Jobs  }
   This directive specifies  the maximum number of Jobs that can be written to
the Volume. If  you specify zero (the default), there is no limit. Otherwise, 
when the number of Jobs backed up to the Volume equals {\bf positive-integer} 
the Volume will be marked {\bf Used}. When the Volume is marked  {\bf Used} it
can no longer be used for appending Jobs, much like  the {\bf Full} status but
it can be recycled if recycling is enabled.  By setting {\bf
MaximumVolumeJobs} to one, you get the same  effect as setting {\bf
UseVolumeOnce = yes}.  

Please note that the value defined by this directive in the  bacula-dir.conf
file is the default value used when a Volume  is created. Once the volume is
created, changing the value  in the bacula-dir.conf file will not change what
is stored  for the Volume. To change the value for an existing Volume  you
must use the {\bf update} command in the Console.  

\item [Maximum Volume Files = \lt{}positive-integer\gt{}]
   \index[fd]{Maximum Volume Files  }
   This directive specifies  the maximum number of files that can be written to
the Volume. If  you specify zero (the default), there is no limit. Otherwise, 
when the number of files written to the Volume equals {\bf positive-integer} 
the Volume will be marked {\bf Used}. When the Volume is marked  {\bf Used} it
can no longer be used for appending Jobs, much like  the {\bf Full} status but
it can be recycled if recycling is enabled.  This value is checked and the
{\bf Used} status is set only  at the end of a job that writes to the
particular volume.  

Please note that the value defined by this directive in the  bacula-dir.conf
file is the default value used when a Volume  is created. Once the volume is
created, changing the value  in the bacula-dir.conf file will not change what
is stored  for the Volume. To change the value for an existing Volume  you
must use the {\bf update} command in the Console.  

\item [Maximum Volume Bytes = \lt{}size\gt{}]
   \index[fd]{Maximum Volume Bytes  }
   This directive specifies  the maximum number of bytes that can be written to
the Volume. If  you specify zero (the default), there is no limit except the 
physical size of the Volume. Otherwise,  when the number of bytes written to
the Volume equals {\bf size}  the Volume will be marked {\bf Used}. When the
Volume is marked  {\bf Used} it can no longer be used for appending Jobs, much
like  the {\bf Full} status but it can be recycled if recycling is enabled. 
This value is checked and the {\bf Used} status set while  the job is writing
to the particular volume.  

Please note that the value defined by this directive in the  bacula-dir.conf
file is the default value used when a Volume  is created. Once the volume is
created, changing the value  in the bacula-dir.conf file will not change what
is stored  for the Volume. To change the value for an existing Volume  you
must use the {\bf update} command in the Console.  

\item [Volume Use Duration = \lt{}time-period-specification\gt{}]
   \index[fd]{Volume Use Duration  }
   The Volume Use Duration directive defines the time period that  the Volume can
be written beginning from the time of first data  write to the Volume. If the
time-period specified is zero (the  default), the Volume can be written
indefinitely. Otherwise,  when the time period from the first write to the
volume (the  first Job written) exceeds the time-period-specification, the 
Volume will be marked {\bf Used}, which means that no more  Jobs can be
appended to the Volume, but it may be recycled if  recycling is enabled.  

You might use this directive, for example, if you have a Volume  used for
Incremental backups, and Volumes used for Weekly Full  backups. Once the Full
backup is done, you will want to use a  different Incremental Volume. This can
be accomplished by setting  the Volume Use Duration for the Incremental Volume
to six days.  I.e. it will be used for the 6 days following a Full save, then 
a different Incremental volume will be used.  

This value is checked and the {\bf Used} status is set only  at the end of a
job that writes to the particular volume, which  means that even though the
use duration may have expired, the  catalog entry will not be updated until
the next job that  uses this volume is run.  

Please note that the value defined by this directive in the  bacula-dir.conf
file is the default value used when a Volume  is created. Once the volume is
created, changing the value  in the bacula-dir.conf file will not change what
is stored  for the Volume. To change the value for an existing Volume  you
must use the {\bf update} command in the Console.  

\item [Catalog Files = \lt{}yes|no\gt{}]
   \index[fd]{Catalog Files  }
   This directive  defines whether or not you want the names of the files  that
were saved to be put into the catalog. The default  is {\bf yes}. The
advantage of specifying {\bf Catalog Files = No}  is that you will have a
significantly smaller Catalog database. The  disadvantage is that you will not
be able to produce a Catalog listing  of the files backed up for each Job
(this is often called Browsing).  Also, without the File entries in the
catalog, you will not be  able to use the Console {\bf restore} command nor
any other  command that references File entries.  
\label{PoolAutoPrune}

\item [AutoPrune = \lt{}yes|no\gt{}]
   \index[fd]{AutoPrune  }
   If AutoPrune is set to  {\bf yes} (default), Bacula (version 1.20 or greater)
will  automatically apply the Volume Retention period when new Volume  is
needed and no appendable Volumes exist in the Pool. Volume  pruning causes
expired Jobs (older than the {\bf Volume  Retention} period) to be deleted
from the Catalog and permits  possible recycling of the Volume.  
\label{VolRetention}

\item [Volume Retention = \lt{}time-period-specification\gt{}]
   \index[fd]{Volume Retention  }
   The  Volume Retention directive defines the length of time that {\bf Bacula} 
will keep Job records associated with the Volume in the Catalog  database.
When this time period expires, and if {\bf AutoPrune}  is set to {\bf yes}
Bacula will prune (remove) Job  records that are older than the specified
Volume Retention period.  All File records associated with pruned Jobs are
also pruned.  The time may be specified as seconds,  minutes, hours, days,
weeks, months, quarters, or years.  The {\bf Volume Retention} applied
independently to the  {\bf Job Retention} and the {\bf File Retention} periods
defined in the Client resource. This means that the shorter  period is the
one that applies. Note, that when the  {\bf Volume Retention} period has been
reached, it will  prune both the Job and the File records.  

The default is 365 days. Note, this directive sets the default  value for each
Volume entry in the Catalog when the Volume is  created. The value in the 
catalog may be later individually changed for each Volume using  the Console
program.  

By defining multiple Pools with different Volume Retention periods,  you may
effectively have a set of tapes that is recycled weekly,  another Pool of
tapes that is recycled monthly and so on. However,  one must keep in mind that
if your {\bf Volume Retention} period  is too short, it may prune the last
valid Full backup, and hence  until the next Full backup is done, you will not
have a complete  backup of your system, and in addition, the next Incremental 
or Differential backup will be promoted to a Full backup. As  a consequence,
the minimum {\bf Volume Retention} period should be at  twice the interval of
your Full backups. This means that if you  do a Full backup once a month, the
minimum Volume retention  period should be two months.  

Please note that the value defined by this directive in the  bacula-dir.conf
file is the default value used when a Volume  is created. Once the volume is
created, changing the value  in the bacula-dir.conf file will not change what
is stored  for the Volume. To change the value for an existing Volume  you
must use the {\bf update} command in the Console.  
\label{PoolRecycle}

\item [Recycle = \lt{}yes|no\gt{}]
   \index[fd]{Recycle  }
   This directive specifies the  default for recycling Purged Volumes. If it is
set to {\bf yes}  and Bacula needs a volume but finds none that are 
appendable, it will search for Purged Volumes (i.e. volumes  with all the Jobs
and Files expired and thus deleted from  the Catalog). If the Volume is
recycled, all previous data  written to that Volume will be overwritten.  

Please note that the value defined by this directive in the  bacula-dir.conf
file is the default value used when a Volume  is created. Once the volume is
created, changing the value  in the bacula-dir.conf file will not change what
is stored  for the Volume. To change the value for an existing Volume  you
must use the {\bf update} command in the Console.  
\label{RecycleOldest}

\item [Recycle Oldest Volume = \lt{}yes|no\gt{}]
   \index[fd]{Recycle Oldest Volume  }
   This directive  instructs the Director to search for the oldest used  Volume
in the Pool when another Volume is requested by  the Storage daemon and none
are available.  The catalog is then {\bf pruned} respecting the retention 
periods of all Files and Jobs written to this Volume.  If all Jobs are pruned
(i.e. the volume is Purged), then  the Volume is recycled and will be used as
the next  Volume to be written. This directive respects any Job,  File, or
Volume retention periods that you may have specified,  and as such it is {\bf
much} better to use this directive  than the Purge Oldest Volume.  

This directive can be useful if you have  a fixed number of Volumes in the
Pool and you want to  cycle through them and you have specified the correct 
retention periods.  
\label{RecycleCurrent}

\item [Recycle Current Volume = \lt{}yes|no\gt{}]
   \index[fd]{Recycle Current Volume  }
   If  Bacula needs a new Volume, this directive instructs Bacula  to Prune the
volume respecting the Job and File  retention periods.  If all Jobs are pruned
(i.e. the volume is Purged), then  the Volume is recycled and will be used as
the next  Volume to be written. This directive respects any Job,  File, or
Volume retention periods that you may have specified,  and thus it is {\bf
much} better to use it rather  than the Purge Oldest Volume directive.  

This directive can be useful if you have:  a fixed number of Volumes in the
Pool, you want to  cycle through them, and you have specified  retention
periods that prune Volumes before  you have cycled through the Volume in the
Pool.  
\label{PurgeOldest}

\item [Purge Oldest Volume = \lt{}yes|no\gt{}]
   \index[fd]{Purge Oldest Volume  }
   This directive  instructs the Director to search for the oldest used  Volume
in the Pool when another Volume is requested by  the Storage daemon and none
are available.  The catalog is then {\bf purged} irrespective of retention 
periods of all Files and Jobs written to this Volume.  The Volume is then
recycled and will be used as the next  Volume to be written. This directive
overrides any Job,  File, or Volume retention periods that you may have
specified.  

This directive can be useful if you have  a fixed number of Volumes in the
Pool and you want to  cycle through them and when all Volumes are full, but
you don't  want to worry about setting proper retention periods. However,  by
using this option you risk losing valuable data.  

{\bf Please be aware that {\bf Purge Oldest Volume} disregards  all retention
periods.} If you have only a single Volume  defined and you turn this variable
on, that Volume will always  be immediately overwritten when it fills! So at a
minimum,  ensure that you have a decent number of Volumes in your Pool  before
running any jobs. If you want retention periods to apply  do not use this
directive. To specify a retention period,  use the {\bf Volume Retention}
directive (see above).  

I highly recommend against using this directive, because it is  sure that some
day, Bacula will recycle a Volume that contains  current data. 

\item [Accept Any Volume = \lt{}yes|no\gt{}]
   \index[fd]{Accept Any Volume  }
   This directive  specifies whether or not any volume from the Pool may  be used
for backup. The default is {\bf yes} as of version  1.27 and later. If it is
{\bf no} then only the first  writable volume in the Pool will be accepted for
writing backup  data, thus Bacula will fill each Volume sequentially  in turn
before using any other appendable volume in the  Pool. If this is {\bf no} and
you mount a volume out  of order, Bacula will not accept it. If this  is {\bf
yes} any appendable volume from the pool  mounted will be accepted.  

If your tape backup procedure dictates that you manually  mount the next
volume, you will almost certainly want to be  sure this directive is turned
on.  

If you are going on vacation and you think the current volume  may not have
enough room on it, you can simply label a new tape  and leave it in the drive,
and assuming that {\bf Accept Any Volume}  is {\bf yes} Bacula will begin
writing on it. When you return  from vacation, simply remount the last tape,
and Bacula will  continue writing on it until it is full. Then you can remount
 your vacation tape and Bacula will fill it in turn.  

\item [Cleaning Prefix = \lt{}string\gt{}]
   \index[fd]{Cleaning Prefix  }
   This directive defines  a prefix string, which if it matches the beginning of 
a Volume name during labeling of a Volume, the Volume  will be defined with
the VolStatus set to {\bf Cleaning} and  thus Bacula will never attempt to use
this tape. This  is primarily for use with autochangers that accept barcodes 
where the convention is that barcodes beginning with {\bf CLN}  are treated as
cleaning tapes.  
\label{Label}

\item [Label Format = \lt{}format\gt{}]
   \index[fd]{Label Format  }
   This directive specifies the  format of the labels contained in this pool. The
format directive  is used as a sort of template to create new Volume names
during  automatic Volume labeling.  

The {\bf format} should be specified in double quotes, and  consists of
letters, numbers and the special characters  hyphen ({\bf -}), underscore
({\bf \_}), colon ({\bf :}), and  period ({\bf .}), which are the legal
characters for a Volume  name. The {\bf format} should be enclosed in  double
quotes ('').  

In addition, the format may contain a number of variable expansion  characters
which will be expanded by a complex algorithm allowing  you to create Volume
names of many different formats. In all  cases, the expansion process must
resolve to the set of characters  noted above that are legal Volume names.
Generally, these  variable expansion characters begin with a dollar sign ({\bf
\$})  or a left bracket ({\bf [}). If you specify variable expansion 
characters, you should always enclose the format with double  quote characters
({\bf ``}). For more details on variable expansion,  please see the 
\ilink{Variable Expansion}{_ChapterStart50} Chapter of  this manual.  

If no variable expansion characters are found in the string,  the Volume name
will be formed from the {\bf format} string  appended with the number of
volumes in the pool plus one, which  will be edited as four digits with
leading zeros. For example,  with a {\bf Label Format = ''File-``}, the first
volumes will be  named {\bf File-0001}, {\bf File-0002}, ...  

With the exception of Job specific variables, you can test  your {\bf
LabelFormat} by using the 
\ilink{ var command}{var} the Console Chapter of this manual.  

In almost all cases, you should enclose the format specification  (part after
the equal sign) in double quotes.  
\end{description}

In order for a Pool to be used during a Backup Job, the Pool must have at
least one Volume associated with it. Volumes are created for a Pool using the
{\bf label} or the {\bf add} commands in the {\bf Bacula Console}, program. In
addition to adding Volumes to the Pool (i.e. putting the Volume names in the
Catalog database), the physical Volume must be labeled with valid Bacula
software volume label before {\bf Bacula} will accept the Volume. This will be
automatically done if you use the {\bf label} command. Bacula can
automatically label Volumes if instructed to do so, but this feature is not
yet fully implemented. 

The following is an example of a valid Pool resource definition: 

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

\section*{The Catalog Resource}
\label{CatalogResource}
\index[general]{Resource!Catalog }
\index[general]{Catalog Resource }
\addcontentsline{toc}{section}{Catalog Resource}

The Catalog Resource defines what catalog to use for the current job.
Currently, Bacula can only handle a single database server (SQLite, MySQL,
built-in) that is defined when configuring {\bf Bacula}. However, there may be
as many Catalogs (databases) defined as you wish. For example, you may want
each Client to have its own Catalog database, or you may want backup jobs to
use one database and verify or restore jobs to use another database. 

\begin{description}

\item [Catalog]
   \index[console]{Catalog }
   Start of the Catalog resource.  At least one Catalog resource must be defined.


\item [Name = \lt{}name\gt{}]
   \index[console]{Name  }
   The name of the Catalog. No  necessary relation to the database server name.
This name  will be specified in the Client resource directive indicating  that
all catalog data for that Client is maintained in this  Catalog. This
directive is required.  

\item [password = \lt{}password\gt{}]
   \index[console]{password  }
   This specifies the password  to use when logging into the database. This
directive is required.  

\item [DB Name = \lt{}name\gt{}]
   \index[console]{DB Name  }
   This specifies the name of the  database. If you use multiple catalogs
(databases), you specify  which one here. If you are using an external
database server  rather than the internal one, you must specify a name that 
is known to the server (i.e. you explicitly created the  Bacula tables using
this name. This directive is  required. 

\item [user = \lt{}user\gt{}]
   \index[console]{user  }
   This specifies what user name  to use to log into the database. This directive
is required.  

\item [DB Socket = \lt{}socket-name\gt{}]
   \index[console]{DB Socket  }
   This is the name of  a socket to use on the local host to connect to the
database.  This directive is used only by MySQL and is ignored by  SQLite.
Normally, if neither {\bf DB Socket} or {\bf DB Address}  are specified, MySQL
will use the default socket.  

\item [DB Address = \lt{}address\gt{}]
   \index[console]{DB Address  }
   This is the host address  of the database server. Normally, you would specify
this instead  of {\bf DB Socket} if the database server is on another machine.
In that case, you will also specify {\bf DB Port}. This directive  is used
only by MySQL and is ignored by SQLite if provided.  This directive is
optional.  

\item [DB Port = \lt{}port\gt{}]
   \index[console]{DB Port  }
   This defines the port to  be used in conjunction with {\bf DB Address} to
access the  database if it is on another machine. This directive is used  only
by MySQL and is ignored by SQLite if provided. This  directive is optional.  

\item [Multiple Connections = \lt{}yes|no\gt{}]
   \index[console]{Multiple Connections  }
   By default, this  directive is set to no. In that case, each job that uses the
same Catalog will use a single connection to the catalog. It will  be shared,
and Bacula will allow only one Job at a time to  communicate. If you set this
directive to yes, Bacula will  permit multiple connections to the database,
and the database  must be multi-thread capable. For SQLite and PostgreSQL,
this is  no problem. For MySQL, you must be *very* careful to have the 
multi-thread version of the client library loaded on your system.  When this
directive is set yes, each Job will have a separate  connection to the
database, and the database will control the  interaction between the different
Jobs. This can significantly  speed up the database operations if you are
running multiple  simultaneous jobs. In addition, for SQLite and PostgreSQL,
Bacula  will automatically enable transactions. This can significantly  speed
up insertion of attributes in the database either for  a single Job or
multiple simultaneous Jobs.  

This directive has not been tested. Please test carefully  before running it
in production and report back your results.  
\end{description}

The following is an example of a valid Catalog resource definition: 

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

or for a Catalog on another machine: 

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

\section*{The Messages Resource}
\label{MessagesResource2}
\index[general]{Resource!Messages }
\index[general]{Messages Resource }
\addcontentsline{toc}{section}{Messages Resource}

For the details of the Messages Resource, please see the 
\ilink{Messages Resource Chapter}{_ChapterStart15} of this
manual. 

\section*{The Console Resource}
\label{ConsoleResource1}
\index[general]{Console Resource }
\index[general]{Resource!Console }
\addcontentsline{toc}{section}{Console Resource}

As of Bacula version 1.33 and higher, there are three different kinds of
consoles, which the administrator or user can use to interact with the
Director. These three kinds of consoles comprise three different security
levels. 

\begin{itemize}
\item The first console type is an {\bf anonymous} or {\bf default}  console,
   which  has full privileges. There is no console resource necessary  for this
   type since the password is specified in the Director's  resource and
consequently such consoles do not have an  name as defined on a {\bf Name =}
directive. This is the kind of  console that was initially implemented in
versions prior to 1.33  and remains valid. Typically you would use it only for
 administrators.  
\item The second type of console, and new to version 1.33 and  higher is a
   ''named`` console defined within  a Console resource in both the Director's
   configuration file and in  the Console's configuration file. Both the names
and the passwords  in these two entries must match much as is the case for 
Client programs.  

This second type of console begins with absolutely no  privileges except those
explicitly specified in the Director's  Console resource. Thus you can have
multiple Consoles with  different names and passwords, sort of like multiple
users, each  with different privileges. As a  default, these consoles can do
absolutely nothing -- no commands  what so ever. You give them privileges or
rather access  to commands and resources by specifying access  control lists
in the Director's Console resource. The ACLs are  specified by a directive
followed by a list of access names.  Examples of this are shown below.  
\item The third type of console is similar to the above mentioned  one in that
   it requires a Console resource definition in both  the Director and the
   Console. In addition, if the console name,  provided on the {\bf Name =}
directive, is the same as a Client  name, that console is permitted to use the
{\bf SetIP}  command to change the Address directive in the  Director's client
resource to the IP address of the Console. This  permits portables or other
machines using DHCP (non-fixed IP addresses)  to ''notify`` the Director of
their current IP address.  
\end{itemize}

The Console resource is optional and need not be specified. The following
directives are permited within the Director's configuration resource: 

\begin{description}

\item [Name = \lt{}name\gt{}]
   \index[console]{Name  }
   The name of the console. This  name must match the name specified in the
Console's configuration  resource (much as is the case with Client
definitions).  

\item [Password = \lt{}password\gt{}]
   \index[console]{Password  }
   Specifies the password that  must be supplied for a named Bacula Console to be
authorized. The same  password must appear in the {\bf Console} resource of
the Console  configuration file. For added security, the password is never 
actually passed across the network but rather a challenge response  hash code
created with the password. This directive is required.  If you have either
{\bf /dev/random}  {\bf bc} on your machine, Bacula will generate a random 
password during the configuration process, otherwise it will  be left blank. 

\item [JobACL = \lt{}name-list\gt{}]
   \index[console]{JobACL  }
   This directive is used to  specify a list of Job resource names that can be
accessed by  the console. Without this directive, the console cannot access 
any of the Director's Job resources. Multiple Job resource names  may be
specified by separating them with commas, and/or by specifying  multiple
JobACL directives. For example, the directive  may be specified as:  

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

With the above specification, the console can access the Director's  resources
for the four jobs named on the JobACL directives,  but for no others.  

\item [ClientACL = \lt{}name-list\gt{}]
   \index[console]{ClientACL  }
   This directive is used to  specify a list of Client resource names that can be
accessed by  the console.  

\item [StorageACL = \lt{}name-list\gt{}]
   \index[console]{StorageACL  }
   This directive is used to  specify a list of Storage resource names that can
be accessed by  the console.  

\item [ScheduleACL = \lt{}name-list\gt{}]
   \index[console]{ScheduleACL  }
   This directive is used to  specify a list of Schedule resource names that can
be accessed by  the console.  

\item [PoolACL = \lt{}name-list\gt{}]
   \index[console]{PoolACL  }
   This directive is used to  specify a list of Pool resource names that can be
accessed by  the console.  

\item [FileSetACL = \lt{}name-list\gt{}]
   \index[console]{FileSetACL  }
   This directive is used to  specify a list of FileSet resource names that can
be accessed by  the console.  

\item [CatalogACL = \lt{}name-list\gt{}]
   \index[console]{CatalogACL  }
   This directive is used to  specify a list of Catalog resource names that can
be accessed by  the console.  

\item [CommandACL = \lt{}name-list\gt{}]
   \index[console]{CommandACL  }
   This directive is used to  specify a list of of console commands that can be
executed by  the console. 
\end{description}

Aside from Director resource names and console command names, the special
keyword {\bf *all*} can be specified in any of the above access control lists.
When this keyword is present, any resource or command name (which ever is
appropriate) will be accepted. For an example configuration file, please see
the 
\ilink{Console Configuration}{_ChapterStart36} chapter of this
manual. 

\section*{The Counter Resource}
\label{CounterResource}
\index[general]{Resource!Counter }
\index[general]{Counter Resource }
\addcontentsline{toc}{section}{Counter Resource}

The Counter Resource defines a counter variable that can be accessed by
variable expansion used for creating Volume labels with the {\bf LabelFormat}
directive. See the 
\ilink{LabelFormat}{Label} directive in this chapter for more
details. 

\begin{description}

\item [Counter]
   \index[console]{Counter }
   Start of the Counter resource.  Counter directives are optional. 

\item [Name = \lt{}name\gt{}]
   \index[console]{Name  }
   The name of the Counter.  This is the name you will use in the variable
expansion  to reference the counter value.  

\item [Minimum = \lt{}integer\gt{}]
   \index[console]{Minimum  }
   This specifies the minimum  value that the counter can have. It also becomes
the default.  If not supplied, zero is assumed.  

\item [Maximum = \lt{}integer\gt{}]
   \index[console]{Maximum  }
   This is the maximum value  value that the counter can have. If not specified
or set to  zero, the counter can have a maximum value of 2,147,483,648  (2 to
the 31 power). When the counter is incremented past  this value, it is reset
to the Minimum.  

\item [*WrapCounter = \lt{}counter-name\gt{}]
   \index[console]{*WrapCounter  }
   If this value  is specified, when the counter is incremented past the maximum 
and thus reset to the minimum, the counter specified on the  {\bf WrapCounter}
is incremented. (This is not currently  implemented). 

\item [Catalog = \lt{}catalog-name\gt{}]
   \index[console]{Catalog  }
   If this directive is  specified, the counter and its values will be saved in 
the specified catalog. If this directive is not present, the  counter will be
redefined each time that Bacula is started. 
\end{description}

\section*{ A Complete Example Director Configuration File}
\label{SampleDirectorConfiguration}
\index[general]{File!Complete Example Director Configuration }
\index[general]{Complete Example Director Configuration File }
\addcontentsline{toc}{section}{Complete Example Director Configuration File}

An example Director configuration file might be the following: 

\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 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