\chapter{New Features in 9.0.0}
+Note: The first beta versions are released as version 7.9.0, and the first
+production release will be 9.0.0.
+
\subsection{Maximum Virtual Full Interval Option}
Two new director directives have been added:
\label{fig:slidingbackups}
\end{figure}
-To implement this the Progressive Virtual Full feature, you add the
-{\bf Backups To Keep} directive to your Job resource. The value
-specified on the directive indicates the number of backup jobs that should
-not be merged into the Virtual Full. The default is zero and behaves the
-same way the prior script {\bf pvf} worked.
+To implement the Progressive Virtual Full feature, simply add the
+{\bf Backups To Keep} directive to your Virtual Full backup Job resource.
+The value specified on the directive indicates the number of backup jobs
+that should not be merged into the Virtual Full (i.e. the number of backup
+jobs that should remain after the Virtual Full has completed. The default
+is zero, which reverts to a standard Virtual Full than consolidates all the
+backup jobs that it finds.
\subsubsection{Backups To Keep Directive}
The new {\bf BackupsToKeep} directive is specified in the Job Resource and
where the value (30 in the above figure and example) is the number of
backups to retain. When this directive is present during a Virtual Full
-(it is ignored for other Job types), it will look for a Full backup that
-has more subsequent backups than the value specified. In the above example
-the Job will simply terminate unless there is a Full back followed by at
-least 31 backups of either level Differential or Incremental.
+(it is ignored for other Job types), it will look for the most recent Full
+backup that has more subsequent backups than the value specified. In the
+above example the Job will simply terminate unless there is a Full back
+followed by at least 31 backups of either level Differential or
+Incremental.
\smallskip
Assuming that the last Full backup is followed by 32 Incremental backups, a
\subsection{TapeAlert Enhancements}
There are some significant enhancements to the TapeAlert feature of Bacula.
-Several directives are used slightly differently, and there is a minor
-compatibility problem with the old TapeAlert implementation.
+Several directives are used slightly differently, which unfortunately
+causes a compatibility problem with the old TapeAlert implementation.
+Consequently, if you are already using TapeAlert, you must modify your
+{\bf bacula-sd.conf} in order for Tape Alerts to work. See below
+for the details ...
\subsubsection{What is New}
First, you must define a \textbf{Alert Command} directive in the Device
}
\end{verbatim}
-The \textbf{Control Device} directive in the Storage Daemon's conf file was
-previously used only for the SAN Shared Storage feature. With Bacula
-version 8.8, it is also used for the TapeAlert command to permit Bacula to
-detect tape alerts on a specific device (normally only tape devices).
+In addition the \textbf{Control Device} directive in the Storage Daemon's
+conf file must be specified in each Device resource to permit Bacula to
+detect tape alerts on a specific devices (normally only tape devices).
Once the above mentioned two directives (Alert Command and Control Device)
are in place in each of your Device resources, Bacula will check for tape
At each of the above times, Bacula will call the new \textbf{tapealert}
script, which uses the \textbf{tapeinfo} program. The tapeinfo utility is
-part of the apt sg3-utils and rpm sg3\_utils packages. Then for each tape
-alert that Bacula finds for that drive, it will emit a Job message that is
-either INFO, WARNING, or FATAL depending on the designation in the Tape
-Alert published by the T10 Technical Committee on SCSI Storage Interfaces
-(www.t10.org). For the specification, please see:
-www.t10.org/ftp/t10/document.02/02-142r0.pdf
+part of the apt sg3-utils and rpm sg3\_utils packages that must be
+installed on your systems. Then after each alert that Bacula finds for
+that drive, Bacula will emit a Job message that is either INFO, WARNING, or
+FATAL depending on the designation in the Tape Alert published by the T10
+Technical Committee on SCSI Storage Interfaces (www.t10.org). For the
+specification, please see: www.t10.org/ftp/t10/document.02/02-142r0.pdf
\smallskip
As a somewhat extreme example, if tape alerts 3, 5, and 39 are set, you
Without the tape alert feature enabled, you would only get the first error
message above, which is the error return Bacula received when it gets the
-error. Notice also, that in this case the alert number 5 is a critical
-error, which causes two things to happen. First the tape drive is disabled,
-and second the Job is failed.
+error. Notice also, that in the above output the alert number 5 is a
+critical error, which causes two things to happen. First the tape drive is
+disabled, and second the Job is failed.
\smallskip
-If you attempt to run another Job using
-the Device that has been disabled, you will get a message similar to the
-following:
+If you attempt to run another Job using the Device that has been disabled,
+you will get a message similar to the following:
\begin{verbatim}
17-Nov 15:08 rufus-sd JobId 2: Warning:
\end{verbatim}
and the Job may be failed if no other drive can be found.
+
\smallskip
Once the problem with the tape drive has been corrected, you can
clear the tape alerts and re-enable the device with the Bacula bconsole
Note, when you enable the device, the list of prior tape alerts for that
drive will be discarded.
-
\smallskip
Since is is possible to miss tape alerts, Bacula maintains a temporary list
of the last 8 alerts, and each time Bacula calls the \textbf{tapealert}
\subsubsection{DirectoryACL}
\index[dir]{Directive!DirectoryACL}
-This directive is used to specify a list of directories that can be accessed by
-a restore session. Without this directive, the console cannot restore any
-file. Multiple directories names may be specified by separating them with
-commas, and/or by specifying multiple DirectoryACL directives. For example,
-the directive may be specified as:
+This directive is used to specify a list of directories that can be
+accessed by a restore session. Without this directive, a restricted
+console cannot restore any file. Multiple directories names may be
+specified by separating them with commas, and/or by specifying multiple
+DirectoryACL directives. For example, the directive may be specified as:
\footnotesize
\begin{verbatim}
\end{verbatim}
\normalsize
-With the above specification, the console can access the following directories:
+With the above specification, the console can access the following
+directories:
\begin{itemize}
\item \texttt{/etc/password}
\item \texttt{/etc/group}
\end{itemize}
If a directory starts with a Windows pattern (ex: c:/), Bacula will
-automatically ignore the case when checking directories.
+automatically ignore the case when checking directory names.
\subsection{New Bconsole ``list'' Command Behavior}
The bconsole \texttt{list} commands can now be used safely from a
restricted bconsole session. The information displayed will respect the
-ACL configured for the Console session. For example, if a Console has
-access to JobA, JobB and JobC, information about JobD will not appear in
-the \texttt{list jobs} command.
+ACL configured for the Console session. For example, if a restricted
+Console has access to JobA, JobB and JobC, information about JobD will not
+appear in the \texttt{list jobs} command.
\subsection{New Console ACL Directives}
\index[dir]{Directive!BackupClientACL}
It is now possible to configure a restricted Console to distinguish Backup
-and Restore jobs permissions. The \texttt{BackupClientACL} can restrict
+and Restore job permissions. The \texttt{BackupClientACL} can restrict
backup jobs on a specific set of clients, while the
\texttt{RestoreClientACL} can restrict restore jobs.
are many new features available (see the New Tray Monitor section below),
but probably the most important is the ability for the user to initiate a
backup of his own machine. The connection established by the FD to the
-Director for the backup can be used by the Director for the backup, thus
+Director for the backup will be used by the Director for the backup, thus
not only can clients (users) initiate backups, but a File Daemon that is
NATed (cannot be reached by the Director) can now be backed up without
-using advanced tunneling techniques.
+using advanced tunneling techniques providing that the File Daemon can
+connect to the Director.
\smallskip
The flow of information is shown in the picture below:
to end up with an average compression ratio that is very small.
In this case, Bacula reports {\bf None} in the Job report.
+\subsection{Deduplication Optimized Volumes}
+This version of Bacula includes a new alternative (or additional)
+volume format that optimizes the placement of files so
+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
+Deduplication Optimized Volumes whitepaper.
+
+\smallskip
+This feature is available if you have Bacula Community produced binaries
+and the Aligned Volumes plugin.
+
+\subsection{New Message Identification Format}
+We are starting to add unique message indentifiers to each message (other
+than debug and the Job report) that Bacula prints. At the current time
+only two files in the Storage Daemon have these message identifiers and
+over time with subsequent releases we will modify all messages.
+
+\smallskip
+The message identifier will be kept unique for each message and once
+assigned to a message it will not change even if the text of the message
+changes. This means that the message identifier will be the same no matter
+what language the text is displayed in, and more importantly, it will allow
+us to make listing of the messages with in some cases, additional
+explanation or instructions on how to correct the problem. All this will
+take several years since it is a lot of work and requires some new programs
+that are not yet written to manage these message identifiers.
+
+\smallskip
+The format of the message identifier is:
+
+\begin{verbatim}
+ [AAnnnn]
+\end{verbatim}
+where A is an upper case character and nnnn is a four digit number, where
+the first charcter indicates the software component (daemon); the second
+letter indicates the severity, and the number is unique for a given
+componet and severity.
+
+\smallskip
+For example:
+
+\begin{verbatim}
+ [SF0001]
+\end{verbatim}
+
+The first charcter representing the componend at the current time one of
+the following:
+
+\begin{verbatim}
+ S Storage daemon
+ D Director
+ F File daemon
+\end{verbatim}
+
+\smallskip
+The second character representing the severity or level can be:
+
+\begin{verbatim}
+ A Abort
+ F Fatal
+ E Erropr
+ W Warning
+ S Security
+ I Info
+ D Debug
+ O OK (i.e. operation completed normallly)
+\end{verbatim}
+
+So in the example above [SF0001] indicates it is a message id, because of
+the brackets and because it is at the beginning of the message, and that
+it was generated by the Storage daemon as a fatal error.
+\smallskip
+As mentioned above it will take some time to implement these message ids
+everywhere, and over time we may add more component letters and more
+severity levels as needed.
+
\chapter{New Features in 7.4.0}
This chapter presents the new features that have been added to
projects / bacula / docs / blobdiff