]> git.sur5r.net Git - bacula/docs/blobdiff - docs/manuals/en/main/newbsfeatures.tex
Tweak images
[bacula/docs] / docs / manuals / en / main / newbsfeatures.tex
index d6e7fb7e83a9f6d9aea5564e9d88575786509c0a..8b23e73d1a7f09f2b1d607cfdb2aed520e3b151c 100644 (file)
@@ -1,4 +1,4 @@
-\chapter{New Features in Bacula Enterprise 6.0.x}
+\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.
@@ -7,9 +7,157 @@ In addition to the features in this chapter, the Enterprise version
 will include the Community features described in the Community new Features
 chapter.
 
-\chapter{New Features in Bacula Enterprise 6.0.6}
+% \section{Bacula Enterprise 6.x.x}
+% \subsection{VirtualFull Backup Consolidation Enhancements}
+% 
+% By default Bacula is selecting jobs automatically, however, you may want to
+% choose any point in time to create the Virtual backup.
+%
+% For example, if you have the following 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}
+%
+% 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} in 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 the jobid 8.
+%
+% If you know what you are doing and still 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}
+
+\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{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.
 
-\section{Incremental Accelerator Plugin for NetApp}
+\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.
@@ -24,7 +172,7 @@ NFS or CIFS) to access files.
 This project was funded by Bacula Systems and is available with the Bacula
 Enterprise Edition.
 
-\section{PostgreSQL Plugin}
+\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
@@ -37,46 +185,40 @@ both dump and Point In Time Recovery (PITR) backup techniques.
 This project was funded by Bacula Systems and is available with the Bacula
 Enterprise Edition.
 
-\chapter{New Features in Bacula Enterprise 6.0.5}
-
-\section{Maximum Reload Requests}
+\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{verbatim}
+\begin{lstlisting}
 Director {
   Name = localhost-dir
   Maximum Reload Requests = 64
   ...
 
 }
-\end{verbatim}
+\end{lstlisting}
 
-\section{FD Storage Address}
+\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
+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
+``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 
+this parameter using the new \texttt{FDStorageAddress} Storage
 % or Client
 directive.
 
-\begin{figure}[htbp]
-  \centering
-  \includegraphics[width=10cm]{\idir BackupOverWan1}
-  \label{fig:fdstorageaddress}
-  \caption{Backup over WAN}
-\end{figure}
+\bsysimageH{BackupOverWan1}{Backup Over WAN}{figbs6:fdstorageaddress}
+%  \label{fig:fdstorageaddress}
 
-\begin{verbatim}
+\begin{lstlisting}
 Storage {
      Name = storage1
      Address = 65.1.1.1
@@ -84,10 +226,10 @@ Storage {
      SD Port 9103
      ...
 }
-\end{verbatim}
+\end{lstlisting}
 
 % # or in the Client resouce
-% 
+%
 % Client {
 %      Name = client1
 %      Address = 65.1.1.2
@@ -95,17 +237,36 @@ Storage {
 %      FD Port 9103
 %      ...
 % }
-% \end{verbatim}
-% 
+% \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}.
 
-\chapter{New Features in Bacula Enterprise 6.0.4}
+\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{VMWare vSphere VADP Plugin}
 
-The \bsee{} vSphere plugin provides virtual
+\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.
 
@@ -115,7 +276,7 @@ Incremental or Differential Backup are sent to the current Incremental or
 Differential backup stream to give you more efficient backups and reduced
 network load.
 
-\section{Oracle RMAN Plugin}
+\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
@@ -123,9 +284,98 @@ 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.
 
-\chapter{New Features in Bacula Enterprise 6.0.0}
 
-\section{Incomplete Jobs}
+\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
@@ -136,7 +386,7 @@ 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.
 
-\section{The Stop Command}
+\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
@@ -146,7 +396,7 @@ 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{verbatim}
+\begin{lstlisting}
 *stop
 Select Job:
      1: JobId=3 Job=Incremental.2012-03-26_12.04.26_07
@@ -155,12 +405,12 @@ Select Job:
 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{verbatim}
+\end{lstlisting}
 
-\section{The Restart Command}
+\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 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.
 
@@ -168,19 +418,19 @@ by a stop command or by some recoverable failure.
 If you enter the {\bf restart} command in bconsole, you will get the
 following prompts:
 
-\begin{verbatim}
+\begin{lstlisting}
 *restart
 You have the following choices:
      1: Incomplete
      2: Canceled
      3: Failed
      4: All
-Select termination code:  (1-4): 
-\end{verbatim}
+Select termination code:  (1-4):
+\end{lstlisting}
 
 If you select the {\bf All} option, you may see something like:
 
-\begin{verbatim}
+\begin{lstlisting}
 Select termination code:  (1-4): 4
 +-------+-------------+---------------------+------+-------+----------+-----------+-----------+
 | jobid | name        | starttime           | type | level | jobfiles |
@@ -195,15 +445,15 @@ jobbytes  | jobstatus |
 |     4 | Incremental | 2012-03-26 12:18:38 | B    | F     |      331 |
 3,548,058 | I         |
 +-------+-------------+---------------------+------+-------+----------+-----------+-----------+
-Enter the JobId list to select: 
-\end{verbatim}
+Enter the JobId list to select:
+\end{lstlisting}
 
-Then you may enter one or more JobIds to be restarted, which may 
+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.
 
-\section{Support for Exchange Incremental Backups}
+\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
@@ -224,8 +474,8 @@ restore operation (see the white paper for details).
 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 
+\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
@@ -233,13 +483,13 @@ Differential backups use Microsoft's partial block backup
 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 
+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. 
+where restore will no longer work correctly.
 
 \smallskip
  We are currently working on producing a white paper that will give more
@@ -250,7 +500,7 @@ 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 
+first shutdown the MSSQL server, then you must perform special
 recovery commands.  Please see Microsoft documentation on how
 to restore the master database.
 
@@ -259,7 +509,7 @@ This project was funded by Bacula Systems and is available with the Bacula
 Enterprise Edition.
 
 
-\section{Job Bandwidth Limitation}
+\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
@@ -267,7 +517,7 @@ 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}
+\begin{lstlisting}
 FileDaemon {
   Name = localhost-fd
   Working Directory = /some/path
@@ -275,7 +525,7 @@ FileDaemon {
   ...
   Maximum Bandwidth Per Job = 5Mb/s
 }
-\end{verbatim}
+\end{lstlisting}
 
 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.
@@ -283,7 +533,7 @@ 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}
+\begin{lstlisting}
 Job {
   Name = locahost-data
   FileSet = FS_localhost
@@ -292,7 +542,7 @@ Job {
   Maximum Bandwidth = 5Mb/s
   ...
 }
-\end{verbatim}
+\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.
@@ -300,9 +550,9 @@ 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}
+\begin{lstlisting}
 * setbandwidth limit=1000000 jobid=10
-\end{verbatim}
+\end{lstlisting}
 
 The \texttt{limit} parameter is in Kb/s.
 
@@ -310,7 +560,7 @@ The \texttt{limit} parameter is in Kb/s.
 This project was funded by Bacula Systems and is available in
 the Enterprise Edition.
 
-\section{Incremental/Differential Block Level Difference Backup}
+\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
@@ -321,7 +571,7 @@ 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}
+\begin{lstlisting}
 Job {
  Accurate = yes
  FileSet = DeltaFS
@@ -351,7 +601,7 @@ FileSet {
  }
 }
 
-\end{verbatim}
+\end{lstlisting}
 
 Please contact Bacula Systems support to get Delta Plugin specific
 documentation.
@@ -360,7 +610,7 @@ documentation.
 This project was funded by Bacula Systems and is available with the Bacula
 Enterprise Edition.
 
-\section{SAN Shared Tape Storage Plugin}
+\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
@@ -375,7 +625,7 @@ documentation.
 This project was funded by Bacula Systems and is available with Bacula
 Enterprise Edition.
 
-\section{Advanced Autochanger Usage}
+\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
@@ -391,11 +641,11 @@ 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}
+\begin{lstlisting}
  $ /opt/bacula/scripts/reset-storageid MediaType StorageName
  $ bconsole
  * update slots storage=StorageName drive=0
-\end{verbatim}
+\end{lstlisting}
 
 Please contact Bacula Systems support to get help on this advanced
 configuration.
@@ -404,7 +654,7 @@ configuration.
 This project was funded by Bacula Systems and is available with Bacula
 Enterprise Edition.
 
-\section{Enhancement of the NDMP Plugin}
+\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
@@ -413,18 +663,18 @@ new NDMP Plugin should now be able to support all NAS vendors with the
 On some NDMP devices such as Celera or Blueray, the administrator can use arbitrary
 volume structure name, ex:
 
-\begin{verbatim}
+\begin{lstlisting}
  /dev/volume_home
  /rootvolume/volume_tmp
  /VG/volume_var
-\end{verbatim}
+\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{verbatim}
+\begin{lstlisting}
 FileSet {
  Name = NDMPFS
  ...
@@ -432,7 +682,7 @@ FileSet {
    Plugin = "ndmp:host=nasbox user=root pass=root file=/dev/vol1 volume_format=/dev/"
  }
 }
-\end{verbatim}
+\end{lstlisting}
 
 Please contact Bacula Systems support to get NDMP Plugin specific
 documentation.
@@ -441,12 +691,12 @@ documentation.
 This project was funded by Bacula Systems and is available with the Bacula
 Enterprise Edition.
 
-\section{Always Backup a File}
+\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{verbatim}
+\begin{lstlisting}
 Job {
    Name = ...
    FileSet = FS_Example
@@ -465,28 +715,28 @@ FileSet {
  }
  ...
 }
-\end{verbatim}
+\end{lstlisting}
 
 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}
+\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{verbatim}
+\begin{lstlisting}
 * run accurate=yes job=Test
-\end{verbatim}
+\end{lstlisting}
 
-\begin{verbatim}
+\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{verbatim}
+\end{lstlisting}
 
 It can allow you to save memory and and CPU resources on the catalog server in
 some cases.
@@ -495,28 +745,28 @@ some cases.
 These advanced tuning options are available with the Bacula Enterprise Edition.
 
 % Common with community
-\section{Additions to RunScript variables}
+\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{verbatim}
+\begin{lstlisting}
 RunAfterJob = "/bin/echo Job=%j JobBytes=%b JobFiles=%F ClientAddress=%h Dir=%D"
-\end{verbatim}
+\end{lstlisting}
 
-\section{LZO Compression}
+\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{verbatim}
+\begin{lstlisting}
 Include {
    Options { compression=LZO }
    File = /home
    File = /data
 }
-\end{verbatim}
+\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
@@ -525,44 +775,35 @@ 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{itemize}
+\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{itemize}
+\end{bsysitemize}
 
 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}
+\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 
+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}
+\bsysimageH{tray-monitor}{New tray monitor}{figbs6:traymonitor}
+
+\bsysimageH{tray-monitor1}{Run a Job through the new tray monitor}{figbs6:traymonitor1}
 
-\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}
+\begin{lstlisting}
 Console {
     Name = win2003-mon
     Password = "xxx"
@@ -576,21 +817,21 @@ Console {
     FileSetACL = *all*
     WhereACL = *all*
 }
-\end{verbatim}
+\end{lstlisting}
 
 \medskip
 This project was funded by Bacula Systems and is available with Bacula
 the Enterprise Edition and the Community Edition.
 
-\section{Purge Migration Job}
+\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 
+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}
+\begin{lstlisting}
 Job {
   Name = "migrate-job"
   Type = Migrate
@@ -605,27 +846,27 @@ Job {
 ...
   Purge Migration Job = yes
 }
-\end{verbatim}
+\end{lstlisting}
 
 \medskip
 
 This project was submitted by Dunlap Blake; testing and documentation was funded
 by Bacula Systems.
 
-\section{Changes in the Pruning Algorithm}
+\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{verbatim}
+\begin{lstlisting}
 JobId: 1  Level: Full
 JobId: 2  Level: Incremental
 JobId: 3  Level: Incremental
 JobId: 4  Level: Differential
 .. Other incrementals up to now
-\end{verbatim}
+\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
@@ -636,7 +877,7 @@ and will prune only JobId 2 and 3.
 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}
+\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.
 
@@ -644,7 +885,7 @@ 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}
+\begin{lstlisting}
 *run job=VerifyVolume jobid=1 level=VolumeToCatalog
 Run Verify job
 JobName:     VerifyVolume
@@ -658,7 +899,7 @@ Verify List: /tmp/regress/working/VerifyVol.bsr
 When:        2010-09-08 14:17:31
 Priority:    10
 OK to run? (yes/mod/no):
-\end{verbatim}
+\end{lstlisting}
 
 \medskip
 This project was funded by Bacula Systems and is available with Bacula