+\chapter{New Features in 7.2.0}
+This chapter presents the new features that have been added to
+the various versions of Bacula.
+
+\section{New Features in 7.2.0}
+\section{Bacula Enterprise 8.3}
+
+\subsection{New Job Edit Codes \%E \%R}
+In various places such as RunScripts, you have now access to \%E to get the
+number of non-fatal errors for the current Job and \%R to get the number of
+bytes read from disk or from the network during a job.
+
+\subsection{Enable/Disable commands}
+The \textbf{bconsole} \textbf{enable} and \textbf{disable} commands have
+been extended from enabling/disabling Jobs to include Clients, Schedule,
+and Storage devices. Examples:
+
+\begin{verbatim}
+ disable Job=NightlyBackup Client=Windows-fd
+\end{verbatim}
+
+will disable the Job named \textbf{NightlyBackup} as well as the
+client named \textbf{Windows-fd}.
+
+\begin{verbatim}
+ disable Storage=LTO-changer Drive=1
+\end{verbatim}
+
+will disable the first drive in the autochanger named \textbf{LTO-changer}.
+
+Please note that doing a \textbf{reload} command will set any values
+changed by the enable/disable commands back to the values in the
+bacula-dir.conf file.
+
+The Client and Schedule resources in the bacula-dir.conf file now permit
+the directive Enable = yes or Enable = no.
+
+
+\section{Bacula 7.2}
+
+\subsection{Snapshot Management}
+
+Bacula 7.2 is now able to handle Snapshots on Linux/Unix
+systems. Snapshots can be automatically created and used to backup files. It is
+also possible to manage Snapshots from Bacula's \texttt{bconsole} tool through a
+unique interface.
+
+\subsubsection{Snapshot Backends}
+
+The following Snapshot backends are supported with Bacula:
+
+\begin{itemize}
+\item BTRFS
+\item ZFS
+\item LVM\footnote{Some restrictions described in \vref{LVMBackend} applies to
+ the LVM backend}
+\end{itemize}
+
+By default, Snapshots are mounted (or directly available) under
+\textbf{.snapshots} directory on the root filesystem. (On ZFS, the default
+is \textbf{.zfs/snapshots}).
+
+\smallskip{}
+
+The Snapshot backend program is called \textbf{bsnapshot} and is available in
+the \textbf{bacula-enterprise-snapshot} package. In order to use the Snapshot
+Management feature, the package must be installed on the Client.
+
+\smallskip{}
+\label{bsnapshotconf}
+The \textbf{bsnapshot} program can be configured using
+\texttt{/opt/bacula/etc/bsnapshot.conf} file. The following parameters can
+be adjusted in the configuration file:
+
+\begin{itemize}
+\item \texttt{trace=<file>} Specify a trace file
+\item \texttt{debug=<num>} Specify a debug level
+\item \texttt{sudo=<yes/no>} Use sudo to run commands
+\item \texttt{disabled=<yes/no>} Disable snapshot support
+\item \texttt{retry=<num>} Configure the number of retries for some operations
+\item \texttt{snapshot\_dir=<dirname>} Use a custom name for the Snapshot directory. (\textbf{.SNAPSHOT}, \textbf{.snapdir}, etc...)
+\item \texttt{lvm\_snapshot\_size=<lvpath:size>} Specify a custom snapshot size for a given LVM volume
+\end{itemize}
+
+\begin{verbatim}
+# cat /opt/bacula/etc/bsnapshot.conf
+trace=/tmp/snap.log
+debug=10
+lvm_snapshot_size=/dev/ubuntu-vg/root:5%
+\end{verbatim}
+
+\subsubsection{Application Quiescing}
+
+When using Snapshots, it is very important to quiesce applications that are
+running on the system. The simplest way to quiesce an application is to stop
+it. Usually, taking the Snapshot is very fast, and the downtime is only about a
+couple of seconds. If downtime is not possible and/or the application provides
+a way to quiesce, a more advanced script can be used. An example is
+described on \vref{SnapRunScriptExample}.
+
+\subsubsection{New Director Directives}
+
+The use of the Snapshot Engine on the FileDaemon is determined by the
+new \textbf{Enable Snapshot} FileSet directive. The default is \textbf{no}.
+
+\begin{verbatim}
+FileSet {
+ Name = LinuxHome
+
+ Enable Snapshot = yes
+
+ Include {
+ Options = { Compression = LZO }
+ File = /home
+ }
+}
+\end{verbatim}
+
+By default, Snapshots are deleted from the Client at the end of the backup. To
+keep Snapshots on the Client and record them in the Catalog for a determined
+period, it is possible to use the \textbf{Snapshot Retention} directive in the
+Client or in the Job resource. The default value is 0 secconds. If, for a given Job,
+both Client and Job \textbf{Snapshot Retention} directives are set, the Job
+directive will be used.
+
+\begin{verbatim}
+Client {
+ Name = linux1
+ ...
+
+ Snapshot Retention = 5 days
+}
+\end{verbatim}
+
+To automatically prune Snapshots, it is possible to use the following RunScript
+command:
+
+\begin{verbatim}
+Job {
+ ...
+ Client = linux1
+ ...
+ RunScript {
+ RunsOnClient = no
+ Console = "prune snapshot client=%c yes"
+ RunsAfter = yes
+ }
+}
+\end{verbatim}
+
+
+\smallskip{}
+
+
+
+In RunScripts, the \texttt{AfterSnapshot} keyword for the \texttt{RunsWhen} directive will
+allow a command to be run just after the Snapshot creation. \\texttt{AfterSnapshot} is a
+synonym for the \texttt{AfterVSS} keyword.
+
+\label{SnapRunScriptExample}
+\begin{verbatim}
+Job {
+ ...
+ RunScript {
+ Command = "/etc/init.d/mysql start"
+ RunsWhen = AfterSnapshot
+ RunsOnClient = yes
+ }
+ RunScript {
+ Command = "/etc/init.d/mysql stop"
+ RunsWhen = Before
+ RunsOnClient = yes
+ }
+}
+\end{verbatim}
+
+\subsubsection{Job Output Information}
+
+Information about Snapshots are displayed in the Job output. The list of all
+devices used by the Snapshot Engine is displayed, and the Job summary
+indicates if Snapshots were available.
+
+\begin{verbatim}
+JobId 3: Create Snapshot of /home/build
+JobId 3: Create Snapshot of /home/build/subvol
+JobId 3: Delete snapshot of /home/build
+JobId 3: Delete snapshot of /home/build/subvol
+...
+JobId 3: Bacula 127.0.0.1-dir 7.2.0 (23Jul15):
+ Build OS: x86_64-unknown-linux-gnu archlinux
+ JobId: 3
+ Job: Incremental.2015-02-24_11.20.27_08
+ Backup Level: Full
+...
+ Snapshot/VSS: yes
+...
+ Termination: Backup OK
+\end{verbatim}
+
+
+\subsubsection{New ``snapshot'' Bconsole Commands}
+
+The new \textbf{snapshot} command will display by default the following menu:
+\begin{verbatim}
+*snapshot
+Snapshot choice:
+ 1: List snapshots in Catalog
+ 2: List snapshots on Client
+ 3: Prune snapshots
+ 4: Delete snapshot
+ 5: Update snapshot parameters
+ 6: Update catalog with Client snapshots
+ 7: Done
+Select action to perform on Snapshot Engine (1-7):
+\end{verbatim}
+
+The \textbf{snapshot} command can also have the following parameters:
+\begin{verbatim}
+[client=<client-name> | job=<job-name> | jobid=<jobid>]
+ [delete | list | listclient | prune | sync | update]
+\end{verbatim}
+
+It is also possible to use traditional \texttt{list}, \texttt{llist},
+\texttt{update}, \texttt{prune} or \texttt{delete} commands on Snapshots.
+
+\begin{verbatim}
+*llist snapshot jobid=5
+ snapshotid: 1
+ name: NightlySave.2015-02-24_12.01.00_04
+ createdate: 2015-02-24 12:01:03
+ client: 127.0.0.1-fd
+ fileset: Full Set
+ jobid: 5
+ volume: /home/.snapshots/NightlySave.2015-02-24_12.01.00_04
+ device: /home/btrfs
+ type: btrfs
+ retention: 30
+ comment:
+\end{verbatim}
+
+\begin{verbatim}
+* snapshot listclient
+Automatically selected Client: 127.0.0.1-fd
+Connecting to Client 127.0.0.1-fd at 127.0.0.1:8102
+Snapshot NightlySave.2015-02-24_12.01.00_04:
+ Volume: /home/.snapshots/NightlySave.2015-02-24_12.01.00_04
+ Device: /home
+ CreateDate: 2015-02-24 12:01:03
+ Type: btrfs
+ Status: OK
+ Error:
+\end{verbatim}
+
+\smallskip{}
+
+With the \textsl{Update catalog with Client snapshots} option (or
+\textbf{snapshot sync}), the Director contacts the FileDaemon, lists snapshots
+of the system and creates catalog records of the Snapshots.
+
+\begin{verbatim}
+*snapshot sync
+Automatically selected Client: 127.0.0.1-fd
+Connecting to Client 127.0.0.1-fd at 127.0.0.1:8102
+Snapshot NightlySave.2015-02-24_12.35.47_06:
+ Volume: /home/.snapshots/NightlySave.2015-02-24_12.35.47_06
+ Device: /home
+ CreateDate: 2015-02-24 12:35:47
+ Type: btrfs
+ Status: OK
+ Error:
+Snapshot added in Catalog
+
+*llist snapshot
+ snapshotid: 13
+ name: NightlySave.2015-02-24_12.35.47_06
+ createdate: 2015-02-24 12:35:47
+ client: 127.0.0.1-fd
+ fileset:
+ jobid: 0
+ volume: /home/.snapshots/NightlySave.2015-02-24_12.35.47_06
+ device: /home
+ type: btrfs
+ retention: 0
+ comment:
+\end{verbatim}
+
+% list
+% llist
+% prune
+% delete
+% update snapshot
+% sync
+
+\subsubsection{LVM Backend Restrictions}
+\label{LVMBackend}
+
+LVM Snapshots are quite primitive compared to ZFS, BTRFS, NetApp and other
+systems. For example, it is not possible to use Snapshots if the Volume Group
+(VG) is full. The administrator must keep some free space in the VG
+to create Snapshots. The amount of free space required depends on the activity of the
+Logical Volume (LV). \textbf{bsnapshot} uses 10\% of the LV by
+default. This number can be configured per LV in the
+\textbf{bsnapshot.conf} file (See \vref{bsnapshotconf}).
+
+% waa - 20150316 - Not exactly sure why this vgdisplay information is here with no explanation.
+\begin{verbatim}
+[root@system1]# vgdisplay
+ --- Volume group ---
+ VG Name vg_ssd
+ System ID
+ Format lvm2
+...
+ VG Size 29,81 GiB
+ PE Size 4,00 MiB
+ Total PE 7632
+ Alloc PE / Size 125 / 500,00 MiB
+ Free PE / Size 7507 / 29,32 GiB
+...
+\end{verbatim}
+
+It is also not advisable to leave snapshots on the LVM backend. Having multiple
+snapshots of the same LV on LVM will slow down the system.
+
+\subsubsection{Debug Options}
+
+To get low level information about the Snapshot Engine, the debug tag ``snapshot''
+should be used in the \textbf{setdebug} command.
+
+\begin{verbatim}
+* setdebug level=10 tags=snapshot client
+* setdebug level=10 tags=snapshot dir
+\end{verbatim}
+
+\subsection{Minor Enhancements}
+\subsubsection{Storage Daemon Reports Disk Usage}
+
+The \texttt{status storage} command now reports the space available on disk devices:
+\begin{verbatim}
+...
+Device status:
+
+Device file: "FileStorage" (/bacula/arch1) is not open.
+ Available Space=5.762 GB
+==
+
+Device file: "FileStorage1" (/bacula/arch2) is not open.
+ Available Space=5.862 GB
+\end{verbatim}
+
+
\chapter{New Features in 7.0.0}
This chapter presents the new features that have been added to
the various versions of Bacula.
projects / bacula / docs / commitdiff