In some respects the Vbackup feature works similar to a Migration job, in
that Bacula normally reads the data from the pool specified in the
-Job resource, and writes it to the \bf{Next Pool} specified in the
+Job resource, and writes it to the {\bf Next Pool} specified in the
Job resource. The input Storage resource and the Output Storage resource
must be different.
The Vbackup is enabled on a Job by Job in the Job resource by specifying
-a level of \bf{VirtualFull}.
+a level of {\bf VirtualFull}.
A typical Job resource definition might look like the following:
So providing there were changes between each of those jobs, you would end up
with a Full backup, a Differential, which includes the first Incremental
backup, then two Incremental backups. All the above jobs would be written to
-the \bf{Default} pool.
+the {\bf Default} pool.
To consolidate those backups into a new Full backup, you would run the
following:
\end{verbatim}
And it would produce a new Full backup without using the client, and the output
-would be written to the \bf{Full} Pool which uses the Diskchanger Storage.
+would be written to the {\bf Full} Pool which uses the Diskchanger Storage.
+
+\section{TLS Authentication}
+\index[general]{TLS Authentication}
+In Bacula version 2.5.x and later, in addition to the normal Bacula
+CRAM-MD5 authentication that is used to authenticate each Bacula
+connection, you can specify that you want TLS Authentication as well,
+which will provide more secure authentication.
+
+This new feature uses Bacula's existing TLS code (normally used for
+communications encryption) to do authentication. To use it, you must
+specify all the TLS directives normally used to enable communications
+encryption (TLS Enable, TLS Verify Peer, TLS Certificate, ...) and
+a new directive:
+
+\begin{verbatim}
+TLS Authenticate = yes
+\end{verbatim}
+
+in the main daemon configuration resource (Director for the Director,
+Client for the File daemon, and Storage for the Storage daemon).
+
+When {\bf TLS Authenticate} is enabled, after doing the CRAM-MD5
+authentication, Bacula will do the normal TLS authentication, then TLS
+encryption will be turned off.
+
+If you want to encrypt communications data, do not turn on {\bf TLS
+Authenticate}.
+
+\section{bextract non-portable Win32 data}
+\index[general]{bextract handles Win32 non-portable data}
+{\bf bextract} has been enhanced to be able to restore
+non-portable Win32 data to any OS. Previous versions were
+unable to restore non-portable Win32 data to machines that
+did not have the Win32 BackupRead and BackupWrite API calls.
+
+\section{State File updated at Job Termination}
+\index[general]{State File}
+In previous versions of Bacula, the state file, which provides a
+summary of previous jobs run in the {\bf status} command output was
+updated only when Bacula terminated, thus if the daemon crashed, the
+state file might not contain all the run data. This version of
+the Bacula daemons updates the state file on each job termination.
+
+\section{Duplicate Job Control}
+\index[general]{Duplicate Jobs}
+The new version of Bacula provides four new directives that
+give additional control over what Bacula does if duplicate jobs
+are started. A duplicate job in the sense we use it here means
+a second or subsequent job with the same name starts. This
+happens most frequently when the first job runs longer than expected because no
+tapes are available.
+
+The four directives each take as an argument a yes or no value and
+are specified in the Job resource.
+
+They are:
+
+\begin{description}
+\item Allow Duplicate Jobs \\
+ If this directive is enabled duplicate jobs will be run. If
+ the directive is set to {\bf no} (default) then only one job of a given name
+ may run at one time, and the action that Bacula takes to ensure only
+ one job runs is determined by the other directives (see below).
+
+\item Allow Higher Duplicates \\
+ If this directive is set to {\bf yes} (default) the job with a higher
+ priority (lower priority number) will be permitted to run. If the
+ priorities of the two jobs are the same, the outcome is determined by
+ other directives (see below).
+
+\item Cancel Queued Duplicates \\
+ If this directive is set to {\bf yes} (default) any job that is
+ already queued to run but not yet running will be canceled.
+
+\item Cancel Running Duplicates \\
+ If this directive is set to {\bf yes} any job that is already running
+ will be canceled. The default is {\bf no}.
+\end{description}
+
+
+
+
+
+
\section{Accurate Backup}
\index[general]{Accurate Backup}
If you see a {\bf *} near the slot number, you have to run {\bf update slots}
command to synchronize autochanger content with your catalog.
-
projects / bacula / docs / commitdiff