]> git.sur5r.net Git - bacula/docs/blobdiff - docs/manuals/en/concepts/newfeatures.tex
Update new features
[bacula/docs] / docs / manuals / en / concepts / newfeatures.tex
index b6ff68f1dc57d5362da46ff6a4a90da29726a100..324b224428f6f8c3d73a5f08ce3e331dcf10a955 100644 (file)
@@ -2,7 +2,88 @@
 
 %%
 
-\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}
 
@@ -28,12 +109,16 @@ backup, there is no difference, but for {\bf Differential} and {\bf
 backed up, and the File daemon will use that list to determine if any new files
 have been added or or moved and if any files have been deleted. This allows
 Bacula to make an accurate backup of your system to that point in time so that
-if you do a restore, it will restore your system exactly.  One note of caution
+if you do a restore, it will restore your system exactly.  
+
+One note of caution
 about using Accurate backup is that it requires more resources (CPU and memory)
 on both the Director and the Client machines to create the list of previous
 files backed up, to send that list to the File daemon, for the File daemon to
 keep the list (possibly very big) in memory, and for the File daemon to do
-comparisons between every file in the FileSet and the list.
+comparisons between every file in the FileSet and the list.  In particular,
+if your client has lots of files (more than a few million), you will need
+lots of memory on the client machine.
 
 Accurate must not be enabled when backing up with a plugin that is not
 specially designed to work with Accurate. If you enable it, your restores
@@ -336,7 +421,8 @@ which has a version number to permit running multiple versions of
 the libraries if desired (not normally the case).
 
 If you have problems with libtool or you wish to use the old
-way of building static libraries, you can do so by disabling
+way of building static libraries, or you want to build a static
+version of Bacula you may disable
 libtool on the configure command line with:
 
 \begin{verbatim}
@@ -344,16 +430,29 @@ libtool on the configure command line with:
 \end{verbatim}
 
 
+\section{Building Static versions of Bacula}
+\index[general]{Static linking}
+In order to build static versions of Bacula, in addition
+to configuration options that were needed you now must
+also add --disable-libtool.  Example
+
+\begin{verbatim}
+  ./configure --enable-static-client-only --disable-libtool
+\end{verbatim}
+
+
 \section{Virtual Backup (Vbackup)}
 \index[general]{Virtual Backup}
 \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 
@@ -366,10 +465,11 @@ daemon. If you then want to do subsequent backups, you may need to
 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}.
@@ -544,22 +644,32 @@ They are:
   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}.
 
 
@@ -1145,6 +1255,16 @@ In your Director's {\bf Messages} resource.
   !$%&'()*+,-/:;<>?[]^`{|}~
 \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
@@ -1260,7 +1380,8 @@ the tape code but actually reading and writing to a disk file. Used with the
 \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}
@@ -1405,7 +1526,7 @@ capacity planning, billings, etc.
 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
@@ -1449,6 +1570,11 @@ A new director directive permits to specify the maximum number of Console
 Connections that could run concurrently. The default is set to 20, but you may
 set it to a larger number.
 
+\subsection{VerId = \lt{}string\gt{}}
+\index[general]{VerId}
+A new director directive permits to specify a personnal identifier that will be
+displayed in the \texttt{version} command.
+
 \subsection{dbcheck enhancements}
 \index[general]{dbcheck enhancements}
 If you are using Mysql, dbcheck will now ask you if you want to create