could run concurrently. The default is set to 20, but you may set it to a
larger number.
+ \item[SharedStorage = \lt{}yes\vb{}no\gt{}]
+ \index[dir]{SharedStorage}
+ \index[dir]{Directive!SharedStorage}
+
+ The \texttt{Shared Storage} directive is a Bacula Enterprise feature that
+ allows you to share volumes between different Storage resources. This
+ directive should be used \textbf{only} if all \texttt{Media Type} are
+ correctly set across all Devices.
+
+ The \texttt{Shared Storage} directive should be used when using the SAN
+ Shared Storage plugin or when accessing from the Director Storage resources
+ directly to Devices of an Autochanger.
+
+ When sharing volumes between different Storage resources, you will
+ need also to use the \texttt{reset-storageid} script before using the
+ \texttt{update slots} command. This script can be scheduled once a day in
+ an Admin job.
+
+\begin{verbatim}
+ $ /opt/bacula/scripts/reset-storageid MediaType StorageName
+ $ bconsole
+ * update slots storage=StorageName drive=0
+\end{verbatim}
+
+ Please contact Bacula Systems support to get help on this advanced
+ configuration.
+
\end{description}
The following is an example of a valid Director resource definition:
\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
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.
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))$$
\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). By default, the Director will let a job running during
- 6 days.
+ 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}
\item [Prune Jobs = \lt{}yes\vb{}no\gt{}]
\index[dir]{Prune Jobs}
\index[dir]{Directive!Prune Jobs}
- Normally, pruning of Jobs from the Catalog is specified on a Pool by
- Pool basis in the Pool resource with the {\bf AutoPrune} directive.
+ 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 Pool resource. The
+ yes}, it will override the value specified in the Client resource. The
default is {\bf no}.
\item [Prune Files = \lt{}yes\vb{}no\gt{}]
\index[dir]{Prune Files}
\index[dir]{Directive!Prune Files}
- Normally, pruning of Files from the Catalog is specified on a Pool by
- Pool basis in the Pool resource with the {\bf AutoPrune} directive.
+ 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 Pool resource. The
+ yes}, it will override the value specified in the Client resource. The
default is {\bf no}.
\item [Prune Volumes = \lt{}yes\vb{}no\gt{}]
\index[dir]{Prune Volumes}
\index[dir]{Directive!Prune Volumes}
- Normally, pruning of Volumes from the Catalog is specified on a Pool
- by Pool basis in the Pool 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 Pool
- resource. The default is {\bf no}.
+ Normally, pruning of Volumes from the Catalog is specified on a Pool by
+ Pool basis in the Pool resource with the {\bf AutoPrune} directive.
+ Note, this is different from File and Job pruning which is done on a
+ Client by Client basis. If this directive is specified (not normally)
+ and the value is {\bf yes}, it will override the value specified in the
+ Pool resource. The default is {\bf no}.
\item [RunScript \{\lt{}body-of-runscript\gt{}\}]
\index[dir]{RunScript}
\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
You can run scripts just after snapshots initializations with
\textsl{AfterVSS} keyword.
- In addition, for a Windows client on version 1.33 and above, please take
+ In addition, for a Windows client, please take
note that you must ensure a correct path to your script. The script or
program can be a .com, .exe or a .bat file. If you just put the program
name in then Bacula will search using the same rules that cmd.exe uses
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. Spooling data
- prevents tape shoe-shine (start and stop) during
- Incremental saves. If you are writing to a disk file using this option
- will probably just slow down the backup jobs.
+ directly to the Volume (normally a tape).
+
+ Thus the data is written in large blocks to the Volume rather than small
+ blocks. This directive is particularly useful when running multiple
+ simultaneous backups to tape. Once all the data arrives or the spool
+ files' maximum sizes are reached, the data will be despooled and written
+ to tape.
+
+ Spooling data prevents interleaving date from several job and reduces or
+ eliminates tape drive stop and start commonly known as "shoe-shine".
+
+ We don't recommend using this option if you are writing to a disk file
+ using this option will probably just slow down the backup jobs.
NOTE: When this directive is set to yes, Spool Attributes is also
automatically set to yes.
+\item [SpoolData=yes\vb{}no]
+ \index[dir]{SpoolData}
+ \index[dir]{Directive!SpoolData}
+ tells Bacula to request the Storage daemon to spool data to a disk file
+ before writing it to the Volume (normally a tape).
+
\item [Spool Attributes = \lt{}yes\vb{}no\gt{}]
\index[dir]{Spool Attributes}
\index[dir]{Directive!Spool Attributes}
NOTE: When Spool Data is set to yes, Spool Attributes is also
automatically set to yes.
+\item [SpoolSize={\it bytes}]
+ \index[dir]{SpoolSize}
+ \index[dir]{Directive!SpoolSize}
+ where the bytes specify the maximum spool size for this job.
+ The default is take from Device Maximum Spool Size limit.
+ This directive is available only in Bacula version 2.3.5 or
+ later.
+
+
\item [Where = \lt{}directory\gt{}]
\index[dir]{Where}
\index[dir]{Directive!Where}
specifies to use the Pool named {\bf Incremental} if the job is an
incremental backup.
-\item [SpoolData=yes\vb{}no]
- \index[dir]{SpoolData}
- \index[dir]{Directive!SpoolData}
- tells Bacula to request the Storage daemon to spool data to a disk file
- before writing it to the Volume (normally a tape). Thus the data is
- written in large blocks to the Volume rather than small blocks. This
- directive is particularly useful when running multiple simultaneous
- backups to tape. It prevents interleaving of the job data and reduces
- or eliminates tape drive stop and start commonly known as "shoe-shine".
-
-\item [SpoolSize={\it bytes}]
- \index[dir]{SpoolSize}
- \index[dir]{Directive!SpoolSize}
- where the bytes specify the maximum spool size for this job.
- The default is take from Device Maximum Spool Size limit.
- This directive is available only in Bacula version 2.3.5 or
- later.
\item [WritePartAfterJob=yes\vb{}no]
\index[dir]{WritePartAfterJob}
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}
projects / bacula / docs / blobdiff