]> git.sur5r.net Git - bacula/docs/blobdiff - docs/manuals/en/main/dirdconf.tex
Document new %D
[bacula/docs] / docs / manuals / en / main / dirdconf.tex
index 652e1748f23fc3344761cb2ea89173064881688c..32f4558b5e2f2151afb81781d663a80489ec0a39 100644 (file)
@@ -678,9 +678,10 @@ For a {\bf Verify} Job, the Level may be one of the  following:
 \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
+   Volume from the last backup Job for the job specified on the {\bf VerifyJob}
+   directive.  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
+   This is similar to the {\bf DiskToCatalog} 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
@@ -697,7 +698,7 @@ For a {\bf Verify} Job, the Level may be one of the  following:
    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}
+   {\bf VerifyJob} directive.  This level differs from the {\bf VolumeToCatalog}
    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.
@@ -723,7 +724,7 @@ For a {\bf Verify} Job, the Level may be one of the  following:
    and renamed directories are restored properly.
 
    In this mode, the File daemon must keep data concerning all files in
-   memory.  So you do not have sufficient memory, the restore may
+   memory.  So If you do not have sufficient memory, the backup may
    either be terribly slow or fail.
 
 %%   $$ memory = \sum_{i=1}^{n}(strlen(path_i + file_i) + sizeof(CurFile))$$
@@ -830,7 +831,7 @@ JobDefs {
 
 \item [FileSet = \lt{}FileSet-resource-name\gt{}]
 \index[dir]{FileSet}
-\index[dir]{FileSet}
+\index[dir]{Directive!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
@@ -838,6 +839,13 @@ JobDefs {
    details, see the \ilink{FileSet Resource section}{FileSetResource} of
    this chapter.  This directive is required.
 
+\item [Base = \lt{}job-resource-name, ...\gt{}]
+\index[dir]{Base}
+\index[dir]{Directive!Base}
+The Base directive permits to specify the list of jobs that will be used during
+Full backup as base. This directive is optional. See the \ilink{Base Job
+chapter}{basejobs} for more information.
+
 \item [Messages = \lt{}messages-resource-name\gt{}]
 \index[dir]{Messages}
 \index[dir]{Directive!Messages}
@@ -924,7 +932,12 @@ JobDefs {
 \index[dir]{Directive!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).
+   job was scheduled). 
+
+   By default, the the watchdog thread will kill any Job that has run more
+   than 6 days.  The maximum watchdog timeout is independent of MaxRunTime
+   and cannot be changed.
+
 
 \item [Incremental|Differential Max Wait Time = \lt{}time\gt{}]
 \index[dir]{Incremental Wait Run Time}
@@ -972,6 +985,12 @@ during working hours. We can see it like \texttt{Max Start Delay + Max Run
   \label{fig:differenttime}
 \end{figure}
 
+\item [Maximum Bandwidth = \lt{}speed\gt{}]
+\index[dir]{Maximum Bandwidth}
+\index[dir]{Directive!Maximum Bandwidth}
+
+The speed parameter specifies the maximum allowed bandwidth that a job may
+use. The speed parameter should be specified in k/s, kb/s, m/s or mb/s.
 
 \item [Max Full Interval = \lt{}time\gt{}]
 \index[dir]{Max Full Interval}
@@ -1123,21 +1142,30 @@ Console          &       &          & Console command\\
 \footnotesize
 \begin{verbatim}
     %% = %
+    %b = Job Bytes
     %c = Client's name
-    %d = Director's name
+    %d = Daemon's name (Such as host-dir or host-fd)
+    %D = Director's name (Also valid on file daemon)
     %e = Job Exit Status
+    %f = Job FileSet (Only on director side)
+    %F = Job Files
+    %h = Client address
     %i = JobId
     %j = Unique Job id
     %l = Job Level
     %n = Job name
+    %p = Pool name (Only on director side)
     %s = Since time
     %t = Job type (Backup, ...)
     %v = Volume name (Only on director side)
+    %w = Storage name (Only on director side)
+    %x = Spooling enabled? ("yes" or "no")
  
 \end{verbatim}
 \normalsize
 
-The Job Exit Status code \%e edits the following values:
+Some character substitutions are not available in all situations. The Job Exit
+Status code \%e edits the following values:
 
 \index[dir]{Exit Status}
 \begin{itemize}
@@ -2313,6 +2341,14 @@ console run command.  This directive is required.
    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.
 
+\item [Maximum Bandwidth Per Job = \lt{}speed\gt{}]
+\index[dir]{Maximum Bandwidth Per Job}
+\index[dir]{Directive!Maximum Bandwidth Per Job}
+
+The speed parameter specifies the maximum allowed bandwidth that a job may use
+when started for this Client. The speed parameter should be specified in
+k/s, Kb/s, m/s or Mb/s.
+
 \item [Priority = \lt{}number\gt{}]
    \index[dir]{Priority}
    \index[dir]{Directive!Priority}