From: Kern Sibbald Date: Tue, 11 Aug 2015 13:42:22 +0000 (+0200) Subject: Add new features X-Git-Tag: Release-7.2.0~2 X-Git-Url: https://git.sur5r.net/?a=commitdiff_plain;h=aa31b403eea56b3a2cd14a957e95b907a140875e;p=bacula%2Fdocs Add new features --- diff --git a/docs/manuals/en/main/newfeatures.tex b/docs/manuals/en/main/newfeatures.tex index 803cf094..593ae369 100644 --- a/docs/manuals/en/main/newfeatures.tex +++ b/docs/manuals/en/main/newfeatures.tex @@ -1,3 +1,353 @@ +\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=} Specify a trace file +\item \texttt{debug=} Specify a debug level +\item \texttt{sudo=} Use sudo to run commands +\item \texttt{disabled=} Disable snapshot support +\item \texttt{retry=} Configure the number of retries for some operations +\item \texttt{snapshot\_dir=} Use a custom name for the Snapshot directory. (\textbf{.SNAPSHOT}, \textbf{.snapdir}, etc...) +\item \texttt{lvm\_snapshot\_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= | job= | 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.