will include the Community features described in the Community new Features
chapter.
+\section{Bacula Enterprise 6.4.0}
+\subsection{Deduplication Optimized Volumes}
+This version of Bacula includes a new alternative (or additional)
+Volume format that optimized the placement of files such
+that an underlying deduplicating filesystem such as ZFS
+can optimally deduplicate the backup data that is written
+by Bacula. These are called Deduplication Optimized Volumes
+or Aligned Volumes for short. The details of how to use this
+feature and its considerations are in the Bacula Systems
+Deduplication Optimized Volumes white paper.
+
+\subsection{Migration/Copy/VirtualFull Performance Enhancements}
+The Bacula Storage daemon now permits multiple jobs to simultaneously read
+the same disk Volume, which gives substantial performance enhancements when
+running Migration, Copy, or VirtualFull jobs that read disk Volumes. Our
+testing shows that when running multiple simultaneous jobs, the jobs can
+finish up to ten times faster with this version of Bacula. This is
+built-in to the Storage daemon, so it happens automatically and
+transparently.
+
+\subsection{VirtualFull Backup Consolidation Enhancements}
+By default Bacula selects jobs automatically for a VirtualFull,
+however, you may want to create the Virtual backup based on a
+particular backup (point in time) that exists.
+
+For example, if you have the following backup Jobs in your catalog:
+\begin{lstlisting}
++-------+---------+-------+----------+----------+-----------+
+| JobId | Name | Level | JobFiles | JobBytes | JobStatus |
++-------+---------+-------+----------+----------+-----------+
+| 1 | Vbackup | F | 1754 | 50118554 | T |
+| 2 | Vbackup | I | 1 | 4 | T |
+| 3 | Vbackup | I | 1 | 4 | T |
+| 4 | Vbackup | D | 2 | 8 | T |
+| 5 | Vbackup | I | 1 | 6 | T |
+| 6 | Vbackup | I | 10 | 60 | T |
+| 7 | Vbackup | I | 11 | 65 | T |
+| 8 | Save | F | 1758 | 50118564 | T |
++-------+---------+-------+----------+----------+-----------+
+\end{lstlisting}
+
+For example, if you want to consolidate only the first 3 jobs and create a
+virtual backup equivalent to Job 1 + Job 2 + Job 3, you will use
+\texttt{jobid=3} in the \texttt{run} command, then Bacula will select the
+previous Full backup, the previous Differential (if any) and all subsequent
+Incremental jobs.
+
+\begin{lstlisting}
+run job=Vbackup jobid=3 level=VirtualFull
+\end{lstlisting}
+
+If you want to consolidate a specific job list, you must specify the exact
+list of jobs to merge in the run command line. For example, to consolidate
+the last Differential and all subsequent Incremental, you will use
+\texttt{jobid=4,5,6,7} or \texttt{jobid=4-7} on the run command line. As one
+of the Job in the list is a Differential backup, Bacula will set the new job
+level to Differential. If the list is composed only with Incremental jobs,
+the new job will have a level set to Incremental.
+
+\begin{lstlisting}
+run job=Vbackup jobid=4-7 level=VirtualFull
+\end{lstlisting}
+
+When using this feature, Bacula will automatically discard jobs that are
+not related to the current Job. For example, specifying
+\texttt{jobid=7,8}, Bacula will discard JobId 8 because it is not
+part of the same backup Job.
+
+We do not recommend it, but really want to consolidate jobs that have
+different names (so probably different clients, filesets, etc...), you must
+use \texttt{alljobid=} keyword instead of \texttt{jobid=}.
+
+\begin{lstlisting}
+run job=Vbackup alljobid=1-3,6-8 level=VirtualFull
+\end{lstlisting}
+
+\subsection{New Prune ``Expired'' Volume Command}
+In Bacula Enterprise 6.4, it is now possible to prune all volumes
+(from a pool, or globally) that are ``expired''. This option can be
+scheduled after or before the backup of the Catalog and can be
+combined with the Truncate On Purge option. The Expired Prune option can
+be used instead of the \texttt{manual\_prune.pl} script.
+
+\begin{lstlisting}
+* prune expired volumes
+
+* prune expired volumes pool=FullPool
+\end{lstlisting}
+
+To schedule this option automatically, it can be added to the BackupCatalog job
+definition.
+
+\begin{lstlisting}
+ Job {
+ Name = CatalogBackup
+ ...
+ RunScript {
+ Console = ``prune expired volume yes''
+ RunsWhen = Before
+ }
+ }
+\end{lstlisting}
+
+\section{Bacula Enterprise 6.2.3}
+
+\subsection{New Job Edit Code \%P \%C}
+In various places such as RunScript, you have now access to \%P to get the
+current Bacula process ID (PID) and \%C to know if the current job is a
+cloned job.
+
\section{Bacula Enterprise 6.2.0}
\subsection{BWeb Bacula Configuration GUI}
-
In Bacula Enterprise version 6.2, the BWeb Management Suite integrates a
Bacula configuration GUI module which is designed to help you create and
modify the Bacula configuration files such as bacula-dir.conf,
The new Online help mode displays automatic help text suggestions when the
user searches data types.
-\bsysimageH{bweb_bconfig_screen}{Configuration with BWeb Management Suite}{fig:BwebBconfigScreen}
+\bsysimageH{bweb_config_screen}{Configuration with BWeb Management Suite}{fig:BwebBconfigScreen}
\smallskip
This project was funded by Bacula Systems and is available with the Bacula
StorageDaemon.
The normal way to handle this situation is to use a canonical name such as
-``storage-server'' that will be resolved on the Director side as the WAN address
-and on the Client side as the LAN address. This is now possible to configure
-this parameter using the new \texttt{FDStorageAddress} Storage
-% or Client
-directive.
+``storage-server'' that will be resolved on the Director side as the WAN
+address and on the Client side as the LAN address. This is now possible to
+configure this parameter using the new directive \texttt{FDStorageAddress} in
+the Storage or Client resource.
+
\bsysimageH{BackupOverWan1}{Backup Over WAN}{figbs6:fdstorageaddress}
% \label{fig:fdstorageaddress}
Name = storage1
Address = 65.1.1.1
FD Storage Address = 10.0.0.1
- SD Port 9103
+ SD Port = 9103
...
}
\end{lstlisting}
% # or in the Client resouce
%
-% Client {
-% Name = client1
-% Address = 65.1.1.2
-% FD Storage Address = 10.0.0.1
-% FD Port 9103
-% ...
-% }
-% \end{lstlisting}
-%
-% Note that using the Client \texttt{FDStorageAddress} directive will not allow
-% to use multiple Storage Daemon, all Backup or Restore requests will be sent to
-% the specified \texttt{FDStorageAddress}.
+
+\begin{lstlisting}
+ Client {
+ Name = client1
+ Address = 65.1.1.2
+ FD Storage Address = 10.0.0.1
+ FD Port = 9102
+ ...
+ }
+\end{lstlisting}
+
+Note that using the Client \texttt{FDStorageAddress} directive will not allow
+to use multiple Storage Daemon, all Backup or Restore requests will be sent to
+the specified \texttt{FDStorageAddress}.
\subsection{Maximum Concurrent Read Jobs}
This is a new directive that can be used in the {\bf bacula-dir.conf} file
complex scripts. The Bacula Enterprise Oracle plugin supports both dump and
Point In Time Recovery (PITR) with RMAN backup techniques.
+
+\section{Bacula Enterprise 6.0.2}
+
+To make Bacula function properly with multiple Autochanger definitions, in
+the Director's configuration, you must adapt your {\bf bacula-dir.conf}
+{\bf Storage} directives.
+
+\smallskip
+Each autochanger that you have defined in an {\bf Autochanger}
+resource in the Storage daemon's {\bf bacula-sd.conf} file,
+must have a corresponding {\bf Autochanger} resource defined
+in the Director's {\bf bacula-dir.conf} file. Normally you will
+already have a {\bf Storage} resource that points to the
+Storage daemon's {\bf Autochanger} resource. Thus you need
+only to change the name of the {\bf Storage} resource to
+{\bf Autochanger}. In addition the {\bf Autochanger = yes}
+directive is not needed in the Director's {\bf Autochanger}
+resource, since the resource name is {\bf Autochanger}, the
+Director already knows that it represents an autochanger.
+
+\smallskip
+In addition to the above change ({\bf Storage} to {\bf Autochanger}),
+you must modify any additional {\bf Storage} resources that correspond
+to devices that are part of the {\bf Autochanger} device.
+Instead of the previous {\bf Autochanger = yes} directive they
+should be modified to be {\bf Autochanger = xxx} where you
+replace the {\bf xxx} with the name of the Autochanger.
+
+\smallskip
+For example, in the bacula-dir.conf file:
+
+\begin{verbatim}
+Autochanger { # New resource
+ Name = Changer-1
+ Address = cibou.company.com
+ SDPort = 9103
+ Password = "xxxxxxxxxx"
+ Device = LTO-Changer-1
+ Media Type = LTO-4
+ Maximum Concurrent Jobs = 50
+}
+
+Storage {
+ Name = Changer-1-Drive0
+ Address = cibou.company.com
+ SDPort = 9103
+ Password = "xxxxxxxxxx"
+ Device = LTO4_1_Drive0
+ Media Type = LTO-4
+ Maximum Concurrent Jobs = 5
+ Autochanger = Changer-1 # New directive
+}
+
+Storage {
+ Name = Changer-1-Drive1
+ Address = cibou.company.com
+ SDPort = 9103
+ Password = "xxxxxxxxxx"
+ Device = LTO4_1_Drive1
+ Media Type = LTO-4
+ Maximum Concurrent Jobs = 5
+ Autochanger = Changer-1 # New directive
+}
+
+...
+\end{verbatim}
+
+Note that Storage resources {\bf Changer-1-Drive0} and
+{\bf Changer-1-Drive1} are not required since they make
+up part of an autochanger, and normally, Jobs refer only
+to the Autochanger resource.
+However, by referring to those
+Storage definitions in a Job, you will use only
+the indicated drive. This is not normally what
+you want to do, but it is very useful and often used
+for reserving a drive for restores. See the Storage daemon
+example .conf below and the use of {\bf AutoSelect = no}.
+
+So, in summary, the changes are:
+\begin{itemize}
+\item Change {\bf Storage} to {\bf Autochanger} in the LTO4 resource.
+\item Remove the {\bf Autochanger = yes} from the {\bf Autochanger}
+LTO4 resource.
+\item Change the {\bf Autochanger = yes} in each of the {\bf Storage}
+device that belong to the {\bf Autochanger} to point to the
+{\bf Autochanger} resource with for the example above the
+directive {\bf Autochanger = LTO4}.
+\end{itemize}
+
\section{Bacula Enterprise 6.0.0}
\subsection{Incomplete Jobs}
projects / bacula / docs / blobdiff