\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{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}).
+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}
\caption{Bat Brestore Panel}
\end{figure}
-\texttt{Important}, the Bvfs module does not yet work correctly 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.
.bvfs_cleanup path=b20001
\end{verbatim}
+\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
\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.
+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.
+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.
+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}
projects / bacula / docs / blobdiff