[bacula/docs] / docs / manuals / en / main / newbsfeatures.tex

\chapter{New Features in Bacula Enterprise}
This chapter presents the new features that have been added to the
current Enterprise version of Bacula.
These features are available only with a Bacula Systems subscription.

In addition to the features in this chapter, the Enterprise version
includes all the Community features described in the Community new Features
chapter.

\section{Bacula Enterprise 6.7.0}

\subsection{Data Encryption Cipher Configuration}
Bacula Enterprise version 6.7.0 and later now allows to configure the data
encryption cipher and the digest algorithm. The cipher was forced to AES 128,
and it is now possible to choose between the following ciphers:

\begin{itemize}
\item AES128 (default)
\item AES192
\item AES256
\item blowfish
\end{itemize}

The digest algorithm was set to SHA1 or SHA256 depending on the local OpenSSL
options. We advise you to not modify the PkiDigest default setting. Please,
refer to OpenSSL documentation to know about pro and cons on these options.

\begin{lstlisting}
  FileDaemon {
    ...
    PkiCipher = AES256
  }
\end{lstlisting}

\subsection{Minor Enhancements}

\subsubsection*{.api version 2}

In Bacula Enterprise version 6.7.0 and later, we introduced a new .api version
to help external tools to parse various Bacula outputs.

The \texttt{api\_opts} option can use the following arguments:
\begin{itemize}
\item [C] Clear current options
\item [tn] Use a specific time format (1 ISO format, 2 Unix Timestamp, 3 default Bacula time format)
\item [sn] Use a specific separator between items (new line by default).
\item [Sn] Use a specific separator between objects (new line by default).
\item [o] Convert all keywords to lowercase and convert all non \textsl{isalpha} characters to \_
\end{itemize}

\begin{lstlisting}
  .api 2 api_opts=t1s43S35
  .status dir running
==================================
jobid=10
job=AJob
...
\end{lstlisting}

\section{Bacula Enterprise 6.6.0}
\subsection{Comm Line Compression}
Bacula Enterprise version 6.6.0 and later now includes communication
line compression. It is turned on by default, and if the
two Bacula components (Dir, FD, SD, bconsole) are both 
version 6.6.0 or greater, comm line compression
will be enabled, by default. If for some reason, you do not want
comm line compression, you may disable it with the
following directive:

\begin{lstlisting}
Comm Compression = no
\end{lstlisting}

This directive can appear in the following resources:
\begin{lstlisting}
bacula-dir.conf: Director resource
bacula-fd.conf Client (or FileDaemon) resource
bacula-sd.conf: Storage resource
bconsole.conf: Console resource
bat.conf: Console resource
\end{lstlisting}

\smallskip
In many cases, the volume of data transmitted across the
communications line can be reduced by a factor of three when 
this directive is enabled (default).

\subsection{Read Only Storage Devices}
This version of Bacula permits tdefining a Storage deamon device
to be read-only. That is if the {\bf ReadOnly} directive is specified and
enabled, the drive can only be used for read operations.
The the {\bf ReadOnly} directive can be defined in any bacula-sd.conf
Device resource, and is most useful to reserve one or more 
drives for restores. An example is:

\begin{lstlisting}
Read Only = yes
\end{lstlisting}

\subsection{Catalog Performance Improvements}
There is a new Bacula database format (schema) in this version
of Bacula that eliminates the FileName table by placing the
Filename into the File record of the File table. 
This permits some substantial performance improvements
particularly for large (1GB or greater) databases.

The update\_xxx\_catalog script will automatically update the
Bacula database format, but you should realize that for 
very large databases (greater than 1GB), it may take some
time, and there are several different options for doing the
update: 1. Shudown the database and update it. 2. Update the
database while production jobs are running.  See the Bacula Systems
White Paper ``Migration-to-6.6'' on this subject.

\smallskip
This database format change can provide very significant improvements in
the speed of metadata insertion into the database, and in some cases
(backup of large email servers) can significantly reduce the size of the
database.

\subsection{Plugin Restore Options}
This version of Bacula permits user configuration of Plugins at restore
time.  For example, it is now possible to choose the \texttt{datastore}
where your VMware image will be restored, or for example to choose
\texttt{pg\_restore} options directly.  See specific Plugin whitepaper
for more information about new restore options.

The restore options, if implemented in a plugin, will be 
presented to you during initiation of a restore either by
command line or if available by a GUI such
as BWeb.  For examples of the command line interface and
the GUI interface, please see below:

\begin{lstlisting}
Run Restore job
JobName:         RestoreFiles
Bootstrap:       /tmp/regress/working/my-dir.restore.1.bsr
Where:           /tmp/regress/tmp/bacula-restores
...
Plugin Options:  *None*
OK to run? (yes/mod/no): mod
Parameters to modify:
     1: Level
...
    13: Plugin Options
Select parameter to modify (1-13): 13
Automatically selected : vsphere: host=squeeze2
Plugin Restore Options
datastore:           *None*               
restore_host:        *None*               
new_hostname:        *None*               
Use above plugin configuration? (yes/mod/no): mod
You have the following choices:
     1: datastore (Datastore to use for restore) 
     2: restore_host (ESX host to use for restore) 
     3: new_hostname (Restore host to specified name) 
Select parameter to modify (1-3): 3
Please enter a value for new_hostname: test
Plugin Restore Options
datastore:           *None*               
restore_host:        *None*               
new_hostname:        test                 
Use above plugin configuration? (yes/mod/no): yes

\end{lstlisting}

Or via the BWeb restore interface (see Fig \vref{fig:bms-restore})

\bsysimageH{vsphere-restore-gui}{Choose datastore, ESXi or hostname at restore time}{fig:bms-restore}

\subsection{Alldrives Plugin Improvements}
The \texttt{alldrives} plugin permits to simplify the FileSet creation of
Windows Clients, the plugin will generate automatically a FileSet including all
local drives.

\smallskip{}

The \texttt{alldrives} plugin now accepts the \texttt{snapshot} option that
permits generating snapshots for all local Windows drives but without
explicitly adding them to the FileSet.  It can be combined with the
\texttt{vss} plugin. For example:

\begin{lstlisting}
FileSet {
 ...
  Include {
    Plugin = "alldrives: snapshot"
    Plugin = "vss:/@MSSQL/"
  }
}
\end{lstlisting}

\subsection{New Truncate Command}
We have added a new truncate command to bconsole, which
will truncate a Volume if the Volume is purged and if
the Volume is also marked {\bf Action On Purge = Truncate}.
This feature was originally added in Bacula version 5.0.1,
but the mechanism for actually doing the truncate required
the user to enter a command such as:

\begin{lstlisting}
purge volume action=truncate storage=File pool=Default
\end{lstlisting}

The above command is now simplified to be:

\begin{lstlisting}
truncate storage=File pool=Default
\end{lstlisting}

\subsection{New Resume Command}
This command does exactly the same thing as a 
{\bf restart} command but for some users the
name may be more logical since in general the 
{\bf restart} command is used to resume running
a Job that was incompleted.

\section{Bacula Enterprise 6.4.x}

The following features were added during the 6.4.x life cycle.

\subsection{SAP Plugin}

The Bacula Enterprise SAP Plugin is designed to implement the official SAP
Backint interface to simplify the backup and restore procedure through your
traditional SAP database tools. See SAP-Backint whitepaper for more
information.

\subsection{Oracle SBT Plugin}

By default, the Oracle backup Manager, RMAN, sends all backups to an operating
system specific directory on disk. You can also configure RMAN to make backups
to media such as tape using SBT module. Bacula will act as Media Manager, and
the data will be transfered directly from RMAN to Bacula. See Oracle Plugin
whitepaper for more information.

\subsection{MySQL Plugin}

The MySQL plugin is designed to simplify the backup and restore of your MySQL
server, the backup administrator doesn't need to know about internals of MySQL
backup techniques or how to write complex scripts.  The plugin will
automatically backup essential information such as configuration or user
definitions.  The MySQL plugin supports both dump (with support for Incremental
backup) and binary backup techniques.  See MySQL Plugin whitepaper for more
information.

\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}

and 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 Codes \%P \%C}
In various places such as RunScripts, 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,
bacula-sd.conf, bacula-fd.conf and bconsole.conf.

The BWeb Management Suite offers a number of Wizards which support the
Administrator in his daily work. The wizards provide a step by step set of
required actions that graphically guide the Administrator to perform quick
and easy creation and modification of configuration files.

BWeb also provides diagnostic tools that enable the Administrator to check
that the Catalog Database is well configured, and that BWeb is installed
properly.

The new Online help mode displays automatic help text suggestions when the
user searches data types.

\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
Enterprise Edition.

\subsection{Performance Improvements}
Bacula Enterprise 6.2 has a number of new performance improvements:

\begin{itemize}
\item An improved way of storing Bacula Resources (as defined in
the .conf files). This new handling permits much faster loading or
reloading of the conf files, and permits larger numbers of resources.

\item Improved performance when inserting large numbers of files in
the DB catalog by breaking the insertion into smaller chunks, thus
allowing better sharing when running multiple simultaneous jobs.

\item Performance enhancements in BVFS concerning eliminating 
duplicate path records.

\item Performance improvement when getting Pool records.

\item Pruning performance enhancements.
\end{itemize}

\subsection{Enhanced Status and Error Messages}
We have enhanced the Storage daemon status output to be more
readable. This is important when there are a large number of
devices. In addition to formatting changes, it also includes more
details on which devices are reading and writing.

A number of error messages have been enhanced to have more specific
data on what went wrong.

If a file changes size while being backed up the old and new size
are reported.

\subsection{WinBMR 3}
The Windows Bare Metal Recovery (BMR) plugin enables you to do safe, reliable
Disaster Recovery with Bacula Enterprise Edition on Windows and allows you to
get critical systems up and running again quickly.  The Enterprise Edition
Windows BMR is a toolkit that allows the Administrator to perform the restore
of a complete operating system to the same or similar hardware without actually
going through the operating system's installation procedure.

\smallskip{}

The WinBMR 3 version is a major rewrite of the product that support all x86
Windows versions and technologies. Especially UEFI and secure boot systems. The
WinBMR 3 File Daemon plugin is now part of the plugins included with the Bacula
File Daemon package.  The rescue CD or USB key is available separately.

\subsection{Miscellaneous New Features}
\begin{itemize}
\item Allow unlimited line lengths in .conf files (previously limited
to 2000 characters).

\item Allow /dev/null in ChangerCommand to indicated a Virtual Autochanger.

\item Add a --fileprune option to the manual\_prune.pl script.

\item Add a -m option to make\_catalog\_backup.pl to do maintenance
on the catalog.

\item Safer code that cleans up the working directory when starting
the daemons. It limits what files can be deleted, hence enhances 
security.

\item Added a new .ls command in bconsole to permit browsing a client's
filesystem.

\item Fixed a number of bugs, includes some obscure seg faults, and a
race condition that occurred infrequently when running Copy, Migration,
or Virtual Full backups.

\item Included a new vSphere library version, which will hopefully
fix some of the more obscure bugs.

\item Upgraded to a newer version of Qt4 for bat. All indications
are that this will improve bat's stability on Windows machines.

\item The Windows installers now detect and refuse to install on
an OS that does not match the 32/64 bit value of the installer.
\end{itemize}


\section{Bacula Enterprise 6.0.6}

\subsection{Incremental Accelerator Plugin for NetApp}

The Incremental Accelerator for NetApp Plugin is designed to simplify the
backup and restore procedure of your NetApp NAS hosting a huge number of files.

\smallskip{} When using the NetApp HFC Plugin, Bacula Enterprise will query the
NetApp device to get the list of all files modified since the last backup
instead of having to walk through the entire filesystem. Once Bacula have the
list of all files to back's up, it will use a standard network share (such as
NFS or CIFS) to access files.

\smallskip
This project was funded by Bacula Systems and is available with the Bacula
Enterprise Edition.

\subsection{PostgreSQL Plugin}

The PostgreSQL plugin is designed to simplify the backup and restore procedure
of your PostgreSQL cluster, the backup administrator doesn't need to learn about
internals of Postgres backup techniques or write complex scripts. The plugin
will automatically take care for you to backup essential information such as
configuration, users definition or tablespaces. The PostgreSQL plugin supports
both dump and Point In Time Recovery (PITR) backup techniques.

\smallskip
This project was funded by Bacula Systems and is available with the Bacula
Enterprise Edition.

\subsection{Maximum Reload Requests}

The new Director directive \texttt{Maximum Reload Requests} permits to
configure the number of reload requests that can be done while jobs are
running.

\begin{lstlisting}
Director {
  Name = localhost-dir
  Maximum Reload Requests = 64
  ...

}
\end{lstlisting}

\subsection{FD Storage Address}

When the Director is behind a NAT, in a WAN area, to connect to
% the FileDaemon or
the StorageDaemon, the Director uses an ``external'' ip address,
and the FileDaemon should use an ``internal'' IP address to contact the
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 directive \texttt{FDStorageAddress} in
the Storage or Client resource.


\bsysimageH{BackupOverWan1}{Backup Over WAN}{figbs6:fdstorageaddress}
%  \label{fig:fdstorageaddress}

\begin{lstlisting}
Storage {
     Name = storage1
     Address = 65.1.1.1
     FD Storage Address = 10.0.0.1
     SD Port = 9103
     ...
}
\end{lstlisting}

% # or in the Client resouce
%

\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
in the Storage resource.  The main purpose is to limit the number
of concurrent Copy, Migration, and VirtualFull jobs so that
they don't monopolize all the Storage drives causing a deadlock situation
where all the drives are allocated for reading but none remain for
writing.  This deadlock situation can occur when running multiple
simultaneous Copy, Migration, and VirtualFull jobs.

\smallskip
The default value is set to 0 (zero), which means there is no
limit on the number of read jobs.  Note, limiting the read jobs
does not apply to Restore jobs, which are normally started by
hand.  A reasonable value for this directive is one half the number
of drives that the Storage resource has rounded down.  Doing so,
will leave the same number of drives for writing and will generally
avoid over committing drives and a deadlock.


\section{Bacula Enterprise 6.0.4}

\subsection{VMWare vSphere VADP Plugin}

The Bacula Enterprise vSphere plugin provides virtual
machine bare metal recovery, while the backup at the guest level simplify data
protection of critical applications.

The plugin integrates the VMware's Changed Block Tracking (CBT) technology to
ensure only blocks that have changed since the initial Full, and/or the last
Incremental or Differential Backup are sent to the current Incremental or
Differential backup stream to give you more efficient backups and reduced
network load.

\subsection{Oracle RMAN Plugin}

The Bacula Enterprise Oracle Plugin is designed to simplify the backup and
restore procedure of your Oracle Database instance, the backup administrator
don't need to learn about internals of Oracle backup techniques or write
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}
During a backup, if the Storage daemon experiences disconnection
with the File daemon during backup (normally a comm line problem
or possibly an FD failure), under conditions that the SD determines
to be safe it will make the failed job as Incomplete rather than
failed.  This is done only if there is sufficient valid backup
data that was written to the Volume. The advantage of an Incomplete
job is that it can be restarted by the new bconsole {\bf restart}
command from the point where it left off rather than from the
beginning of the jobs as is the case with a cancel.

\subsection{The Stop Command}
Bacula has been enhanced to provide a {\bf stop} command,
very similar to the {\bf cancel} command with the main difference
that the Job that is stopped is marked as Incomplete so that
it can be restarted later by the {\bf restart} command where
it left off (see below).  The {\bf stop} command with no
arguments, will like the cancel command, prompt you with the
list of running jobs allowing you to select one, which might
look like the following:

\begin{lstlisting}
*stop
Select Job:
     1: JobId=3 Job=Incremental.2012-03-26_12.04.26_07
     2: JobId=4 Job=Incremental.2012-03-26_12.04.30_08
     3: JobId=5 Job=Incremental.2012-03-26_12.04.36_09
Choose Job to stop (1-3): 2
2001 Job "Incremental.2012-03-26_12.04.30_08" marked to be stopped.
3000 JobId=4 Job="Incremental.2012-03-26_12.04.30_08" marked to be stopped.
\end{lstlisting}

\subsection{The Restart Command}
The new {\bf Restart command} allows console users to restart
a canceled, failed, or incomplete Job.  For canceled and failed
Jobs, the Job will restart from the beginning.  For incomplete
Jobs the Job will restart at the point that it was stopped either
by a stop command or by some recoverable failure.

\smallskip
If you enter the {\bf restart} command in bconsole, you will get the
following prompts:

\begin{lstlisting}
*restart
You have the following choices:
     1: Incomplete
     2: Canceled
     3: Failed
     4: All
Select termination code:  (1-4):
\end{lstlisting}

If you select the {\bf All} option, you may see something like:

\begin{lstlisting}
Select termination code:  (1-4): 4
+-------+-------------+---------------------+------+-------+----------+-----------+-----------+
| jobid | name        | starttime           | type | level | jobfiles |
jobbytes  | jobstatus |
+-------+-------------+---------------------+------+-------+----------+-----------+-----------+
|     1 | Incremental | 2012-03-26 12:15:21 | B    | F     |        0 |
    0 | A         |
|     2 | Incremental | 2012-03-26 12:18:14 | B    | F     |      350 |
4,013,397 | I         |
|     3 | Incremental | 2012-03-26 12:18:30 | B    | F     |        0 |
    0 | A         |
|     4 | Incremental | 2012-03-26 12:18:38 | B    | F     |      331 |
3,548,058 | I         |
+-------+-------------+---------------------+------+-------+----------+-----------+-----------+
Enter the JobId list to select:
\end{lstlisting}

Then you may enter one or more JobIds to be restarted, which may
take the form of a list of JobIds separated by commas, and/or JobId
ranges such as {\bf 1-4}, which indicates you want to restart JobIds
1 through 4, inclusive.

\subsection{Support for Exchange Incremental Backups}
The Bacula Enterprise version 6.0 VSS plugin now supports
Full and Incremental backups for Exchange.  We strongly
recommend that you do not attempt to run Differential jobs with
Exchange as it is likely to produce a situation where restores
will no longer select the correct jobs, and thus the
Windows Exchange VSS writer will fail when applying log files.
There is a Bacula Systems Enterprise white paper that provides
the details of backup and restore of Exchange 2010 with the
Bacula VSS plugin.

\smallskip
Restores can be done while Exchange is running, but you
must first unmount (dismount in Microsoft terms) any database
you wish to restore and explicitly mark them to permit a
restore operation (see the white paper for details).

\smallskip
This project was funded by Bacula Systems and is available with the Bacula
Enterprise Edition.

\subsection{Support for MSSQL Block Level Backups}
With the addition of block level backup support to the
Bacula Enterprise VSS MSSQL component, you can now do
Differential backups in addition to Full backups.
Differential backups use Microsoft's partial block backup
(a block differencing or deduplication that we call Delta).
This partial block backup permits backing up only those
blocks that have changed.  Database restores can be made while
the MSSQL server is running, but any databases selected for
restore will be automatically taken offline by the MSSQL
server during the restore process.

Incremental backups for MSSQL are not support by
Microsoft. We strongly recommend that you not perform Incremental
backups with MSSQL as they will probably produce a situation
where restore will no longer work correctly.

\smallskip
 We are currently working on producing a white paper that will give more
details of backup and restore with MSSQL. One point to note is that during
a restore, you will normally not want to restore the {\bf master} database.
You must exclude it from the backup selections that you have made or the
restore will fail.

\smallskip
It is possible to restore the {\bf master} database, but you must
first shutdown the MSSQL server, then you must perform special
recovery commands.  Please see Microsoft documentation on how
to restore the master database.

\smallskip
This project was funded by Bacula Systems and is available with the Bacula
Enterprise Edition.


\subsection{Job Bandwidth Limitation}

The new {\bf Job Bandwidth Limitation} directive may be added to the File
daemon's and/or Director's configuration to limit the bandwidth used by a
Job on a Client.  It can be set in the File daemon's conf file for all Jobs
run in that File daemon, or it can be set for each Job in the Director's
conf file. The speed is always specified in bytes per second.

For example:
\begin{lstlisting}
FileDaemon {
  Name = localhost-fd
  Working Directory = /some/path
  Pid Directory = /some/path
  ...
  Maximum Bandwidth Per Job = 5Mb/s
}
\end{lstlisting}

The above example would cause any jobs running with the FileDaemon to not
exceed 5 megabytes per second of throughput when sending data to the
Storage Daemon. Note, the speed is always specified in bytes per second
(not in bits per second), and the case (upper/lower) of the specification
characters is ignored (i.e. 1MB/s = 1Mb/s).

You may specify the following speed parameter modifiers:
   k/s (1,000 bytes per second), kb/s (1,024 bytes per second),
   m/s (1,000,000 bytes per second), or mb/s (1,048,576 bytes per second).

For example:
\begin{lstlisting}
Job {
  Name = locahost-data
  FileSet = FS_localhost
  Accurate = yes
  ...
  Maximum Bandwidth = 5Mb/s
  ...
}
\end{lstlisting}

The above example would cause Job \texttt{localhost-data} to not exceed 5MB/s
of throughput when sending data from the File daemon to the Storage daemon.

A new console command \texttt{setbandwidth} permits to set dynamically the
maximum throughput of a running Job or for future jobs of a Client.

\begin{lstlisting}
* setbandwidth limit=1000 jobid=10
\end{lstlisting}

Please note that the value specified for the \texttt{limit} command
line parameter is always in units of 1024 bytes (i.e. the number
is multiplied by 1024 to give the number of bytes per second).  As 
a consequence, the above limit of 1000 will be interpreted as a
limit of 1000 * 1024 = 1,024,000 bytes per second.

\medskip
This project was funded by Bacula Systems and is available in
the Enterprise Edition.

\subsection{Incremental/Differential Block Level Difference Backup}

The new \texttt{delta} Plugin is able to compute and apply signature-based file
differences. It can be used to backup only changes in a big binary file like
Outlook PST, VirtualBox/VMware images or database files.

It supports both Incremental and Differential backups and stores signatures
database in the File Daemon working directory. This plugin is available on all
platform including Windows 32 and 64bit.

Accurate option should be turned on in the Job resource.
\begin{lstlisting}
Job {
 Accurate = yes
 FileSet = DeltaFS
 ...
}

FileSet {
 Name = DeltaFS
 ...
 Include {
   # Specify one file
   Plugin = "delta:/home/eric/.VirtualBox/HardDisks/lenny-i386.vdi"
 }
}

FileSet {
 Name = DeltaFS-Include
 ...
 Include {
   Options {
      Compression = GZIP1
      Signature = MD5
      Plugin = delta
   }
   # Use the Options{} filtering and options
   File = /home/user/.VirtualBox
 }
}

\end{lstlisting}

Please contact Bacula Systems support to get Delta Plugin specific
documentation.

\medskip
This project was funded by Bacula Systems and is available with the Bacula
Enterprise Edition.

\subsection{SAN Shared Tape Storage Plugin}

The problem with backing up multiple servers at the same time to the
same tape library (or autoloader) is that if both servers access the
same tape drive same time, you will very likely get data corruption.
This is where the Bacula Systems shared tape storage plugin comes into play.  The
plugin ensures that only one server at a time can connect to each device
(tape drive) by using the SPC-3 SCSI reservation protocol.  Please contact
Bacula Systems support to get SAN Shared Storage Plugin specific
documentation.

\medskip
This project was funded by Bacula Systems and is available with Bacula
Enterprise Edition.

\subsection{Advanced Autochanger Usage}

The new \texttt{Shared Storage} Director's 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{lstlisting}
 $ /opt/bacula/scripts/reset-storageid MediaType StorageName
 $ bconsole
 * update slots storage=StorageName drive=0
\end{lstlisting}

Please contact Bacula Systems support to get help on this advanced
configuration.

\medskip
This project was funded by Bacula Systems and is available with Bacula
Enterprise Edition.

\medskip
\textbf{The reset-storageid procedure is no longer required when using
the appropriate Autochanger configuration in the Director configuration
side.}

\subsection{Enhancement of the NDMP Plugin}

The previous NDMP Plugin 4.0 was fully supporting only the NetApp hardware, the
new NDMP Plugin should now be able to support all NAS vendors with the
\texttt{volume\_format} plugin command option.

On some NDMP devices such as Celera or Blueray, the administrator can use arbitrary
volume structure name, ex:

\begin{lstlisting}
 /dev/volume_home
 /rootvolume/volume_tmp
 /VG/volume_var
\end{lstlisting}

The NDMP plugin should be aware of the structure organization in order to
detect if the administrator wants to restore in a new volume
(\texttt{where=/dev/vol\_tmp}) or inside a subdirectory of the targeted volume
(\texttt{where=/tmp}).

\begin{lstlisting}
FileSet {
 Name = NDMPFS
 ...
 Include {
   Plugin = "ndmp:host=nasbox user=root pass=root file=/dev/vol1 volume_format=/dev/"
 }
}
\end{lstlisting}

Please contact Bacula Systems support to get NDMP Plugin specific
documentation.

\medskip
This project was funded by Bacula Systems and is available with the Bacula
Enterprise Edition.

\subsection{Always Backup a File}

When the Accurate mode is turned on, you can decide to always backup a file
by using then new {\bf A} Accurate option in your FileSet. For example:

\begin{lstlisting}
Job {
   Name = ...
   FileSet = FS_Example
   Accurate = yes
   ...
}

FileSet {
 Name = FS_Example
 Include {
   Options {
     Accurate = A
   }
   File = /file
   File = /file2
 }
 ...
}
\end{lstlisting}

This project was funded by Bacula Systems based on an idea of James Harper and
is available with the Bacula Enterprise Edition.

\subsection{Setting Accurate Mode During at Runtime}

You are now able to specify the Accurate mode on the \texttt{run} command and
in the Schedule resource.

\begin{lstlisting}
* run accurate=yes job=Test
\end{lstlisting}

\begin{lstlisting}
Schedule {
  Name = WeeklyCycle
  Run = Full 1st sun at 23:05
  Run = Differential accurate=yes 2nd-5th sun at 23:05
  Run = Incremental  accurate=no  mon-sat at 23:05
}
\end{lstlisting}

It can allow you to save memory and and CPU resources on the catalog server in
some cases.

\medskip
These advanced tuning options are available with the Bacula Enterprise Edition.

% Common with community
\subsection{Additions to RunScript variables}
You can have access to JobBytes, JobFiles and Director name using \%b, \%F and \%D
in your runscript command. The Client address is now available through \%h.

\begin{lstlisting}
RunAfterJob = "/bin/echo Job=%j JobBytes=%b JobFiles=%F ClientAddress=%h Dir=%D"
\end{lstlisting}

\subsection{LZO Compression}

LZO compression was added in the Unix File Daemon. From the user point of view,
it works like the GZIP compression (just replace {\bf compression=GZIP} with
{\bf compression=LZO}).

For example:
\begin{lstlisting}
Include {
   Options { compression=LZO }
   File = /home
   File = /data
}
\end{lstlisting}

LZO provides much faster compression and decompression speed but lower
compression ratio than GZIP. It is a good option when you backup to disk. For
tape, the built-in compression may be a better option.

LZO is a good alternative for GZIP1 when you don't want to slow down your
backup. On a modern CPU it should be able to run almost as fast as:

\begin{bsysitemize}
\item your client can read data from disk. Unless you have very fast disks like
  SSD or large/fast RAID array.
\item the data transfers between the file daemon and the storage daemon even on
  a 1Gb/s link.
\end{bsysitemize}

Note that bacula only use one compression level LZO1X-1.

\medskip
The code for this feature was contributed by Laurent Papier.

\subsection{New Tray Monitor}

Since the old integrated Windows tray monitor doesn't work with
recent Windows versions, we have written a new Qt Tray Monitor that is available
for both Linux and Windows.  In addition to all the previous features,
this new version allows you to run Backups from
the tray monitor menu.

\bsysimageH{tray-monitor}{New tray monitor}{figbs6:traymonitor}

\bsysimageH{tray-monitor1}{Run a Job through the new tray monitor}{figbs6:traymonitor1}



To be able to run a job from the tray monitor, you need to
allow specific commands in the Director monitor console:
\begin{lstlisting}
Console {
    Name = win2003-mon
    Password = "xxx"
    CommandACL = status, .clients, .jobs, .pools, .storage, .filesets, .messages, run
    ClientACL = *all*               # you can restrict to a specific host
    CatalogACL = *all*
    JobACL = *all*
    StorageACL = *all*
    ScheduleACL = *all*
    PoolACL = *all*
    FileSetACL = *all*
    WhereACL = *all*
}
\end{lstlisting}

\medskip
This project was funded by Bacula Systems and is available with Bacula
the Enterprise Edition and the Community Edition.

\subsection{Purge Migration Job}

The new {\bf Purge Migration Job} directive may be added to the Migration
Job definition in the Director's configuration file. When it is enabled
the Job that was migrated during a migration will be purged at
the end of the migration job.

For example:
\begin{lstlisting}
Job {
  Name = "migrate-job"
  Type = Migrate
  Level = Full
  Client = localhost-fd
  FileSet = "Full Set"
  Messages = Standard
  Storage = DiskChanger
  Pool = Default
  Selection Type = Job
  Selection Pattern = ".*Save"
...
  Purge Migration Job = yes
}
\end{lstlisting}

\medskip

This project was submitted by Dunlap Blake; testing and documentation was funded
by Bacula Systems.

\subsection{Changes in the Pruning Algorithm}

We rewrote the job pruning algorithm in this version. Previously, in some users
reported that the pruning process at the end of jobs was very long. It should
not be longer the case. Now, Bacula won't prune automatically a Job if this
particular Job is needed to restore data. Example:

\begin{lstlisting}
JobId: 1  Level: Full
JobId: 2  Level: Incremental
JobId: 3  Level: Incremental
JobId: 4  Level: Differential
.. Other incrementals up to now
\end{lstlisting}

In this example, if the Job Retention defined in the Pool or in the Client
resource causes that Jobs with Jobid in 1,2,3,4 can be pruned, Bacula will
detect that JobId 1 and 4 are essential to restore data at the current state
and will prune only JobId 2 and 3.

\texttt{Important}, this change affect only the automatic pruning step after a
Job and the \texttt{prune jobs} Bconsole command. If a volume expires after the
\texttt{VolumeRetention} period, important jobs can be pruned.

\subsection{Ability to Verify any specified Job}
You now have the ability to tell Bacula which Job should verify instead of
automatically verify just the last one.

This feature can be used with VolumeToCatalog, DiskToCatalog and Catalog level.

To verify a given job, just specify the Job jobid in argument when starting the
job.
\begin{lstlisting}
*run job=VerifyVolume jobid=1 level=VolumeToCatalog
Run Verify job
JobName:     VerifyVolume
Level:       VolumeToCatalog
Client:      127.0.0.1-fd
FileSet:     Full Set
Pool:        Default (From Job resource)
Storage:     File (From Job resource)
Verify Job:  VerifyVol.2010-09-08_14.17.17_03
Verify List: /tmp/regress/working/VerifyVol.bsr
When:        2010-09-08 14:17:31
Priority:    10
OK to run? (yes/mod/no):
\end{lstlisting}

\medskip
This project was funded by Bacula Systems and is available with Bacula
Enterprise Edition and Community Edition.