-\chapter{Community Bacula New Features in 5.1.x}
-This chapter presents the new features that have been added to the
-current Community version of Bacula that is under development. This version will be
-released at some later date, probably near the end of April 2011.
+\chapter{New Features in 5.2.x}
+This chapter presents the new features that have been added to the next
+Community version of Bacula that is not yet released.
+
+\chapter{New Features in 5.2.2}
+This chapter presents the new features that have been added to the current
+Community version of Bacula that is now released.
+
+\section{Additions to RunScript variables}
+You can have access to Director name using \%D in your runscript
+command.
+
+\begin{verbatim}
+RunAfterJob = "/bin/echo Director=%D
+\end{verbatim}
+
+\chapter{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.
-\section{Restart Incomplete Job}
+\section{LZO Compression}
+
+LZO compression was added in the Unix File Daemon. From the user point of view,
+it works like the GZIP compression (just replace {\bf compression=GZIP} with
+{\bf compression=LZO}).
+
+For example:
+\begin{verbatim}
+Include {
+ Options { compression=LZO }
+ File = /home
+ File = /data
+}
+\end{verbatim}
+
+LZO provides 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 built-in compression may be a better option.
+
+LZO is a good altenative for GZIP1 when you don't want to slow down your
+backup. On a modern CPU it should be able to run almost as fast as:
+\begin{itemize}
+\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{itemize}
+
+Note that bacula only use one compression level LZO1X-1.
\medskip
-This project was funded by Bacula Systems and is available with Bacula
-Enterprise Edition and Community Edition.
+The code for this feature was contributed by Laurent Papier.
\section{New Tray Monitor}
-Since the old integrated Windows tray monitor doesn't work anymore with
+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. This new version allows you to run Backup from
+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]
\caption{Run a Job through the new tray monitor}
\end{figure}
+
+To be able to run a job from the tray monitor, you need to
+allow specific commands in the Director monitor console:
+\begin{verbatim}
+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{verbatim}
+
\medskip
This project was funded by Bacula Systems and is available with Bacula
the Enterprise Edition and the Community Edition.
Selection Type = Job
Selection Pattern = ".*Save"
...
- Purge Migrated Job = yes
+ Purge Migration Job = yes
}
\end{verbatim}
\medskip
-This project was submited by Dunlap Blake, testing and documentation was funded
+This project was submited by Dunlap Blake; testing and documentation was funded
by Bacula Systems.
-\section{Job Bandwidth Limitation}
-
-The new {\bf Job Bandwidth Limitation} directive may be added to the File
-daemon's and/or Director's configuration to limit the bandwidth used by a Job on a
-Client. It can be set in the File daemon's conf file for all Jobs run
-in that File daemon, or it can be set for each Job in the
-Director's conf file.
-
-For example:
-\begin{verbatim}
-FileDaemon {
- Name = localhost-fd
- Working Directory = /some/path
- Pid Directory = /some/path
- ...
- Maximum Bandwidth Per Job = 5MB/s
-}
-\end{verbatim}
-
-The above example would cause any jobs running with the FileDaemon to not
-exceed 5MB/s of throughput when sending data to the Storage Daemon.
-
-You can specify the speed parameter in k/s, KB/s, m/s, MB/s.
-
-For example:
-\begin{verbatim}
-Job {
- Name = locahost-data
- FileSet = FS_localhost
- Accurate = yes
- ...
- Maximum Bandwidth = 5MB/s
- ...
-}
-\end{verbatim}
-
-The above example would cause Job \texttt{localhost-data} to not exceed 5MB/s
-of throughput when sending data from the File daemon to the Storage daemon.
-
-A new console command \texttt{setbandwidth} permits to set dynamically the
-maximum throughput of a running Job or for future jobs of a Client.
-
-\begin{verbatim}
-* setbandwidth limit=1000000 jobid=10
-\end{verbatim}
-
-The \texttt{limit} parameter is in KB/s.
-
-\medskip
-This project was funded by Bacula Systems and is available in
-the Enterprise Edition and the Community Edition.
-
-
-\section{SQL Catalog Enhancements}
-
-% TODO: Marco can explain more things
-Bacula uses a new catalog backend structure, it allows to build all SQL drivers
-with the same \texttt{./configure ; make} session.
-
-We also added cursor support for PostgreSQL backend, this improves memory usage
-for large installation.
-
\section{Changes in Bvfs (Bacula Virtual FileSystem)}
Bat has now a bRestore panel that uses Bvfs to display files and
-directories. It's still experimental.
+directories.
\begin{figure}[htbp]
\centering
\caption{Bat Brestore Panel}
\end{figure}
-\texttt{Important}, the Bvfs module is not currently compatible with BaseJobs,
-Copy and Migration jobs.
+the Bvfs module works correctly with BaseJobs, Copy and Migration jobs.
\medskip
This project was funded by Bacula Systems.
OK
\end{verbatim}
-\subsection*{Cleanup after restore}
+\subsection*{Cleanup after Restore}
To drop the table used by the restore command, you can use the
\texttt{.bvfs\_cleanup} command.
.bvfs_cleanup path=b20001
\end{verbatim}
-\section{Changes in the pruning algorithm}
+\subsection*{Clearing the BVFS Cache}
+
+To clear the BVFS cache, you can use the \texttt{.bvfs\_clear_cache} command.
+
+\begin{verbatim}
+.bvfs_clear_cache yes
+OK
+\end{verbatim}
+
+\section{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
Enterprise Edition and Community Edition.
\section{Additions to RunScript variables}
-You can have access to JobBytes and JobFiles using \%b and \%f in your runscript
+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{verbatim}
-RunAfterJob = "/bin/echo Job=%j JobBytes=%b JobFiles=%f ClientAddress=%h"
+RunAfterJob = "/bin/echo Job=%j JobBytes=%b JobFiles=%F ClientAddress=%h"
\end{verbatim}
%\section{Changes in drivetype.exe}
%\end{verbatim}
%
-\section{ACL/Extended Attributes}
-
-We added support for NFSv4 ACLs on FreeBSD 8.1 and IRIX extended attributes.
-
-This project was funded by Marco van Wieringen.
-
\section{Additions to the Plugin API}
The bfuncs structure has been extended to include a number of
new entrypoints.
for this purpose.
\end{description}
+\section{ACL enhancements}
+
+The following enhancements are made to the Bacula Filed with regards to
+Access Control Lists (ACLs)
+
+\begin{itemize}
+\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 possitives on detection. Also when acls
+ are detected no other acl checks are performed anymore.
+\end{itemize}
+
+\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.
+
+\section{XATTR enhancements}
+
+The following enhancements are made to the Bacula Filed with regards to
+Extended Attributes (XATTRs)
+
+\begin{itemize}
+\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 possitives on detection. Also when xattrs
+ are detected no other xattr checks are performed anymore.
+\end{itemize}
+
+\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.
+
+\section{Class Based Database Backend Drivers}
+
+The main Bacula Director code is independent of the SQL backend
+in version 5.2.0 and greater. This means that the Bacula 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{verbatim}
+ --with-sqlite3
+ --with-mysql
+ --with-postgresql
+\end{verbatim}
+
+Order of testing for databases is:
+\begin{itemize}
+\item postgresql
+\item mysql
+\item sqlite3
+\end{itemize}
+
+Each configured backend generates a file named:
+\verb+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
+\verb+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
+\verb+libbaccats-<version>.so+ e.g.
+
+An actual command, depending on your Bacula version might be:
+\begin{verbatim}
+ cp libbaccats-postgresql-5.2.2.so libbaccats-5.2.2.so
+\end{verbatim}
+
+where the \verb+5.2.2+ must be replaced by the Bacula release
+version number.
+
+Then you must update the default backend in the following files:
+
+\begin{verbatim}
+ create_bacula_database
+ drop_bacula_database
+ drop_bacula_tables
+ grant_bacula_privileges
+ make_bacula_tables
+ make_catalog_backup
+ update_bacula_tables
+\end{verbatim}
+
+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
+boundery 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.
+
+\section{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.
+
+%%
+%%
+%%% =====================================================================
+%%
+%%
+
+
\chapter{Release Version 5.0.3}
There are no new features in version 5.0.2. This version simply fixes a
\chapter{New Features in 5.0.0}
-\section{Maximum Concurent Jobs for Devices}
-\label{sec:maximumconcurentjobdevice}
+\section{Maximum Concurrent Jobs for Devices}
+\label{sec:maximumconcurrentjobdevice}
{\bf Maximum Concurrent Jobs} is a new Device directive in the Storage
Daemon configuration permits setting the maximum number of Jobs that can
projects / bacula / docs / blobdiff