First cut documenting my new features

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

\chapter{New Features in Bacula Enterprise 6.0}
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
will include the Community features described in the Community new Features
chapter.

\section{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.

\section{The Stop Command}
Bacula has been enhanced to provid 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.  This permits
the Job to be started later by the {\bf restart} command (see below).

\section{The Restart Command}
The new {\bf Restart command} allows console users to restart
a cancelled, failed, or incomplete Job.  For cancelled 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.

\section{Support for Exchange Differential and Incremental Backups}
The Bacula Enterprise version 6.0 VSS plugin now supports
Full, Differential, and Incremental backups for Exchange.
There is a Bacula Systems Enterprise white paper that provides
the details of backup and restore of Exchange 2010 with the
Bacula VSS plugin.

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

\section{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.
Incremental backups for MSSQL are not support by
Microsoft.

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


\section{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.

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

The above example would cause any jobs running with the FileDaemon to not
exceed 5Mb/s of throughput when sending data to the Storage Daemon.

You can specify the speed parameter in k/s, Kb/s, m/s, Mb/s.

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

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{verbatim}
* setbandwidth limit=1000000 jobid=10
\end{verbatim}

The \texttt{limit} parameter is in Kb/s.

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

\section{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{verbatim}
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{verbatim}

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.

\section{SAN Shared 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 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.

\section{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{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.

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

\section{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{verbatim}
 /dev/volume_home
 /rootvolume/volume_tmp
 /VG/volume_var
\end{verbatim}

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{verbatim}
FileSet {
 Name = NDMPFS
 ...
 Include {
   Plugin = "ndmp:host=nasbox user=root pass=root file=/dev/vol1 volume_format=/dev/"
 }
}
\end{verbatim}

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.

\section{Always Backup a File}

When the Accurate mode is turned on, you can decide to always backup a file
by using the following option:

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

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

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

\section{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{verbatim}
* run accurate=yes job=Test
\end{verbatim}

\begin{verbatim}
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{verbatim}

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
\section{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{verbatim}
RunAfterJob = "/bin/echo Job=%j JobBytes=%b JobFiles=%F ClientAddress=%h Dir=%D"
\end{verbatim}

\section{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{verbatim}
Include {
   Options { compression=LZO }
   File = /home
   File = /data
}
\end{verbatim}

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 altenative 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{itemize}
\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{itemize}

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

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

\section{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.

\begin{figure}[htbp]
  \centering
  \includegraphics[width=10cm]{\idir tray-monitor}
  \label{fig:traymonitor}
  \caption{New tray monitor}
\end{figure}

\begin{figure}[htbp]
  \centering
  \includegraphics[width=10cm]{\idir tray-monitor1}
  \label{fig:traymonitor1}
  \caption{Run a Job through the new tray monitor}
\end{figure}


To be able to run a job from the tray monitor, you need to
allow specific commands in the Director monitor console:
\begin{verbatim}
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{verbatim}

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

\section{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{verbatim}
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{verbatim}

\medskip

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

\section{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{verbatim}
JobId: 1  Level: Full
JobId: 2  Level: Incremental
JobId: 3  Level: Incremental
JobId: 4  Level: Differential
.. Other incrementals up to now
\end{verbatim}

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.

\section{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{verbatim}
*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{verbatim}

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