-\chapter{New Features in 5.0.1}
+\chapter{New Features in 5.2.x}
+This chapter presents the new features that have been added to the next
+Community version of \mbacula{} that is not yet released.
+
+\section{New Features in 5.2.2}
+This chapter presents the new features that have been added to the current
+Community version of \mbacula{} that is now released.
+
+\subsection{Additions to RunScript variables}
+You can have access to Director name using \%D in your runscript
+command.
+
+\begin{lstlisting}
+RunAfterJob = "/bin/echo Director=%D
+\end{lstlisting}
+
+\section{New Features in 5.2.1}
+This chapter presents the new features were added in the
+Community release version 5.2.1.
+
+There are additional features (plugins) available in the Enterprise version
+that are described in another chapter. A subscription to Bacula Systems
+is required for the Enterprise version.
+
+\subsection{LZO Compression}
+
+LZO compression has been to the File daemon. From the user's point of view,
+it works like the GZIP compression (just replace {\bf compression=GZIP} with
+{\bf compression=LZO}).
+
+For example:
+\begin{lstlisting}
+Include {
+ Options { compression=LZO }
+ File = /home
+ File = /data
+}
+\end{lstlisting}
+
+LZO provides a much faster compression and decompression speed but lower
+compression ratio than GZIP. It is a good option when you backup to disk. For
+tape, the hardware compression is almost always a better option.
+
+LZO is a good alternative for GZIP1 when you don't want to slow down your
+backup. With a modern CPU it should be able to run almost as fast as:
+
+\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{bsysitemize}
+
+Note, \mbacula{} uses compression level LZO1X-1.
+
+\medskip
+The code for this feature was contributed by Laurent Papier.
+
+\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
+the tray monitor menu.
+
+%\begin{figure}[htbp]
+% \centering
+% \includegraphics[width=10cm]{\idir tray-monitor}
+\bsysimageH{tray-monitor}{New tray monitor}{figcom:traymonitor}
+% \label{figcom:traymonitor}
+% \caption{New tray monitor}
+%\end{figure}
+
+%% \begin{figure}[htbp]
+%% \centering
+%% \includegraphics[width=10cm]{\idir tray-monitor1}
+%% \label{figcom:traymonitor1}
+%% \caption{Run a Job through the new tray monitor}
+%% \end{figure}
+\bsysimageH{tray-monitor1}{Run a Job through the new tray monitor}{figcom:traymonitor1}
+
+To be able to run a job from the tray monitor, you need to
+allow specific commands in the Director monitor console:
+\begin{lstlisting}
+Console {
+ Name = win2003-mon
+ Password = "xxx"
+ CommandACL = status, .clients, .jobs, .pools, .storage, .filesets, .messages, run
+ ClientACL = *all* # you can restrict to a specific host
+ CatalogACL = *all*
+ JobACL = *all*
+ StorageACL = *all*
+ ScheduleACL = *all*
+ PoolACL = *all*
+ FileSetACL = *all*
+ WhereACL = *all*
+}
+\end{lstlisting}
+
+\medskip
+This project was funded by Bacula Systems and is available with Bacula
+the Enterprise Edition and the Community Edition.
+
+\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
+the Job that was migrated during a migration will be purged at
+the end of the migration job.
+
+For example:
+\begin{lstlisting}
+Job {
+ Name = "migrate-job"
+ Type = Migrate
+ Level = Full
+ Client = localhost-fd
+ FileSet = "Full Set"
+ Messages = Standard
+ Storage = DiskChanger
+ Pool = Default
+ Selection Type = Job
+ Selection Pattern = ".*Save"
+...
+ Purge Migration Job = yes
+}
+\end{lstlisting}
+
+\medskip
+
+This project was submitted by Dunlap Blake; testing and documentation was funded
+by Bacula Systems.
+
+\subsection{Changes in Bvfs (Bacula Virtual FileSystem)}
+
+Bat has now a bRestore panel that uses Bvfs to display files and
+directories.
+
+%% \begin{figure}[htbp]
+%% \centering
+%% \includegraphics[width=12cm]{\idir
+%% \label{figcom:batbrestore}
+%% \caption{Bat Brestore Panel}
+%% \end{figure}
+\bsysimageH{bat-brestore}{Bat Brestore Panel}{figcom:batbrestore}
+
+the Bvfs module works correctly with BaseJobs, Copy and Migration jobs.
+
+\medskip
+This project was funded by Bacula Systems.
+
+\subsubsection*{General notes}
+
+\begin{bsysitemize}
+\item All fields are separated by a tab
+\item You can specify \texttt{limit=} and \texttt{offset=} to list smoothly
+ records in very big directories
+\item All operations (except cache creation) are designed to run instantly
+\item At this time, Bvfs works faster on PostgreSQL than MySQL catalog. If you
+ can contribute new faster SQL queries we will be happy, else don't complain
+ about speed.
+\item The cache creation is dependent of the number of directories. As Bvfs
+ shares information across jobs, the first creation can be slow
+\item All fields are separated by a tab
+\item Due to potential encoding problem, it's advised to always use pathid in
+ queries.
+\end{bsysitemize}
+
+\subsubsection*{Get dependent jobs from a given JobId}
+
+Bvfs allows you to query the catalog against any combination of jobs. You
+can combine all Jobs and all FileSet for a Client in a single session.
+
+To get all JobId needed to restore a particular job, you can use the
+\texttt{.bvfs\_get\_jobids} command.
+
+\begin{lstlisting}
+.bvfs_get_jobids jobid=num [all]
+\end{lstlisting}
+
+\begin{lstlisting}
+.bvfs_get_jobids jobid=10
+1,2,5,10
+.bvfs_get_jobids jobid=10 all
+1,2,3,5,10
+\end{lstlisting}
+
+In this example, a normal restore will need to use JobIds 1,2,5,10 to
+compute a complete restore of the system.
+
+With the \texttt{all} option, the Director will use all defined FileSet for
+this client.
+
+\subsubsection*{Generating Bvfs cache}
+
+The \texttt{.bvfs\_update} command computes the directory cache for jobs
+specified in argument, or for all jobs if unspecified.
+
+\begin{lstlisting}
+.bvfs_update [jobid=numlist]
+\end{lstlisting}
+
+Example:
+\begin{lstlisting}
+.bvfs_update jobid=1,2,3
+\end{lstlisting}
+
+You can run the cache update process in a RunScript after the catalog backup.
+
+\subsubsection*{Get all versions of a specific file}
+
+Bvfs allows you to find all versions of a specific file for a given Client with
+the \texttt{.bvfs\_version} command. To avoid problems with encoding, this
+function uses only PathId and FilenameId. The jobid argument is mandatory but
+unused.
+
+\begin{lstlisting}
+.bvfs_versions client=filedaemon pathid=num filenameid=num jobid=1
+PathId FilenameId FileId JobId LStat Md5 VolName Inchanger
+PathId FilenameId FileId JobId LStat Md5 VolName Inchanger
+...
+\end{lstlisting}
+
+Example:
+
+\begin{lstlisting}
+.bvfs_versions client=localhost-fd pathid=1 fnid=47 jobid=1
+1 47 52 12 gD HRid IGk D Po Po A P BAA I A /uPgWaxMgKZlnMti7LChyA Vol1 1
+\end{lstlisting}
+
+\subsubsection*{List directories}
+
+Bvfs allows you to list directories in a specific path.
+\begin{lstlisting}
+.bvfs_lsdirs pathid=num path=/apath jobid=numlist limit=num offset=num
+PathId FilenameId FileId JobId LStat Path
+PathId FilenameId FileId JobId LStat Path
+PathId FilenameId FileId JobId LStat Path
+...
+\end{lstlisting}
+
+You need to \texttt{pathid} or \texttt{path}. Using \texttt{path=""} will list
+``/'' on Unix and all drives on Windows. If FilenameId is 0, the record
+listed is a directory.
+
+\begin{lstlisting}
+.bvfs_lsdirs pathid=4 jobid=1,11,12
+4 0 0 0 A A A A A A A A A A A A A A .
+5 0 0 0 A A A A A A A A A A A A A A ..
+3 0 0 0 A A A A A A A A A A A A A A regress/
+\end{lstlisting}
+
+In this example, to list directories present in \texttt{regress/}, you can use
+\begin{lstlisting}
+.bvfs_lsdirs pathid=3 jobid=1,11,12
+3 0 0 0 A A A A A A A A A A A A A A .
+4 0 0 0 A A A A A A A A A A A A A A ..
+2 0 0 0 A A A A A A A A A A A A A A tmp/
+\end{lstlisting}
+
+\subsubsection*{List files}
+
+Bvfs allows you to list files in a specific path.
+\begin{lstlisting}
+.bvfs_lsfiles pathid=num path=/apath jobid=numlist limit=num offset=num
+PathId FilenameId FileId JobId LStat Path
+PathId FilenameId FileId JobId LStat Path
+PathId FilenameId FileId JobId LStat Path
+...
+\end{lstlisting}
+
+You need to \texttt{pathid} or \texttt{path}. Using \texttt{path=""} will list
+``/'' on Unix and all drives on Windows. If FilenameId is 0, the record listed
+is a directory.
+
+\begin{lstlisting}
+.bvfs_lsfiles pathid=4 jobid=1,11,12
+4 0 0 0 A A A A A A A A A A A A A A .
+5 0 0 0 A A A A A A A A A A A A A A ..
+1 0 0 0 A A A A A A A A A A A A A A regress/
+\end{lstlisting}
+
+In this example, to list files present in \texttt{regress/}, you can use
+\begin{lstlisting}
+.bvfs_lsfiles pathid=1 jobid=1,11,12
+1 47 52 12 gD HRid IGk BAA I BMqcPH BMqcPE BMqe+t A titi
+1 49 53 12 gD HRid IGk BAA I BMqe/K BMqcPE BMqe+t B toto
+1 48 54 12 gD HRie IGk BAA I BMqcPH BMqcPE BMqe+3 A tutu
+1 45 55 12 gD HRid IGk BAA I BMqe/K BMqcPE BMqe+t B ficheriro1.txt
+1 46 56 12 gD HRie IGk BAA I BMqe/K BMqcPE BMqe+3 D ficheriro2.txt
+\end{lstlisting}
+
+\subsubsection*{Restore set of files}
+
+Bvfs allows you to create a SQL table that contains files that you want to
+restore. This table can be provided to a restore command with the file option.
+
+\begin{lstlisting}
+.bvfs_restore fileid=numlist dirid=numlist hardlink=numlist path=b2num
+OK
+restore file=?b2num ...
+\end{lstlisting}
+
+To include a directory (with \texttt{dirid}), Bvfs needs to run a query to
+select all files. This query could be time consuming.
+
+\texttt{hardlink} list is always composed of a series of two numbers (jobid,
+fileindex). This information can be found in the LinkFI field of the LStat
+packet.
+
+The \texttt{path} argument represents the name of the table that Bvfs will
+store results. The format of this table is \texttt{b2[0-9]+}. (Should start by
+b2 and followed by digits).
+
+Example:
+
+\begin{lstlisting}
+.bvfs_restore fileid=1,2,3,4 hardlink=10,15,10,20 jobid=10 path=b20001
+OK
+\end{lstlisting}
+
+\subsubsection*{Cleanup after Restore}
+
+To drop the table used by the restore command, you can use the
+\texttt{.bvfs\_cleanup} command.
+
+\begin{lstlisting}
+.bvfs_cleanup path=b20001
+\end{lstlisting}
+
+\subsubsection*{Clearing the BVFS Cache}
+
+To clear the BVFS cache, you can use the \texttt{.bvfs\_clear\_cache} command.
+
+\begin{lstlisting}
+.bvfs_clear_cache yes
+OK
+\end{lstlisting}
+
+\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, \mbacula{} won't prune automatically a Job if this
+particular Job is needed to restore data. Example:
+
+\begin{lstlisting}
+JobId: 1 Level: Full
+JobId: 2 Level: Incremental
+JobId: 3 Level: Incremental
+JobId: 4 Level: Differential
+.. Other incrementals up to now
+\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, \mbacula{} will
+detect that JobId 1 and 4 are essential to restore data at the current state
+and will prune only JobId 2 and 3.
+
+\texttt{Important}, this change affect only the automatic pruning step after a
+Job and the \texttt{prune jobs} Bconsole command. If a volume expires after the
+\texttt{VolumeRetention} period, important jobs can be pruned.
+
+\subsection{Ability to Verify any specified Job}
+You now have the ability to tell \mbacula{} which Job should verify instead of
+automatically verify just the last one.
+
+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{lstlisting}
+*run job=VerifyVolume jobid=1 level=VolumeToCatalog
+Run Verify job
+JobName: VerifyVolume
+Level: VolumeToCatalog
+Client: 127.0.0.1-fd
+FileSet: Full Set
+Pool: Default (From Job resource)
+Storage: File (From Job resource)
+Verify Job: VerifyVol.2010-09-08_14.17.17_03
+Verify List: /tmp/regress/working/VerifyVol.bsr
+When: 2010-09-08 14:17:31
+Priority: 10
+OK to run? (yes/mod/no):
+\end{lstlisting}
+
+\medskip
+This project was funded by Bacula Systems and is available with Bacula
+Enterprise Edition and Community Edition.
+
+\subsection{Additions to RunScript variables}
+You can have access to JobBytes and JobFiles using \%b and \%F in your runscript
+command. The Client address is now available through \%h.
+
+\begin{lstlisting}
+RunAfterJob = "/bin/echo Job=%j JobBytes=%b JobFiles=%F ClientAddress=%h"
+\end{lstlisting}
+
+%\subsection{Changes in drivetype.exe}
+%
+%Now the \texttt{drivetype.exe} program allows you to list all local hard
+%drives. It can help to build dynamic FileSet on Windows.
+%
+%\begin{lstlisting}
+%File = "\\|\"c:/program files/bacula/bin32/drivetype\" -l -a"
+%\end{lstlisting}
+%
+
+\subsection{Additions to the Plugin API}
+The bfuncs structure has been extended to include a number of
+new entrypoints.
+
+\subsubsection{bfuncs}
+The bFuncs structure defines the callback entry points within \mbacula{}
+that the plugin can use register events, get \mbacula{} values, set
+\mbacula{} values, and send messages to the Job output or debug output.
+
+The exact definition as of this writing is:
+\begin{lstlisting}
+typedef struct s_baculaFuncs {
+ uint32_t size;
+ uint32_t version;
+ bRC (*registerBaculaEvents)(bpContext *ctx, ...);
+ bRC (*getBaculaValue)(bpContext *ctx, bVariable var, void *value);
+ bRC (*setBaculaValue)(bpContext *ctx, bVariable var, void *value);
+ bRC (*JobMessage)(bpContext *ctx, const char *file, int line,
+ int type, utime_t mtime, const char *fmt, ...);
+ bRC (*DebugMessage)(bpContext *ctx, const char *file, int line,
+ int level, const char *fmt, ...);
+ void *(*baculaMalloc)(bpContext *ctx, const char *file, int line,
+ size_t size);
+ void (*baculaFree)(bpContext *ctx, const char *file, int line, void *mem);
+
+ /* New functions follow */
+ bRC (*AddExclude)(bpContext *ctx, const char *file);
+ bRC (*AddInclude)(bpContext *ctx, const char *file);
+ bRC (*AddIncludeOptions)(bpContext *ctx, const char *opts);
+ bRC (*AddRegex)(bpContext *ctx, const char *item, int type);
+ bRC (*AddWild)(bpContext *ctx, const char *item, int type);
+ bRC (*checkChanges)(bpContext *ctx, struct save_pkt *sp);
+
+} bFuncs;
+\end{lstlisting}
+
+\begin{description}
+\item [AddExclude] can be called to exclude a file. The file
+ string passed may include wildcards that will be interpreted by
+ the {\bf fnmatch} subroutine. This function can be called
+ multiple times, and each time the file specified will be added
+ to the list of files to be excluded. Note, this function only
+ permits adding excludes of specific file or directory names,
+ or files matched by the rather simple fnmatch mechanism.
+ See below for information on doing wild-card and regex excludes.
+
+\item [NewPreInclude] can be called to create a new Include block. This
+ block will be added after the current defined Include block. This
+ function can be called multiple times, but each time, it will create
+ a new Include section (not normally needed). This function should
+ be called only if you want to add an entirely new Include block.
+
+\item [NewInclude] can be called to create a new Include block. This
+ block will be added before any user defined Include blocks. This
+ function can be called multiple times, but each time, it will create
+ a new Include section (not normally needed). This function should
+ be called only if you want to add an entirely new Include block.
+
+\item [AddInclude] can be called to add new files/directories to
+ be included. They are added to the current Include block. If
+ NewInclude has not been included, the current Include block is
+ the last one that the user created. This function
+ should be used only if you want to add totally new files/directories
+ to be included in the backup.
+
+\item [NewOptions] adds a new Options block to the current Include
+ in front of any other Options blocks. This permits the plugin to
+ add exclude directives (wild-cards and regexes) in front of the
+ user Options, and thus prevent certain files from being backed up.
+ This can be useful if the plugin backs up files, and they should
+ not be also backed up by the main \mbacula{} code. This function
+ may be called multiple times, and each time, it creates a new
+ prepended Options block. Note: normally you want to call this
+ entry point prior to calling AddOptions, AddRegex, or AddWild.
+
+\item [AddOptions] allows the plugin it set options in
+ the current Options block, which is normally created with the
+ NewOptions call just prior to adding Include Options.
+ The permitted options are passed as a character string, where
+ each character has a specific meaning as defined below:
+
+ \begin{description}
+ \item [a] always replace files (default).
+ \item [e] exclude rather than include.
+ \item [h] no recursion into subdirectories.
+ \item [H] do not handle hard links.
+ \item [i] ignore case in wildcard and regex matches.
+ \item [M] compute an MD5 sum.
+ \item [p] use a portable data format on Windows (not recommended).
+ \item [R] backup resource forks and Findr Info.
+ \item [r] read from a fifo
+ \item [S1] compute an SHA1 sum.
+ \item [S2] compute an SHA256 sum.
+ \item [S3] comput an SHA512 sum.
+ \item [s] handle sparse files.
+ \item [m] use st\_mtime only for file differences.
+ \item [k] restore the st\_atime after accessing a file.
+ \item [A] enable ACL backup.
+ \item [Vxxx:] specify verify options. Must terminate with :
+ \item [Cxxx:] specify accurate options. Must terminate with :
+ \item [Jxxx:] specify base job Options. Must terminate with :
+ \item [Pnnn:] specify integer nnn paths to strip. Must terminate with :
+ \item [w] if newer
+ \item [Zn] specify gzip compression level n.
+ \item [K] do not use st\_atime in backup decision.
+ \item [c] check if file changed during backup.
+ \item [N] honor no dump flag.
+ \item [X] enable backup of extended attributes.
+ \end{description}
+
+\item [AddRegex] adds a regex expression to the current Options block.
+ The following options are permitted:
+ \begin{description}
+ \item [ ] (a blank) regex applies to whole path and filename.
+ \item [F] regex applies only to the filename (directory or path stripped).
+ \item [D] regex applies only to the directory (path) part of the name.
+ \end{description}
+
+\item [AddWild] adds a wildcard expression to the current Options block.
+ The following options are permitted:
+ \begin{description}
+ \item [ ] (a blank) regex applies to whole path and filename.
+ \item [F] regex applies only to the filename (directory or path stripped).
+ \item [D] regex applies only to the directory (path) part of the name.
+ \end{description}
+
+\item [checkChanges] call the \texttt{check\_changes()} function in \mbacula{} code
+ that can use Accurate code to compare the file information in argument with
+ the previous file information. The \texttt{delta\_seq} attribute of the
+ \texttt{save\_pkt} will be updated, and the call will return
+ \texttt{bRC\_Seen} if the core code wouldn't decide to backup it.
+
+\end{description}
+
+
+\subsubsection{Bacula events}
+The list of events has been extended to include:
+
+\begin{lstlisting}
+typedef enum {
+ bEventJobStart = 1,
+ bEventJobEnd = 2,
+ bEventStartBackupJob = 3,
+ bEventEndBackupJob = 4,
+ bEventStartRestoreJob = 5,
+ bEventEndRestoreJob = 6,
+ bEventStartVerifyJob = 7,
+ bEventEndVerifyJob = 8,
+ bEventBackupCommand = 9,
+ bEventRestoreCommand = 10,
+ bEventLevel = 11,
+ bEventSince = 12,
+
+ /* New events */
+ bEventCancelCommand = 13,
+ bEventVssBackupAddComponents = 14,
+ bEventVssRestoreLoadComponentMetadata = 15,
+ bEventVssRestoreSetComponentsSelected = 16,
+ bEventRestoreObject = 17,
+ bEventEndFileSet = 18,
+ bEventPluginCommand = 19,
+ bEventVssBeforeCloseRestore = 20,
+ bEventVssPrepareSnapshot = 21
+
+} bEventType;
+\end{lstlisting}
+
+\begin{description}
+\item [bEventCancelCommand] is called whenever the currently
+ running Job is canceled */
+
+\item [bEventVssBackupAddComponents]
+
+\item [bEventVssPrepareSnapshot] is called before creating VSS snapshots, it
+ provides a char[27] table where the plugin can add Windows drives that will
+ be used during the Job. You need to add them without duplicates, and you can
+ use in \texttt{fd\_common.h} \texttt{add\_drive()} and \texttt{copy\_drives()}
+ for this purpose.
+\end{description}
+
+\subsection{ACL enhancements}
+
+The following enhancements are made to the \mbacula{} Filed with regards to
+Access Control Lists (ACLs)
+
+\begin{bsysitemize}
+\item Added support for AIX 5.3 and later new aclx\_get interface which supports
+ POSIX and NFSv4 ACLs.
+\item Added support for new acl types on FreeBSD 8.1 and later which supports
+ POSIX and NFSv4 ACLs.
+\item Some generic cleanups for internal ACL handling.
+\item Fix for acl storage on OSX
+\item Cleanup of configure checks for ACL detection, now configure only
+ tests for a certain interface type based on the operating system
+ this should give less false positives on detection. Also when ACLs
+ are detected no other acl checks are performed anymore.
+\end{bsysitemize}
+
+\medskip
+This project was funded by Planets Communications B.V. and ELM Consultancy B.V.
+and is available with Bacula Enterprise Edition and Community Edition.
+
+\subsection{XATTR enhancements}
+
+The following enhancements are made to the \mbacula{} Filed with regards to
+Extended Attributes (XATTRs)
+
+\begin{bsysitemize}
+\item Added support for IRIX extended attributes using the attr\_get interface.
+\item Added support for Tru64 (OSF1) extended attributes using the
+ getproplist interface.
+\item Added support for AIX extended attributes available in AIX 6.x
+ and higher using the listea/getea/setea interface.
+\item Added some debugging to generic xattr code so it easier to
+ debug.
+\item Cleanup of configure checks for XATTR detection, now configure only
+ tests for a certain interface type based on the operating system
+ this should give less false positives on detection. Also when xattrs
+ are detected no other xattr checks are performed anymore.
+\end{bsysitemize}
+
+\medskip
+This project was funded by Planets Communications B.V. and ELM Consultancy B.V.
+and is available with Bacula Enterprise Edition and Community Edition.
+
+\subsection{Class Based Database Backend Drivers}
+
+The main \mbacula{} Director code is independent of the SQL backend
+in version 5.2.0 and greater. This means that the \mbacula{} Director can be
+packaged by itself, then each of the different SQL backends supported can
+be packaged separately. It is possible to build all the DB backends at the
+same time by including multiple database options at the same time.
+
+./configure can be run with multiple database configure options.
+\begin{lstlisting}
+ --with-sqlite3
+ --with-mysql
+ --with-postgresql
+\end{lstlisting}
+
+Order of testing for databases is:
+\begin{bsysitemize}
+\item postgresql
+\item mysql
+\item sqlite3
+\end{bsysitemize}
+
+Each configured backend generates a file named:
+\lstinline+libbaccats-<sql_backend_name>-<version>.so+
+A dummy catalog library is created named libbaccats-version.so
+
+At configure time the first detected backend is used as the so called
+default backend and at install time the dummy
+\lstinline+libbaccats-<version>.so+ is replaced with the default backend type.
+
+If you configure all three backends you get three backend libraries and the
+postgresql gets installed as the default.
+
+When you want to switch to another database, first save any old catalog you
+may have then you can copy one of the three backend libraries over the
+\lstinline+libbaccats-<version>.so+ e.g.
+
+An actual command, depending on your \mbacula{} version might be:
+\begin{lstlisting}
+ cp libbaccats-postgresql-5.2.2.so libbaccats-5.2.2.so
+\end{lstlisting}
+
+where the \lstinline+5.2.2+ must be replaced by the \mbacula{} release
+version number.
+
+Then you must update the default backend in the following files:
+
+\begin{lstlisting}
+ create_bacula_database
+ drop_bacula_database
+ drop_bacula_tables
+ grant_bacula_privileges
+ make_bacula_tables
+ make_catalog_backup
+ update_bacula_tables
+\end{lstlisting}
+
+And re-run all the above scripts. Please note, this means
+you will have a new empty database and if you had a previous
+one it will be lost.
+
+All current database backend drivers for catalog information are rewritten
+to use a set of multi inherited C++ classes which abstract the specific
+database specific internals and make sure we have a more stable generic
+interface with the rest of SQL code. From now on there is a strict
+boundary between the SQL code and the low-level database functions. This
+new interface should also make it easier to add a new backend for a
+currently unsupported database. As part of the rewrite the SQLite 2 code
+was removed (e.g. only SQLite 3 is now supported). An extra bonus of the
+new code is that you can configure multiple backends in the configure and
+build all backends in one compile session and select the correct database
+backend at install time. This should make it a lot easier for packages
+maintainers.
+
+
+
+\medskip
+We also added cursor support for PostgreSQL backend, this improves memory
+usage for large installation.
+
+\medskip
+This project was implemented by Planets Communications B.V. and ELM
+Consultancy B.V. and Bacula Systems and is available with both the Bacula
+Enterprise Edition and the Community Edition.
+
+\subsection{Hash List Enhancements}
+
+The htable hash table class has been extended with extra hash functions for
+handling next to char pointer hashes also 32 bits and 64 bits hash keys.
+Also the hash table initialization routines have been enhanced with
+support for passing a hint as to the number of initial pages to use
+for the size of the hash table. Until now the hash table always used
+a fixed value of 10 Mb. The private hash functions of the mountpoint entry
+cache have been rewritten to use the new htable class with a small memory
+footprint.
+
+\medskip
+This project was funded by Planets Communications B.V. and ELM Consultancy B.V.
+and Bacula Systems and is available with Bacula Enterprise Edition and
+Community Edition.
+
+%%
+%%
+%%% =====================================================================
+%%
+%%
+
+
+\section{Release Version 5.0.3}
+
+There are no new features in version 5.0.2. This version simply fixes a
+number of bugs found in version 5.0.1 during the ongoing development
+process.
+
+\section{Release Version 5.0.2}
+
+There are no new features in version 5.0.2. This version simply fixes a
+number of bugs found in version 5.0.1 during the ongoing development
+process.
+
+%%
+%%
+
+\section{New Features in 5.0.1}
This chapter presents the new features that are in the released Bacula version
5.0.1. This version mainly fixes a number of bugs found in version 5.0.0 during
-the onging development process.
+the ongoing development process.
-\section{Truncate volume after purge}
-\label{sec:actiononpurge}
+\subsection{Truncate Volume after Purge}
+\label{seccom:actiononpurge}
The Pool directive \textbf{ActionOnPurge=Truncate} instructs Bacula to truncate
the volume when it is purged with the new command \texttt{purge volume
- action}.It is useful to prevent disk based volumes from consuming too much
+ action}. It is useful to prevent disk based volumes from consuming too much
space.
-\begin{verbatim}
+\begin{lstlisting}
Pool {
Name = Default
Action On Purge = Truncate
...
}
-\end{verbatim}
+\end{lstlisting}
-As usual You can also set this property with the \texttt{update volume} command
-\begin{verbatim}
-*update volume=xxx actiononpurge=Truncate
+As usual you can also set this property with the \texttt{update volume} command
+\begin{lstlisting}
+*update volume=xxx ActionOnPurge=Truncate
*update volume=xxx actiononpurge=None
-\end{verbatim}
+\end{lstlisting}
-To ask Bacula to truncate your \texttt{Purged} volumes, you need to use the
+To ask \mbacula{} to truncate your \texttt{Purged} volumes, you need to use the
following command in interactive mode or in a RunScript as shown after:
-\begin{verbatim}
+\begin{lstlisting}
*purge volume action=truncate storage=File allpools
# or by default, action=all
*purge volume action storage=File pool=Default
-\end{verbatim}
+\end{lstlisting}
This is possible to specify the volume name, the media type, the pool, the
storage, etc\dots (see \texttt{help purge}) Be sure that your storage device is
idle when you decide to run this command.
-\begin{verbatim}
+\begin{lstlisting}
Job {
Name = CatalogBackup
...
Console = "purge volume action=all allpools storage=File"
}
}
-\end{verbatim}
+\end{lstlisting}
\textbf{Important note}: This feature doesn't work as
expected in version 5.0.0. Please do not use it before version 5.0.1.
-\chapter{New Features in 5.0.0}
+\subsection{Allow Higher Duplicates}
+This directive did not work correctly and has been depreciated
+(disabled) in version 5.0.1. Please remove it from your bacula-dir.conf
+file as it will be removed in a future release.
+
+\subsection{Cancel Lower Level Duplicates}
+This directive was added in Bacula version 5.0.1. It compares the
+level of a new backup job to old jobs of the same name, if any,
+and will kill the job which has a lower level than the other one.
+If the levels are the same (i.e. both are Full backups), then
+nothing is done and the other Cancel XXX Duplicate directives
+will be examined.
-\section{Maximum Concurent Jobs for Devices}
-\label{sec:maximumconcurentjobdevice}
+\section{New Features in 5.0.0}
+
+\subsection{Maximum Concurrent Jobs for Devices}
+\label{seccom:maximumconcurrentjobdevice}
{\bf Maximum Concurrent Jobs} is a new Device directive in the Storage
Daemon configuration permits setting the maximum number of Jobs that can
This project was funded by Bacula Systems.
-\section{Restore from Multiple Storage Daemons}
+\subsection{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
+Daemon. Now, \mbacula{} 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
+your incremental jobs use another Storage Daemon with lots of disks, \mbacula{}
will switch automatically from one Storage Daemon to an other within the same
Restore job.
This project was funded by Bacula Systems with the help of Equiinet.
-\section{File Deduplication using Base Jobs}
+\subsection{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,
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
+win for the user, it makes \mbacula{} 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}
-
-\textbf{Important note}: The current implementation doesn't permit to scan
-volume with \textbf{bscan}. The result wouldn't permit to restore files easily.
+See the \ilink{Base Job Chapter}{basejobs} for more information.
This project was funded by Bacula Systems.
-\section{AllowCompression = \lt{}yes\vb{}no\gt{}}
+\subsection{AllowCompression = \lt{}yes\vb{}no\gt{}}
\index[dir]{AllowCompression}
This new directive may be added to Storage resource within the Director's
any job which writes to this storage resource.
For example:
-\begin{verbatim}
+\begin{lstlisting}
Storage {
Name = UltriumTape
Address = ultrium-tape
Media Type = LTO 3
AllowCompression = No # Tape drive has hardware compression
}
-\end{verbatim}
+\end{lstlisting}
The above example would cause any jobs running with the UltriumTape storage
resource to run without compression from the client file daemons. This
effectively overrides any compression settings defined at the FileSet level.
This project was funded by Collaborative Fusion, Inc.
-\section{Accurate Fileset Options}
-\label{sec:accuratefileset}
+\subsection{Accurate Fileset Options}
+\label{seccom:accuratefileset}
In previous versions, the accurate code used the file creation and modification
times to determine if a file was modified or not. Now you can specify which
attributes to use (time, size, checksum, permission, owner, group, \dots),
similar to the Verify options.
-\begin{verbatim}
+\begin{lstlisting}
FileSet {
Name = Full
Include = {
Options {
- Accurate = mcs5
+ Accurate = mcs
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{lstlisting}
+
+\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 normally would not
be saved. This increases the I/O load, but also the accuracy of the
-deduplication. By default, Bacula will check modification/creation time
+deduplication. By default, \mbacula{} will check modification/creation time
and size.
This project was funded by Bacula Systems.
-\section{Tab-completion for Bconsole}
-\label{sec:tabcompletion}
+\subsection{Tab-completion for Bconsole}
+\label{seccom:tabcompletion}
If you build \texttt{bconsole} with readline support, you will be able to use
the new auto-completion mode. This mode supports all commands, gives help
To use this feature, you should have readline development package loaded on
your system, and use the following option in configure.
-\begin{verbatim}
+\begin{lstlisting}
./configure --with-readline=/usr/include/readline --disable-conio ...
-\end{verbatim}
+\end{lstlisting}
The new bconsole won't be able to tab-complete with older directors.
This project was funded by Bacula Systems.
-\section{Pool File and Job retention}
-\label{sec:poolfilejobretention}
+\subsection{Pool File and Job Retention}
+\label{seccom:poolfilejobretention}
-% TODO check
We added two new Pool directives, \texttt{FileRetention} and
\texttt{JobRetention}, that take precedence over Client directives of the same
name. It allows you to control the Catalog pruning algorithm Pool by Pool. For
example, you can decide to increase Retention times for Archive or OffSite Pool.
-\section{Read-only File Daemon using capabilities}
-\label{sec:fdreadonly}
+It seems obvious to us, but apparently not to some users, that given the
+definition above that the Pool File and Job Retention periods is a global
+override for the normal Client based pruning, which means that when the
+Job is pruned, the pruning will apply globally to that particular Job.
+
+Currently, there is a bug in the implementation that causes any Pool
+retention periods specified to apply to {\bf all} Pools for that
+particular Client. Thus we suggest that you avoid using these two
+directives until this implementation problem is corrected.
+
+\subsection{Read-only File Daemon using capabilities}
+\label{seccom:fdreadonly}
This feature implements support of keeping \textbf{ReadAll} capabilities after
UID/GID switch, this allows FD to keep root read but drop write permission.
It introduces new \texttt{bacula-fd} option (\texttt{-k}) specifying that
\textbf{ReadAll} capabilities should be kept after UID/GID switch.
-\begin{verbatim}
+\begin{lstlisting}
root@localhost:~# bacula-fd -k -u nobody -g nobody
-\end{verbatim}
+\end{lstlisting}
-The code for this feature was contributed by AltLinux.
+The code for this feature was contributed by our friends at AltLinux.
-\section{Bvfs API}
-\label{sec:bvfs}
+\subsection{Bvfs API}
+\label{seccom:bvfs}
To help developers of restore GUI interfaces, we have added new \textsl{dot
commands} that permit browsing the catalog in a very simple way.
-\begin{itemize}
+\begin{bsysitemize}
\item \texttt{.bvfs\_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{.bvfs\_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 character encoding.
-\end{itemize}
+\end{bsysitemize}
You can use \texttt{limit=xxx} and \texttt{offset=yyy} to limit the amount of
data that will be displayed.
-\begin{verbatim}
+\begin{lstlisting}
* .bvfs_update jobid=1,2
* .bvfs_update
* .bvfs_lsdir path=/ jobid=1,2
-\end{verbatim}
+\end{lstlisting}
This project was funded by Bacula Systems.
-\section{Testing your Tape Drive}
-\label{sec:btapespeed}
+\subsection{Testing your Tape Drive}
+\label{seccom:btapespeed}
To determine the best configuration of your tape drive, you can run the new
\texttt{speed} command available in the \texttt{btape} program.
This command can have the following arguments:
-\begin{itemize}
+\begin{bsysitemize}
\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
\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
+\item[\texttt{skip\_block}] This flag permits to skip tests with \mbacula{} block
access.
-\end{itemize}
+\end{bsysitemize}
-\begin{verbatim}
+\begin{lstlisting}
*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:383 Total Volume bytes=9.664 GB. Total Write rate = 7.365 MB/s
-\end{verbatim}
+\end{lstlisting}
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).
+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}
+\subsection{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
+that \mbacula{} uses when writing blocks to a Volume. This is
done by adding:
-\begin{verbatim}
+\begin{lstlisting}
Block Checksum = no
-\end{verbatim}
+\end{lstlisting}
doing so can reduce the Storage daemon CPU usage slightly. It
-will also permit Bacula to read a Volume that has corrupted data.
+will also permit \mbacula{} 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.
+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 go undetected.
-\section{New Bat Features}
+\subsection{New Bat Features}
Those new features were funded by Bacula Systems.
-\subsection{Media List View}
+\subsubsection{Media List View}
By clicking on ``Media'', you can see the list of all your volumes. You will be
able to filter by Pool, Media Type, Location,\dots And sort the result directly
in the table. The old ``Media'' view is now known as ``Pool''.
-\begin{figure}[htbp]
- \centering
- \includegraphics[width=13cm]{\idir bat-mediaview.eps}
- \label{fig:mediaview}
-\end{figure}
-
+%% \begin{figure}[htbp]
+%% \centering
+%% \includegraphics[width=13cm]{\idir bat-mediaview}
+%% \label{figcom:mediaview}
+%% \end{figure}
+\bsysimageH{bat-mediaview}{List of all Volumes}{figcom:mediaview}
-\subsection{Media Information View}
+\subsubsection{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}
+Volume. (cf. figure \bsysref{figcom:mediainfo}.)
+%% \begin{figure}[htbp]
+%% \centering
+%% \includegraphics[width=13cm]{\idir bat11}
+%% \caption{Media information}
+%% \label{figcom:mediainfo}
+%% \end{figure}
+\bsysimageH{bat11}{Media information}{figcom:mediainfo}
+\subsubsection{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}
+\bsysref{figcom:jobinfo}.)
+%% \begin{figure}[htbp]
+%% \centering
+%% \includegraphics[width=13cm]{\idir bat12}
+%% \caption{Job information}
+%% \label{figcom:jobinfo}
+%% \end{figure}
+\bsysimageH{bat12}{Job information}{figcom:jobinfo}
-\subsection{Autochanger Content View}
+\subsubsection{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}
+access a detailed overview of your Autochanger. (cf. figure \bsysref{figcom:jobinfo}.)
+%% \begin{figure}[htbp]
+%% \centering
+%% \includegraphics[width=13cm]{\idir bat13}
+%% \caption{Autochanger content}
+%% \label{figcom:achcontent}
+%% \end{figure}
+\bsysimageH{bat13}{Autochanger content}{figcom:achcontent}
To use this feature, you need to use the latest mtx-changer script
version. (With new \texttt{listall} and \texttt{transfer} commands)
-\section{Bat on Windows}
-We have ported {\bf bat} to Windows and it is now installed
-by default when the installer is run. It works quite well
+\subsection{Bat on Windows}
+We have ported {\bf bat} to Windows and it is now installed
+by default when the installer is run. It works quite well
on Win32, but has not had a lot of testing there, so your
-feedback would be welcome. Unfortunately, eventhough it is
+feedback would be welcome. Unfortunately, even though it is
installed by default, it does not yet work on 64 bit Windows
operating systems.
-\section{New Win32 Installer}
+\subsection{New Win32 Installer}
The Win32 installer has been modified in several very important
-ways.
-\begin{itemize}
+ways.
+\begin{bsysitemize}
\item You must deinstall any current version of the
-Win32 File daemon before upgrading to the new one.
+Win32 File daemon before upgrading to the new one.
If you forget to do so, the new installation will fail.
-To correct this failure, you must manually shutdown
-and deinstall the old File daemon.
+To correct this failure, you must manually shutdown
+and deinstall the old File daemon.
\item All files (other than menu links) are installed
-in {\bf c:/Program Files/Bacula}.
+in {\bf c:/Program Files/Bacula}.
\item The installer no longer sets this
file to require administrator privileges by default. If you want
to do so, please do it manually using the {\bf cacls} program.
For example:
-\begin{verbatim}
+\begin{lstlisting}
cacls "C:\Program Files\Bacula" /T /G SYSTEM:F Administrators:F
-\end{verbatim}
+\end{lstlisting}
\item The server daemons (Director and Storage daemon) are
no longer included in the Windows installer. If you want the
Windows servers, you will either need to build them yourself (note
-they have not been ported to 64 bits), or you can contact
+they have not been ported to 64 bits), or you can contact
Bacula Systems about this.
-\end{itemize}
+\end{bsysitemize}
-\section{Win64 Installer}
+\subsection{Win64 Installer}
We have corrected a number of problems that required manual
editing of the conf files. In most cases, it should now
install and work. {\bf bat} is by default installed in
{\bf c:/Program Files/Bacula} as is the case with the 32
bit Windows installer.
-\section{Bare Metal Recovery USB Key}
+\subsection{Linux Bare Metal Recovery USB Key}
We have made a number of significant improvements in the
Bare Metal Recovery USB key. Please see the README files
it the {\bf rescue} release for more details.
+We are working on an equivalent USB key for Windows bare
+metal recovery, but it will take some time to develop it (best
+estimate 3Q2010 or 4Q2010)
-\section{bconsole Timeout Option}
+\subsection{bconsole Timeout Option}
You can now use the -u option of {\bf bconsole} to set a timeout in seconds
for commands. This is useful with GUI programs that use {\bf bconsole}
to interface to the Director.
-\section{Important Changes}
-\label{sec:importantchanges}
+\subsection{Important Changes}
+\label{seccom:importantchanges}
-\begin{itemize}
+\begin{bsysitemize}
\item You are now allowed to Migrate, Copy, and Virtual Full to read and write
to the same Pool. The Storage daemon ensures that you do not read and
write to the same Volume.
\item The \texttt{Device Poll Interval} is now 5 minutes. (previously did not
poll by default).
+\item Virtually all the features of {\bf mtx-changer} have
+ now been parametrized, which allows you to configure
+ mtx-changer without changing it. There is a new configuration file {\bf mtx-changer.conf}
+ that contains variables that you can set to configure mtx-changer.
+ This configuration file will not be overwritten during upgrades.
+ We encourage you to submit any changes
+ that are made to mtx-changer and to parametrize it all in
+ mtx-changer.conf so that all configuration will be done by
+ changing only mtx-changer.conf.
\item The new \texttt{mtx-changer} script has two new options, \texttt{listall}
- and \texttt{transfer}. Be sure to apply any custom changes on to the
- mtx-changer script, or better yet, use mtx-changer.conf to configure
- them.
+ and \texttt{transfer}. Please configure them as appropriate
+ in mtx-changer.conf.
\item To enhance security of the \texttt{BackupCatalog} job, we provide a new
script (\texttt{make\_catalog\_backup.pl}) that does not expose your catalog
- password. If you want to use the new script, you will need to
+ password. If you want to use the new script, you will need to
manually change the \texttt{BackupCatalog} Job definition.
\item The \texttt{bconsole} \texttt{help} command now accepts
an argument, which if provided produces information on that
command (ex: \texttt{help run}).
-\end{itemize}
+\end{bsysitemize}
\subsubsection*{Truncate volume after purge}
Note that the Truncate Volume after purge feature doesn't work as expected
in 5.0.0 version. Please, don't use it before version 5.0.1.
-\subsection{Custom Catalog queries}
+\subsubsection{Custom Catalog queries}
If you wish to add specialized commands that list the contents of the catalog,
you can do so by adding them to the \texttt{query.sql} file. This
\texttt{examples/sample-query.sql} has an a number of sample commands
you might find useful.
-\subsection{Deprecated parts}
+\subsubsection{Deprecated parts}
The following items have been \textbf{deprecated} for a long time, and are now
removed from the code.
-\begin{itemize}
+\begin{bsysitemize}
\item Gnome console
\item Support for SQLite 2
-\end{itemize}
+\end{bsysitemize}
-\section{Misc Changes}
-\label{sec:miscchanges}
+\subsection{Misc Changes}
+\label{seccom:miscchanges}
-\begin{itemize}
+\begin{bsysitemize}
\item Updated Nagios check\_bacula
\item Updated man files
\item Added OSX package generation script in platforms/darwin
\item Added lock/unlock order protection in lock manager
\item Allow 64 bit sizes for a number of variables
\item Fixed several deadlocks or potential race conditions in the SD
-\end{itemize}
+\end{bsysitemize}
\chapter{Released Version 3.0.3 and 3.0.3a}
There are no new features in version 3.0.3. This version simply fixes a
-number of bugs found in version 3.0.2 during the onging development
+number of bugs found in version 3.0.2 during the ongoing development
process.
-\chapter{New Features in Released Version 3.0.2}
+\section{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}
+\subsection{Full Restore from a Given JobId}
\index[general]{Restore menu}
-This feature allows selecting a single JobId and having Bacula
+This feature allows selecting a single JobId and having \mbacula{}
automatically select all the other jobs that comprise a full backup up to
and including the selected date (through JobId).
Assume we start with the following jobs:
-\begin{verbatim}
+\begin{lstlisting}
+-------+--------------+---------------------+-------+----------+------------+
| jobid | client | starttime | level | jobfiles | jobbytes |
+-------+--------------+---------------------+-------+----------+------------
| 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}
+\end{lstlisting}
Below is an example of this new feature (which is number 12 in the
menu).
-\begin{verbatim}
+\begin{lstlisting}
* restore
To select the JobIds, you have the following choices:
1: List last 20 Jobs run
Building directory tree for JobId(s) 1,3,5 ... +++++++++++++++++++
1,444 files inserted into the tree.
-\end{verbatim}
+\end{lstlisting}
This project was funded by Bacula Systems.
-\section{Source Address}
-\index[general]{Source Address}
+\subsection{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
networks utilizing multi-homing and policy-routing.
To accomplish this, two new configuration directives have been implemented:
-\begin{verbatim}
+\begin{lstlisting}
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}
+\end{lstlisting}
Simply adding specific host routes on the OS
would have an undesirable side-effect: any
This project was funded by Collaborative Fusion, Inc.
-\section{Show volume availability when doing restore}
+\subsection{Show volume availability when doing restore}
When doing a restore the selection dialog ends by displaying this
screen:
-\begin{verbatim}
+\begin{lstlisting}
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
+ *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}
+\end{lstlisting}
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}
+\subsection{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}
+\begin{lstlisting}
* estimate listing accurate=yes level=incremental job=BackupJob
-\end{verbatim}
+\end{lstlisting}
This project was funded by Bacula Systems.
-\chapter{New Features in 3.0.0}
-\label{NewFeaturesChapter}
-\index[general]{New Features}
+\section{New Features in 3.0.0}
+\label{3:NewFeaturesChapter}
+\index[general]{New features}
This chapter presents the new features added to the development 2.5.x
versions to be released as Bacula version 3.0.0 sometime in April 2009.
-\section{Accurate Backup}
-\index[general]{Accurate Backup}
+\subsection{Accurate Backup}\label{accuratemode}
+\index[general]{Accurate backup}
-As with most other backup programs, by default Bacula decides what files to
-backup for Incremental and Differental backup by comparing the change
+As with most other backup programs, by default \mbacula{} decides what files to
+backup for Incremental and Differential backup by comparing the change
(st\_ctime) and modification (st\_mtime) times of the file to the time the last
backup completed. If one of those two times is later than the last backup
time, then the file will be backed up. This does not, however, permit tracking
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\vb{}no\gt{}}
+\subsubsection{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.
+\mbacula{} 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
about using Accurate backup is that it requires more resources (CPU and memory)
will probably not work correctly.
This project was funded by Bacula Systems.
-
-\section{Copy Jobs}
-\index[general]{Copy Jobs}
+
+\subsection{Copy Jobs}
+\index[general]{Copy jobs}
A new {\bf Copy} job type 'C' has been implemented. It is similar to the
existing Migration feature with the exception that the Job that is copied is
backup. However, the copy is treated as a copy rather than a backup job, and
hence is not directly available for restore. The {\bf restore} command lists
copy jobs and allows selection of copies by using \texttt{jobid=}
-option. If the keyword {\bf copies} is present on the command line, Bacula will
+option. If the keyword {\bf copies} is present on the command line, \mbacula{} will
display the list of all copies for selected jobs.
-\begin{verbatim}
+\begin{lstlisting}
* restore copies
[...]
These JobIds have copies as follows:
Building directory tree for JobId(s) 19,2 ... ++++++++++++++++++++++++++++++++++++++++++++
5,611 files inserted into the tree.
...
-\end{verbatim}
+\end{lstlisting}
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
directive named {\bf PoolUncopiedJobs} which selects all Jobs that were
-not already copied to another Pool.
+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.
+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,
+If \mbacula{} 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.
called disk-to-disk-to-tape backup (DTDTT). A sample config could
look something like the one below:
-\begin{verbatim}
+\begin{lstlisting}
Pool {
Name = FullBackupsVirtualPool
Pool Type = Backup
Maximum Concurrent Jobs = 10
SpoolData = No
Allow Duplicate Jobs = Yes
- Allow Higher Duplicates = No
Cancel Queued Duplicates = No
Cancel Running Duplicates = No
Priority = 13
Pool = FullBackupsVirtualPool
JobDefs = CopyDiskToTape
}
-\end{verbatim}
+\end{lstlisting}
The example above had 2 pool which are copied using the PoolUncopiedJobs
selection criteria. Normal Full backups go to the Virtual pool and are copied
The command \texttt{list copies [jobid=x,y,z]} lists copies for a given
\textbf{jobid}.
-\begin{verbatim}
+\begin{lstlisting}
*list copies
+-------+------------------------------------+-----------+------------------+
| JobId | Job | CopyJobId | MediaType |
+-------+------------------------------------+-----------+------------------+
| 9 | CopyJobSave.2008-12-20_22.26.49.05 | 11 | DiskChangerMedia |
+-------+------------------------------------+-----------+------------------+
-\end{verbatim}
+\end{lstlisting}
-\section{ACL Updates}
-\index[general]{ACL Updates}
+\subsection{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
allow certain platform specific ACL streams to be decoded and restored on the
same platform that they were created on. The old code allowed to restore ACL
cross platform but the comments already mention that not being to wise. For
-backward compatability the new code will accept the two old ACL streams and
+backward compatibility the new code will accept the two old ACL streams and
handle those with the platform specific handler. But for all new backups it
will save the ACLs using the new streams.
Currently the following platforms support ACLs:
-\begin{itemize}
+\begin{bsysitemize}
\item {\bf AIX}
\item {\bf Darwin/OSX}
\item {\bf FreeBSD}
\item {\bf Linux}
\item {\bf Tru64}
\item {\bf Solaris}
-\end{itemize}
+\end{bsysitemize}
Currently we support the following ACL types (these ACL streams use a reserved
part of the stream numbers):
-\begin{itemize}
+\begin{bsysitemize}
\item {\bf STREAM\_ACL\_AIX\_TEXT} 1000 AIX specific string representation from
acl\_get
\item {\bf STREAM\_ACL\_DARWIN\_ACCESS\_ACL} 1001 Darwin (OSX) specific acl\_t
string representation from acltotext or acl\_totext (POSIX acl)
\item {\bf STREAM\_ACL\_SOLARIS\_ACE} 1013 Solaris specific ace\_t string
representation from from acl\_totext (NFSv4 or ZFS acl)
-\end{itemize}
+\end{bsysitemize}
In future versions we might support conversion functions from one type of acl
-into an other for types that are either the same or easily convertable. For now
-the streams are seperate and restoring them on a platform that doesn't
+into an other for types that are either the same or easily convertible. For now
+the streams are separate and restoring them on a platform that doesn't
recognize them will give you a warning.
-\section{Extended Attributes}
-\index[general]{Extended Attributes}
+\subsection{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 specific these attributes are saved in separate streams for each
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
+filesystem on the same platform may lead to surprises. 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
security labels.
Currently the following platforms support extended attributes:
-\begin{itemize}
+\begin{bsysitemize}
\item {\bf Darwin/OSX}
\item {\bf FreeBSD}
\item {\bf Linux}
\item {\bf NetBSD}
-\end{itemize}
+\end{bsysitemize}
-On linux acls are also extended attributes, as such when you enable ACLs on a
+On Linux acls are also extended attributes, as such when you enable ACLs on a
Linux platform it will NOT save the same data twice e.g. it will save the ACLs
-and not the same exteneded attribute.
+and not the same extended attribute.
To enable the backup of extended attributes please add the following to your
fileset definition.
-\begin{verbatim}
+\begin{lstlisting}
FileSet {
Name = "MyFileSet"
Include {
File = ...
}
}
-\end{verbatim}
+\end{lstlisting}
-\section{Shared objects}
+\subsection{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.
+A default build of \mbacula{} 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
portable.
the binary release is smaller since the library code appears only once rather
than once for every program that uses it; this results in significant reduction
in the size of the binaries particularly for the utility tools.
-
+
In order for the system loader to find the shared objects when loading the
-Bacula binaries, the Bacula shared objects must either be in a shared object
+\mbacula{} binaries, the \mbacula{} shared objects must either be in a shared object
directory known to the loader (typically /usr/lib) or they must be in the
directory that may be specified on the {\bf ./configure} line using the {\bf
{-}{-}libdir} option as:
-\begin{verbatim}
+\begin{lstlisting}
./configure --libdir=/full-path/dir
-\end{verbatim}
+\end{lstlisting}
the default is /usr/lib. If {-}{-}libdir is specified, there should be
no need to modify your loader configuration provided that
-the shared objects are installed in that directory (Bacula
+the shared objects are installed in that directory (\mbacula{}
does this with the make install command). The shared objects
-that Bacula references are:
+that \mbacula{} references are:
-\begin{verbatim}
+\begin{lstlisting}
libbaccfg.so
libbacfind.so
libbacpy.so
libbac.so
-\end{verbatim}
+\end{lstlisting}
These files are symbolically linked to the real shared object file,
which has a version number to permit running multiple versions of
If you have problems with libtool or you wish to use the old
way of building static libraries, or you want to build a static
-version of Bacula you may disable
+version of \mbacula{} you may disable
libtool on the configure command line with:
-\begin{verbatim}
+\begin{lstlisting}
./configure --disable-libtool
-\end{verbatim}
+\end{lstlisting}
-\section{Building Static versions of Bacula}
+\subsection{Building Static versions of Bacula}
\index[general]{Static linking}
-In order to build static versions of Bacula, in addition
+In order to build static versions of \mbacula{}, in addition
to configuration options that were needed you now must
also add --disable-libtool. Example
-\begin{verbatim}
+\begin{lstlisting}
./configure --enable-static-client-only --disable-libtool
-\end{verbatim}
+\end{lstlisting}
-\section{Virtual Backup (Vbackup)}
+\subsection{Virtual Backup (Vbackup)}
\index[general]{Virtual Backup}
\index[general]{Vbackup}
-Bacula's virtual backup feature is often called Synthetic Backup or
+\mbacula{}'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 new Full
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
-Job resource, and writes it to the {\bf Next Pool} specified in the
+that \mbacula{} normally reads the data from the pool specified in the
+Job resource, and writes it to the {\bf Next Pool} specified in the
Job resource. Note, this means that usually the output from the Virtual
Backup is written into a different pool from where your prior backups
are saved. Doing it this way guarantees that you will not get a deadlock
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, because Bacula will
+pool. This will cause \mbacula{} to read and write to Volumes in the
+current pool. In general, this will work, because \mbacula{} 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
+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 typical Job resource definition might look like the following:
-\begin{verbatim}
+\begin{lstlisting}
Job {
Name = "MyBackup"
Type = Backup
Maximum Concurrent Jobs = 4
Autochanger = yes
}
-\end{verbatim}
+\end{lstlisting}
Then in bconsole or via a Run schedule, you would run the job as:
-\begin{verbatim}
+\begin{lstlisting}
run job=MyBackup level=Full
run job=MyBackup level=Incremental
run job=MyBackup level=Differential
run job=MyBackup level=Incremental
run job=MyBackup level=Incremental
-\end{verbatim}
+\end{lstlisting}
So providing there were changes between each of those jobs, you would end up
with a Full backup, a Differential, which includes the first Incremental
To consolidate those backups into a new Full backup, you would run the
following:
-\begin{verbatim}
+\begin{lstlisting}
run job=MyBackup level=VirtualFull
-\end{verbatim}
+\end{lstlisting}
And it would produce a new Full backup without using the client, and the output
would be written to the {\bf Full} Pool which uses the Diskchanger Storage.
-\section{Catalog Format}
-\index[general]{Catalog Format}
+\subsection{Catalog Format}
+\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
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
+backup of your database before executing the upgrade script. See the
ReleaseNotes for additional details.
-\section{64 bit Windows Client}
-\index[general]{Win64 Client}
+\subsection{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.
+their 64 bit OS versions is not compatible with a 32 bit \mbacula{} Client.
+As a consequence, we are also releasing a 64 bit version of the \mbacula{}
+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.
+a 64 bit version of the Windows OS.
-Compared to the Win32 Bacula Client, the 64 bit release contains a few differences:
+Compared to the Win32 \mbacula{} 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
+\item Before installing the Win64 \mbacula{} Client, you must totally
+ deinstall any prior 2.4.x Client installation using the
+ \mbacula{} 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 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
+ any prior version of \mbacula{} 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
+ 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
+\item All \mbacula{} 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
This project was funded by Bacula Systems.
-\section{Duplicate Job Control}
-\index[general]{Duplicate Jobs}
-The new version of Bacula provides four new directives that
-give additional control over what Bacula does if duplicate jobs
+\subsection{Duplicate Job Control}
+\index[general]{Duplicate jobs}
+The new version of \mbacula{} provides four new directives that
+give additional control over what \mbacula{} does if duplicate jobs
are started. A duplicate job in the sense we use it here means
a second or subsequent job with the same name starts. This
-happens most frequently when the first job runs longer than expected because no
+happens most frequently when the first job runs longer than expected because no
tapes are available.
The four directives each take as an argument a {\bf yes} or {\bf no} value and
They are:
-\subsection{Allow Duplicate Jobs = \lt{}yes\vb{}no\gt{}}
+\subsubsection{Allow Duplicate Jobs = \lt{}yes\vb{}no\gt{}}
\index[general]{Allow Duplicate Jobs}
- If this directive is enabled duplicate jobs will be run. If
+ If this directive is set to {\bf yes}, 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
+ may run at one time, and the action that \mbacula{} 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.
+ Canceling a job, then the current job (the second one started)
+ will be canceled.
-
-\subsection{Allow Higher Duplicates = \lt{}yes\vb{}no\gt{}}
+\subsubsection{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, 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\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}.
+ This directive was in version 5.0.0, but does not work as
+ expected. If used, it should always be set to no. In later versions
+ of \mbacula{} the directive is disabled (disregarded).
-\subsection{Cancel Running Duplicates = \lt{}yes\vb{}no\gt{}}
+\subsubsection{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}.
+\subsubsection{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}.
+
-\section{TLS Authentication}
-\index[general]{TLS Authentication}
-In Bacula version 2.5.x and later, in addition to the normal Bacula
-CRAM-MD5 authentication that is used to authenticate each Bacula
+\subsection{TLS Authentication}
+\index[general]{TLS authentication}
+In Bacula version 2.5.x and later, in addition to the normal \mbacula{}
+CRAM-MD5 authentication that is used to authenticate each \mbacula{}
connection, you can specify that you want TLS Authentication as well,
which will provide more secure authentication.
-This new feature uses Bacula's existing TLS code (normally used for
+This new feature uses \mbacula{}'s existing TLS code (normally used for
communications encryption) to do authentication. To use it, you must
specify all the TLS directives normally used to enable communications
-encryption (TLS Enable, TLS Verify Peer, TLS Certificate, ...) and
+encryption (TLS Enable, TLS Verify Peer, TLS Certificate, \ldots{}) and
a new directive:
-\subsection{TLS Authenticate = yes}
-\begin{verbatim}
+\subsubsection{TLS Authenticate = yes}
+\begin{lstlisting}
TLS Authenticate = yes
-\end{verbatim}
+\end{lstlisting}
in the main daemon configuration resource (Director for the Director,
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 also do TLS authentication, then TLS
+authentication, \mbacula{} 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.
+the two \mbacula{} daemons will be done without encryption.
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}
+\subsection{bextract non-portable Win32 data}
\index[general]{bextract handles Win32 non-portable data}
+\index[general]{Win32!bextract handles non-portable data}
{\bf bextract} has been enhanced to be able to restore
-non-portable Win32 data to any OS. Previous versions were
+non-portable Win32 data to any OS. Previous versions were
unable to restore non-portable Win32 data to machines that
did not have the Win32 BackupRead and BackupWrite API calls.
-\section{State File updated at Job Termination}
-\index[general]{State File}
-In previous versions of Bacula, the state file, which provides a
+\subsection{State File updated at Job Termination}
+\index[general]{State file}
+In previous versions of \mbacula{}, the state file, which provides a
summary of previous jobs run in the {\bf status} command output was
-updated only when Bacula terminated, thus if the daemon crashed, the
+updated only when \mbacula{} terminated, thus if the daemon crashed, the
state file might not contain all the run data. This version of
-the Bacula daemons updates the state file on each job termination.
+the \mbacula{} daemons updates the state file on each job termination.
-\section{MaxFullInterval = \lt{}time-interval\gt{}}
+\subsection{MaxFullInterval = \lt{}time-interval\gt{}}
\index[general]{MaxFullInterval}
The new Job resource directive {\bf Max Full Interval = \lt{}time-interval\gt{}}
can be used to specify the maximum time interval between {\bf Full} backup
{\bf Incremental} or {\bf Differential}, it will be automatically
upgraded to a {\bf Full} backup.
-\section{MaxDiffInterval = \lt{}time-interval\gt{}}
+\subsection{MaxDiffInterval = \lt{}time-interval\gt{}}
\index[general]{MaxDiffInterval}
The new Job resource directive {\bf Max Diff Interval = \lt{}time-interval\gt{}}
can be used to specify the maximum time interval between {\bf Differential} backup
{\bf Incremental}, it will be automatically
upgraded to a {\bf Differential} backup.
-\section{Honor No Dump Flag = \lt{}yes\vb{}no\gt{}}
+\subsection{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
-to not backup that particular file. This version of Bacula contains a
-new Options directive within a FileSet resource, which instructs Bacula to
+to not backup that particular file. This version of \mbacula{} contains a
+new Options directive within a FileSet resource, which instructs \mbacula{} to
obey this flag. The new directive is:
-\begin{verbatim}
+\begin{lstlisting}
Honor No Dump Flag = yes\vb{}no
-\end{verbatim}
+\end{lstlisting}
The default value is {\bf no}.
-\section{Exclude Dir Containing = \lt{}filename-string\gt{}}
+\subsection{Exclude Dir Containing = \lt{}filename-string\gt{}}
\index[general]{IgnoreDir}
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:
-\begin{verbatim}
+\begin{lstlisting}
# List of files to be backed up
FileSet {
Name = "MyFileSet"
Exclude Dir Containing = .excludeme
}
}
-\end{verbatim}
+\end{lstlisting}
But in /home, there may be hundreds of directories of users and some
people want to indicate that they don't want to have certain
directories backed up. For example, with the above FileSet, if
-the user or sysadmin creates a file named {\bf .excludeme} in
+the user or sysadmin creates a file named {\bf .excludeme} in
specific directories, such as
-\begin{verbatim}
+\begin{lstlisting}
/home/user/www/cache/.excludeme
/home/user/temp/.excludeme
-\end{verbatim}
+\end{lstlisting}
-then Bacula will not backup the two directories named:
+then \mbacula{} will not backup the two directories named:
-\begin{verbatim}
+\begin{lstlisting}
/home/user/www/cache
/home/user/temp
-\end{verbatim}
+\end{lstlisting}
NOTE: subdirectories will not be backed up. That is, the directive
applies to the two directories in question and any children (be they
files, directories, etc).
-\section{Bacula Plugins}
+\subsection{Bacula Plugins}
\index[general]{Plugin}
Support for shared object plugins has been implemented in the Linux, Unix
and Win32 File daemons. The API will be documented separately in
get control to backup and restore a file.
Plugins are also planned (partially implemented) in the Director and the
-Storage daemon.
+Storage daemon.
-\subsection{Plugin Directory}
+\subsubsection{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
+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
-find the Bacula plugins. If this directive is not specified, Bacula will not
+find the \mbacula{} plugins. If this directive is not specified, \mbacula{} will not
load any plugins. Since each plugin has a distinctive name, all the daemons
-can share the same plugin directory.
+can share the same plugin directory.
-\subsection{Plugin Options}
+\subsubsection{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
+argument (after the equal sign) and may be specified in the
Job resource. The options specified will be passed to all plugins
when they are run. This each plugin must know what it is looking
for. The value defined in the Job resource can be modified
-by the user when he runs a Job via the {\bf bconsole} command line
+by the user when he runs a Job via the {\bf bconsole} command line
prompts.
Note: this directive may be specified, and there is code to modify
the string in the run command, but the plugin options are not yet passed to
the plugin (i.e. not fully implemented).
-\subsection{Plugin Options ACL}
+\subsubsection{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
+do by permitting users running restricted consoles to specify a
{\bf Plugin Options} that overrides the one specified in the Job
definition. Without this directive restricted consoles may not modify
the Plugin Options.
-\subsection{Plugin = \lt{}plugin-command-string\gt{}}
+\subsubsection{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:
-\begin{verbatim}
+\begin{lstlisting}
FileSet {
Name = "MyFileSet"
Include {
Plugin = "bpipe:..."
}
}
-\end{verbatim}
+\end{lstlisting}
In the above example, when the File daemon is processing the directives
in the Include section, it will first backup all the files in {\bf /home}
is passed to the plugin. Thus the plugin writer may define the meaning of the
rest of the string as he wishes.
-Please see the next section for information about the {\bf bpipe} Bacula
+Please see the next section for information about the {\bf bpipe} \mbacula{}
plugin.
-\section{The bpipe Plugin}
-\index[general]{The bpipe Plugin}
+\subsection{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 \mbacula{} 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}.
+Please note that this is a very simple plugin that was written for
+demonstration and test purposes. It is and can be used in production, but
+that was never really intended.
The purpose of the plugin is to provide an interface to any system program for
backup and restore. As specified above the {\bf bpipe} plugin is specified in
plugin directive as interpreted by the {\bf bpipe} plugin (each plugin is free
to specify the sytax as it wishes) is:
-\begin{verbatim}
+\begin{lstlisting}
Plugin = "<field1>:<field2>:<field3>:<field4>"
-\end{verbatim}
+\end{lstlisting}
where
\begin{description}
You must be careful to choose a naming convention that is unique to avoid
a conflict with a path and filename that actually exists on your system.
-\item {\bf field3} for the {\bf bpipe} plugin
+\item {\bf field3} for the {\bf bpipe} plugin
specifies the "reader" program that is called by the plugin during
backup to read the data. {\bf bpipe} will call this program by doing a
{\bf popen} on it.
\item {\bf field4} for the {\bf bpipe} plugin
specifies the "writer" program that is called by the plugin during
-restore to write the data back to the filesystem.
+restore to write the data back to the filesystem.
\end{description}
+Please note that for two items above describing the "reader" and "writer"
+fields, these programs are "executed" by \mbacula{}, which
+means there is no shell interpretation of any command line arguments
+you might use. If you want to use shell characters (redirection of input
+or output, \ldots{}), then we recommend that you put your command or commands
+in a shell script and execute the script. In addition if you backup a
+file with the reader program, when running the writer program during
+the restore, \mbacula{} will not automatically create the path to the file.
+Either the path must exist, or you must explicitly do so with your command
+or in a shell script.
+
Putting it all together, the full plugin directive line might look
like the following:
-\begin{verbatim}
-Plugin = "bpipe:/MYSQL/regress.sql:mysqldump -f
+\begin{lstlisting}
+Plugin = "bpipe:/MYSQL/regress.sql:mysqldump -f
--opt --databases bacula:mysql"
-\end{verbatim}
+\end{lstlisting}
The directive has been split into two lines, but within the {\bf bacula-dir.conf} file
would be written on a single line.
This causes the File daemon to call the {\bf bpipe} plugin, which will write
-its data into the "pseudo" file {\bf /MYSQL/regress.sql} by calling the
+its data into the "pseudo" file {\bf /MYSQL/regress.sql} by calling the
program {\bf mysqldump -f --opt --database bacula} to read the data during
backup. The mysqldump command outputs all the data for the database named
{\bf bacula}, which will be read by the plugin and stored in the backup.
then write it back to the same database from which it came ({\bf bacula}
in this case).
-The {\bf bpipe} plugin is a generic pipe program, that simply transmits
-the data from a specified program to Bacula for backup, and then from Bacula to
+The {\bf bpipe} plugin is a generic pipe program, that simply transmits
+the data from a specified program to \mbacula{} for backup, and then from \mbacula{} to
a specified program for restore.
By using different command lines to {\bf bpipe},
you can backup any kind of data (ASCII or binary) depending
on the program called.
-\section{Microsoft Exchange Server 2003/2007 Plugin}
-\index[general]{Microsoft Exchange Server 2003/2007 Plugin}
-\subsection{Background}
+\subsection{Microsoft Exchange Server 2003/2007 Plugin}
+\index[general]{Microsoft Exchange Server 2003/2007 plugin}
+\subsubsection{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
+The code for the plugin was written by James Harper, and the \mbacula{} 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.
+part of the \mbacula{} project. Thanks to everyone who made it happen.
-\subsection{Concepts}
-Although it is possible to backup Exchange using Bacula VSS the Exchange
-plugin adds a good deal of functionality, because while Bacula VSS
+\subsubsection{Concepts}
+Although it is possible to backup Exchange using \mbacula{} VSS the Exchange
+plugin adds a good deal of functionality, because while \mbacula{} VSS
completes a full backup (snapshot) of Exchange, it does
not support Incremental or Differential backups, restoring is more
complicated, and a single database restore is not possible.
Microsoft Exchange organises its storage into Storage Groups with
Databases inside them. A default installation of Exchange will have a
single Storage Group called 'First Storage Group', with two Databases
-inside it, "Mailbox Store (SERVER NAME)" and
-"Public Folder Store (SERVER NAME)",
+inside it, "Mailbox Store (SERVER NAME)" and
+"Public Folder Store (SERVER NAME)",
which hold user email and public folders respectively.
In the default configuration, Exchange logs everything that happens to
restoring at the individual mailbox or email item is not supported but
can be simulated by use of the "Recovery" Storage Group (see below).
-\subsection{Installing}
+\subsubsection{Installing}
The Exchange plugin requires a DLL that is shipped with Microsoft
Exchanger Server called {\bf esebcli2.dll}. Assuming Exchange is installed
correctly the Exchange plugin should find this automatically and run
without any additional installation.
If the DLL can not be found automatically it will need to be copied into
-the Bacula installation
-directory (eg C:\verb+\+Program Files\verb+\+Bacula\verb+\+bin). The Exchange API DLL is
-named esebcli2.dll and is found in C:\verb+\+Program Files\verb+\+Exchsrvr\verb+\+bin on a
+the \mbacula{} installation
+directory (eg C:\lstinline+\+Program Files\lstinline+\+Bacula\lstinline+\+bin). The Exchange API DLL is
+named esebcli2.dll and is found in C:\lstinline+\+Program Files\lstinline+\+Exchsrvr\lstinline+\+bin on a
default Exchange installation.
-\subsection{Backing Up}
+\subsubsection{Backing Up}
To back up an Exchange server the Fileset definition must contain at
least {\bf Plugin = "exchange:/@EXCHANGE/Microsoft Information Store"} for
-the backup to work correctly. The 'exchange:' bit tells Bacula to look
+the backup to work correctly. The 'exchange:' bit tells \mbacula{} to look
for the exchange plugin, the '@EXCHANGE' bit makes sure all the backed
up files are prefixed with something that isn't going to share a name
with something outside the plugin, and the 'Microsoft Information Store'
done, and may also truncate log files incorrectly. It is important,
therefore, that the Exchange database files be excluded from the backup,
although the folders the files are in should be included, or they will
-have to be recreated manually if a baremetal restore is done.
+have to be recreated manually if a bare metal restore is done.
-\begin{verbatim}
+\begin{lstlisting}
FileSet {
Include {
File = C:/Program Files/Exchsrvr/mdbdata
File = C:/Program Files/Exchsrvr/mdbdata/priv1.edb
}
}
-\end{verbatim}
+\end{lstlisting}
The advantage of excluding the above files is that you can significantly
reduce the size of your backup since all the important Exchange files
will be properly saved by the Plugin.
-\subsection{Restoring}
-The restore operation is much the same as a normal Bacula restore, with
+\subsubsection{Restoring}
+The restore operation is much the same as a normal \mbacula{} restore, with
the following provisos:
-\begin{itemize}
+\begin{bsysitemize}
\item The {\bf Where} restore option must not be specified
\item Each Database directory must be marked as a whole. You cannot just
select (say) the .edb file and not the others.
overwritten by restore"
\item If an entire Storage Group is to be restored (eg all databases and
logs in the Storage Group), then it is best to manually delete the
- database files from the server (eg C:\verb+\+Program Files\verb+\+Exchsrvr\verb+\+mdbdata\verb+\+*)
+ database files from the server (eg C:\lstinline+\+Program Files\lstinline+\+Exchsrvr\lstinline+\+mdbdata\lstinline+\+*)
as Exchange can get confused by stray log files lying around.
-\end{itemize}
+\end{bsysitemize}
-\subsection{Restoring to the Recovery Storage Group}
+\subsubsection{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},
-but to briefly summarize...
+Microsoft
+\elink{http://support.microsoft.com/kb/824126}{http://support.microsoft.com/kb/824126},
+but to briefly summarize\ldots{}
Microsoft Exchange allows the creation of an additional Storage Group
called the Recovery Storage Group, which is used to restore an older
To create the Recovery Storage Group, drill down to the Server in Exchange
System Manager, right click, and select
-{\bf "New -> Recovery Storage Group..."}. Accept or change the file
+{\bf "New -> Recovery Storage Group\ldots{}"}. Accept or change the file
locations and click OK. On the Recovery Storage Group, right click and
-select {\bf "Add Database to Recover..."} and select the database you will
+select {\bf "Add Database to Recover\ldots{}"} and select the database you will
be restoring.
Restore only the single database nominated as the database in the
Recovery Storage Group automatically.
Then run the restore.
-\subsection{Restoring on Microsoft Server 2007}
+\subsubsection{Restoring on Microsoft Server 2007}
Apparently the {\bf Exmerge} program no longer exists in Microsoft Server
-2007, and henc you use a new proceedure for recovering a single mail box.
-This procedure is ducomented by Microsoft at:
+2007, and hence you use a new procedure for recovering a single mail box.
+This procedure is documented by Microsoft at:
\elink{http://technet.microsoft.com/en-us/library/aa997694.aspx}{http://technet.microsoft.com/en-us/library/aa997694.aspx},
and involves using the {\bf Restore-Mailbox} and {\bf
-Get-MailboxStatistics} shell commands.
+Get-Mailbox Statistics} shell commands.
-\subsection{Caveats}
+\subsubsection{Caveats}
This plugin is still being developed, so you should consider it
currently in BETA test, and thus use in a production environment
should be done only after very careful testing.
will not be added to the estimate total that is displayed.
-\section{libdbi Framework}
-\index[general]{libdbi Framework}
-As a general guideline, Bacula has support for a few catalog database drivers
+\subsection{libdbi Framework}
+\index[general]{libdbi framework}
+As a general guideline, \mbacula{} has support for a few catalog database drivers
(MySQL, PostgreSQL, SQLite)
coded natively by the Bacula team. With the libdbi implementation, which is a
-Bacula driver that uses libdbi to access the catalog, we have an open field to
+\mbacula{} driver that uses libdbi to access the catalog, we have an open field to
use many different kinds database engines following the needs of users.
The according to libdbi (http://libdbi.sourceforge.net/) project: libdbi
connections by using this framework.
Currently the libdbi driver in Bacula project only supports the same drivers
-natively coded in Bacula. However the libdbi project has support for many
+natively coded in \mbacula{}. However the libdbi project has support for many
others database engines. You can view the list at
http://libdbi-drivers.sourceforge.net/. In the future all those drivers can be
supported by Bacula, however, they must be tested properly by the Bacula team.
Some of benefits of using libdbi are:
-\begin{itemize}
+\begin{bsysitemize}
\item The possibility to use proprietary databases engines in which your
proprietary licenses prevent the Bacula team from developing the driver.
\item The possibility to use the drivers written for the libdbi project.
- \item The possibility to use other database engines without recompiling Bacula
+ \item The possibility to use other database engines without recompiling \mbacula{}
to use them. Just change one line in bacula-dir.conf
\item Abstract Database access, this is, unique point to code and profiling
catalog database access.
- \end{itemize}
-
+ \end{bsysitemize}
+
The following drivers have been tested:
- \begin{itemize}
+ \begin{bsysitemize}
\item PostgreSQL, with and without batch insert
\item Mysql, with and without batch insert
\item SQLite
\item SQLite3
- \end{itemize}
+ \end{bsysitemize}
In the future, we will test and approve to use others databases engines
(proprietary or not) like DB2, Oracle, Microsoft SQL.
libdbi framework doesn't know the default access port of each database.
The next phase is checking (or configuring) the bacula-dir.conf, example:
-\begin{verbatim}
+\begin{lstlisting}
Catalog {
Name = MyCatalog
dbdriver = dbi:mysql; dbaddress = 127.0.0.1; dbport = 3306
dbname = regress; user = regress; password = ""
}
-\end{verbatim}
+\end{lstlisting}
The parameter {\bf dbdriver} indicates that we will use the driver dbi with a
-mysql database. Currently the drivers supported by Bacula are: postgresql,
+mysql database. Currently the drivers supported by \mbacula{} are: postgresql,
mysql, sqlite, sqlite3; these are the names that may be added to string "dbi:".
-The following limitations apply when Bacula is set to use the libdbi framework:
+The following limitations apply when \mbacula{} is set to use the libdbi framework:
- Not tested on the Win32 platform
- - A little performance is lost if comparing with native database driver.
- The reason is bound with the database driver provided by libdbi and the
+ - A little performance is lost if comparing with native database driver.
+ The reason is bound with the database driver provided by libdbi and the
simple fact that one more layer of code was added.
-It is important to remember, when compiling Bacula with libdbi, the
+It is important to remember, when compiling \mbacula{} with libdbi, the
following packages are needed:
- \begin{itemize}
+ \begin{bsysitemize}
\item libdbi version 1.0.0, http://libdbi.sourceforge.net/
\item libdbi-drivers 1.0.0, http://libdbi-drivers.sourceforge.net/
- \end{itemize}
-
+ \end{bsysitemize}
+
You can download them and compile them on your system or install the packages
from your OS distribution.
-\section{Console Command Additions and Enhancements}
-\index[general]{Console Additions}
+\subsection{Console Command Additions and Enhancements}
+\index[general]{Console additions}
-\subsection{Display Autochanger Content}
+\subsubsection{Display Autochanger Content}
\index[general]{StatusSlots}
The {\bf status slots storage=\lt{}storage-name\gt{}} command displays
autochanger content.
\footnotesize
-\begin{verbatim}
+\begin{lstlisting}
Slot | Volume Name | Status | Media Type | Pool |
------+---------------+----------+-------------------+------------|
1 | 00001 | Append | DiskChangerMedia | Default |
2 | 00002 | Append | DiskChangerMedia | Default |
3*| 00003 | Append | DiskChangerMedia | Scratch |
4 | | | | |
-\end{verbatim}
+\end{lstlisting}
\normalsize
If you an asterisk ({\bf *}) appears after the slot number, you must run an
{\bf update slots} command to synchronize autochanger content with your
catalog.
-\subsection{list joblog job=xxx or jobid=nnn}
+\subsubsection{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
the time and date of the entry.
-Note for the catalog to have Job Log entries, you must have a directive
+Note for the catalog to have Job Log entries, you must have a directive
such as:
-\begin{verbatim}
+\begin{lstlisting}
catalog = all
-\end{verbatim}
+\end{lstlisting}
In your Director's {\bf Messages} resource.
-\subsection{Use separator for multiple commands}
-\index[general]{Command Separator}
- When using bconsole with readline, you can set the command separator with
+\subsubsection{Use separator for multiple commands}
+\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}
+\begin{lstlisting}
!$%&'()*+,-/:;<>?[]^`{|}~
-\end{verbatim}
+\end{lstlisting}
-\subsection{Deleting Volumes}
+\subsubsection{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
This new behavior is indicated in the prompt if you read it
carefully.
-\section{Bare Metal Recovery}
+\subsection{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
+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.
+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.
+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.
+ 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.
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 ...
+ to the main manual. See below \ldots{}
\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{Miscellaneous}
+\index[general]{Misc new features}
-\subsection{Allow Mixed Priority = \lt{}yes\vb{}no\gt{}}
+\subsubsection{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
the running jobs finishes. However, new priority 10 jobs will not
be run until the priority 5 job has finished.
-\subsection{Bootstrap File Directive -- FileRegex}
-\index[general]{Bootstrap File Directive}
+\subsubsection{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.
During a restore, if all File records are pruned from the catalog
- for a Job, normally Bacula can restore only all files saved. That
+ for a Job, normally \mbacula{} can restore only all files saved. That
is there is no way using the catalog to select individual files.
- With this new feature, Bacula will ask if you want to specify a Regex
+ With this new feature, \mbacula{} will ask if you want to specify a Regex
expression for extracting only a part of the full backup.
-\begin{verbatim}
+\begin{lstlisting}
Building directory tree for JobId(s) 1,3 ...
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\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
-\end{verbatim}
+\end{lstlisting}
-\subsection{Bootstrap File Optimization Changes}
+\subsubsection{Bootstrap File Optimization Changes}
In order to permit proper seeking on disk files, we have extended the bootstrap
file format to include a {\bf VolStartAddr} and {\bf VolEndAddr} records. Each
takes a 64 bit unsigned integer range (i.e. nnn-mmm) which defines the start
format (automatically generated by the new Director), restores will seek
properly and stop reading the volume when all the files have been restored.
-\subsection{Solaris ZFS/NFSv4 ACLs}
+\subsubsection{Solaris ZFS/NFSv4 ACLs}
This is an upgrade of the previous Solaris ACL backup code
to the new library format, which will backup both the old
POSIX(UFS) ACLs as well as the ZFS ACLs.
be used to transfer from UFS to ZFS filesystems.
-\subsection{Virtual Tape Emulation}
-\index[general]{Virtual Tape Emulation}
+\subsubsection{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
directive. This feature is only implemented on Linux machines and should not be
used for production.
-\subsection{Bat Enhancements}
-\index[general]{Bat Enhancements}
+\subsubsection{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
+enhanced and stabilized. In particular, there are new table based status
commands; it can now be easily localized using Qt4 Linguist.
The Bat communications protocol has been significantly enhanced to improve
the Director you are using otherwise the communications protocol will not
work.
-\subsection{RunScript Enhancements}
-\index[general]{RunScript Enhancements}
+\subsubsection{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.
-\begin{verbatim}
+\begin{lstlisting}
Job {
Name = aJob
RunScript {
}
...
}
-\end{verbatim}
+\end{lstlisting}
A new Client RunScript {\bf RunsWhen} keyword of {\bf AfterVSS} has been
implemented, which runs the command after the Volume Shadow Copy has been made.
Console commands can be specified within a RunScript by using:
-{\bf Console = \lt{}command\gt{}}, however, this command has not been
+{\bf Console = \lt{}command\gt{}}, however, this command has not been
carefully tested and debugged and is known to easily crash the Director.
We would appreciate feedback. Due to the recursive nature of this command, we
may remove it before the final release.
-\subsection{Status Enhancements}
-\index[general]{Status Enhancements}
+\subsubsection{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}
+\subsubsection{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}
+\subsubsection{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
+properly truncated because NFS does not implement ftruncate (file
truncate). This is now corrected in the new version because we have
written code (actually a kind user) that deletes and recreates the Volume,
thus accomplishing the same thing as a truncate.
-\subsection{Support for Ubuntu}
-The new version of Bacula now recognizes the Ubuntu (and Kubuntu)
+\subsubsection{Support for Ubuntu}
+The new version of \mbacula{} now recognizes the Ubuntu (and Kubuntu)
version of Linux, and thus now provides correct autostart routines.
-Since Ubuntu officially supports Bacula, you can also obtain any
+Since Ubuntu officially supports \mbacula{}, you can also obtain any
recent release of Bacula from the Ubuntu repositories.
-\subsection{Recycle Pool = \lt{}pool-name\gt{}}
+\subsubsection{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
probably most useful when defined in the Scratch pool, so that volumes will
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,
+\subsubsection{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{}}
+\subsubsection{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{}}
+\subsubsection{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,
\textbf{Incr/Diff/Full Max Run Time}. \textbf{Incr/Diff/Full Max Wait Time}
directives are now deprecated.
-\subsection{Incremental|Differential Max Wait Time = \lt{}time-period-in-seconds\gt{}}
+\subsubsection{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}
+\subsubsection{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.
-\addcontentsline{lof}{figure}{Job time control directives}
-\includegraphics{\idir different_time.eps}
+%\addcontentsline{lof}{figure}{Job time control directives}
+%\includegraphics{\idir different_time}
+\bsysimageH{different_time}{Job time control directives}{figcom:different_time}
-\subsection{Statistics Enhancements}
-\index[general]{Statistics Enhancements}
+\subsubsection{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:
-\begin{itemize}
+\begin{bsysitemize}
\item jobs have run
\item jobs have been successful
\item files have been backed up
-\item ...
-\end{itemize}
+\item \ldots{}
+\end{bsysitemize}
However, these statistics are accurate only if your job retention is greater
than your statistics period. Ie, if jobs are purged from the catalog, you won't
-be able to use them.
+be able to use them.
Now, you can use the \textbf{update stats [days=num]} console command to fill
the JobHistory table with new Job records. If you want to be sure to take in
can also use tools like Talend or extract information by yourself.
The \textbf{Statistics Retention = \lt{}time\gt{}} director directive defines
-the length of time that Bacula will keep statistics job records in the Catalog
+the length of time that \mbacula{} 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
+period expires, and if user runs \texttt{prune stats} command, \mbacula{} will
prune (remove) Job records that are older than the specified period.
You can use the following Job resource in your nightly \textbf{BackupCatalog}
job to maintain statistics.
-\begin{verbatim}
+\begin{lstlisting}
Job {
Name = BackupCatalog
...
RunsOnClient = no
}
}
-\end{verbatim}
+\end{lstlisting}
-\subsection{ScratchPool = \lt{}pool-resource-name\gt{}}
+\subsubsection{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}
+\subsubsection{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{}}
+\subsubsection{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}
+\subsubsection{MaximumConsoleConnections = \lt{}number\gt{}}
+\index[general]{MaximumConsoleConnections}
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{}}
+\subsubsection{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}
+\subsubsection{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.
+temporary indexes to speed up orphaned Path and Filename elimination.
A new \texttt{-B} option allows you to print catalog information in a simple
text based format. This is useful to backup it in a secure way.
-\begin{verbatim}
- $ dbcheck -B
+\begin{lstlisting}
+ $ dbcheck -B
catalog=MyCatalog
db_type=SQLite
db_name=regress
db_address=
db_port=0
db_socket=
-\end{verbatim} %$
+\end{lstlisting} %$
You can now specify the database connection port in the command line.
-\subsection{{-}{-}docdir configure option}
+\subsubsection{{-}{-}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
+specify the directory where you want \mbacula{} to install the
+LICENSE, ReleaseNotes, ChangeLog, \ldots{} files. The default is
{\bf /usr/share/doc/bacula}.
-
-\subsection{{-}{-}htmldir configure option}
+
+\subsubsection{{-}{-}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
+specify the directory where you want \mbacula{} to install the bat html help
files. The default is {\bf /usr/share/doc/bacula/html}
-\subsection{{-}{-}with-plugindir configure option}
+\subsubsection{{-}{-}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
+specify the directory where you want \mbacula{} to install
the plugins (currently only bpipe-fd). The default is
/usr/lib.
projects / bacula / docs / blobdiff