Updates

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

%%
%%

\section*{Configuring the Director}
\label{_ChapterStart40}
\index[general]{Director!Configuring the }
\index[general]{Configuring the Director }
\addcontentsline{toc}{section}{Configuring the Director}

Of all the configuration files needed to run {\bf Bacula}, the Director's is
the most complicated, and the one that you will need to modify the most often
as you add clients or modify the FileSets. 

For a general discussion of configuration file and resources including the
data types recognized by {\bf Bacula}. Please see the 
\ilink{Configuration}{_ChapterStart16} chapter of this manual. 

\subsection*{Director Resource Types}
\index[general]{Types!Director Resource }
\index[general]{Director Resource Types }
\addcontentsline{toc}{subsection}{Director Resource Types}

Director resource type may be one of the following: 

Job, JobDefs, Client, Storage, Catalog, Schedule, FileSet, Pool, Director,  or
Messages. We present them here in the most logical order for defining them: 

\begin{itemize}
\item 
   \ilink{Director}{DirectorResource4} -- to  define the Director's
   name and its access password used for  authenticating the Console program.
Only a single  Director resource definition may appear in the Director's 
configuration file.  If you have either {\bf /dev/random} or  {\bf bc} on your
machine, Bacula will generate a random  password during the configuration
process, otherwise it will  be left blank. 
\item 
   \ilink{Job}{JobResource} -- to define the backup/restore Jobs 
   and to tie together the Client, FileSet and Schedule resources to  be used
for
each Job.  
\item 
   \ilink{JobDefs}{JobDefsResource} -- optional resource for 
   providing defaults for Job resources.  
\item 
   \ilink{Schedule}{ScheduleResource} -- to define when a Job is to 
   be automatically run by {\bf Bacula's} internal scheduler.  
\item 
   \ilink{FileSet}{FileSetResource} -- to define the set of files 
   to be backed up for each Client. 
\item 
   \ilink{Client}{ClientResource2} -- to define what Client is  to be
   backed up.  
\item 
   \ilink{Storage}{StorageResource2} -- to define on what  physical
   device the Volumes should be mounted. 
\item 
   \ilink{Pool}{PoolResource} -- to define the pool of Volumes
   that can be used for a particular Job. 
\item 
   \ilink{Catalog}{CatalogResource} -- to define in what database to
 keep the list of files and the Volume names where they are backed up.  
\item 
   \ilink{Messages}{_ChapterStart15} -- to define where error  and
   information messages are to be sent or logged. 
\end{itemize}

\subsection*{The Director Resource}
\label{DirectorResource4}
\index[general]{Director Resource }
\index[general]{Resource!Director }
\addcontentsline{toc}{subsection}{Director Resource}

The Director resource defines the attributes of the Directors running on the
network. In the current implementation, there is only a single Director
resource, but the final design will contain multiple Directors to maintain
index and media database redundancy. 

\begin{description}

\item [Director]
   \index[dir]{Director }
   Start of the Director resource. One and only one  director resource must be
supplied.  

\item [Name = \lt{}name\gt{}]
   \index[dir]{Name  }
   The director name used by the system  administrator. This directive is
required.  

\item [Description = \lt{}text\gt{}]
   \index[dir]{Description  }
   The text field contains a  description of the Director that will be displayed
in the  graphical user interface. This directive is optional.  

\item [Password = \lt{}UA-password\gt{}]
   \index[dir]{Password  }
   Specifies the password that  must be supplied for the default Bacula Console
to be  authorized. The same password must appear in the  {\bf Director}
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 and  you must manually supply it.  

\item [Messages = \lt{}Messages-resource-name\gt{}]
   \index[dir]{Messages  }
   The messages resource  specifies where to deliver Director messages that are
not associated  with a specific Job. Most messages are specific to a job and
will  be directed to the Messages resource specified by the job. However, 
there are a few messages that can occur when no job is running.  This
directive is required.  

\item [Working Directory = \lt{}Directory\gt{}]
   \index[dir]{Working Directory  }
   This directive  is mandatory and specifies a directory in which the Director 
   may put its status files. This directory should be used only  by Bacula but
   may be shared by other Bacula daemons. However, please note, if this
   directory is shared with other Bacula daemons (the File daemon and Storage
   daemon), you must ensure that the {\bf Name} given to each daemon is
   unique so that the temporary filenames used do not collide.  By default
   the Bacula configure process creates unique daemon names by postfixing them
   with -dir, -fd, and -sd. Standard shell expansion of the {\bf
   Directory}  is done when the configuration file is read so that values such 
   as {\bf \$HOME} will be properly expanded. This directive is required.

\item [Pid Directory = \lt{}Directory\gt{}]
   \index[dir]{Pid Directory  }
   This directive  is mandatory and specifies a directory in which the Director 
may put its process Id file files. The process Id file is used to  shutdown
Bacula and to prevent multiple copies of  Bacula from running simultaneously. 
Standard shell expansion of the {\bf Directory}  is done when the
configuration file is read so that values such  as {\bf \$HOME} will be
properly expanded.  

Typically on Linux systems, you will set this to:  {\bf /var/run}. If you are
not installing Bacula in the  system directories, you can use the {\bf Working
Directory} as  defined above.  This directive is required.  

\item [Scripts Directory = \lt{}Directory\gt{}]
   \index[dir]{Scripts Directory  }
   This directive is optional and, if defined, specifies a directory in which
the Director 
will look for the Python startup script {\bf DirStartup.py}. This directory
may be shared by other Bacula daemons.  Standard shell expansion of the
directory is done when the configuration file is read so that values such 
as {\bf \$HOME} will be properly expanded.

\item [QueryFile = \lt{}Path\gt{}]
   \index[dir]{QueryFile  }
   This directive  is mandatory and specifies a directory and file in which the
Director  can find the canned SQL statements for the {\bf Query} command of 
the Console. Standard shell expansion of the {\bf Path} is done  when the
configuration file is read so that values such as  {\bf \$HOME} will be
properly expanded. This directive is required.  
\label{DirMaxConJobs}

\item [Maximum Concurrent Jobs = \lt{}number\gt{}]
   \index[dir]{Maximum Concurrent Jobs  }
   where \lt{}number\gt{}  is the maximum number of total Director Jobs that
should run  concurrently. The default is set to 1, but you may set it to a 
larger number.  

Please  note that the Volume format becomes much more complicated with 
multiple simultaneous jobs, consequently, restores can take much  longer if
Bacula must sort through interleaved volume blocks from  multiple simultaneous
jobs. This can be avoided by having each  simultaneously running job write to
a different volume or  by using data spooling, which will first spool the data
to disk simultaneously, then write each spool file to the  volume in
sequence.  

There may also still be some cases where directives such as  {\bf Maximum
Volume Jobs} are not properly synchronized with  multiple simultaneous jobs
(subtle timing issues can arise),  so careful testing is recommended. 

At the current time,  there is no configuration parameter set to limit the
number of console connections. A maximum of five simultaneous console 
connections are permitted.  

For more details on getting concurrent jobs to run, please  see 
\ilink{Running Concurrent Jobs}{ConcurrentJobs} in the Tips chapter
of this manual.  

\item [FD Connect Timeout = \lt{}time\gt{}]
   \index[dir]{FD Connect Timeout  }
   where {\bf time}  is the time that the Director should continue attempting 
to
contact the File daemon to start a job, and after which the  Director will
cancel the job. The default is 30 minutes. 

\item [SD Connect Timeout = \lt{}time\gt{}]
   \index[dir]{SD Connect Timeout  }
   where {\bf time}  is the time that the Director should continue attempting 
to
contact the Storage daemon to start a job, and after which the  Director will
cancel the job. The default is 30 minutes. 

\item [DirAddresses = \lt{}IP-address-specification\gt{}]
   \index[dir]{DirAddresses  }
   Specify the ports and addresses on which the Director daemon will  listen for
Bacula Console connections. Probably the simplest way  to explain this is to
show
an example: 

\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

where ip, ip4, ip6, addr, and port are all keywords. Note, that  the address
can be specified as either a dotted quadruple, or  IPv6 colon notation, or as
a symbolic name (only in the ip specification).  Also, port can be specified
as a number or as the mnemonic value from  the /etc/services file.  If a port
is not specified, the default will be used. If an ip  section is specified,
the resolution can be made either by IPv4 or  IPv6. If ip4 is specified, then
only IPv4 resolutions will be permitted,  and likewise with ip6. 

\item [DIRport = \lt{}port-number\gt{}]
   \index[dir]{DIRport  }
   Specify the port (a positive  integer) on which the  Director daemon will
listen for Bacula Console connections.  This same port number must be
specified in the Director resource  of the Console configuration file. The
default is 9101, so  normally this directive need not be specified.  This
directive is not needed if you specify DirAddresses. 

\item [DirAddress = \lt{}IP-Address\gt{}]
   \index[dir]{DirAddress  }
   This directive is optional,  but if it is specified, it will cause the
Director server (for  the Console program) to bind to the specified {\bf
IP-Address},  which is either a domain name or an IP address specified as a 
dotted quadruple in string or quoted string format.  If this directive is not
specified, the Director  will bind to any available address (the default). 
Note, unlike the DirAddresses specification noted above, this  directive only
permits a single address to be specified.  This directive is not needed if you
specify a DirAddresses  (not plural). 
\end{description}

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

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

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

The Job resource defines a Job (Backup, Restore, ...) that Bacula must
perform. Each Job resource definition contains the name of a Client and
a FileSet to backup, the Schedule for the Job, where the data
are to be stored, and what media Pool can be used. In effect, each Job
resource must specify What, Where, How, and When or FileSet, Storage,
Backup/Restore/Level, and Schedule respectively. Note, the FileSet must
be specified for a restore job for historical reasons, but it is no longer used.

Only a single type ({\bf Backup}, {\bf Restore}, ...) can be specified for any
job. If you want to backup multiple FileSets on the same Client or multiple
Clients, you must define a Job for each one. 

\begin{description}

\item [Job]
   \index[dir]{Job }
   Start of the Job resource. At least one Job  resource is required. 

\item [Name = \lt{}name\gt{}]
   \index[dir]{Name  }
   The Job name. This name can be specified  on the {\bf Run} command in the
   console program to start a job. If the  name contains spaces, it must be
   specified between quotes. It is  generally a good idea to give your job the
   same name as the Client  that it will backup. This permits easy
identification
   of jobs.  

   When the job actually runs, the unique Job Name will consist  of the name you
   specify here followed by the date and time the  job was scheduled for
   execution. This directive is required. 

\item [Type = \lt{}job-type\gt{}]
   \index[dir]{Type  }
   The {\bf Type} directive specifies  the Job type, which may be one of the
following: {\bf Backup},  {\bf Restore}, {\bf Verify}, or {\bf Admin}. This
directive  is required. Within a particular Job Type, there are also Levels 
as discussed in the next item.  

\begin{description}

\item [Backup]
   \index[dir]{Backup }
   Run a backup Job. Normally you will  have at least one Backup job for each
client you want  to save. Normally, unless you turn off cataloging,  most all
the important statistics and data concerning  files backed up will be placed
in the catalog. 

\item [Restore]
   \index[dir]{Restore }
   Run a restore Job. Normally, you will  specify only one Restore job which
acts
as a sort  of prototype that you will modify using the console  program in
order to perform restores. Although certain  basic information from a Restore
job is saved in the  catalog, it is very minimal compared to the information 
stored for a Backup job -- for example, no File database  entries are
generated since no Files are saved.  

\item [Verify]
   \index[dir]{Verify }
   Run a verify Job. In general, {\bf verify}  jobs permit you to compare the
contents of the catalog  to the file system, or to what was backed up. In
addition,  to verifying that a tape that was written can be read,  you can
also use {\bf verify} as a sort of tripwire  intrusion detection.  

\item [Admin]
   \index[dir]{Admin }
   Run an admin Job. An {\bf Admin} job can  be used to periodically run catalog
pruning, if you  do not want to do it at the end of each {\bf Backup}  Job.
Although an Admin job is recorded in the  catalog, very little data is saved. 
\end{description}

\label{Level}

\item [Level = \lt{}job-level\gt{}]
   \index[dir]{Level  }
   The Level directive specifies  the default Job level to be run. Each
different
Job Type (Backup, Restore, ...) has a different set of Levels  that can be
specified. The Level is normally overridden  by a different value that is
specified in the {\bf Schedule}  resource. This directive is not required, but
must be specified either  by a {\bf Level} directive or as a override
specified in the  {\bf Schedule} resource.  

For a {\bf Backup} Job, the Level may be one of the  following:  

\begin{description}

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

\item [Incremental]
   \index[dir]{Incremental }
   is all files that have changed since the  last successful backup of the
specified FileSet. If the  Director cannot find a previous Full backup then
the job will be  upgraded into a Full backup. When the Director looks for a 
"suitable" backup record in the catalog database, it  looks for a previous
Job with:  

\begin{itemize}
\item The same Job name.  
\item The same Client name.  
\item The same FileSet (any change to the definition of  the FileSet such as
   adding or deleting a file in the  Include or Exclude sections constitutes a
   different FileSet.  
\item The Job was a Full, Differential, or Incremental backup.  
\item The Job terminated normally (i.e. did not fail or was not  canceled).  
   \end{itemize}

If all the above conditions do not hold, the Director will upgrade  the
Incremental to a Full save. Otherwise, the Incremental  backup will be
performed as requested.  

The File daemon (Client) decides which files to backup for an  Incremental
backup by comparing start time of the prior Job  (Full, Differential, or
Incremental) against the time each file  was last "modified" (st\_mtime) and
the time its  attributes were last "changed"(st\_ctime). If the  file was
modified or its attributes changed on or after this  start time, it will then
be backed up.  

Please note that some  virus scanning software may change st\_ctime while
doing the  scan. For example, if the the virus scanning program attempts  to
reset the access time (st\_atime), which Bacula does not use,  it will cause
st\_ctime to change and hence Bacula will backup  the file during an
Incremental or Differential backup. In the  case of Sophos virus scanning, you
can prevent it from  resetting the access time (st\_atime) and hence changing 
st\_ctime by using the {\bf \verb:--:no-reset-atime} option. For  other
software,
please see their manual.  

When Bacula does an Incremental backup, all modified  files that are still on
the system are backed up.  However, any file that has been deleted since the
last  Full backup remains in the Bacula catalog, which means  that if between
a Full save and the time you do a  restore, some files are deleted, those
deleted files  will also be restored. The deleted files will no longer  appear
in the catalog after doing another Full save.  However, to remove deleted
files from the catalog during an Incremental backup is quite a time consuming
process  and not currently implemented in Bacula. 

In addition, if you move a directory rather than copy it, the files in it do not
have their modification time (st\_mtime) or their attribute change time
(st\_ctime) 
changed. As a consequence, those files will probably not be backed up by an
Incremental
or Differential backup which depend solely on these time stamps. If you move a
directory,
and which it to be properly backed up, it is generally preferable to copy it
then
delete the original.

\item [Differential]
   \index[dir]{Differential }
   is all files that have changed since the  last successful Full backup of the
specified FileSet.  If the Director cannot find a previous Full backup or a 
suitable Full backup, then the Differential job will be  upgraded into a Full
backup. When the Director looks for  a "suitable" Full backup record in the
catalog  database, it looks for a previous Job with:  

\begin{itemize}
\item The same Job name.  
\item The same Client name.  
\item The same FileSet (any change to the definition of  the FileSet such as
   adding or deleting a file in the  Include or Exclude sections constitutes a
   different FileSet.  
\item The Job was a FULL backup.  
\item The Job terminated normally (i.e. did not fail or was not  canceled).  
\end{itemize}

If all the above conditions do not hold, the Director will  upgrade the
Differential to a Full save. Otherwise, the  Differential backup will be
performed as requested.  

The File daemon (Client) decides which files to backup for a  differential
backup by comparing the start time of the prior  Full backup Job against the
time each file was last  "modified" (st\_mtime) and the time its attributes
were  last "changed" (st\_ctime). If the file was modified or its attributes
were changed on or after this start time, it will then be backed up. The
start time used is displayed after the  {\bf Since} on the Job report. In rare
cases, using the start  time of the prior backup may cause some files to be
backed up  twice, but it ensures that no change is missed. As with the 
Incremental option, you should ensure that the clocks on your  server and
client are synchronized or as close as possible to  avoid the possibility of a
file being skipped. Note, on  versions 1.33 or greater Bacula automatically
makes the  necessary adjustments to the time between the server and the  client
so that the times Bacula uses are synchronized.  

When Bacula does a Differential backup, all modified  files that are still on
the system are backed up.  However, any file that has been deleted since the
last  Full backup remains in the Bacula catalog, which means  that if between
a Full save and the time you do a  restore, some files are deleted, those
deleted files  will also be restored. The deleted files will no longer  appear
in the catalog after doing another Full save.  However, to remove deleted
files from the catalog during a Differential backup is quite a time consuming
process  and not currently implemented in Bacula. 

As noted above, if you move a directory rather than copy it, the
files in it do not have their modification time (st\_mtime) or
their attribute change time (st\_ctime) changed.  As a
consequence, those files will probably not be backed up by an
Incremental or Differential backup which depend solely on these
time stamps.  If you move a directory, and which it to be
properly backed up, it is generally preferable to copy it then
delete the original.  

Every once and a while, someone asks why we need Differential
backups as long as Incremental backups pickup all changed files.
There are possibly many answers to this question, but the one
that is the most important for me is that it effectively combines
all the Incremental and Differential backups since the last Full 
backup into a single Differential backup. This has two effects:
1. It gives some redundancy. 2. More importantly, it reduces the
number of Volumes that are needed to do a restore effectively
eliminating the need to read all the volumes on which the
preceding Incremental and Differential backups since the last
Full are done.


\end{description}

For a {\bf Restore} Job, no level needs to be specified.  

For a {\bf Verify} Job, the Level may be one of the  following:  

\begin{description}

\item [InitCatalog]
   \index[dir]{InitCatalog }
   does a scan of the specified {\bf FileSet} and stores the file
   attributes in the Catalog database.  Since no file data is saved, you
   might ask why you would want to do this.  It turns out to be a very
   simple and easy way to have a {\bf Tripwire} like feature using {\bf
   Bacula}.  In other words, it allows you to save the state of a set of
   files defined by the {\bf FileSet} and later check to see if those files
   have been modified or deleted and if any new files have been added.
   This can be used to detect system intrusion.  Typically you would
   specify a {\bf FileSet} that contains the set of system files that
   should not change (e.g.  /sbin, /boot, /lib, /bin, ...).  Normally, you
   run the {\bf InitCatalog} level verify one time when your system is
   first setup, and then once again after each modification (upgrade) to
   your system.  Thereafter, when your want to check the state of your
   system files, you use a {\bf Verify} {\bf level = Catalog}.  This
   compares the results of your {\bf InitCatalog} with the current state of
   the files.

\item [Catalog]
   \index[dir]{Catalog }
   Compares the current state of the files against the state previously
   saved during an {\bf InitCatalog}.  Any discrepancies are reported.  The
   items reported are determined by the {\bf verify} options specified on
   the {\bf Include} directive in the specified {\bf FileSet} (see the {\bf
   FileSet} resource below for more details).  Typically this command will
   be run once a day (or night) to check for any changes to your system
   files.

   Please note!  If you run two Verify Catalog jobs on the same client at
   the same time, the results will certainly be incorrect.  This is because
   Verify Catalog modifies the Catalog database while running in order to
   track new files.

\item [VolumeToCatalog]
   \index[dir]{VolumeToCatalog }
   This level causes Bacula to read  the file attribute data written to the
Volume from the last Job.  The file attribute data are compared to the values
saved in the  Catalog database and any differences are reported. This is 
similar to the {\bf Catalog} level except that instead of  comparing the disk
file attributes to the catalog database, the  attribute data written to the
Volume is read and compared to the  catalog database. Although the attribute
data including the  signatures (MD5 or SHA1) are compared the actual file data
is not  compared (it is not in the catalog). 

Please note! If you  run two Verify VolumeToCatalog jobs on the same client at
the  same time, the results will certainly be incorrect. This is  because the
Verify VolumeToCatalog modifies the Catalog database  while running. 

\item [DiskToCatalog]
   \index[dir]{DiskToCatalog }
   This level causes Bacula to read the  files as they currently are on disk,
and
to compare the  current file attributes with the attributes saved in the 
catalog from the last backup for the job specified on  the {\bf VerifyJob}
directive. This level differs from the  {\bf Catalog} level described above by
the fact that it  doesn't compare against a previous Verify job but against a 
previous backup. When you run this level, you must supply the  verify options
on your Include statements. Those options  determine what attribute fields are
compared.  

This command can be very useful if you have disk problems  because it will
compare the current state of your disk against  the last successful backup,
which may be several jobs.  

Note, the current implementation (1.32c) does not  identify files that have
been deleted.  
\end{description}

\item [Verify Job = \lt{}Job-Resource-Name\gt{}]
   \index[dir]{Verify Job  }
   If you run  a verify job without this directive, the last job run will  be
compared with the catalog, which means that you must  immediately follow a
backup by a verify command. If you  specify a {\bf Verify Job} Bacula will
find the last  job with that name that ran. This permits you to run  all your
backups, then run Verify jobs on those that  you wish to be verified (most
often a {\bf VolumeToCatalog})  so that the tape just written is re-read. 

\item [JobDefs = \lt{}JobDefs-Resource-Name\gt{}]
   \index[dir]{JobDefs  }
   If a JobDefs-Resource-Name  is specified, all the values contained in the
named JobDefs resource  will be used as the defaults for the current Job. Any
value that  you explicitly define in the current Job resource, will override 
any defaults specified in the JobDefs resource. The use of this  directive
permits writing much more compact Job resources where the  bulk of the
directives are defined in one or more JobDefs. This  is particularly useful if
you have many similar Jobs but with  minor variations such as different
Clients. A simple example  of the use of JobDefs is provided in the default
bacula-dir.conf  file. 

\item [Bootstrap = \lt{}bootstrap-file\gt{}]
   \index[dir]{Bootstrap  }
   The Bootstrap  directive specifies a bootstrap file that, if provided, will 
be used during {\bf Restore} Jobs and is ignored in other  Job types. The {\bf
bootstrap}  file contains the list of tapes to be used in a restore  Job as
well as which files are to be restored. Specification  of this directive is
optional, and  if specified, it is used only for a restore job. In addition, 
when running a Restore job from the console, this value can  be changed.  

If you use the {\bf Restore} command in the Console program,  to start a
restore job, the {\bf bootstrap}  file will be created automatically from the
files you  select to be restored.  

For additional details of the {\bf bootstrap} file, please see  
\ilink{Restoring Files with the Bootstrap File}{_ChapterStart43} 
chapter of this manual. 

\label{writebootstrap}
\item [Write Bootstrap =  \lt{}bootstrap-file-specification\gt{}]
   \index[dir]{a name }
   The  {\bf writebootstrap} directive specifies a file name where  Bacula will
write a {\bf bootstrap} file for each Backup job  run. Thus this directive
applies only to Backup Jobs. If the Backup  job is a Full save, Bacula will
erase any current contents of  the specified file before writing the bootstrap
records. If the Job  is an Incremental save, Bacula will append the current 
bootstrap record to the end of the file.  

Using this feature,  permits you to constantly have a bootstrap file that can
recover the  current state of your system. Normally, the file specified should
be a mounted drive on another machine, so that if your hard disk is  lost,
you will immediately have a bootstrap record available.  Alternatively, you
should copy the bootstrap file to another machine  after it is updated.  

If the {\bf bootstrap-file-specification} begins with a  vertical bar (|),
Bacula will use the specification as the  name of a program to which it will
pipe the bootstrap record.  It could for example be a shell script that emails
you the  bootstrap record. 

For more details on using this file,  please see the chapter entitled 
\ilink{The Bootstrap File}{_ChapterStart43} of this manual. 

\item [Client = \lt{}client-resource-name\gt{}]
   \index[dir]{Client  }
   The Client directive  specifies the Client (File daemon) that will be used in
   the  current Job. Only a single Client may be specified in any one Job.  The
   Client runs on the machine to be backed up,  and sends the requested files to
   the Storage daemon for backup,  or receives them when restoring. For
   additional details, see the  
   \ilink{Client Resource section}{ClientResource2} of this chapter.
   This directive is required. 

\item [FileSet = \lt{}FileSet-resource-name\gt{}]
   \index[dir]{FileSet  }
   The FileSet directive  specifies the FileSet that will be used in the 
current
   Job. The FileSet specifies which directories (or files)  are to be backed up,
   and what options to use (e.g. compression, ...).  Only a single FileSet
   resource may be specified in any one Job.  For additional details, see the  
   \ilink{FileSet Resource section}{FileSetResource} of this
   chapter. This directive is required. 

\item [Messages = \lt{}messages-resource-name\gt{}]
   \index[dir]{Messages  }
   The Messages directive  defines what Messages resource should be used for
this
   job, and thus  how and where the various messages are to be delivered. For
   example,  you can direct some messages to a log file, and others can be  sent
   by email. For additional details, see the  
   \ilink{Messages Resource}{_ChapterStart15} Chapter of this 
   manual. This directive is required. 

\item [Pool = \lt{}pool-resource-name\gt{}]
   \index[dir]{Pool  }
   The Pool directive defines the pool of Volumes where your data can be backed
   up. Many Bacula  installations will use only the {\bf Default} pool. However,
   if  you want to specify a different set of Volumes for different  Clients or
   different Jobs, you will probably want to use Pools.  For additional details,
   see the 
   \ilink{Pool Resource section}{PoolResource} of this chapter. This
   directive is required. 

\item [Full Backup Pool = \lt{}pool-resource-name\gt{}]
   \index[dir]{Full Backup Pool  }
   The {\it Full Backup Pool} specifies a Pool to be used for  Full backups. It
   will override any Pool specification during a  Full backup. This directive is
   optional. 
   
\item [Differential Backup Pool = \lt{}pool-resource-name\gt{}]  
   \index[dir]{Differential Backup Pool  }
   The {\it Differential Backup Pool} specifies a Pool to be used for 
   Differential backups. It will override any Pool specification during a 
   Differential backup. This directive is optional. 
   
\item [Incremental Backup Pool = \lt{}pool-resource-name\gt{}]  
   \index[dir]{Incremental Backup Pool  }
   The {\it Incremental Backup Pool} specifies a Pool to be used for 
Incremental
   backups. It will override any Pool specification during an  Incremental
backup.
   This directive is optional. 

\item [Schedule = \lt{}schedule-name\gt{}]
   \index[dir]{Schedule  }
   The Schedule directive defines what schedule is to be used for the Job.
   The schedule in turn determines when the Job will be automatically
   started and what Job level (i.e.  Full, Incremental, ...) is to be run.
   This directive is optional, and if left out, the Job can only be started
   manually using the Console program.  Although you may specify only a
   single Schedule resource for any one job, the Schedule resource may
   contain multiple {\bf Run} directives, which allow you to run the Job at
   many different times, and each {\bf run} directive permits overriding
   the default Job Level Pool, Storage, and Messages resources.  This gives
   considerable flexibility in what can be done with a single Job.  For
   additional details, see the \ilink{Schedule Resource
   Chapter}{ScheduleResource} of this manual.
          

\item [Storage = \lt{}storage-resource-name\gt{}]
   \index[dir]{Storage  }
   The Storage directive  defines the name of the storage services where you
want
   to backup  the FileSet data. For additional details, see the 
   \ilink{Storage Resource Chapter}{StorageResource2} of this manual.
    This directive is required.  

\item [Max Start Delay = \lt{}time\gt{}]
   \index[dir]{Max Start Delay  }
   The time specifies the maximum delay between the scheduled time and the
   actual start time for the Job.  For example, a job can be scheduled to
   run at 1:00am, but because other jobs are running, it may wait to run.
   If the delay is set to 3600 (one hour) and the job has not begun to run
   by 2:00am, the job will be canceled.  This can be useful, for example,
   to prevent jobs from running during day time hours.  The default is 0
   which indicates no limit.

\item [Max Run Time = \lt{}time\gt{}]
   \index[dir]{Max Run Time  }
   The time specifies the maximum allowed time that a job may run, counted
   from when the job starts, ({\bf not} necessarily the same as when the
   job was scheduled).  This directive is implemented in version 1.33 and
   later.

\item [Max Wait Time = \lt{}time\gt{}]
   \index[dir]{Max Wait Time  }
   The time specifies the maximum allowed time that a job may block waiting
   for a resource (such as waiting for a tape to be mounted, or waiting for
   the storage or file daemons to perform their duties), counted from the
   when the job starts, ({\bf not} necessarily the same as when the job was
   scheduled).  This directive is implemented only in version 1.33 and
   later.



\item [Incremental Max Wait Time = \lt{}time\gt{}]
   \index[dir]{Incremental Max Wait Time  }
   The time specifies the maximum allowed time that an Incremental backup
   job may block waiting for a resource (such as waiting for a tape to be
   mounted, or waiting for the storage or file daemons to perform their
   duties), counted from the when the job starts, ({\bf not} necessarily
   the same as when the job was scheduled).  Please note that if there is a
   {\bf Max Wait Time} it may also be applied to the job.

\item [Differential Max Wait Time = \lt{}time\gt{}]
   \index[dir]{Differential Max Wait Time  }
   The time specifies the maximum allowed time that a Differential backup
   job may block waiting for a resource (such as waiting for a tape to be
   mounted, or waiting for the storage or file daemons to perform their
   duties), counted from the when the job starts, ({\bf not} necessarily
   the same as when the job was scheduled).  Please note that if there is a
   {\bf Max Wait Time} it may also be applied to the job.

\item [Prefer Mounted Volumes = \lt{}yes|no\gt{}]
   \index[dir]{Prefer Mounted Volumes}
   It the Prefer Mounted Volumes directive is set to {\bf yes}
   (default yes), it is used to inform the Storage daemon
   to select either an Autochanger or a drive with a valid
   Volume already mounted in preference to a drive that is
   not ready. If none is available, it will select the first 
   available drive. If the directive is set to {\bf no}, the
   Storage daemon will prefer finding an unused drive. This
   can potentially be useful for those sites that prefer to
   maximum backup throughput at the expense of using additional
   drives and Volumes.


\item [Prune Jobs = \lt{}yes|no\gt{}]
   \index[dir]{Prune Jobs  }
   Normally, pruning of Jobs from the Catalog is specified on a Client by
   Client basis in the Client resource with the {\bf AutoPrune} directive.
   If this directive is specified (not normally) and the value is {\bf
   yes}, it will override the value specified in the Client resource.  The
   default is {\bf no}.


\item [Prune Files = \lt{}yes|no\gt{}]
   \index[dir]{Prune Files  }
   Normally, pruning of Files from the Catalog is specified on a Client by
   Client basis in the Client resource with the {\bf AutoPrune} directive.
   If this directive is specified (not normally) and the value is {\bf
   yes}, it will override the value specified in the Client resource.  The
   default is {\bf no}.

\item [Prune Volumes = \lt{}yes|no\gt{}]
   \index[dir]{Prune Volumes  }
   Normally, pruning of Volumes from the Catalog is specified on a Client
   by Client basis in the Client resource with the {\bf AutoPrune}
   directive.  If this directive is specified (not normally) and the value
   is {\bf yes}, it will override the value specified in the Client
   resource.  The default is {\bf no}.

\item [Run Before Job = \lt{}command\gt{}]
   \index[dir]{Run Before Job  }
   The specified {\bf command} is run as an external program prior to
   running the current Job.  Any output sent by the command to standard output
   will be included in the Bacula job report.  The command string must be a
   valid program name or name of a shell script.  This directive is not
   required, but if it is defined, and if the exit code of the program run
   is non-zero, the current Bacula job will be canceled.  In addition, the
   command string is parsed then fed to the execvp() function, which means
   that the path will be searched to execute your specified command, but
   there is no shell interpretation, as a consequence, if you invoke
   complicated commands or want any shell features such as redirection or
   piping, you must call a shell script and do it inside that script.
 
   Before submitting the specified command to the operating system, Bacula
   performs character substitution of the following characters:
  
\footnotesize
\begin{verbatim}
    %% = %
    %c = Client's name
    %d = Director's name
    %i = JobId
    %e = Job Exit Status
    %j = Unique Job name
    %l = Job Level
    %n = Job name
    %t = Job type
    %v = Volume name
    
\end{verbatim}
\normalsize

The Job Exit Status code \%e edits the following values:

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

   Thus if you edit it on a command line, you will need to enclose 
   it within some sort of quotes.
   
   Bacula checks the exit status of the RunBeforeJob program.  If it is
   non-zero, the job will be error terminated.  Lutz Kittler has pointed
   out that using the RunBeforJob directive can be a simple way to modify
   your schedules during a holiday.  For example, suppose that you normally
   do Full backups on Fridays, but Thursday and Friday are holidays.  To
   avoid having to change tapes between Thursday and Friday when no one is
   in the office, you can create a RunBeforeJob that returns a non-zero
   status on Thursday and zero on all other days.  That way, the Thursday
   job will not run, and on Friday the tape you inserted on Wednesday
   before leaving will be used.

\item [Run After Job = \lt{}command\gt{}]
   \index[dir]{Run After Job  }
   The specified {\bf command} is run as an external program after the
   current job terminates.  This directive is not required.  The command
   string must be a valid program name or name of a shell script.  If the
   exit code of the program run is non-zero, the current Bacula job will
   terminate in error.  Before submitting the specified command to the
   operating system, Bacula performs character substitution as described
   above for the {\bf Run Before Job} directive.
   
   An example of the use of this directive is given in the  
   \ilink{Tips Chapter}{JobNotification} of this manual.  As of version
   1.30, Bacula checks the exit status of the RunAfter  program. If it is
   non-zero, the job will be terminated in error.  

\item [Client Run Before Job = \lt{}command\gt{}]
   \index[dir]{Client Run Before Job  }
   This directive  is the same as {\bf Run Before Job} except that the program is  run on
   the client machine. The same restrictions apply to  Unix systems as noted
   above for the {\bf Run Before Job}. In  addition, for a Windows client on
   version 1.33 and above, please  take careful note that you must ensure a
   correct path to your  script. The script or program can be a .com, .exe or
   a .bat  file. However, if you specify a path, you must also specify  the full
   extension. Unix like commands will not work unless you  have installed and
   properly configured Cygwin in addition to  and separately from Bacula.  
   
   {\bf Special Windows Considerations}
   The command can be anything that cmd.exe or command.com will  recognize as an
   executable file. Specifying the executable's  extension is optional, unless
   there is an ambiguity. (i.e.  ls.bat, ls.exe)  
   
   The System \%Path\% will be searched for the command. (under  the environment
   variable dialog you have have both System  Environment and User Environment,
   we believe that only the  System environment will be available to bacula-fd,
   if it is  running as a service.)  
   
   System environment variables can be referenced with \%var\% and
   used as either part of the command name or  arguments.  
   
   When specifying a full path to an executable if the path or  executable name
   contains whitespace or special characters they  will need to be quoted.
   Arguments containing whitespace or  special characters will also have to be
   quoted. 

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

   The special characters \&()[]\{\}\^{}=;!'+,`\~{} will need to be quoted  if
   they are part of a filename or argument.  
   
   If someone is logged in, a blank "command" window running the  commands
will
   be present during the execution of the command.  
   
   Some Suggestions from Phil Stracchino for running on Win32 machines  with the
   native Win32 File daemon: 

   \begin{enumerate}
   \item You might want the ClientRunBeforeJob directive to specify a .bat file
      which  runs the actual client-side commands, rather than trying to run
(for 
      example) regedit /e directly.  
   \item The batch file should explicitly 'exit 0' on successful completion.  
   \item The path to the batch file should be specified in Unix form:  
   
      ClientRunBeforeJob = "c:/bacula/bin/systemstate.bat"  
   
   rather than DOS/Windows form:  
   
   ClientRunBeforeJob =
  
"c:\textbackslash{}bacula\textbackslash{}bin\textbackslash{}systemstate.bat"
   INCORRECT 
   \end{enumerate}
   
The following example of the use of the Client Run Before Job directive was 
submitted by a user:\\
You could write a shell script to back up a DB2 database to a FIFO. The shell
script is:

\footnotesize
\begin{verbatim}
 #!/bin/sh
 # ===== backupdb.sh
 DIR=/u01/mercuryd
 
 mkfifo $DIR/dbpipe
 db2 BACKUP DATABASE mercuryd TO $DIR/dbpipe WITHOUT PROMPTING &
 sleep 1
\end{verbatim}
\normalsize
 
The following line in the Job resource in the bacula-dir.conf file:
\footnotesize
\begin{verbatim}
 Client Run Before Job = "su - mercuryd -c \"/u01/mercuryd/backupdb.sh '%t'
'%l'\""
\end{verbatim}
\normalsize
 When the job is run, you will get messages from the output of the script
stating 
 that the backup has started. Even though the command being run is 
 backgrounded with \&, the job will block until the "db2 BACKUP DATABASE"
command,
 thus the backup stalls.
 
 To remedy this situation, the "db2 BACKUP DATABASE" line should be changed to
the following:
 
\footnotesize
\begin{verbatim} 
 db2 BACKUP DATABASE mercuryd TO $DIR/dbpipe WITHOUT PROMPTING > $DIR/backup.log
2>&1 < /dev/null &
\end{verbatim}
\normalsize

It is important to redirect the input and outputs of a backgrounded command to
/dev/null to prevent the script from blocking.


\item [Client Run After Job = \lt{}command\gt{}]
   \index[dir]{Client Run After Job  }
   This directive  is the same as {\bf Run After Job} except that it is  run on
the
   client machine. Note, please see the notes above  in {\bf Client Run Before
   Job} concerning Windows clients. 

\item [Rerun Failed Levels = \lt{}yes|no\gt{}]
   \index[dir]{Rerun Failed Levels  }
   If this directive  is set to {\bf yes} (default no), and Bacula detects that
a
   previous job at a higher level (i.e. Full or Differential)  has failed, the
   current job level will be upgraded to the  higher level. This is particularly
   useful for Laptops where  they may often be unreachable, and if a prior Full
   save has  failed, you wish the very next backup to be a Full save  rather
than
   whatever level it is started as. 

\item [Spool Data = \lt{}yes|no\gt{}]
   \index[dir]{Spool Data  }
   If this directive is set  to {\bf yes} (default no), the Storage daemon will
be requested  to spool the data for this Job to disk rather than write it 
directly to tape. Once all the data arrives or the spool files' maximum sizes
are reached, the data will be despooled and written  to tape. When this
directive is set to yes, the Spool Attributes  is also automatically set to
yes. Spooling data prevents tape  shoe-shine (start and stop) during
Incremental saves. This option  should not be used if you are writing to a
disk file. 

\item [Spool Attributes = \lt{}yes|no\gt{}]
   \index[dir]{Spool Attributes  }
   The default is set to  {\bf no}, which means that the File attributes are
sent
by the  Storage daemon to the Director as they are stored on tape. However, 
if you want to avoid the possibility that database updates will  slow down
writing to the tape, you may want to set the value to  {\bf yes}, in which
case the Storage daemon will buffer the  File attributes and Storage
coordinates to a temporary file  in the Working Directory, then when writing
the Job data to the tape is  completed, the attributes and storage coordinates
will be  sent to the Director. 

\item [Where = \lt{}directory\gt{}]
   \index[dir]{Where  }
   This directive applies only  to a Restore job and specifies a prefix to the
directory name  of all files being restored. This permits files to be restored
in a different location from which they were saved. If {\bf Where}  is not
specified or is set to backslash ({\bf /}), the files  will be restored to
their original location. By default, we  have set {\bf Where} in the example
configuration files to be  {\bf /tmp/bacula-restores}. This is to prevent
accidental overwriting  of your files. 

\item [Replace = \lt{}replace-option\gt{}]
   \index[dir]{Replace  }
   This directive applies only  to a Restore job and specifies what happens when
Bacula wants to  restore a file or directory that already exists. You have the
 following options for {\bf replace-option}:  

\begin{description}

\item [always]
   \index[dir]{always }
  when the file to be restored already exists,  it is deleted and then replaced
by
  the copy that was backed up.  

\item [ifnewer]
   \index[dir]{ifnewer }
  if the backed up file (on tape) is newer than the  existing file, the existing
  file is deleted and replaced by  the back up.  

\item [ifolder]
   \index[dir]{ifolder }
  if the backed up file (on tape) is older than the  existing file, the existing
  file is deleted and replaced by  the back up.  

\item [never]
   \index[dir]{never }
  if the backed up file already exists, Bacula skips  restoring this file.  
\end{description}

\item [Prefix Links=\lt{}yes|no\gt{}]
   \index[dir]{Prefix Links }
   If a {\bf Where} path prefix is specified for a recovery job, apply it
   to absolute links as well.  The default is {\bf No}.  When set to {\bf
   Yes} then while restoring files to an alternate directory, any absolute
   soft links will also be modified to point to the new alternate
   directory.  Normally this is what is desired -- i.e.  everything is self
   consistent.  However, if you wish to later move the files to their
   original locations, all files linked with absolute names will be broken.

\item [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 [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 [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 [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.

\item [Run = \lt{}job-name\gt{}]
   \index[dir]{Run directive}
   \index[dir]{Clone a Job}
   The Run directive (not to be confused with the Run option in a 
   Schedule) allows you to clone jobs and thus, if you want backup
   the same data (or almost the same data) to two or more drives
   at the same time. The {\bf job-name} is normally the same name
   as the current Job resource (thus creating a clone). However, it
   may be any Job name, so one job may start other related jobs.

   The part after the equal sign must be enclosed in double quotes,
   and can contain any string or set of options (overrides) that you
   can specify when entering the Run command from the console. For
   example {\bf storage=DDS-4 ...}.  In addition, there are two special
   keywords that permit you to clone the current job. They are {\bf level=\%l}
   and {\bf since=\%s}. The \%l in the level keyword permits 
   entering the actual level of the current job and the \%s in the since
   keyword permits putting the same time for comparison as used on the
   current job.  Note, in the case of the since keyword, the \%s must be
   enclosed in double quotes, and thus they must be preceded by a backslash
   since they are already inside quotes. For example:

\begin{verbatim}
   run = "Nightly-backup level=%s since=\"%s\" storage=DDS-4"
\end{verbatim}


   A cloned job will not start additional clones, so it is not
   possible to recurse.

   

\label{Priority}
\item [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 a 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 [Write Part After Job = \lt{}yes|no\gt{}]
   \index[dir]{Write Part After Job  }
   This directive is only implemented in version 1.37 and later.
   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

\subsection*{The JobDefs Resource}
\label{JobDefsResource}
\index[general]{JobDefs Resource }
\index[general]{Resource!JobDefs }
\addcontentsline{toc}{subsection}{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 to
be mentioned in each Job. 

\subsection*{The Schedule Resource}
\label{ScheduleResource}
\index[general]{Resource!Schedule }
\index[general]{Schedule Resource }
\addcontentsline{toc}{subsection}{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 can only
be run manually. In general, you specify an action to be taken and when. 

\begin{description}

\item [Schedule]
   \index[dir]{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[dir]{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[dir]{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[dir]{Level }
   is all files in the FileSet whether or not  they have changed.  

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

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

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

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

\item [FullPool=Full]
   \index[dir]{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[dir]{DifferentialPool }
   specifies to use the Pool  named {\bf Differential} if the job is a
differential  backup.  

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

\item [SpoolData=yes|no]
   \index[dir]{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[dir]{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}). Please note, this directive is implemented 
   only in version 1.37 and later.

\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 specifying 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 | saturday
<week-of-year-keyword> = w00 | w01 | ... w52 | w53
<month-keyword>   = jan | feb | mar | apr | may | jun | jul |
                    aug | sep | oct | nov | dec | january |
                    february | ... | december
<daily-keyword>   = daily
<weekly-keyword>  = weekly
<monthly-keyword> = monthly
<hourly-keyword>  = hourly
<digit>           = 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 0
<number>          = <digit> | <digit><number>
<12hour>          = 0 | 1 | 2 | ... 12
<hour>            = 0 | 1 | 2 | ... 23
<minute>          = 0 | 1 | 2 | ... 59
<day>             = 1 | 2 | ... 31
<time>            = <hour>:<minute> |
                    <12hour>:<minute>am |
                    <12hour>:<minute>pm
<time-spec>       = <at-keyword> <time> |
                    <hourly-keyword>
<date-keyword>    = <void-keyword>  <weekly-keyword>
<day-range>       = <day>-<day>
<month-range>     = <month-keyword>-<month-keyword>
<wday-range>      = <wday-keyword>-<wday-keyword>
<range>           = <day-range> | <month-range> |
                          <wday-range>
<date>            = <date-keyword> | <day> | <range>
<date-spec>       = <date> | <date-spec>
<day-spec>        = <day> | <wday-keyword> |
                    <day-range> | <wday-range> |
                    <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). 

\input{fileset}

\subsection*{The Client Resource}
\label{ClientResource2}
\index[general]{Resource!Client }
\index[general]{Client Resource }
\addcontentsline{toc}{subsection}{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[dir]{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[dir]{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[dir]{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[dir]{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[dir]{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  affect 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 a
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[dir]{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[dir]{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[dir]{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[dir]{*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

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

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

\begin{description}

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

\item [Name = \lt{}name\gt{}]
   \index[dir]{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[dir]{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[dir]{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[dir]{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[dir]{Device  }
   This directive specifies the name  of the device to be used 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 or if
the device is an Autochanger, you must put the name as defined on the {\bf Name}
directive contained in the {\bf Autochanger resource definition of the {\bf
Storage daemon}. 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[dir]{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 that 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[dir]{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[dir]{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

\subsection*{The Pool Resource}
\label{PoolResource}
\index[general]{Resource!Pool }
\index[general]{Pool Resource }
\addcontentsline{toc}{subsection}{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[dir]{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[dir]{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[dir]{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[dir]{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. Be careful about setting the 
   duration to short periods such as 23 hours, or you might experience problems
   of Bacula waiting for a tape over the weekend only to complete the backups
   Monday morning when an operator mounts a new tape.
   
   The use duration 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 
   \ilink{\bf update volume}{UpdateCommand} command in the Console.  

\item [Catalog Files = \lt{}yes|no\gt{}]
   \index[dir]{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[dir]{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[dir]{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 may prune (remove) Job  records that are older than the specified
   Volume Retention period if it is necessary to free up a Volume.
   Recycling will not occur until it is absolutely necessary to free up a
   volume. 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, and it is necessary to obtain a new volume, Bacula
   will prune both the Job and the File records.

   It is important to know that when the Volume Retention period expires, 
   Bacula does not automatically recycle a Volume. It attempts to keep the
   Volume data intact as long as possible before pruning it.
   
   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[dir]{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[dir]{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.  
However, if you use this directive and have only one
Volume in the Pool, you will immediately recycle your Volume if you fill
it and Bacula needs another one. Thus your backup will be totally invalid.
Please use this directive with care.

\label{RecycleCurrent}

\item [Recycle Current Volume = \lt{}yes|no\gt{}]
   \index[dir]{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.  
However, if you use this directive and have only one
Volume in the Pool, you will immediately recycle your Volume if you fill
it and Bacula needs another one. Thus your backup will be totally invalid.
Please use this directive with care.

\label{PurgeOldest}

\item [Purge Oldest Volume = \lt{}yes|no\gt{}]
   \index[dir]{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 reusing the oldest one 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).  

We {\bf highly} recommend against using this directive, because it is sure that
some day, Bacula will recycle a Volume that contains current data.

\item [Cleaning Prefix = \lt{}string\gt{}]
   \index[dir]{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[dir]{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.  Please note that this directive is
deprecated and is replaced in version 1.37 and greater with a Python script
for creating volume names.

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

\subsubsection*{The Scratch Pool}
\addcontentsline{toc}{subsection}{Scratch Pool}
\index[general]{Scratch Pool}
In general, you can give your Pools any name you wish, but there is one 
important restriction: the Pool named {\bf Scratch}, if it exists behaves 
like a scratch pool of Volumes in that when Bacula needs a new Volume for 
writing and it cannot find one, it will look in the Scratch pool, and if
it finds an available Volume, it will move it out of the Scratch pool into
the Pool currently being used by the job.


\subsection*{The Catalog Resource}
\label{CatalogResource}
\index[general]{Resource!Catalog }
\index[general]{Catalog Resource }
\addcontentsline{toc}{subsection}{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, 
PostgreSQL) 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[dir]{Catalog }
   Start of the Catalog resource.  At least one Catalog resource must be
defined.


\item [Name = \lt{}name\gt{}]
   \index[dir]{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[dir]{password  }
   This specifies the password  to use when logging into the database. This
directive is required.  

\item [DB Name = \lt{}name\gt{}]
   \index[dir]{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[dir]{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[dir]{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[dir]{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[dir]{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[dir]{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

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

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

\subsection*{The Console Resource}
\label{ConsoleResource1}
\index[general]{Console Resource }
\index[general]{Resource!Console }
\addcontentsline{toc}{subsection}{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 a 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  whatsoever. 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 permitted within the Director's configuration resource: 

\begin{description}

\item [Name = \lt{}name\gt{}]
   \index[dir]{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[dir]{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[dir]{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[dir]{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[dir]{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[dir]{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[dir]{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[dir]{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[dir]{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[dir]{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. 

\subsection*{The Counter Resource}
\label{CounterResource}
\index[general]{Resource!Counter }
\index[general]{Counter Resource }
\addcontentsline{toc}{subsection}{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[dir]{Counter }
   Start of the Counter resource.  Counter directives are optional. 

\item [Name = \lt{}name\gt{}]
   \index[dir]{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[dir]{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[dir]{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[dir]{*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[dir]{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}

\subsection*{Example Director Configuration File}
\label{SampleDirectorConfiguration}
\index[general]{File!Example Director Configuration }
\index[general]{Example Director Configuration File }
\addcontentsline{toc}{subsection}{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 for a DLT autochanger device
Storage {
  Name = Autochanger
  Address = rufus
  Password = "jMeWZvfikUHvt3kzKVVPpQ0ccmV6emPnF2cPYFdhLApQ"
  Device = "Autochanger"    # same as Device in Storage daemon
  Media Type = DLT-8000     # Different from DLTDrive
  Autochanger = yes
}
# Definition of DDS tape storage device
Storage {
  Name = SDT-10000
  Address = rufus
  Password = "jMeWZvfikUHvt3kzKVVPpQ0ccmV6emPnF2cPYFdhLApQ"
  Device = SDT-10000        # same as Device in Storage daemon
  Media Type = DDS-4        # same as MediaType in Storage daemon
}
# Definition of 8mm tape storage device
Storage {
  Name = "8mmDrive"
  Address = rufus
  Password = "jMeWZvfikUHvt3kzKVVPpQ0ccmV6emPnF2cPYFdhLApQ"
  Device = "Exabyte 8mm"
  MediaType = "8mm"
}
# Definition of file storage device
Storage {
  Name = File
  Address = rufus
  Password = "jMeWZvfikUHvt3kzKVVPpQ0ccmV6emPnF2cPYFdhLApQ"
  Device = FileStorage
  Media Type = File
}
# Generic catalog service
Catalog {
  Name = MyCatalog
  dbname = bacula; user = bacula; password = ""
}
# Reasonable message delivery -- send most everything to
#   the email address and to the console
Messages {
  Name = Standard
  mail = root@localhost = all, !skipped, !terminate
  operator = root@localhost = mount
  console = all, !skipped, !saved
}
    
# Default pool definition
Pool {
  Name = Default
  Pool Type = Backup
  AutoPrune = yes
  Recycle = yes
}
#
# Restricted console used by tray-monitor to get the status of the director
#
Console {
  Name = Monitor
  Password = "GN0uRo7PTUmlMbqrJ2Gr1p0fk0HQJTxwnFyE4WSST3MWZseR"
  CommandACL = status, .status
}
\end{verbatim}
\normalsize