]> 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 28aee4c5fd782b430dacb430136aaad92bfc8996..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))$$
@@ -931,7 +932,12 @@ chapter}{basejobs} for more information.
 \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}
@@ -1136,17 +1142,24 @@ 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
@@ -2334,7 +2347,7 @@ console run command.  This directive is required.
 
 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.
+k/s, Kb/s, m/s or Mb/s.
 
 \item [Priority = \lt{}number\gt{}]
    \index[dir]{Priority}