%%
+
%%
-\chapter{New Features}
+\chapter{New Features in 3.1.4 (Development Version}
+\label{NewFeaturesChapter}
+
+This chapter presents the new features that are currently under development
+in the 3.1.x versions to be released as Bacula version 3.2.0 sometime in
+late 2009 or early 2010.
+
+
+\section{Maximum concurent jobs for Devices}
+\label{sec:maximumconcurentjobdevice}
+
+{\bf Maximum Concurrent Jobs} is a new Device directive in the Storage
+Daemon configuration permits setting the maximum number of Jobs that can
+run concurrently on a specified Device. Using this directive, it is
+possible to have different Jobs using multiple drives, because when the
+Maximum Concurrent Jobs limit is reached, the Storage Daemon will start new
+Jobs on any other available compatible drive. This facilitates writing to
+multiple drives with multiple Jobs that all use the same Pool.
+
+\section{Restore from Multiple Storage Daemons}
+\index[general]{Restore}
+
+Previously, you were able to restore from multiple devices in a single Storage
+Daemon. Now, Bacula is able to restore from multiple Storage Daemons. For
+example, if your full backup runs on a Storage Daemon with an autochanger, and
+your incremental jobs use another Storage Daemon with lots of disks, Bacula
+will switch automatically from one Storage Daemon to an other within the same
+Restore job.
+
+You must upgrade your File Daemon to version 3.0.3 to use this feature.
+
+This project was funded by Bacula Systems with the help of Equiinet.
+
+\section{File Deduplication using Base Jobs}
+A base job is sort of like a Full save except that you will want the FileSet to
+contain only files that are unlikely to change in the future (i.e. a snapshot
+of most of your system after installing it). After the base job has been run,
+when you are doing a Full save, you specify one or more Base jobs to be used.
+All files that have been backed up in the Base job/jobs but not modified will
+then be excluded from the backup. During a restore, the Base jobs will be
+automatically pulled in where necessary.
+
+This is something none of the competition does, as far as we know (except
+perhaps BackupPC, which is a Perl program that saves to disk only). It is big
+win for the user, it makes Bacula stand out as offering a unique optimization
+that immediately saves time and money. Basically, imagine that you have 100
+nearly identical Windows or Linux machine containing the OS and user files.
+Now for the OS part, a Base job will be backed up once, and rather than making
+100 copies of the OS, there will be only one. If one or more of the systems
+have some files updated, no problem, they will be automatically restored.
+
+A new Job directive \texttt{Base=Jobx, Joby...} permits to specify the list of
+files that will be used during Full backup as base.
+
+\begin{verbatim}
+Job {
+ Name = BackupLinux
+ Level= Base
+ ...
+}
+
+Job {
+ Name = BackupZog4
+ Base = BackupZog4, BackupLinux
+ Accurate = yes
+ ...
+}
+\end{verbatim}
+
+In this example, the job \texttt{BackupZog4} will use the most recent version
+of all files contained in \texttt{BackupZog4} and \texttt{BackupLinux}
+jobs. Base jobs should have run with \texttt{level=Base} to be used.
+
+By default, Bacula will compare permissions bits, user and group fields,
+modification time, size and the checksum of the file to choose between the
+current backup and the BaseJob file list. You can change this behavior with the
+\texttt{BaseJob} FileSet option. This option works like the \texttt{verify=}
+one, that is described in the \ilink{FileSet}{FileSetResource} chapter.
+
+\begin{verbatim}
+FileSet {
+ Name = Full
+ Include = {
+ Options {
+ BaseJob = pmugcs5
+ Accurate = mcs5
+ Verify = pin5
+ }
+ File = /
+ }
+}
+\end{verbatim}
+
+
+This project was funded by Bacula Systems.
+
+
+\section{Accurate Fileset options}
+\label{sec:accuratefileset}
+
+In previous version, the accurate code was using file time creation and
+modification to determine if a file was modified or not. Now you can specify
+witch attribute to use (time, size, checksum, permission, owner, group,
+\dots).
+
+\begin{verbatim}
+FileSet {
+ Name = Full
+ Include = {
+ Options {
+ Accurate = mcs5
+ Verify = pin5
+ }
+ File = /
+ }
+}
+\end{verbatim}
+
+\begin{description}
+\item {\bf i}
+ compare the inodes
+
+\item {\bf p}
+ compare the permission bits
+
+\item {\bf n}
+ compare the number of links
+
+\item {\bf u}
+ compare the user id
+
+\item {\bf g}
+ compare the group id
+
+\item {\bf s}
+ compare the size
+
+\item {\bf a}
+ compare the access time
+
+\item {\bf m}
+ compare the modification time (st\_mtime)
+
+\item {\bf c}
+ compare the change time (st\_ctime)
+
+\item {\bf d}
+ report file size decreases
+
+\item {\bf 5}
+ compare the MD5 signature
+
+\item {\bf 1}
+ compare the SHA1 signature
+\end{description}
+
+\textbf{Important note:} If you decide to use checksum in Accurate jobs, the
+File Daemon will have to read all files even if they won't be saved. It
+increases the I/O load, but also the security. By default, Bacula will
+check modification/creation time and size.
+
+\section{Bvfs API}
+\label{sec:bvfs}
+
+To help developers in restore GUI interfaces, we have added new \textsl{dot
+ commands} that permit to browse the catalog in a very simple way.
+
+\begin{itemize}
+\item \texttt{.update [jobid=x,y,z]} This command is required to update the
+ Bvfs cache in the catalog. You need to run it before any access to the Bvfs
+ layer.
+\item \texttt{.lsdirs jobid=x,y,z path=/path | pathid=101} This command will
+ list all directories in the specified \texttt{path} or \texttt{pathid}. Using
+ \texttt{pathid} avoids problems with caracters encoding.
+\item \texttt{.lsfiles jobid=x,y,z path=/path | pathid=101} This command will
+ list all files in the specified \texttt{path} or \texttt{pathid}. Using
+ \texttt{pathid} avoids problems with caracters encoding.
+\end{itemize}
+
+You can use \texttt{limit=xxx} and \texttt{offset=yyy} to limit the amount of
+data that will be displayed.
+
+\begin{verbatim}
+* .update jobid=1,2
+* .update
+* .lsdir path=/ jobid=1,2
+\end{verbatim}
+
+\section{Testing your tape drive}
+\label{sec:btapespeed}
+
+To determine the best configuration of your tape drive, you can run the new
+\texttt{speed} command available in \texttt{btape}.
+
+This command can have the following arguments:
+\begin{itemize}
+\item[\texttt{file\_size=n}] Specify the Maximum File Size for this test
+ (between 1 and 5GB). This counter is in GB.
+\item[\texttt{nb\_file=n}] Specify the number of file to be written. The amount
+ of data should be greater than your memory ($file\_size*nb\_file$).
+\item[\texttt{skip\_zero}] This flag permits to skip tests with constant
+ data.
+\item[\texttt{skip\_random}] This flag permits to skip tests with random
+ data.
+\item[\texttt{skip\_raw}] This flag permits to skip tests with raw access.
+\item[\texttt{skip\_block}] This flag permits to skip tests with Bacula block
+ access.
+\end{itemize}
+
+\begin{verbatim}
+*speed file_size=3 skip_raw
+btape.c:1078 Test with zero data and bacula block structure.
+btape.c:956 Begin writing 3 files of 3.221 GB with blocks of 129024 bytes.
+++++++++++++++++++++++++++++++++++++++++++
+btape.c:604 Wrote 1 EOF to "Drive-0" (/dev/nst0)
+btape.c:406 Volume bytes=3.221 GB. Write rate = 44.128 MB/s
+...
+btape.c:383 Total Volume bytes=9.664 GB. Total Write rate = 43.531 MB/s
+
+btape.c:1090 Test with random data, should give the minimum throughput.
+btape.c:956 Begin writing 3 files of 3.221 GB with blocks of 129024 bytes.
++++++++++++++++++++++++++++++++++++++++++++
+btape.c:604 Wrote 1 EOF to "Drive-0" (/dev/nst0)
+btape.c:406 Volume bytes=3.221 GB. Write rate = 7.271 MB/s
++++++++++++++++++++++++++++++++++++++++++++
+...
+btape.c:383 Total Volume bytes=9.664 GB. Total Write rate = 7.365 MB/s
+
+\end{verbatim}
+
+When using compression, the random test will give your the minimum throughput
+of your drive . The test using constant string will give you the maximum speed
+of your hardware chain. (cpu, memory, scsi card, cable, drive, tape).
+
+You can change the block size in the Storage Daemon configuration file.
+
+\section{New {\bf Block Checksum} Device directive}
+You may now turn off the Block Checksum (CRC32) code
+that Bacula uses when writing blocks to a Volume. This is
+done by adding:
+
+\begin{verbatim}
+Block Checksum = no
+\end{verbatim}
+
+doing so can reduce the Storage daemon CPU speed slightly. It
+will also permit Bacula to read a Volume that has corrupted data.
+
+The default is {\bf yes} -- i.e. the checksum is computed on write
+and checked on read.
+
+We do not recommend to turn this off particularly on older tape
+drives or for disk Volumes where doing so may allow corrupted data
+to be undetected.
+
+\section{New Bat Features}
+
+\subsection{Media information view}
+
+By double-clicking on a volume (on the Media list, in the Autochanger content
+or in the Job information panel), you can access a detailed overview of your
+Volume. (cf \ref{fig:mediainfo}.)
+\begin{figure}[htbp]
+ \centering
+ \includegraphics[width=13cm]{\idir bat11.eps}
+ \caption{Media information}
+ \label{fig:mediainfo}
+\end{figure}
+
+\subsection{Job information view}
+
+By double-clicking on a Job record (on the Job run list or in the Media
+information panel), you can access a detailed overview of your Job. (cf
+\ref{fig:jobinfo}.)
+\begin{figure}[htbp]
+ \centering
+ \includegraphics[width=13cm]{\idir bat12.eps}
+ \caption{Job information}
+ \label{fig:jobinfo}
+\end{figure}
+
+\subsection{Autochanger content view}
+
+By double-clicking on a Storage record (on the Storage list panel), you can
+access a detailed overview of your Autochanger. (cf \ref{fig:jobinfo}.)
+\begin{figure}[htbp]
+ \centering
+ \includegraphics[width=13cm]{\idir bat13.eps}
+ \caption{Autochanger content}
+ \label{fig:achcontent}
+\end{figure}
+
+\chapter{New Features in Released Version 3.0.2}
+
+This chapter presents the new features added to the
+Released Bacula Version 3.0.2.
+
+\section{Full restore from a given JobId}
+\index[general]{Restore menu}
+
+This feature allows selecting a single JobId and having Bacula
+automatically select all the other jobs that comprise a full backup up to
+and including the selected JobId.
+
+Assume we start with the following jobs:
+\begin{verbatim}
++-------+--------------+---------------------+-------+----------+------------+
+| jobid | client | starttime | level | jobfiles | jobbytes |
++-------+--------------+---------------------+-------+----------+------------
+| 6 | localhost-fd | 2009-07-15 11:45:49 | I | 2 | 0 |
+| 5 | localhost-fd | 2009-07-15 11:45:45 | I | 15 | 44143 |
+| 3 | localhost-fd | 2009-07-15 11:45:38 | I | 1 | 10 |
+| 1 | localhost-fd | 2009-07-15 11:45:30 | F | 1527 | 44143073 |
++-------+--------------+---------------------+-------+----------+------------+
+\end{verbatim}
+
+Below is an example of this new feature (which is number 12 in the
+menu).
+
+\begin{verbatim}
+* restore
+To select the JobIds, you have the following choices:
+ 1: List last 20 Jobs run
+ 2: List Jobs where a given File is saved
+...
+ 12: Select full restore to a specified JobId
+ 13: Cancel
+
+Select item: (1-13): 12
+Enter JobId to restore: 5
+You have selected the following JobIds: 1,3,5
+
+Building directory tree for JobId(s) 1,3,5 ... +++++++++++++++++++
+1,444 files inserted into the tree.
+\end{verbatim}
+
+This project was funded by Bacula Systems.
+
+\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 establish connections. 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 on the OS
+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 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 (in the autochanger).
+\end{verbatim}
+
+This should help speed up large restores by minimizing the time spent
+waiting for the operator to discover that he must 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 the command line by using
+\texttt{accurate=yes\vb{}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}
what files have been deleted and will miss any file with an old time that may
have been restored to or moved onto the client filesystem.
-\subsection{Accurate = \lt{}yes|no\gt{}}
-If the {\bf Accurate = \lt{}yes|no\gt{}} directive is enabled (default no) in
+\subsection{Accurate = \lt{}yes\vb{}no\gt{}}
+If the {\bf Accurate = \lt{}yes\vb{}no\gt{}} directive is enabled (default no) in
the Job resource, the job will be run as an Accurate Job. For a {\bf Full}
backup, there is no difference, but for {\bf Differential} and {\bf
Incremental} backups, the Director will send a list of all previous files
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
will probably not work correctly.
+
+This project was funded by Bacula Systems.
The Copy Job runs without using the File daemon by copying the data from the
old backup Volume to a different Volume in a different Pool. See the Migration
documentation for additional details. For copy Jobs there is a new selection
-criterium named PoolUncopiedJobs which copies all jobs from a pool to an other
-pool which were not copied before. Next to that the client, volume, job or sql
-query are possible ways of selecting jobs which should be copied. Selection
-types like smallestvolume, oldestvolume, pooloccupancy and pooltime are
-probably more suited for migration jobs only. But we could imagine some people
-have a valid use for those kind of copy jobs too.
-
-If bacula founds a copy when a job record is purged (deleted) from the catalog,
-it will promote the copy as \textsl{real} backup and will make it available for
-automatic restore. If more than one copy is available, it will promote the copy
-with the smallest jobid.
-
-A nice solution which can be build with the new copy jobs is what is
-called the disk-to-disk-to-tape backup (DTDTT). A sample config could
-look somethings like the one below:
+directive named {\bf PoolUncopiedJobs} which selects all Jobs that were
+not already copied to another Pool.
+
+As with Migration, the Client, Volume, Job, or SQL query, are
+other possible ways of selecting the Jobs to be copied. Selection
+types like SmallestVolume, OldestVolume, PoolOccupancy and PoolTime also
+work, but are probably more suited for Migration Jobs.
+
+If Bacula finds a Copy of a job record that is purged (deleted) from the catalog,
+it will promote the Copy to a \textsl{real} backup job and will make it available for
+automatic restore. If more than one Copy is available, it will promote the copy
+with the smallest JobId.
+
+A nice solution which can be built with the new Copy feature is often
+called disk-to-disk-to-tape backup (DTDTT). A sample config could
+look something like the one below:
\begin{verbatim}
Pool {
\end{verbatim}
\section{ACL Updates}
+\index[general]{ACL Updates}
The whole ACL code had been overhauled and in this version each platforms has
different streams for each type of acl available on such an platform. As ACLs
between platforms tend to be not that portable (most implement POSIX acls but
recognize them will give you a warning.
\section{Extended Attributes}
+\index[general]{Extended Attributes}
Something that was on the project list for some time is now implemented for
platforms that support a similar kind of interface. Its the support for backup
and restore of so called extended attributes. As extended attributes are so
platform specific these attributes are saved in seperate streams for each
-platform. Restores can only be performed on the same platform the backup was
-done. There is support for all types of extended attributes, but restoring from
-one type of filesystem onto an other type of filesystem on the same platform
-may lead to supprises. As extended attributes can contain any type of data they
-are stored as a series of so called value-pairs. This data must be seen as
-mostly binary and is stored as such. As security labels from selinux are also
-extended attributes this option also stores those labels and no specific code
-is enabled for handling selinux security labels.
+platform. Restores of the extended attributes can only be performed on the
+same platform the backup was done. There is support for all types of extended
+attributes, but restoring from one type of filesystem onto an other type of
+filesystem on the same platform may lead to supprises. As extended attributes
+can contain any type of data they are stored as a series of so called
+value-pairs. This data must be seen as mostly binary and is stored as such.
+As security labels from selinux are also extended attributes this option also
+stores those labels and no specific code is enabled for handling selinux
+security labels.
Currently the following platforms support extended attributes:
\begin{itemize}
\end{verbatim}
\section{Shared objects}
+\index[general]{Shared objects}
A default build of Bacula will now create the libraries as shared objects
(.so) rather than static libraries as was previously the case.
The shared libraries are built using {\bf libtool} so it should be quite
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}
\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
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}.
\section{Catalog Format}
-Bacula 3.0 comes with some changes on the catalog format. The upgrade
-operation will convert an essential field of the File table that permits to
-handle more than 4 billion objects over the time, and this operation will take
-TIME and will likely DOUBLE THE SIZE of your catalog during the conversion.
-You won't be able to run jobs during this period. For example, a 3 million
-files catalog will take 2 minutes to upgrade on a normal machine. Please don't
-forget to make a valid backup of your database before executing the upgrade
-script.
+\index[general]{Catalog Format}
+Bacula 3.0 comes with some changes to the catalog format. The upgrade
+operation will convert the FileId field of the File table from 32 bits (max 4
+billion table entries) to 64 bits (very large number of items). The
+conversion process can take a bit of time and will likely DOUBLE THE SIZE of
+your catalog during the conversion. Also you won't be able to run jobs during
+this conversion period. For example, a 3 million file catalog will take 2
+minutes to upgrade on a normal machine. Please don't forget to make a valid
+backup of your database before executing the upgrade script. See the
+ReleaseNotes for additional details.
+
+\section{64 bit Windows Client}
+\index[general]{Win64 Client}
+Unfortunately, Microsoft's implementation of Volume Shadown Copy (VSS) on
+their 64 bit OS versions is not compatible with a 32 bit Bacula Client.
+As a consequence, we are also releasing a 64 bit version of the Bacula
+Windows Client (win64bacula-3.0.0.exe) that does work with VSS.
+These binaries should only be installed on 64 bit Windows operating systems.
+What is important is not your hardware but whether or not you have
+a 64 bit version of the Windows OS.
+
+Compared to the Win32 Bacula Client, the 64 bit release contains a few differences:
+\begin{enumerate}
+\item Before installing the Win64 Bacula Client, you must totally
+ deinstall any prior 2.4.x Client installation using the
+ Bacula deinstallation (see the menu item). You may want
+ to save your .conf files first.
+\item Only the Client (File daemon) is ported to Win64, the Director
+ and the Storage daemon are not in the 64 bit Windows installer.
+\item bwx-console is not yet ported.
+\item bconsole is ported but it has not been tested.
+\item The documentation is not included in the installer.
+\item Due to Vista security restrictions imposed on a default installation
+ of Vista, before upgrading the Client, you must manually stop
+ any prior version of Bacula from running, otherwise the install
+ will fail.
+\item Due to Vista security restrictions imposed on a default installation
+ of Vista, attempting to edit the conf files via the menu items
+ will fail. You must directly edit the files with appropriate
+ permissions. Generally double clicking on the appropriate .conf
+ file will work providing you have sufficient permissions.
+\item All Bacula files are now installed in
+ {\bf C:/Program Files/Bacula} except the main menu items,
+ which are installed as before. This vastly simplifies the installation.
+\item If you are running on a foreign language version of Windows, most
+ likely {\bf C:/Program Files} does not exist, so you should use the
+ Custom installation and enter an appropriate location to install
+ the files.
+\item The 3.0.0 Win32 Client continues to install files in the locations used
+ by prior versions. For the next version we will convert it to use
+ the same installation conventions as the Win64 version.
+\end{enumerate}
+
+This project was funded by Bacula Systems.
+
\section{Duplicate Job Control}
\index[general]{Duplicate Jobs}
They are:
-\subsection{Allow Duplicate Jobs = \lt{}yes|no\gt{}}
+\subsection{Allow Duplicate Jobs = \lt{}yes\vb{}no\gt{}}
+\index[general]{Allow Duplicate Jobs}
If this directive is enabled duplicate jobs will be run. If
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{}}
+\subsection{Allow Higher Duplicates = \lt{}yes\vb{}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{}}
- If this directive is set to {\bf yes} (default) any job that is
+\subsection{Cancel Queued Duplicates = \lt{}yes\vb{}no\gt{}}
+\index[general]{Cancel Queued Duplicates}
+ 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{}}
- If this directive is set to {\bf yes} any job that is already running
+\subsection{Cancel Running Duplicates = \lt{}yes\vb{}no\gt{}}
+\index[general]{Cancel Running Duplicates}
+ 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}.
Client for the File daemon, and Storage for the Storage daemon).
When {\bf TLS Authenticate} is enabled, after doing the CRAM-MD5
-authentication, Bacula will do the normal TLS authentication, then TLS
-encryption will be turned off.
+authentication, Bacula will also do TLS authentication, then TLS
+encryption will be turned off, and the rest of the communication between
+the two Bacula daemons will be done without encryption.
-If you want to encrypt communications data, do not turn on {\bf TLS
-Authenticate}.
+If you want to encrypt communications data, use the normal TLS directives
+but do not turn on {\bf TLS Authenticate}.
\section{bextract non-portable Win32 data}
\index[general]{bextract handles Win32 non-portable data}
{\bf Incremental}, it will be automatically
upgraded to a {\bf Differential} backup.
-\section{Honor No Dump Flag = \lt{}yes|no\gt{}}
+\section{Honor No Dump Flag = \lt{}yes\vb{}no\gt{}}
\index[general]{MaxDiffInterval}
On FreeBSD systems, each file has a {\bf no dump flag} that can be set
by the user, and when it is set it is an indication to backup programs
obey this flag. The new directive is:
\begin{verbatim}
- Honor No Dump Flag = yes|no
+ Honor No Dump Flag = yes\vb{}no
\end{verbatim}
The default value is {\bf no}.
-\section{Exclude Dirs Containing = \lt{}filename-string\gt{}}
+\section{Exclude Dir Containing = \lt{}filename-string\gt{}}
\index[general]{IgnoreDir}
-The {\bf ExcludeDirsContaining = \lt{}filename\gt{}} is a new directive that
+The {\bf ExcludeDirContaining = \lt{}filename\gt{}} is a new directive that
can be added to the Include section of the FileSet resource. If the specified
filename ({\bf filename-string}) is found on the Client in any directory to be
backed up, the whole directory will be ignored (not backed up). For example:
signature = MD5
}
File = /home
- Exclude Dirs Containing = .excludeme
+ Exclude Dir Containing = .excludeme
}
}
\end{verbatim}
files, directories, etc).
-
\section{Bacula Plugins}
\index[general]{Plugin}
Support for shared object plugins has been implemented in the Linux, Unix
Storage daemon.
\subsection{Plugin Directory}
+\index[general]{Plugin Directory}
Each daemon (DIR, FD, SD) has a new {\bf Plugin Directory} directive that may
be added to the daemon definition resource. The directory takes a quoted
string argument, which is the name of the directory in which the daemon can
can share the same plugin directory.
\subsection{Plugin Options}
+\index[general]{Plugin Options}
The {\bf Plugin Options} directive takes a quoted string
arguement (after the equal sign) and may be specified in the
Job resource. The options specified will be passed to all plugins
the plugin (i.e. not fully implemented).
\subsection{Plugin Options ACL}
+\index[general]{Plugin Options ACL}
The {\bf Plugin Options ACL} directive may be specified in the
Director's Console resource. It functions as all the other ACL commands
do by permitting users running restricted consoles to specify a
the Plugin Options.
\subsection{Plugin = \lt{}plugin-command-string\gt{}}
+\index[general]{Plugin}
The {\bf Plugin} directive is specified in the Include section of
a FileSet resource where you put your {\bf File = xxx} directives.
For example:
plugin.
\section{The bpipe Plugin}
+\index[general]{The bpipe Plugin}
The {\bf bpipe} plugin is provided in the directory src/plugins/fd/bpipe-fd.c of
the Bacula source distribution. When the plugin is compiled and linking into
the resulting dynamic shared object (DSO), it will have the name {\bf bpipe-fd.so}.
on the program called.
\section{Microsoft Exchange Server 2003/2007 Plugin}
+\index[general]{Microsoft Exchange Server 2003/2007 Plugin}
+\subsection{Background}
+The Exchange plugin was made possible by a funded development project
+between Equiinet Ltd -- www.equiinet.com (many thanks) and Bacula Systems.
+The code for the plugin was written by James Harper, and the Bacula core
+code by Kern Sibbald. All the code for this funded development has become
+part of the Bacula project. Thanks to everyone who made it happen.
\subsection{Concepts}
Although it is possible to backup Exchange using Bacula VSS the Exchange
\subsection{Restoring}
-
The restore operation is much the same as a normal Bacula restore, with
the following provisos:
\end{itemize}
\subsection{Restoring to the Recovery Storage Group}
-
The concept of the Recovery Storage Group is well documented by
Microsoft
\elink{http://support.microsoft.com/kb/824126}{http://support.microsoft.com/kb/824126},
never makes it to the backup medium (eg because of spooling) then the
logs will still be truncated, but they will also not have been backed
up. A solution to this is being worked on. You will have to schedule a
-new Full backup to ensure that your backup is usable.
+new Full backup to ensure that your next backups will be usable.
The "Enable Circular Logging" option cannot be enabled or the plugin
will fail.
\section{libdbi Framework}
+\index[general]{libdbi Framework}
As a general guideline, Bacula has support for a few catalog database drivers
(MySQL, PostgreSQL, SQLite)
coded natively by the Bacula team. With the libdbi implementation, which is a
from your OS distribution.
\section{Console Command Additions and Enhancements}
+\index[general]{Console Additions}
\subsection{Display Autochanger Content}
\index[general]{StatusSlots}
catalog.
\subsection{list joblog job=xxx or jobid=nnn}
+\index[general]{list joblog}
A new list command has been added that allows you to list the contents
of the Job Log stored in the catalog for either a Job Name (fully qualified)
or for a particular JobId. The {\bf llist} command will include a line with
In your Director's {\bf Messages} resource.
\subsection{Use separator for multiple commands}
- When using bconsole with readline, you can set the command separator to one
+\index[general]{Command Separator}
+ When using bconsole with readline, you can set the command separator with
+ \textbf{@separator} command to one
of those characters to write commands who require multiple input in one line.
\begin{verbatim}
!$%&'()*+,-/:;<>?[]^`{|}~
\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
+CD based on the kernel on your system. The problem was that
+every distribution has a different boot procedure and different
+scripts, and worse yet, the boot procedures and scripts change
+from one distribution to another. This meant that maintaining
+(keeping up with the changes) the rescue CD was too much work.
+
+To replace it, a new bare metal recovery USB boot stick has been developed
+by Bacula Systems. This technology involves remastering a Ubuntu LiveCD to
+boot from a USB key.
+
+Advantages:
+\begin{enumerate}
+\item Recovery can be done from within graphical environment.
+\item Recovery can be done in a shell.
+\item Ubuntu boots on a large number of Linux systems.
+\item The process of updating the system and adding new
+ packages is not too difficult.
+\item The USB key can easily be upgraded to newer Ubuntu versions.
+\item The USB key has writable partitions for modifications to
+ the OS and for modification to your home directory.
+\item You can add new files/directories to the USB key very easily.
+\item You can save the environment from multiple machines on
+ one USB key.
+\item Bacula Systems is funding its ongoing development.
+\end{enumerate}
+
+The disadvantages are:
+\begin{enumerate}
+\item The USB key is usable but currently under development.
+\item Not everyone may be familiar with Ubuntu (no worse
+ than using Knoppix)
+\item Some older OSes cannot be booted from USB. This can
+ be resolved by first booting a Ubuntu LiveCD then plugging
+ in the USB key.
+\item Currently the documentation is sketchy and not yet added
+ to the main manual. See below ...
+\end{enumerate}
+
+The documentation and the code can be found in the {\bf rescue} package
+in the directory {\bf linux/usb}.
+
\section{Miscellaneous}
\index[general]{Misc New Features}
-\subsection{Allow Mixed Priority = \lt{}yes|no\gt{}}
+\subsection{Allow Mixed Priority = \lt{}yes\vb{}no\gt{}}
+\index[general]{Allow Mixed Priority}
This directive is only implemented in version 2.5 and later. When
set to {\bf yes} (default {\bf no}), this job may run even if lower
priority jobs are already running. This means a high priority job
be run until the priority 5 job has finished.
\subsection{Bootstrap File Directive -- FileRegex}
+\index[general]{Bootstrap File Directive}
{\bf FileRegex} is a new command that can be added to the bootstrap
(.bsr) file. The value is a regular expression. When specified, only
matching filenames will be restored.
There were no files inserted into the tree, so file selection
is not possible.Most likely your retention policy pruned the files
- Do you want to restore all the files? (yes|no): no
+ Do you want to restore all the files? (yes\vb{}no): no
Regexp matching files to restore? (empty to abort): /tmp/regress/(bin|tests)/
Bootstrap records written to /tmp/regress/working/zog4-dir.restore.1.bsr
\subsection{Virtual Tape Emulation}
+\index[general]{Virtual Tape Emulation}
We now have a Virtual Tape emulator that allows us to run though 99.9\% of
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}
Bat (the Bacula Administration Tool) GUI program has been significantly
enhanced and stabilized. In particular, there are new table based status
commands; it can now be easily localized using Qt4 Linguist.
work.
\subsection{RunScript Enhancements}
+\index[general]{RunScript Enhancements}
The {\bf RunScript} resource has been enhanced to permit multiple
commands per RunScript. Simply specify multiple {\bf Command} directives
in your RunScript.
may remove it before the final release.
\subsection{Status Enhancements}
+\index[general]{Status Enhancements}
The bconsole {\bf status dir} output has been enhanced to indicate
Storage daemon job spooling and despooling activity.
\subsection{Connect Timeout}
+\index[general]{Connect Timeout}
The default connect timeout to the File
daemon has been set to 3 minutes. Previously it was 30 minutes.
\subsection{ftruncate for NFS Volumes}
+\index[general]{ftruncate for NFS Volumes}
If you write to a Volume mounted by NFS (say on a local file server),
in previous Bacula versions, when the Volume was recycled, it was not
properly truncated because NFS does not implement ftruncate (file
recent release of Bacula from the Ubuntu repositories.
\subsection{Recycle Pool = \lt{}pool-name\gt{}}
+\index[general]{Recycle Pool}
The new \textbf{RecyclePool} directive defines to which pool the Volume will
be placed (moved) when it is recycled. Without this directive, a Volume will
remain in the same pool when it is recycled. With this directive, it can be
be recycled back into the Scratch pool.
\subsection{FD Version}
+\index[general]{FD Version}
The File daemon to Director protocol now includes a version
number, which although there is no visible change for users,
will help us in future versions automatically determine
if a File daemon is not compatible.
\subsection{Max Run Sched Time = \lt{}time-period-in-seconds\gt{}}
+\index[general]{Max Run Sched Time}
The time specifies the maximum allowed time that a job may run, counted from
when the job was scheduled. This can be useful to prevent jobs from running
during working hours. We can see it like \texttt{Max Start Delay + Max Run
Time}.
\subsection{Max Wait Time = \lt{}time-period-in-seconds\gt{}}
-
+\index[general]{Max Wait Time}
Previous \textbf{MaxWaitTime} directives aren't working as expected, instead
of checking the maximum allowed time that a job may block for a resource,
those directives worked like \textbf{MaxRunTime}. Some users are reporting to
directives are now deprecated.
\subsection{Incremental|Differential Max Wait Time = \lt{}time-period-in-seconds\gt{}}
+\index[general]{Incremental Max Wait Time}
+\index[general]{Differential Max Wait Time}
+
These directives have been deprecated in favor of
\texttt{Incremental|Differential Max Run Time}.
\subsection{Max Run Time directives}
+\index[general]{Max Run Time directives}
Using \textbf{Full/Diff/Incr Max Run Time}, it's now possible to specify the
maximum allowed time that a job can run depending on the level.
\includegraphics{\idir different_time.eps}
\subsection{Statistics Enhancements}
+\index[general]{Statistics Enhancements}
If you (or probably your boss) want to have statistics on your backups to
provide some \textit{Service Level Agreement} indicators, you could use a few
SQL queries on the Job table to report how many:
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
\end{verbatim}
\subsection{ScratchPool = \lt{}pool-resource-name\gt{}}
+\index[general]{ScratchPool}
This directive permits to specify a specific \textsl{Scratch} pool for the
current pool. This is useful when using multiple storage sharing the same
mediatype or when you want to dedicate volumes to a particular set of pool.
\subsection{Enhanced Attribute Despooling}
+\index[general]{Attribute Despooling}
If the storage daemon and the Director are on the same machine, the spool file
that contains attributes is read directly by the Director instead of being
transmitted across the network. That should reduce load and speedup insertion.
\subsection{SpoolSize = \lt{}size-specification-in-bytes\gt{}}
+\index[general]{SpoolSize}
A new Job directive permits to specify the spool size per job. This is used
in advanced job tunning. {\bf SpoolSize={\it bytes}}
\subsection{MaxConsoleConnections = \lt{}number\gt{}}
+\index[general]{MaxConsoleConnections}
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
temporary indexes to speed up orphaned Path and Filename elimination.
You can now specify the database connection port in the command line.
-\section{Building Bacula Plugins}
-There is currently one sample program {\bf example-plugin-fd.c} and
-one working plugin {\bf bpipe-fd.c} that can be found in the Bacula
-{\bf src/plugins/fd} directory. Both are built with the following:
-
-\begin{verbatim}
- cd <bacula-source>
- ./configure <your-options>
- make
- ...
- cd src/plugins/fd
- make
- make test
-\end{verbatim}
-
-After building Bacula and changing into the src/plugins/fd directory,
-the {\bf make} command will build the {\bf bpipe-fd.so} plugin, which
-is a very useful and working program.
-
-The {\bf make test} command will build the {\bf example-plugin-fd.so}
-plugin and a binary named {\bf main}, which is build from the source
-code located in {\bf src/filed/fd\_plugins.c}.
-
-If you execute {\bf ./main}, it will load and run the example-plugin-fd
-plugin simulating a small number of the calling sequences that Bacula uses
-in calling a real plugin. This allows you to do initial testing of
-your plugin prior to trying it with Bacula.
-
-You can get a good idea of how to write your own plugin by first
-studying the example-plugin-fd, and actually running it. Then
-it can also be instructive to read the bpipe-fd.c code as it is
-a real plugin, which is still rather simple and small.
-
-When actually writing your own plugin, you may use the example-plugin-fd.c
-code as a template for your code.
-
-
+\subsection{{-}{-}docdir configure option}
+\index[general]{{-}{-}docdir configure option}
+You can use {-}{-}docdir= on the ./configure command to
+specify the directory where you want Bacula to install the
+LICENSE, ReleaseNotes, ChangeLog, ... files. The default is
+{\bf /usr/share/doc/bacula}.
+
+\subsection{{-}{-}htmldir configure option}
+\index[general]{{-}{-}htmldir configure option}
+You can use {-}{-}htmldir= on the ./configure command to
+specify the directory where you want Bacula to install the bat html help
+files. The default is {\bf /usr/share/doc/bacula/html}
+
+\subsection{{-}{-}with-plugindir configure option}
+\index[general]{{-}{-}plugindir configure option}
+You can use {-}{-}plugindir= on the ./configure command to
+specify the directory where you want Bacula to install
+the plugins (currently only bpipe-fd). The default is
+/usr/lib.
projects / bacula / docs / blobdiff