%%
-\chapter{New Features}
+\chapter{New Features in 3.0.2}
+\label{NewFeaturesChapter}
+
+This chapter presents the new features added to the development 3.0.2
+versions to be released as Bacula version 3.0.2 sometime in 2009.
+
+\section{Source Address}
+\index[general]{Source Address}
+
+A feature has been added which allows the administrator to specify the address
+from which the director and file daemons will attempt connections from. This
+may be used to simplify system configuration overhead when working in complex
+networks utilizing multi-homing and policy-routing.
+
+To accomplish this, two new configuration directives have been implemented:
+\begin{verbatim}
+FileDaemon {
+ FDSourceAddress=10.0.1.20 # Always initiate connections from this address
+}
+
+Director {
+ DirSourceAddress=10.0.1.10 # Always initiate connections from this address
+}
+\end{verbatim}
+
+Simply adding specific host routes would have an undesirable side-effect: any
+application trying to contact the destination host would be forced to use the
+more specific route, possibly diverting management traffic onto a backup VLAN.
+Instead of adding host routes for each client connected to a multi-homed backup
+server (for example where there are management and backup VLANs), one can
+use the new directives to specify a specific source address at the application
+level.
+
+Additionally, this allows the simplification and abstraction of firewall rules
+when dealing with a Hot-Standby director or storage daemon configuration. The
+Hot-standby pair may share a CARP address, which connections must be sourced
+from, while system services listen and act from the unique interface addresses.
+
+This project was funded by Collaborative Fusion, Inc.
+
+\section{Show volume availability when doing restore}
+
+When doing a restore the restore selection dialog ends by displaying this
+screen:
+
+\begin{verbatim}
+ The job will require the following
+ Volume(s) Storage(s) SD Device(s)
+ ===========================================================================
+ *000741L3 LTO-4 LTO3
+ *000866L3 LTO-4 LTO3
+ *000765L3 LTO-4 LTO3
+ *000764L3 LTO-4 LTO3
+ *000756L3 LTO-4 LTO3
+ *001759L3 LTO-4 LTO3
+ *001763L3 LTO-4 LTO3
+ 001762L3 LTO-4 LTO3
+ 001767L3 LTO-4 LTO3
+
+Volumes marked with ``*'' are online.
+\end{verbatim}
+
+This should help getting large restores through minimizing the time spent
+waiting for operator to drop by and change tapes in the library.
+
+This project was funded by Bacula Systems.
+
+\section{Accurate estimate command}
+
+The \texttt{estimate} command can now use the accurate code to detect changes
+and give a better estimation.
+
+You can set the accurate behavior on command line using
+\texttt{accurate=yes/no} or use the Job setting as default value.
+
+\begin{verbatim}
+* estimate listing accurate=yes level=incremental job=BackupJob
+\end{verbatim}
+
+This project was funded by Bacula Systems.
+
+\chapter{New Features in 3.0.0}
\label{NewFeaturesChapter}
\index[general]{New Features}
\index[general]{Vbackup}
Bacula's virtual backup feature is often called Synthetic Backup or
-Consolidation in other backup products. It permits you to consolidate
-the previous Full backup plus the most recent Differential backup and any
-subsequent Incremental backups into a new Full backup. This is accomplished
-without contacting the client by reading the previous backup data and
-writing it to a volume in a different pool.
+Consolidation in other backup products. It permits you to consolidate the
+previous Full backup plus the most recent Differential backup and any
+subsequent Incremental backups into a new Full backup. This new Full
+backup will then be considered as the most recent Full for any future
+Incremental or Differential backups. The VirtualFull backup is
+accomplished without contacting the client by reading the previous backup
+data and writing it to a volume in a different pool.
In some respects the Vbackup feature works similar to a Migration job, in
that Bacula normally reads the data from the pool specified in the
move the Virtual Full Volume back to your normal backup pool.
Alternatively, you can set your {\bf Next Pool} to point to the current
pool. This will cause Bacula to read and write to Volumes in the
-current pool. In general, this will work, but doing the Virtual Full
-requires reading more than one Volume, this procedure may cause a
-deadlock where Bacula is writing on a Volume that is later needed
-for reading.
+current pool. In general, this will work, because Bacula will
+not allow reading and writing on the same Volume. In any case, once
+a VirtualFull has been created, and a restore is done involving the
+most current Full, it will read the Volume or Volumes by the VirtualFull
+regardless of in which Pool the Volume is found.
The Vbackup is enabled on a Job by Job in the Job resource by specifying
a level of {\bf VirtualFull}.
the directive is set to {\bf no} (default) then only one job of a given name
may run at one time, and the action that Bacula takes to ensure only
one job runs is determined by the other directives (see below).
+
+ If {\bf Allow Duplicate Jobs} is set to {\bf no} and two jobs
+ are present and none of the three directives given below permit
+ cancelling a job, then the current job (the second one started)
+ will be cancelled.
+
\subsection{Allow Higher Duplicates = \lt{}yes|no\gt{}}
\index[general]{Allow Higher Duplicates}
If this directive is set to {\bf yes} (default) the job with a higher
- priority (lower priority number) will be permitted to run. If the
+ priority (lower priority number) will be permitted to run, and
+ the current job will be cancelled. If the
priorities of the two jobs are the same, the outcome is determined by
other directives (see below).
\subsection{Cancel Queued Duplicates = \lt{}yes|no\gt{}}
\index[general]{Cancel Queued Duplicates}
- If this directive is set to {\bf yes} (default) any job that is
+ If {\bf Allow Duplicate Jobs} is set to {\bf no} and
+ if this directive is set to {\bf yes} any job that is
already queued to run but not yet running will be canceled.
+ The default is {\bf no}.
\subsection{Cancel Running Duplicates = \lt{}yes|no\gt{}}
\index[general]{Cancel Running Duplicates}
- If this directive is set to {\bf yes} any job that is already running
+ If {\bf Allow Duplicate Jobs} is set to {\bf no} and
+ if this directive is set to {\bf yes} any job that is already running
will be canceled. The default is {\bf no}.
!$%&'()*+,-/:;<>?[]^`{|}~
\end{verbatim}
+\subsection{Deleting Volumes}
+The delete volume bconsole command has been modified to
+require an asterisk (*) in front of a MediaId otherwise the
+value you enter is a taken to be a Volume name. This is so that
+users may delete numeric Volume names. The previous Bacula versions
+assumed that all input that started with a number was a MediaId.
+
+This new behavior is indicated in the prompt if you read it
+carefully.
+
\section{Bare Metal Recovery}
The old bare metal recovery project is essentially dead. One
of the main features of it was that it would build a recovery
\textbf{disk-changer} script, you can now emulate an autochanger with 10 drives
and 700 slots. This feature is most useful in testing. It is enabled
by using {\bf Device Type = vtape} in the Storage daemon's Device
-directive. This feature is only implemented on Linux machines.
+directive. This feature is only implemented on Linux machines and should not be
+used for production.
\subsection{Bat Enhancements}
\index[general]{Bat Enhancements}
The Bweb interface provides a statistics module that can use this feature. You
can also use tools like Talend or extract information by yourself.
-The {\textbf Statistics Retention = \lt{}time\gt{}} director directive defines
+The \textbf{Statistics Retention = \lt{}time\gt{}} director directive defines
the length of time that Bacula will keep statistics job records in the Catalog
database after the Job End time. (In \texttt{JobHistory} table) When this time
period expires, and if user runs \texttt{prune stats} command, Bacula will
projects / bacula / docs / blobdiff