week, if you want me to know sooner that you have contributed, please
send me an email directly: kern at sibbald dot com.
+ <p>
If you need an invoice, I can send you one, but in order to limit my
administrative work, I kindly request you to make a donation of at least
$200 before requesting an invoice. To obtain one, simply email me the exact
\section*{Console Configuration}
\label{_ChapterStart36}
-\index[general]{Configuration!Console }
-\index[general]{Console Configuration }
+\index[general]{Configuration!Console}
+\index[general]{Console Configuration}
\addcontentsline{toc}{section}{Console Configuration}
\subsection*{General}
-\index[general]{General }
+\index[general]{General}
\addcontentsline{toc}{subsection}{General}
The Console configuration file is the simplest of all the configuration files,
\subsection*{The Director Resource}
\label{DirectorResource3}
-\index[general]{Director Resource }
-\index[general]{Resource!Director }
+\index[general]{Director Resource}
+\index[general]{Resource!Director}
\addcontentsline{toc}{subsection}{Director Resource}
The Director resource defines the attributes of the Director running on the
\begin{description}
\item [Director]
- \index[console]{Director }
+ \index[console]{Director}
Start of the Director records.
\item [Name = \lt{}name\gt{}]
- \index[console]{Name }
+ \index[console]{Name}
The director name used to select among different Directors, otherwise, this
name is not used.
\item [DIRPort = \lt{}port-number\gt{}]
- \index[dir]{DIRPort }
+ \index[dir]{DIRPort}
Specify the port to use to connect to the Director. This value will most
likely already be set to the value you specified on the {\bf
\verb:--:with-base-port} option of the {\bf ./configure} command. This port must be
default is 9101 so this record is not normally specified.
\item [Address = \lt{}address\gt{}]
- \index[dir]{Address }
+ \index[dir]{Address}
Where the address is a host name, a fully qualified domain name, or a network
address used to connect to the Director.
\item [Password = \lt{}password\gt{}]
- \index[dir]{Password }
+ \index[dir]{Password}
Where the password is the password needed for the Director to accept the
Console connection. This password must be identical to the {\bf Password}
specified in the {\bf Director} resource of the
\normalsize
\subsection*{The ConsoleFont Resource}
-\index[general]{Resource!ConsoleFont }
-\index[general]{ConsoleFont Resource }
+\index[general]{Resource!ConsoleFont}
+\index[general]{ConsoleFont Resource}
\addcontentsline{toc}{subsection}{ConsoleFont Resource}
The ConsoleFont resource is available only in the GNOME version of the
\begin{description}
\item [ConsoleFont]
- \index[console]{ConsoleFont }
+ \index[console]{ConsoleFont}
Start of the ConsoleFont records.
\item [Name = \lt{}name\gt{}]
- \index[console]{Name }
+ \index[console]{Name}
The name of the font.
-\item [Font = \lt{}X-Window Font Specification\gt{}]
- \index[console]{Font }
+\item [Font = \lt{}Pango Font Name\gt{}]
+ \index[console]{Font}
The string value given here defines the desired font. It is specified in the
-standard cryptic X Window format. For example, the default specification is:
+Pango format. For example, the default specification is:
\footnotesize
\begin{verbatim}
-Font = "-misc-fixed-medium-r-normal-*-*-130-*-*-c-*-iso8859-1"
+Font = "LucidaTypewriter 9"
\end{verbatim}
\normalsize
Thanks to Phil Stracchino for providing the code for this feature.
-An actual example might be:
+An different example might be:
\footnotesize
\begin{verbatim}
ConsoleFont {
Name = Default
-Font = "-misc-fixed-medium-r-normal-*-*-130-*-*-c-*-iso8859-1"
+Font = "Monospace 10"
}
\end{verbatim}
\normalsize
\subsection*{The Console Resource}
\label{ConsoleResource}
-\index[general]{Console Resource }
-\index[general]{Resource!Console }
+\index[general]{Console Resource}
+\index[general]{Resource!Console}
\addcontentsline{toc}{subsection}{Console Resource}
As of Bacula version 1.33 and higher, there are three different kinds of
DIRport = 9101
Address = myserver
Password = "XXXXXXXXXXX" # no, really. this is not obfuscation.
- }
+}
Console {
Name = restricted-user
Password = "UntrustedUser"
- }
+}
\end{verbatim}
\normalsize
and do with Bacula.
\subsection*{Console Commands}
-\index[general]{Console Commands }
-\index[general]{Commands!Console }
+\index[general]{Console Commands}
+\index[general]{Commands!Console}
\addcontentsline{toc}{subsection}{Console Commands}
For more details on running the console and its commands, please see the
\subsection*{Sample Console Configuration File}
\label{SampleConfiguration2}
-\index[general]{File!Sample Console Configuration }
-\index[general]{Sample Console Configuration File }
+\index[general]{File!Sample Console Configuration}
+\index[general]{Sample Console Configuration File}
\addcontentsline{toc}{subsection}{Sample Console Configuration File}
An example Console configuration file might be the following:
The name of the pool. For most applications, you will use the default
pool name {\bf Default}. This directive is required.
-\item [Number of Volumes = \lt{}number\gt{}]
- \index[dir]{Number of Volumes }
- This directive specifies the number of volumes (tapes or files)
- contained in the pool. Normally, it is defined and updated
- automatically by the Bacula catalog handling routines.
-
\label{MaxVolumes}
\item [Maximum Volumes = \lt{}number\gt{}]
\index[dir]{Maximum Volumes }
\label{PoolRecycle}
\item [Recycle = \lt{}yes|no\gt{}]
\index[dir]{Recycle }
- This directive specifies whether or not Purged Volumes will be recycled.
+ This directive specifies whether or not Purged Volumes may be recycled.
If it is set to {\bf yes} (default) and Bacula needs a volume but finds
none that are appendable, it will search for and recycle (reuse) Purged
Volumes (i.e. volumes with all the Jobs and Files expired and thus
deleted from the Catalog). If the Volume is recycled, all previous data
written to that Volume will be overwritten. If Recycle is set to {\bf
- no} you must manually set the recycle flag (update command) for
- a Volume to be reused.
+ no}, the Volume will not be recycled, and hence, the data will remain
+ valid. If you want to reuse (re-write) the Volume, and the recycle flag
+ is no (0 in the catalog), you may manually set the recycle flag (update
+ command) for a Volume to be reused.
Please note that the value defined by this directive in the
bacula-dir.conf file is the default value used when a Volume is created.
However, if you use this directive and have only one
Volume in the Pool, you will immediately recycle your Volume if you fill
it and Bacula needs another one. Thus your backup will be totally invalid.
- Please use this directive with care. The default is {\no}.
+ Please use this directive with care. The default is {\bf no}.
\label{RecycleCurrent}
However, if you use this directive and have only one Volume in the Pool,
you will immediately recycle your Volume if you fill it and Bacula needs
another one. Thus your backup will be totally invalid. Please use this
- directive with care. The default is {\no}.
+ directive with care. The default is {\bf no}.
\label{PurgeOldest}
We {\bf highly} recommend against using this directive, because it is
sure that some day, Bacula will recycle a Volume that contains current
- data. The default is {\no}.
+ data. The default is {\bf no}.
\item [Cleaning Prefix = \lt{}string\gt{}]
\index[dir]{Cleaning Prefix }
This script creates the PostgreSQL {\bf bacula} database.
If it fails, it is probably because the database is owned by a
user other than yourself. On many systems, the database owner is
- {\bf pgsql} and on others such as RedHat and Fedora it is {\bf postgre}.
+ {\bf pgsql} and on others such as RedHat and Fedora it is {\bf postgres}.
You can find out which it is by examining your /etc/passwd file.
To create a new user under either your name or with say the name
{\bf bacula}, you can do the following:
\begin{verbatim}
su
(enter root password)
- password pgsql (or postgre)
+ password pgsql (or postgres)
(enter a password for this account)
exit
- su pgsql (or postgre)
+ su pgsql (or postgres)
(enter password just created)
createuser kern (or perhaps bacula)
Shall the new user be allowed to create databases? (y/n) y
to do from a security standpoint. However, it allowed me to run
my regression scripts without having a password.
+A more secure way to perform database authentication is with md5
+password hashes. Begin by editing the {\bf pg_hba.conf} file, and
+just prior the the existing ``local'' and ``host'' lines, add the line:
+
+\footnotesize
+\begin{verbatim}
+ local bacula bacula md5
+\end{verbatim}
+\normalsize
+
+and restart the Postgres database server (frequently, this can be done
+using "/etc/init.d/postgresql restart") to put this new authentication
+rule into effect.
+
+Next, become the Postgres administrator, postgres, either by logging
+on as the postgres user, or by using su to become root and then using
+su - postgres to become postgres. Add a password to the bacula
+database for the bacula user using:
+
+\footnotesize
+\begin{verbatim}
+ \$ psql bacula
+ bacula=# alter user bacula with password 'secret';
+ ALTER USER
+ bacula=# \\q
+\end{verbatim}
+\normalsize
+
+Next, you'll have to add this password to two locations in the
+bacula-dir.conf file: once to the Catalog resource and once to the
+RunBeforeJob entry in the BackupCatalog Job resource. With the
+password in place, these two lines should look something like:
+
+\footnotesize
+\begin{verbatim}
+ dbname = bacula; user = bacula; password = "secret"
+ ... and ...
+ RunBeforeJob = "/etc/make_catalog_backup bacula bacula secret"
+\end{verbatim}
+\normalsize
+
+Naturally, you should choose your own significantly more random
+password, and ensure that the bacula-dir.conf file containing this
+password is readable only by the root.
+
+Even with the files containing the database password properly
+restricted, there is still a security problem with this approach: on
+some platforms, the environment variable that is used to supply the
+password to Postgres is unavoidable made available to all users of the
+local system. To eliminate this problem, the Postgres team have
+deprecated the use of the environment variable password-passing
+mechanism and recommend the use of a .pgpass file instead. To use
+this mechanism, create a file named .pgpass containing the single
+line:
+
+\footnotesize
+\begin{verbatim}
+ localhost:5432:bacula:bacula:secret
+\end{verbatim}
+\normalsize
+
+This file should be copied into the home directory of all accounts
+that will need to gain access to the database: typically, root,
+bacula, and any users who will make use of any of the console
+programs. The files must then have the owner and group set to match
+the user (so root:root for the copy in ~root, and so on), and the mode
+set to 600, limiting access to the owner of the file.
\subsection*{Re-initializing the Catalog Database}
\index[general]{Database!Re-initializing the Catalog }
\index[general]{Modes!Details}
\index[general]{Details of Tape Modes}
\addcontentsline{toc}{subsection}{Details of Tape Modes}
-Rudolf Cejkar has provided the following information concerning
+Rudolf Cejka has provided the following information concerning
certain tape modes and MTEOM.
\begin{description}
The above script will ask you a number of questions. You may simply answer
each of them by entering a return, or if you wish you may enter your own data.
+An alternative is to generate your self-signed certificates with TinyCA,
+which has a very nice Graphical User Interface. TinyCA can be found at
+\elink{http://tinyca.sm-zone.net/}{http://tinyca.sm-zone.net/}.
+
\subsection*{Getting a CA Signed Certificate}
\index[general]{Certificate!Getting a CA Signed }
\normalsize
-
-1.38.2 (20 November 2005)
+1.38.3 (27 November 2005)
%%
%%
-\section*{Autochangers Support}
+\section*{Autochanger Support}
\label{_ChapterStart18}
-\index[general]{Support!Autochangers }
-\index[general]{Autochangers Support }
-\addcontentsline{toc}{section}{Autochangers Support}
+\index[general]{Support!Autochanger }
+\index[general]{Autochanger Support }
+\addcontentsline{toc}{section}{Autochanger Support}
\subsection*{Autochangers -- General}
\index[general]{General!Autochangers -- }
\index[general]{Autochangers -- General }
\addcontentsline{toc}{subsection}{Autochangers -- General}
-Beginning with version 1.23, Bacula provides autochanger support for reading
-and writing tapes. In order to work with an autochanger, Bacula requires three
-things, each of which is explained in more detail after this list:
+Bacula provides autochanger support for reading and writing tapes. In
+order to work with an autochanger, Bacula requires three things, each of
+which is explained in more detail after this list:
\begin{itemize}
\item A script that actually controls the autochanger according to commands
sent by Bacula. We furnish such a script that works with {\bf mtx} found in
the {\bf depkgs} distribution. This script works only with single drive
-autochangers.
+ autochangers.
\item That each Volume (tape) to be used must be defined in the Catalog and
have a Slot number assigned to it so that Bacula knows where the Volume is in
the autochanger. This is generally done with the {\bf label} command. See
-below for more details.
+ below for more details. You must pre-label the tapes manually before
+ using them.
\item Modifications to your Storage daemon's Device configuration resource to
identify that the device is a changer, as well as a few other parameters.
-\item Optionally, you can modify your Storage resource definition in the
- Director's configuration file so that you are automatically prompted for the
+\item You should also modify your Storage resource definition in the
+ Director's configuration file so that you are automatically prompted for the
Slot when labeling a Volume.
+\item You need to ensure that your Storage daemon (if not running as root)
+ has access permissions to both the tape drive and the control device.
+\item You need to have {\bf Autochanger = yes} in your Storage resource
+ in your bacula-dir.conf file so that you will be prompted for the
+ slot number when you label Volumes.
\end{itemize}
-Bacula uses its own {\bf mtx-changer} script to interface with a a program
-that actually does the tape changing. Thus in principle, {\bf mtx-changer} can
-be adapted to function with any autochanger program. The current version of
-{\bf mtx-changer} works with the {\bf mtx} program.
+In version 1.37, there is a new \ilink{Autochanger
+resource}{AutochangerRes} that permits you to group Device resources thus
+creating a multi-drive autochanger. If you have a multi-drive autochanger,
+you must use this new resource. If you have a single drive autochanger,
+it is recommended, but not required.
-As of version 1.30 and later, Bacula supports autochangers with barcode
-readers. This support includes two new Console commands: {\bf label barcodes}
-and {\bf update slots}. For more details on these commands, see the ``Barcode
-Support'' section below.
+Bacula uses its own {\bf mtx-changer} script to interface with a program
+that actually does the tape changing. Thus in principle, {\bf mtx-changer}
+can be adapted to function with any autochanger program. The current
+version of {\bf mtx-changer} works with the {\bf mtx} program. However,
+FreeBSD users have provided a script in the {\bf examples/autochangers}
+directory that allows Bacula to use the {\bf chio} program.
+
+Bacula also supports autochangers with barcode
+readers. This support includes two Console commands: {\bf label barcodes}
+and {\bf update slots}. For more details on these commands, see the "Barcode
+Support" section below.
Current Bacula autochanger support does not include cleaning, stackers, or
-silos. However, under certain conditions, you may be able to make Bacula work
-with stackers (gravity feed and such). Bacula supports only single drive
-autochangers. Bacula does have code to operate multi-drive autochangers.
-However, the implementation is only partial. See below for more details.
+silos. However, under certain conditions, you may be able to make Bacula
+work with stackers (gravity feed and such). Support for multi-drive
+autochangers requires the \ilink{Autochanger resource}{AutochangerRes}
+introduced in version 1.37. This resource is also recommended for single
+drive autochangers.
In principle, if {\bf mtx} will operate your changer correctly, then it is
just a question of adapting the {\bf mtx-changer} script (or selecting one
already adapted) for proper interfacing. You can find a list of autochangers
supported by {\bf mtx} at the following link:
\elink{http://mtx.badtux.net/compatibility.php}
-{http://mtx.badtux.net/compatibility.php}. The home page for the {\bf mtx}
-project can be found at:
-\elink{ http://mtx.badtux.net/}{http://mtx.badtux.net/}.
+{http://mtx.badtux.net/compatibility.php}.
+The home page for the {\bf mtx} project can be found at:
+\elink{http://mtx.badtux.net/}{http://mtx.badtux.net/}.
If you are having troubles, please use the {\bf auto} command in the {\bf
btape} program to test the functioning of your autochanger with Bacula. When
-Bacula is running, pleas remember that for many distributions (e.g. FreeBSD,
+Bacula is running, please remember that for many distributions (e.g. FreeBSD,
Debian, ...) the Storage daemon runs as {\bf bacula.tape} rather than {\bf
root.root}, so you will need to ensure that the Storage daemon has sufficient
permissions to access the autochanger.
-\label{devices}
+\label{SCSI devices}
\subsection*{Knowing What SCSI Devices You Have}
\index[general]{Have!Knowing What SCSI Devices You }
\index[general]{Knowing What SCSI Devices You Have }
+\index[general]{SCSI devices}
+\index[general]{devices!SCSI}
\addcontentsline{toc}{subsection}{Knowing What SCSI Devices You Have}
Under Linux, you can
To list the SCSI devices as well as the {\bf /dev/passn} that you will use on
the Bacula {\bf Changer Device = } directive.
+
+Please check that your Storage daemon has permission to access this
+device.
+
+The following tip for FreeBSD users comes from Danny Butroyd:
+n reboot bacula will NOT have permissions to
+control the device /dev/pass0 (assuming this is your changer device).
+To get around this just edit the /etc/devfs.conf file and add the
+following to the bottom of the config file:
+\footnotesize
+\begin{verbatim}
+own pass0 root:bacula
+perm pass0 0666
+own nsa0.0 root:bacula
+perm nsa0.0 0666
+\end{verbatim}
+\normalsize
+I have given the bacula group permission to write to the nsa0.0 device
+too just to be on the safe side. To bring these changes into effect
+just run:-
+
+/etc/rc.d/devfs restart
+
+Basically this will stop you having to change permissions on these
+devices to make bacula work when operating the AutoChanger after a reboot.
+
\label{scripts}
\subsection*{Example Scripts}
example {\bf HP-autoloader.conf} Bacula Device resource, and several {\bf
mtx-changer} scripts that have been modified to work with different
autochangers.
+
\label{Slots}
\subsection*{Slots}
when not loaded into the drive. Bacula numbers these slots from one to the
number of cartridges contained in the autochanger.
-Bacula will not automatically use a Volume in your auotchanger unless it is
-labeled and the slot number is stored in the catalog. For each Volume in your
+Bacula will not automatically use a Volume in your autochanger unless it is
+labeled and the slot number is stored in the catalog and the Volume is marked
+as InChanger. For each Volume in your
changer, you will, using the Console program, assign a slot. This information
is kept in {\bf Bacula's} catalog database along with the other data for the
volume. If no slot is given, or the slot is set to zero, Bacula will not
are present. In addition, the console {\bf mount} command does not cause
Bacula to operate the autochanger, it only tells Bacula to read any tape that
may be in the drive.
-\label{mult}
+You can check if the Slot number and InChanger flag are set by doing a:
+\begin{verbatim}
+list Volumes
+\end{verbatim}
+
+in the Console program.
+
+\label{mult}
\subsection*{Multiple Devices}
\index[general]{Devices!Multiple }
\index[general]{Multiple Devices }
\addcontentsline{toc}{subsection}{Multiple Devices}
-Some autochangers have more than one read/write device (drive). The current
-implementation has limited support for multiple devices by using the {\bf
+Some autochangers have more than one read/write device (drive). The
+new
+\ilink{Autochanger resource}{AutochangerRes} introduced in version
+1.37 permits you to group Device resources, where each device
+represents a drive. The Director may still reference the Devices (drives)
+directly, but doing so, bypasses the proper functioning of the
+drives together. Instead, the Director (in the Storage resource)
+should reference the Autochanger resource name. Doing so permits
+the Storage daemon to ensure that only one drive uses the mtx-changer
+script at a time, and also that two drives don't reference the
+same Volume.
+
+Multi-drive requires the use of the {\bf
Drive Index} directive in the Device resource of the Storage daemon's
configuration file. Drive numbers or the Device Index are numbered beginning
at zero, which is the default. To use the second Drive in an autochanger, you
-need to define a second Device resource and set the Drive Index to one for
+need to define a second Device resource and set the Drive Index to 1 for
that device. In general, the second device will have the same {\bf Changer
Device} (control channel) as the first drive, but a different {\bf Archive
Device}.
-The current implementation of Bacula does not coordinate between the two
-drives, so you must make sure that Bacula doesn't attempt to mount the same
-Volume on both drives at the same time. There are a number of ways to do this.
-One was is to use different pools for each drive.
-
-Worse than the above, the {\bf mtx} program apparently does not prevent two
-accesses to the same control device at the same time, which means that if
-Bacula happens to attempt to call the mtx-changer script for two drives
-simultaneously, something will break.
-
-A user supplied modified version of the mtx-changer script, which does locking
-to avoid this problem can be found in {\bf
-examples/autochangers/locking-mtx-changer}. If you are using multiple drives,
-you will probably want to modify this script to work for you.
\label{ConfigRecords}
-
\subsection*{Device Configuration Records}
\index[general]{Records!Device Configuration }
\index[general]{Device Configuration Records }
the autochanger.
These four records, permitted in {\bf Device} resources, are described in
-detail below:
+detail below. Note, however, that the {\bf Changer Device} and the
+{\bf Changer Command} directives are not needed in the Device resource
+if they are present in the {\bf Autochanger} resource.
\begin{description}
\item [Autochanger = {\it Yes|No} ]
- \index[console]{Autochanger }
+ \index[sd]{Autochanger }
The {\bf Autochanger} record specifies that the current device is or is not
an autochanger. The default is {\bf no}.
\item [Changer Device = \lt{}device-name\gt{}]
- \index[console]{Changer Device }
+ \index[sd]{Changer Device }
In addition to the Archive Device name, you must specify a {\bf Changer
Device} name. This is because most autochangers are controlled through a
different device than is used for reading and writing the cartridges. For
-example, on Linux, one normally uses the generic SCSI interface for
-controlling the autochanger, but the standard SCSI interface for reading and
+example, on Linux, one normally uses the generic SCSI interface for
+controlling the autochanger, but the standard SCSI interface for reading and
writing the tapes. On Linux, for the {\bf Archive Device = /dev/nst0}, you
would typically have {\bf Changer Device = /dev/sg0}. Note, some of the more
-advanced autochangers will locate the changer device on {\bf /dev/sg1}. Such
+advanced autochangers will locate the changer device on {\bf /dev/sg1}. Such
devices typically have several drives and a large number of tapes.
-On FreeBSD systems, the changer device will typically be on {\bf /dev/pass0}
+On FreeBSD systems, the changer device will typically be on {\bf /dev/pass0}
through {\bf /dev/passn}.
-On Solaris, the changer device will typically be some file under {\bf
+On Solaris, the changer device will typically be some file under {\bf
/dev/rdsk}.
+Please ensure that your Storage daemon has permission to access this
+device.
+
\item [Changer Command = \lt{}command\gt{}]
- \index[fd]{Changer Command }
+ \index[sd]{Changer Command }
This record is used to specify the external program to call and what
arguments to pass to it. The command is assumed to be a standard program or
shell script that can be executed by the operating system. This command is
-invoked each time that Bacula wishes to manipulate the autochanger. The
+invoked each time that Bacula wishes to manipulate the autochanger. The
following substitutions are made in the {\bf command} before it is sent to
the operating system for execution:
%s = Slot base 0
%S = Slot base 1
%v = Volume name
-
\end{verbatim}
\normalsize
An actual example for using {\bf mtx} with the {\bf mtx-changer} script (part
-of the Bacula distribution) is:
+of the Bacula distribution) is:
\footnotesize
\begin{verbatim}
Changer Command = "/etc/bacula/mtx-changer %c %o %S %a %d"
-
\end{verbatim}
\normalsize
section below.
\item [Maximum Changer Wait = \lt{}time\gt{}]
- \index[fd]{Maximum Changer Wait }
- This record is used to define the maximum amount of time that Bacula will
-wait for an autoloader to respond to a command (e.g. load). The default is
-set to 120 seconds. If you have a slow autoloader you may want to set it
-longer.
+ \index[sd]{Maximum Changer Wait }
+ This record is used to define the maximum amount of time that Bacula
+ will wait for an autoloader to respond to a command (e.g. load). The
+ default is set to 120 seconds. If you have a slow autoloader you may
+ want to set it longer.
If the autoloader program fails to respond in this time, it will be killed
-and Bacula will request operator intervention.
+and Bacula will request operator intervention.
\item [Drive Index = \lt{}number\gt{}]
- \index[fd]{Drive Index }
- This record allows you to tell Bacula to use the second or subsequent drive
-in an autochanger with multiple drives. Since the drives are numbered from
-zero, the second drive is defined by
+ \index[sd]{Drive Index }
+ This record allows you to tell Bacula to use the second or subsequent
+ drive in an autochanger with multiple drives. Since the drives are
+ numbered from zero, the second drive is defined by
\footnotesize
\begin{verbatim}
chapter for more information.
\end{description}
-\label{example}
+In addition, for proper functioning of the Autochanger, you must
+define an Autochanger resource.
+\input{autochangerres}
+\label{example}
\subsection*{An Example Configuration File}
\index[general]{Example Configuration File }
\index[general]{File!Example Configuration }
\addcontentsline{toc}{subsection}{Example Configuration File}
-The following {\bf Device} resource implements an autochanger:
+The following two resources implement an autochanger:
\footnotesize
\begin{verbatim}
-Device {
+Autochanger {
Name = "Autochanger"
+ Device = DDS-4
+ Changer Device = /dev/sg0
+ Changer Command = "/etc/bacula/mtx-changer %c %o %S %a %d"
+}
+
+Device {
+ Name = DDS-4
Media Type = DDS-4
Archive Device = /dev/nst0 # Normal archive device
- Changer Device = /dev/sg0 # Generic SCSI device name
+ Autochanger = yes
+ LabelMedia = no;
+ AutomaticMount = yes;
+ AlwaysOpen = yes;
+ Mount Anonymous Volumes = no;
+}
+\end{verbatim}
+\normalsize
+
+where you will adapt the {\bf Archive Device}, the {\bf Changer Device}, and
+the path to the {\bf Changer Command} to correspond to the values used on your
+system.
+
+\subsection*{A Multi-drive Example Configuration File}
+\index[general]{Multi-drive Example Configuration File }
+\addcontentsline{toc}{subsection}{A Multi-drive Example Configuration File}
+
+The following resources implement a multi-drive autochanger:
+
+\footnotesize
+\begin{verbatim}
+Autochanger {
+ Name = "Autochanger"
+ Device = Drive-1, Drive-2
+ Changer Device = /dev/sg0
Changer Command = "/etc/bacula/mtx-changer %c %o %S %a %d"
+}
+
+Device {
+ Name = Drive-1
+ Drive Index = 0
+ Media Type = DDS-4
+ Archive Device = /dev/nst0 # Normal archive device
+ Autochanger = yes
+ LabelMedia = no;
+ AutomaticMount = yes;
+ AlwaysOpen = yes;
+ Mount Anonymous Volumes = no;
+}
+
+Device {
+ Name = Drive-2
+ Drive Index = 1
+ Media Type = DDS-4
+ Archive Device = /dev/nst1 # Normal archive device
Autochanger = yes
LabelMedia = no;
AutomaticMount = yes;
AlwaysOpen = yes;
Mount Anonymous Volumes = no;
}
+
\end{verbatim}
\normalsize
the path to the {\bf Changer Command} to correspond to the values used on your
system.
-The above {\bf Device} resource will work equally well for any standard tape
-drive (with device name {\bf /dev/nst0}) since the extra autochanger commands
-will not be used unless a {\bf slot} has been specified in the catalog record
-for the Volume to be used. See below for more details on the {\bf slot}.
\label{SpecifyingSlots}
-
\subsection*{Specifying Slots When Labeling}
\index[general]{Specifying Slots When Labeling }
\index[general]{Labeling!Specifying Slots When }
If you add an {\bf Autochanger = yes} record to the Storage resource in your
Director's configuration file, the Bacula Console will automatically prompt
-you for the slot number and whether or not the Volume is in the changer when
-you {\bf add} or {\bf label} tapes for that Storage device. You must also set
-{\bf Autochanger = yes} in the Device resource as we have described above in
+you for the slot number when the Volume is in the changer when
+you {\bf add} or {\bf label} tapes for that Storage device. If your
+{\bf mtx-changer} script is properly installed, Bacula will automatically
+load the correct tape during the label command.
+
+You must also set
+{\bf Autochanger = yes} in the Storage daemon's Device resource
+as we have described above in
order for the autochanger to be used. Please see the
\ilink{Storage Resource}{Autochanger1} in the Director's chapter
and the
Bacula will attempt to access the autochanger only if a {\bf slot} is non-zero
in the catalog Volume record (with the Volume name).
-p>If your autochanger has barcode labels, you can label all the Volumes in
+If your autochanger has barcode labels, you can label all the Volumes in
your autochanger one after another by using the {\bf label barcodes} command.
For each tape in the changer containing a barcode, Bacula will mount the tape
and then label it with the same name as the barcode. An appropriate Media
record will also be created in the catalog. Any barcode that begins with the
-same characters as specified on the ``CleaningPrefix=xxx'' command, will be
+same characters as specified on the "CleaningPrefix=xxx" command, will be
treated as a cleaning tape, and will not be labeled. For example with:
+Please note that Volumes must be pre-labeled to be automatically used in
+the autochanger during a backup. If you do not have a barcode reader, this
+is done manually (or via a script).
+
\footnotesize
\begin{verbatim}
Pool {
\normalsize
Any slot containing a barcode of CLNxxxx will be treated as a cleaning tape
-and will not be mounted.
+and will not be mounted.
+
\label{Magazines}
\subsection*{Dealing with Multiple Magazines}
\addcontentsline{toc}{subsection}{Dealing with Multiple Magazines}
If you have several magazines or if you insert or remove cartridges from a
-magazine, you will need to notify Bacula of this. By doing so, Bacula will as
+magazine, you should notify Bacula of this. By doing so, Bacula will as
a preference, use Volumes that it knows to be in the autochanger before
accessing Volumes that are not in the autochanger. This prevents unneeded
operator intervention.
\end{verbatim}
\normalsize
-command that will cause Bacula to read the label on each of the cartridges in
-the magazine in turn and update the information (Slot, InChanger flag) in the
-catalog. This is quite effective but does take time to load each cartridge
-into the drive in turn and read the Volume label.
+ command that will cause Bacula to read the label on each of the cartridges in
+ the magazine in turn and update the information (Slot, InChanger flag) in the
+ catalog. This is quite effective but does take time to load each cartridge
+ into the drive in turn and read the Volume label.
\item You can modify the mtx-changer script so that it simulates an
autochanger with barcodes. See below for more details.
\end{enumerate}
where the keyword {\bf scan} can be appended or not. The n1,n2, ... represent
Slot numbers to be updated and the form n3-n4 represents a range of Slot
-numbers to be updates (e.g. 4-7 will update Slots 4,5,6, and 7).
+numbers to be updated (e.g. 4-7 will update Slots 4,5,6, and 7).
This form is particularly useful if you want to do a scan (time expensive) and
restrict the update to one or two slots.
the tape device {\bf /dev/nsa1} disappear when there is no tape mounted in the
autochanger slot. As a consequence, Bacula is unable to open the device. The
solution to the problem is to make sure that some tape is loaded into the tape
-drive before starting Bacula. This problem is correct in Bacula versions
+drive before starting Bacula. This problem is corrected in Bacula versions
1.32f-5 and later.
Please see the
mtx-changer Script}
Before attempting to use the autochanger with Bacula, it is preferable to
-``hand-test'' that the changer works. To do so, we suggest you do the
+"hand-test" that the changer works. To do so, we suggest you do the
following commands (assuming that the {\bf mtx-changer} script is installed in
{\bf /etc/bacula/mtx-changer}):
\begin{description}
\item [Make sure Bacula is not running.]
- \index[fd]{Make sure Bacula is not running. }
+ \index[sd]{Make sure Bacula is not running. }
\item [/etc/bacula/mtx-changer \ /dev/sg0 \ list \ 0 \ /dev/nst0 \ 0]
- \index[fd]{/etc/bacula/mtx-changer \ /dev/sg0 \ list \ 0 \ /dev/nst0 \ 0
+ \index[sd]{/etc/bacula/mtx-changer \ /dev/sg0 \ list \ 0 \ /dev/nst0 \ 0
}
This command should print:
autochanger SCSI control device is generally {\bf /dev/pass2}.
\item [/etc/bacula/mtx-changer \ /dev/sg0 \ slots \ 0 \ /dev/nst0 \ 0]
- \index[fd]{/etc/bacula/mtx-changer \ /dev/sg0 \ slots \ 0 \ /dev/nst0 \ 0
+ \index[sd]{/etc/bacula/mtx-changer \ /dev/sg0 \ slots \ 0 \ /dev/nst0 \ 0
}
This command should return the number of slots in your autochanger.
\item [/etc/bacula/mtx-changer \ /dev/sg0 \ unload \ ]
- \index[fd]{/etc/bacula/mtx-changer \ /dev/sg0 \ unload \ }
+ \index[sd]{/etc/bacula/mtx-changer \ /dev/sg0 \ unload \ }
If a tape is loaded, this should cause it to be unloaded.
\item [/etc/bacula/mtx-changer \ /dev/sg0 \ load \ 3 \ /dev/nst0 \ 0 ]
- \index[fd]{/etc/bacula/mtx-changer \ /dev/sg0 \ load \ 3 \ /dev/nst0 \ 0
+ \index[sd]{/etc/bacula/mtx-changer \ /dev/sg0 \ load \ 3 \ /dev/nst0 \ 0
}
Assuming you have a tape in slot 3, it will be loaded into the read slot (0).
\item [/etc/bacula/mtx-changer \ /dev/sg0 \ loaded \ 0 \ /dev/nst0 \ 0]
- \index[fd]{/etc/bacula/mtx-changer \ /dev/sg0 \ loaded \ 0 \ /dev/nst0 \
+ \index[sd]{/etc/bacula/mtx-changer \ /dev/sg0 \ loaded \ 0 \ /dev/nst0 \
0 }
-It should print ``3''
+It should print "3"
\item [/etc/bacula/mtx-changer \ /dev/sg0 \ unload]
- \index[fd]{/etc/bacula/mtx-changer \ /dev/sg0 \ unload }
+ \index[sd]{/etc/bacula/mtx-changer \ /dev/sg0 \ unload }
\end{description}
Once all the above commands work correctly, assuming that you have the right
\normalsize
If the above script runs, you probably have no timing problems. If it does not
-run, start by putting a {\bf sleep 30} or possibly a {\bf sleep 60} in the the
+run, start by putting a {\bf sleep 30} or possibly a {\bf sleep 60} in the
script just after the mtx-changer load command. If that works, then you should
move the sleep into the actual {\bf mtx-changer} script so that it will be
effective when Bacula runs.
\lt{}bacula-source\gt{}/examples/devices} that implement the above features,
so they may be a help to you in getting your script to work.
-If Bacula complains ``Rewind error on /dev/nst0. ERR=Input/output error.'' you
+If Bacula complains "Rewind error on /dev/nst0. ERR=Input/output error." you
most likely need more sleep time in your {\bf mtx-changer} before returning to
-Bacula after a load command has been completed.
+Bacula after a load command has been completed.
+
\label{using}
\subsection*{Using the Autochanger}
./console
Connecting to Director rufus:8101
1000 OK: rufus-dir Version: 1.26 (4 October 2002)
-*{\bf label}
+*label
\end{verbatim}
\normalsize
The defined Storage resources are:
1: Autochanger
2: File
-Select Storage resource (1-2): {\bf 1}
+Select Storage resource (1-2): 1
\end{verbatim}
\normalsize
\footnotesize
\begin{verbatim}
-Enter new Volume name: {\bf TestVolume1}
-Enter slot (0 for none): {\bf 1}
+Enter new Volume name: TestVolume1
+Enter slot (0 for none): 1
\end{verbatim}
\normalsize
Defined Pools:
1: Default
2: File
-Select the Pool (1-2): {\bf 1}
+Select the Pool (1-2): 1
\end{verbatim}
\normalsize
Once all your Volumes are labeled, Bacula will automatically load them as they
are needed.
-To ``see'' how you have labeled your Volumes, simply enter the {\bf list
+To "see" how you have labeled your Volumes, simply enter the {\bf list
volumes} command from the Console program, which should print something like
the following:
Defined Pools:
1: Default
2: File
-Select the Pool (1-2): {\bf 1}
+Select the Pool (1-2): 1
+-------+----------+--------+---------+-------+--------+----------+-------+------+
| MedId | VolName | MedTyp | VolStat | Bites | LstWrt | VolReten | Recyc | Slot |
+-------+----------+--------+---------+-------+--------+----------+-------+------+
\addcontentsline{toc}{subsection}{Barcode Support}
Bacula provides barcode support with two Console commands, {\bf label
-barcodes} and {\bf update slots}.
+barcodes} and {\bf update slots}.
The {\bf label barcodes} will cause Bacula to read the barcodes of all the
cassettes that are currently installed in the magazine (cassette holder) using
The {\bf update slots} command will first obtain the list of cassettes and
their barcodes from {\bf mtx-changer}. Then it will find each volume in turn
-in the catalog database corresponding to to the barcodes and set its Slot to
+in the catalog database corresponding to the barcodes and set its Slot to
correspond to the value just read. If the Volume is not in the catalog, then
nothing will be done. This command is useful for synchronizing Bacula with the
current magazine in case you have changed magazines or in case you have moved
-cassettes from one slot to another.
+cassettes from one slot to another.
The {\bf Cleaning Prefix} statement can be used in the Pool resource to define
a Volume name prefix, which if it matches that of the Volume (barcode) will
cause that Volume to be marked with a VolStatus of {\bf Cleaning}. This will
-prevent Bacula from attempting to write on the Volume.
+prevent Bacula from attempting to write on the Volume.
+
\label{interface}
\subsection*{Bacula Autochanger Interface}
Bacula calls the autochanger script that you specify on the {\bf Changer
Device} statement. Normally this script will be the {\bf mtx-changer} script
that we can provide, but it can in fact be any program. The only requirements
-are that the ``commands'' that Bacula uses are {\bf loaded}, {\bf load}, {\bf
-unload} and {\bf list} ({\bf slots} may be used in the future). In addition,
+are that the "commands" that Bacula uses are {\bf loaded}, {\bf load}, {\bf
+unload}, {\bf list}, and {\bf slots}. In addition,
each of those commands must return the information in the precise format as
specified below:
\footnotesize
\begin{verbatim}
- Currently the changer commands used are:
- loaded -- returns number of the slot that is loaded in
- the drive or 0 if the drive is empty.
+ loaded -- returns number of the slot that is loaded, base 1,
+ in the drive or 0 if the drive is empty.
load -- loads a specified slot (note, some autochangers
require a 30 second pause after this command) into
the drive.
associated with the cassette if it exists and if you
autoloader supports barcodes. Otherwise the barcode
field is blank.
-- Other changer commands defined but not yet used:
slots -- returns total number of slots in the autochanger.
\end{verbatim}
\normalsize
\item [VolFile]
\index[fd]{VolFile }
The value is a file number, a list of file numbers, or a range of file
-numbers numbers to match on the current Volume. The file number represents
+numbers to match on the current Volume. The file number represents
the physical file on the Volume where the data is stored. For a tape volume,
this record is used to position to the correct starting file, and once the
tape is past the last specified file, reading will stop.
\item [VolBlock]
\index[fd]{VolBlock }
The value is a block number, a list of block numbers, or a range of block
-numbers numbers to match on the current Volume. The block number represents
+numbers to match on the current Volume. The block number represents
the physical block on the Volume where the data is stored. This record is
currently not used.
database size will remain constant.
If you started with the default configuration files, they already contain
-reasonable defaults for a small number of machines (less that 5), so if you
+reasonable defaults for a small number of machines (less than 5), so if you
fall into that case, catalog maintenance will not be urgent if you have a few
hundred megabytes of disk space free. Whatever the case may be, some knowledge
of retention periods will be useful.
\index[dir]{File Retention }
The File Retention record defines the length of time that Bacula will keep
File records in the Catalog database. When this time period expires, and if
-{\bf AutoPrune} is set to {\bf yes}, Bacula will prune (remove) File records
+{\bf AutoPrune} is set to {\bf yes}, Bacula will prune (remove) File records
that are older than the specified File Retention period. The pruning will
occur at the end of a backup Job for the given Client. Note that the Client
database record contains a copy of the File and Job retention periods, but
Bacula uses the current values found in the Director's Client resource to do
the pruning.
-Retention periods are specified in seconds, but as a convenience, there are a
-number of modifiers that permit easy specification in terms of minutes,
-hours, days, weeks, months, quarters, or years on the record. See the
-\ilink{ Configuration chapter}{Time} of this manual for
-additional details of modifier specification.
+Since File records in the database account for probably 80 percent of the
+size of the database, you should carefully determine exactly what File
+Retention period you need. Once the File records have been removed from
+the database, you will no longer be able to restore individual files
+in a Job. However, with Bacula version 1.37 and later, as long as the
+Job record still exists, you will be able to restore all files in the
+job.
-The default is 60 days.
+Retention periods are specified in seconds, but as a convenience, there are
+a number of modifiers that permit easy specification in terms of minutes,
+hours, days, weeks, months, quarters, or years on the record. See the
+\ilink{ Configuration chapter}{Time} of this manual for additional details
+of modifier specification.
+
+The default File retention period is 60 days.
\item [Job Retention = \lt{}time-period-specification\gt{}]
\index[dir]{Job Retention }
- The Job Retention record defines the length of time that {\bf Bacula} will
-keep Job records in the Catalog database. When this time period expires, and
-if {\bf AutoPrune} is set to {\bf yes} Bacula will prune (remove) Job records
-that are older than the specified File Retention period. Note, if a Job
-record is selected for pruning, all associated File and JobMedia records
-will also be pruned regardless of the File Retention period set. As a
-consequence, you normally will set the File retention period to be less than
-the Job retention period.
-
-The retention period is specified in seconds, but as a convenience, there are
-a number of modifiers that permit easy specification in terms of minutes,
-hours, days, weeks, months, quarters, or years. See the
-\ilink{ Configuration chapter}{Time} of this manual for
-additional details of modifier specification.
-
-The default is 180 days.
-
-\item [AutoPrune = \lt{}yes|no\gt{}]
+ The Job Retention record defines the length of time that {\bf Bacula}
+will keep Job records in the Catalog database. When this time period
+expires, and if {\bf AutoPrune} is set to {\bf yes} Bacula will prune
+(remove) Job records that are older than the specified Job Retention
+period. Note, if a Job record is selected for pruning, all associated File
+and JobMedia records will also be pruned regardless of the File Retention
+period set. As a consequence, you normally will set the File retention
+period to be less than the Job retention period.
+
+As mentioned above, once the File records are removed from the database,
+you will no longer be able to restore individual files from the Job.
+However, as long as the Job record remains in the database, you will be
+able to restore all the files backuped for the Job (on version 1.37 and
+later). As a consequence, it is generally a good idea to retain the Job
+records much longer than the File records.
+
+The retention period is specified in seconds, but as a convenience, there
+are a number of modifiers that permit easy specification in terms of
+minutes, hours, days, weeks, months, quarters, or years. See the \ilink{
+Configuration chapter}{Time} of this manual for additional details of
+modifier specification.
+
+The default Job Retention period is 180 days.
+
+\item [AutoPrune = \lt{}yes/no\gt{}]
\index[dir]{AutoPrune }
If AutoPrune is set to {\bf yes} (default), Bacula will automatically apply
the File retention period and the Job retention period for the Client at the
All database programs have some means of writing the database out in ASCII
format and then reloading it. Doing so will re-create the database from
scratch producing a compacted result, so below, we show you how you can do
-this for both MySQL and SQLite.
+this for MySQL, PostgreSQL and SQLite.
For a {\bf MySQL} database, you could write the Bacula database as an ASCII
file (bacula.sql) then reload it by doing the following:
If the errors you are getting are simply SQL warnings, then you might try
running dbcheck before (or possibly after) using the MySQL database repair
-program. It can clean up many of the orphanned record problems, and certain
+program. It can clean up many of the orphaned record problems, and certain
other inconsistencies in the Bacula database.
-\label{ReparingPSQL}
+\label{RepairingPSQL}
\subsection*{Repairing Your PostgreSQL Database}
\index[general]{Database!Repairing Your PostgreSQL }
using (see above).
\label{CompactingPostgres}
+\subsection*{Performance Issues}
+\index[general]{Database Performance Issues}
+\index[general]{Performance!Database}
+\addcontentsline{toc}{subsection}{Database Performance Issues}
+
+There are a considerable number of ways each of the databases can be
+tuned to improve the performance. Going from an untuned database to one
+that is properly tuned can make a difference of a factor of 100 or more
+in the time to insert or search for records.
+
+For each of the databases, you may get significant improvements by adding
+additional indexes. The comments in the Bacula make_xxx_tables give some
+indications as to what indexes may be appropriate.
+
+For MySQL, what seems to be very important is to use the examine the
+my.cnf file. You may obtain significant performances by switching to
+the my-large.cnf or my-huge.cnf files that come with the MySQL source
+code.
+
+For SQLite3, one significant factor in improving the performance is
+to ensure that there is a "PRAGMA synchronous = NORMAL;" statement.
+This reduces the number of times that the database flushes the in memory
+cache to disk. There are other settings for this PRAGMA that can
+give even further performance improvements at the risk of a database
+corruption if your system crashes.
+
+For PostgreSQL, you might want to consider turning fsync off. Of course
+doing so can cause corrupted databases in the even of a machine crash.
+There are many different ways that you can tune PostgreSQL, the
+following document discusses a few of them:
+\elink{
+http://www.varlena.com/varlena/GeneralBits/Tidbits/perf.html}
+{http://www.varlena.com/varlena/GeneralBits/Tidbits/perf.html}.
+
+There is also a PostgreSQL FAQ question number 3.3 that may
+answer some of your questions about how to improve performance
+of the PostgreSQL engine:
+\elink{
+http://www.postgresql.org/docs/faqs.FAQ.html#3.3}
+{http://www.postgresql.org/docs/faqs.FAQ.html#3.3}.
+
+
+
+
\subsection*{Compacting Your PostgreSQL Database}
\index[general]{Database!Compacting Your PostgreSQL }
\index[general]{Compacting Your PostgreSQL Database }
\footnotesize
\begin{verbatim}
cd {\bf working-directory}
-echo 'vacuum' | sqlite bacula.db
+echo 'vacuum;' | sqlite bacula.db
\end{verbatim}
\normalsize
You may begin using Bacula with SQLite then later find that you want to switch
to MySQL for any of a number of reasons: SQLite tends to use more disk than
MySQL, SQLite apparently does not handle database sizes greater than 2GBytes,
-... Several users have done so by first producing an ASCII ``dump'' of the
+... Several users have done so by first producing an ASCII "dump" of the
SQLite database, then creating the MySQL tables with the {\bf
create\_mysql\_tables} script that comes with Bacula, and finally feeding the
SQLite dump into MySQL using the {\bf -f} command line option to continue past
the errors that are generated by the DDL statements that SQLite's dump
creates. Of course, you could edit the dump and remove the offending
statements. Otherwise, MySQL accepts the SQL produced by SQLite.
-\label{BackingUpBacula}
+\label{BackingUpBacula}
\subsection*{Backing Up Your Bacula Database}
\index[general]{Backing Up Your Bacula Database }
\index[general]{Database!Backing Up Your Bacula }
\addcontentsline{toc}{subsection}{Backing Up Your Bacula Database}
-If ever the machine on which you Bacula database crashes, and you need to
+If ever the machine on which your Bacula database crashes, and you need to
restore from backup tapes, one of your first priorities will probably be to
recover the database. Although Bacula will happily backup your catalog
database if it is specified in the FileSet, this is not a very good way to do
-it because the database will be saved while Bacula is modifying it. Thus the
-database may be in and instable state. Worse yet, you will backup the database
+it, because the database will be saved while Bacula is modifying it. Thus the
+database may be in an instable state. Worse yet, you will backup the database
before all the Bacula updates have been applied.
-To resolve these problems, you need backup the database after all the backup
+To resolve these problems, you need to backup the database after all the backup
jobs have been run. In addition, you will want to make a copy while Bacula is
not modifying it. To do so, you can use two scripts provided in the release
{\bf make\_catalog\_backup} and {\bf delete\_catalog\_backup}. These files
will be automatically generated along with all the other Bacula scripts. The
first script will make an ASCII copy of your Bacula database into {\bf
-bacula.sql} in the working directory you specified on your configuration, and
+bacula.sql} in the working directory you specified in your configuration, and
the second will delete the {\bf bacula.sql} file.
The basic sequence of events to make this work correctly is as follows:
Pool = Default
RunBeforeJob = "/home/kern/bacula/bin/make_catalog_backup"
RunAfterJob = "/home/kern/bacula/bin/delete_catalog_backup"
+ Write Bootstrap = "/home/kern/bacula/working/BackupCatalog.bsr"
}
# This schedule does the catalog. It starts after the WeeklyCycle
Schedule {
\end{verbatim}
\normalsize
-\label{BackingUPOtherDBs}
+Be sure to write a bootstrap file as in the above example. It is preferable
+to write or copy the bootstrap file to another computer. It will allow
+you to quickly recover the database backup should that be necessary. If
+you do not have a bootstrap file, it is still possible to recover your
+database backup, but it will be more work and take longer.
+\label{BackingUPOtherDBs}
\subsection*{Backing Up Third Party Databases}
\index[general]{Backing Up Third Party Databases }
\index[general]{Databases!Backing Up Third Party }
%%
\section*{Bacula Console}
-\label{_ChapterStart23}
+\label{_ConsoleChapter}
\index[general]{Console!Bacula }
\index[general]{Bacula Console }
+\index[console]{Console!Bacula }
+\index[console]{Bacula Console }
\addcontentsline{toc}{section}{Bacula Console}
\subsection*{General}
-\index[general]{General }
+\index[general]{General}
\addcontentsline{toc}{subsection}{General}
The {\bf Bacula Console} (sometimes called the User Agent) is a program that
In addition, there is a wx-console built with wxWidgets that allows a graphic
restore of files. As of version 1.34.1 it is in an early stage of development,
-but it quite useful.
+but it already is quite useful.
-Since the Console program interacts with the Director by the network, your
+Since the Console program interacts with the Director through the network, your
Console and Director programs do not necessarily need to run on the same
machine.
requests a new tape, it waits until the user, via the Console program,
indicates that the new tape is mounted.
-\subsection*{Configuration}
-\index[general]{Configuration }
-\addcontentsline{toc}{subsection}{Configuration}
+\subsection*{Console Configuration}
+\index[general]{Console Configuration}
+\index[general]{Configuration!Console}
+\index[console]{Console Configuration}
+\index[console]{Configuration!Console}
+\addcontentsline{toc}{subsection}{Console Configuration}
When the Console starts, it reads a standard Bacula configuration file named
{\bf bconsole.conf} or {\bf gnome-console.conf} in the case of the GNOME
\subsection*{Running the Console Program}
\index[general]{Running the Console Program }
\index[general]{Program!Running the Console }
+\index[console]{Running the Console Program }
+\index[console]{Program!Running the Console }
\addcontentsline{toc}{subsection}{Running the Console Program}
After launching the Console program (bconsole), it will prompt you for the
\subsection*{Stopping the Console Program}
\index[general]{Program!Stopping the Console }
\index[general]{Stopping the Console Program }
+\index[console]{Program!Stopping the Console }
+\index[console]{Stopping the Console Program }
\addcontentsline{toc}{subsection}{Stopping the Console Program}
Normally, you simply enter {\bf quit} or {\bf exit} and the Console program
{\bf .quit} command.
There is currently no way to interrupt a Console command once issued (i.e.
-ctl-C does not work). However, if you are at a prompt that is asking you to
+Ctrl-C does not work). However, if you are at a prompt that is asking you to
select one of several possibilities and you would like to abort the command,
you can enter a period ({\bf .}), and in most cases, you will either be
returned to the main command prompt or if appropriate the previous prompt (in
\subsection*{Alphabetic List of Console Commands}
\index[general]{Commands!Alphabetic List of Console }
\index[general]{Alphabetic List of Console Commands }
+\index[console]{Commands!Alphabetic List of Console }
+\index[console]{Alphabetic List of Console Commands }
\addcontentsline{toc}{subsection}{Alphabetic List of Console Commands}
The following commands are currently implemented:
\begin{description}
-
\item [{add [pool=\lt{}pool-name\gt{} storage=\lt{}storage\gt{}
- jobid=\lt{}JobId\gt{}] }]
- \index[console]{add [pool }
+ jobid=\lt{}JobId\gt{}]} ]
+ \index[console]{add}
This command is used to add Volumes to an existing Pool. The Volume names
entered are placed in the Catalog and thus become available for backup
operations. Normally, the {\bf label} command is used rather than this
command below for the list of legal characters in a Volume name.
\item [autodisplay on/off]
- \index[console]{autodisplay on/off }
- This command accepts {\bf on} or {\bf off} as an argument, and turns
-auto-display of messages on or off respectively. The default for the console
-program is {\bf off}, which means that you will be notified when there are
-console messages pending, but they will not automatically be displayed. The
-default for the gnome-console program is {\bf on}, which means that messages
-will be displayed when they are received (usually within 5 seconds of them
-being generated).
-
-When autodisplay is turned off, you must explicitly retrieve the messages
-with the {\bf messages} command. When autodisplay is turned on, the messages
-will be displayed on the console as they are received.
+ \index[console]{autodisplay on/off}
+ This command accepts {\bf on} or {\bf off} as an argument, and turns
+ auto-display of messages on or off respectively. The default for the
+ console program is {\bf off}, which means that you will be notified when
+ there are console messages pending, but they will not automatically be
+ displayed. The default for the gnome-console program is {\bf on}, which
+ means that messages will be displayed when they are received (usually
+ within 5 seconds of them being generated).
+
+ When autodisplay is turned off, you must explicitly retrieve the
+ messages with the {\bf messages} command. When autodisplay is turned
+ on, the messages will be displayed on the console as they are received.
\item [automount on/off]
- \index[console]{automount on/off }
- This command accepts {\bf on} or {\bf off} as the argument, and turns
-auto-mounting of the tape after a {\bf label} command on or off respectively.
-The default is {\bf on}. If {\bf automount} is turned off, you must
-explicitly {\bf mount} the tape after a label command to use it.
+ \index[console]{automount on/off}
+ This command accepts {\bf on} or {\bf off} as the argument, and turns
+ auto-mounting of the tape after a {\bf label} command on or off
+ respectively. The default is {\bf on}. If {\bf automount} is turned
+ off, you must explicitly {\bf mount} the tape after a label command to
+ use it.
\item [{cancel [jobid=\lt{}number\gt{} job=\lt{}job-name\gt{}]}]
- \index[console]{cancel [jobid }
- This command is used to cancel a job and accepts {\bf jobid=nnn} or {\bf
-job=xxx} as an argument where nnn is replaced by the JobId and xxx is
-replaced by the job name. If you do not specify a keyword, the Console
-program will prompt you with the names of all the active jobs allowing you to
-choose one.
-
-Once a Job is marked to be canceled, it may take a bit of time (generally
-within a minute) before it actually terminates, depending on what operations
-it is doing.
-
-\item [{create [pool=\lt{}pool-name\gt{}]}]
- \index[console]{create [pool }
- This command is used to create a Pool record in the database using the Pool
-resource record defined in the Director's configuration file. So in a sense,
-this command simply transfers the information from the Pool resource in the
-configuration file into the Catalog. Normally this command is done
-automatically for you when the Director starts providing the Pool is
-referenced within a Job resource. If you use this command on an existing
-Pool, it will automatically update the Catalog to have the same information
-as the Pool resource. After creating a Pool, you will most likely use the
-{\bf label} command to label one or more volumes and add their names to the
-Media database.
-
-When starting a Job, if Bacula determines that there is no Pool record in the
-database, but there is a Pool resource of the appropriate name, it will
-create it for you. If you want the Pool record to appear in the database
-immediately, simply use this command to force it to be created.
-
-\item [{delete [volume=\lt{}vol-name\gt{} pool=\lt{}pool-name\gt{} job
+ \index[console]{cancel jobid}
+ This command is used to cancel a job and accepts {\bf jobid=nnn} or {\bf
+ job=xxx} as an argument where nnn is replaced by the JobId and xxx is
+ replaced by the job name. If you do not specify a keyword, the Console
+ program will prompt you with the names of all the active jobs allowing
+ you to choose one.
+
+ Once a Job is marked to be canceled, it may take a bit of time
+ (generally within a minute) before it actually terminates, depending on
+ what operations it is doing.
+
+\item [{ create [pool=\lt{}pool-name\gt{}]}]
+ \index[console]{create pool}
+ This command is used to create a Pool record in the database using the
+ Pool resource record defined in the Director's configuration file. So
+ in a sense, this command simply transfers the information from the Pool
+ resource in the configuration file into the Catalog. Normally this
+ command is done automatically for you when the Director starts providing
+ the Pool is referenced within a Job resource. If you use this command
+ on an existing Pool, it will automatically update the Catalog to have
+ the same information as the Pool resource. After creating a Pool, you
+ will most likely use the {\bf label} command to label one or more
+ volumes and add their names to the Media database.
+
+ When starting a Job, if Bacula determines that there is no Pool record
+ in the database, but there is a Pool resource of the appropriate name,
+ it will create it for you. If you want the Pool record to appear in the
+ database immediately, simply use this command to force it to be created.
+
+\item [{ delete [volume=\lt{}vol-name\gt{} pool=\lt{}pool-name\gt{} job
jobid=\lt{}id\gt{}] }]
- \index[fd]{delete [volume }
-The delete command is used to delete a Volume, Pool or Job record from the
-Catalog as well as all associated Volume records that were created. This
-command operates only on the Catalog database and has no effect on the actual
-data written to a Volume. This command can be dangerous and we strongly
-recommend that you do not use it unless you know what you are doing.
-
-If the keyword {\bf Volume} appears on the command line, the named Volume
-will be deleted from the catalog, if the keyword {\bf Pool} appears on the
-command line, a Pool will be deleted, and if the keyword {\bf Job} appears on
-the command line, a Job and all its associated records (File and JobMedia)
-will be deleted from the catalog. The full form of this command is:
+ \index[console]{delete}
+ The delete command is used to delete a Volume, Pool or Job record from
+ the Catalog as well as all associated catalog Volume records that were
+ created. This command operates only on the Catalog database and has no
+ effect on the actual data written to a Volume. This command can be
+ dangerous and we strongly recommend that you do not use it unless you
+ know what you are doing.
+
+ If the keyword {\bf Volume} appears on the command line, the named
+ Volume will be deleted from the catalog, if the keyword {\bf Pool}
+ appears on the command line, a Pool will be deleted, and if the keyword
+ {\bf Job} appears on the command line, a Job and all its associated
+ records (File and JobMedia) will be deleted from the catalog. The full
+ form of this command is:
delete pool=\lt{}pool-name\gt{}
-or
+ or
delete volume=\lt{}volume-name\gt{} pool=\lt{}pool-name\gt{} or
delete Job JobId=n,m,o-r,t ...
-The first form deletes a Pool record from the catalog database. The second
-form deletes a Volume record from the specified pool in the catalog database.
-The third form delete the specified Job record from the catalog database.
-The last form deletes JobId records for JobIds n,m,o,p, q,r, and t. When each
-one of the n,m,... is, of course, a number.
-\label{estimate}
+ The first form deletes a Pool record from the catalog database. The
+ second form deletes a Volume record from the specified pool in the
+ catalog database. The third form deletes the specified Job record from
+ the catalog database. The last form deletes JobId records for JobIds
+ n,m,o,p, q,r, and t. Where each one of the n,m,... is, of course, a
+ number.
+\label{estimate}
\item [estimate]
- \index[fd]{estimate }
- Using this command, you can get an idea how many files will be backed up, or
-if you are unsure about your Include statements in your FileSet, you can test
-them without doing an actual backup. The default is to assume a Full backup.
-However, you can override this by specifying a {\bf level=Incremental} or
-{\bf level=Differential} on the command line. A Job name must be specified
-or you will be prompted for one, and optionally a Client and FileSet may be
-specified on the command line. It then contacts the client which computes
-the number of files and bytes that would be backed up. Please note that this
-is an estimated calculated from the number of blocks in the file rather than
-by reading the actual bytes. As such, the estimated backup size will
-generally be larger than an actual backup.
-
-Optionally you may specify the keyword {\bf listing} in which case, all the
-files to be backed up will be listed. Note, it could take quite some time to
-display them if the backup is large. The full form is:
+ \index[console]{estimate}
+ Using this command, you can get an idea how many files will be backed
+ up, or if you are unsure about your Include statements in your FileSet,
+ you can test them without doing an actual backup. The default is to
+ assume a Full backup. However, you can override this by specifying a
+ {\bf level=Incremental} or {\bf level=Differential} on the command line.
+ A Job name must be specified or you will be prompted for one, and
+ optionally a Client and FileSet may be specified on the command line.
+ It then contacts the client which computes the number of files and bytes
+ that would be backed up. Please note that this is an estimate
+ calculated from the number of blocks in the file rather than by reading
+ the actual bytes. As such, the estimated backup size will generally be
+ larger than an actual backup.
+
+ Optionally you may specify the keyword {\bf listing} in which case, all the
+ files to be backed up will be listed. Note, it could take quite some time to
+ display them if the backup is large. The full form is:
estimate job=\lt{}job-name\gt{} listing client=\lt{}client-name\gt{}
fileset=\lt{}fileset-name\gt{} level=\lt{}level-name\gt{}
-Specification of the {\bf job} is sufficient, but you can also override the
-client, fileset and/or level by specifying them on the estimate command line.
+ Specification of the {\bf job} is sufficient, but you can also override
+ the client, fileset and/or level by specifying them on the estimate
+ command line.
As an example, you might do:
@output /tmp/listing
estimate job=NightlySave listing level=Incremental
@output
-
\end{verbatim}
\normalsize
/tmp/listing}.
\item [help]
- \index[fd]{help }
+ \index[console]{help}
This command displays the list of commands available.
\item [label]
- \index[fd]{label }
+ \index[console]{label}
+ \index[console]{relabel}
+ \index[general]{label}
+ \index[general]{relabel}
This command is used to label physical volumes. The full form of this command
-is:
+ is:
label storage=\lt{}storage-name\gt{} volume=\lt{}volume-name\gt{}
slot=\lt{}slot\gt{}
-If you leave out any part, you will be prompted for it. The media type is
-automatically taken from the Storage resource definition that you supply.
-Once the necessary information is obtained, the Console program contacts the
-specified Storage daemon and requests that the tape be labeled. If the tape
-labeling is successful, the Console program will create a Volume record in
-the appropriate Pool.
+ If you leave out any part, you will be prompted for it. The media type
+ is automatically taken from the Storage resource definition that you
+ supply. Once the necessary information is obtained, the Console program
+ contacts the specified Storage daemon and requests that the tape be
+ labeled. If the tape labeling is successful, the Console program will
+ create a Volume record in the appropriate Pool.
-The Volume name is restricted to letters, numbers, and the special characters
-hyphen ({\bf -}), underscore ({\bf \_}), colon ({\bf :}), and period ({\bf
-.}). All other characters including a space are illegal. This restriction is
-to ensure good readability of Volume names to reduce operator errors.
+ The Volume name is restricted to letters, numbers, and the special
+ characters hyphen ({\bf -}), underscore ({\bf \_}), colon ({\bf :}), and
+ period ({\bf .}). All other characters including a space are illegal.
+ This restriction is to ensure good readability of Volume names to reduce
+ operator errors.
-Please note, when labeling a blank tape, Bacula will get read I/O error when
-it attempts to ensure that the tape is already labeled. If you wish to avoid
-getting these messages, please write and EOF mark on your tape before
-attempting to label it:
+ Please note, when labeling a blank tape, Bacula will get {\bf read I/O
+ error} when it attempts to ensure that the tape is already labeled. If
+ you wish to avoid getting these messages, please write and EOF mark on
+ your tape before attempting to label it:
\footnotesize
\begin{verbatim}
case you must {\bf unmount} the device, insert a blank tape, then do the
{\bf label} command.
\item The tape in the device is already a Bacula labeled tape. (Bacula will
- never relabel a Bacula labeled tape unless it is recycled and you use the
+ never relabel a Bacula labeled tape unless it is recycled and you use the
{\bf relabel} command).
\item There is no tape in the drive.
- \end{enumerate}
+\end{enumerate}
-There are two ways to relabel a volume that already has a Bacula label. The
+There are two ways to relabel a volume that already has a Bacula label. The
brute force method is to write an end of file mark on the tape using the
system {\bf mt} program, something like the following:
\begin{verbatim}
mt -f /dev/st0 rewind
mt -f /dev/st0 weof
-
\end{verbatim}
\normalsize
each tape in the changer containing a barcode, Bacula will mount the tape and
then label it with the same name as the barcode. An appropriate Media record
will also be created in the catalog. Any barcode that begins with the same
-characters as specified on the ``CleaningPrefix=xxx'' command, will be
-treated as a cleaning tape, and will not be labeled. For example with:
+characters as specified on the "CleaningPrefix=xxx" directive in the
+Director's Pool resource, will be
+treated as a cleaning tape, and will not be labeled. However,
+an entry for the cleaning tape will be created in
+the catalog. For example with:
\footnotesize
\begin{verbatim}
\footnotesize
\begin{verbatim}
-
update storage=xxx pool=yyy slots=1-5,10 barcodes
\end{verbatim}
\normalsize
\item [list]
- \index[fd]{list }
- The list command lists the requested contents of the Catalog. The various
-fields of each record are listed on a single line. If there The various forms
-of the list command are:
-
-list jobs
-
-list jobid=\lt{}id\gt{}
-
-list job=\lt{}job-name\gt{}
-
-list jobmedia
-
-list jobmedia jobid=\lt{}id\gt{}
-
-list jobmedia job=\lt{}job-name\gt{}
-
-list files jobid=\lt{}id\gt{}
-
-list files job=\lt{}job-name\gt{}
-
-list pools
-
-list clients
-
-list jobtotals
-
-list volumes
-
-list volumes jobid=\lt{}id\gt{}
-
-list volumes pool=\lt{}pool-name\gt{}
-
-list volumes job=\lt{}job-name\gt{}
-
-list volume=\lt{}volume-name\gt{} list nextvolume job=\lt{}job-name\gt{}
-
-list nextvol job=\lt{}job-name\gt{}
-
-What most of the above commands do should be more or less obvious. In general
-if you do not specify all the command line arguments, the command will prompt
-you for what is needed.
-
-The {\bf list nextvol} command will print the Volume name to be used by the
-specified job. You should be aware that exactly what Volume will be used
-depends on a lot of factors including the time and what a prior job will do.
-It may fill a tape that is not full when you issue this command. As a
-consequence, this command will give you a good estimate of what Volume will
-be used but not a definitive answer. In addition, this command may have
-certain side effect because it runs through the same algorithm as a job,
-which means it may automatically purge or recycle a Volume.
+ \index[console]{list}
+ The list command lists the requested contents of the Catalog. The
+ various fields of each record are listed on a single line. The various
+ forms of the list command are:
+\footnotesize
+\begin{verbatim}
+ list jobs
+
+ list jobid=\lt{}id\gt{}
+
+ list job=\lt{}job-name\gt{}
+
+ list jobmedia
+
+ list jobmedia jobid=\lt{}id\gt{}
+
+ list jobmedia job=\lt{}job-name\gt{}
+
+ list files jobid=\lt{}id\gt{}
+
+ list files job=\lt{}job-name\gt{}
+
+ list pools
+
+ list clients
+
+ list jobtotals
+
+ list volumes
+
+ list volumes jobid=\lt{}id\gt{}
+
+ list volumes pool=\lt{}pool-name\gt{}
+
+ list volumes job=\lt{}job-name\gt{}
+
+ list volume=\lt{}volume-name\gt{}
+
+ list nextvolume job=\lt{}job-name\gt{}
+
+ list nextvol job=\lt{}job-name\gt{}
-If you wish to add specialized commands that list the contents of the
-catalog, you can do so by adding them to the {\bf query.sql} file. However,
-this takes some knowledge of programming SQL. Please see the {\bf query}
-command below for additional information. See below for listing the full
-contents of a catalog record with the {\bf llist} command.
+\end{verbatim}
+\normalsize
-As an example, the command {\bf list pools} might produce the following
-output:
+ What most of the above commands do should be more or less obvious. In
+ general if you do not specify all the command line arguments, the
+ command will prompt you for what is needed.
+
+ The {\bf list nextvol} command will print the Volume name to be used by
+ the specified job. You should be aware that exactly what Volume will be
+ used depends on a lot of factors including the time and what a prior job
+ will do. It may fill a tape that is not full when you issue this
+ command. As a consequence, this command will give you a good estimate
+ of what Volume will be used but not a definitive answer. In addition,
+ this command may have certain side effect because it runs through the
+ same algorithm as a job, which means it may automatically purge or
+ recycle a Volume.
+
+ If you wish to add specialized commands that list the contents of the
+ catalog, you can do so by adding them to the {\bf query.sql} file.
+ However, this takes some knowledge of programming SQL. Please see the
+ {\bf query} command below for additional information. See below for
+ listing the full contents of a catalog record with the {\bf llist}
+ command.
+
+ As an example, the command {\bf list pools} might produce the following
+ output:
\footnotesize
\begin{verbatim}
\end{verbatim}
\normalsize
-As mentioned above, the {\bf list} command lists what is in the database.
-Some things are put into the database immediately when Bacula starts up, but
-in general, most things are put in only when they are first used, which is
-the case for a Client as with Job records, etc.
+ As mentioned above, the {\bf list} command lists what is in the
+ database. Some things are put into the database immediately when Bacula
+ starts up, but in general, most things are put in only when they are
+ first used, which is the case for a Client as with Job records, etc.
-Bacula should create a client record in the database the first time you run a
-job for that client. Doing a {\bf status} will not cause a database record to
-be created. The client database record will be created whether or not job
-fails, but it must at least start. When the Client is actually contacted,
-additional info from the client will be added to the client record (a ``uname
--a'' output).
+ Bacula should create a client record in the database the first time you
+ run a job for that client. Doing a {\bf status} will not cause a
+ database record to be created. The client database record will be
+ created whether or not the job fails, but it must at least start. When
+ the Client is actually contacted, additional info from the client will
+ be added to the client record (a "uname -a" output).
-If you want to see what Client resources you have available in your conf
-file, you use the Console command {\bf show clients}.
+ If you want to see what Client resources you have available in your conf
+ file, you use the Console command {\bf show clients}.
\item [llist]
- \index[fd]{llist }
- The llist or ``long list'' command takes all the same arguments that the list
-command described above does. The difference is that the llist command list
-the full contents of each database record selected. It does so by listing the
-various fields of the record vertically, with one field per line. It is
-possible to produce a very large number of output lines with this command.
+ \index[console]{llist}
+ The llist or "long list" command takes all the same arguments that the
+ list command described above does. The difference is that the llist
+ command list the full contents of each database record selected. It
+ does so by listing the various fields of the record vertically, with one
+ field per line. It is possible to produce a very large number of output
+ lines with this command.
-If instead of the {\bf list pools} as in the example above, you enter {\bf
-llist pools} you might get the following output:
+ If instead of the {\bf list pools} as in the example above, you enter
+ {\bf llist pools} you might get the following output:
\footnotesize
\begin{verbatim}
\normalsize
\item [messages]
- \index[fd]{messages }
+ \index[console]{messages}
This command causes any pending console messages to be immediately displayed.
\item [mount]
- \index[console]{mount }
- The mount command is used to get Bacula to read a volume on a physical
-device. It is a way to tell Bacula that you have mounted a tape and that
-Bacula should examine the tape. This command is used only after there was no
-Volume in a drive and Bacula requests you to mount a new Volume or when you
-have specifically unmounted a Volume with the {\bf unmount} console command,
-which causes Bacula to close the drive. If you have an autoloader, the mount
-command will not cause Bacula to operate the autoloader. The various forms of
-the mount command are:
+ \index[console]{mount}
+ The mount command is used to get Bacula to read a volume on a physical
+ device. It is a way to tell Bacula that you have mounted a tape and
+ that Bacula should examine the tape. This command is used only after
+ there was no Volume in a drive and Bacula requests you to mount a new
+ Volume or when you have specifically unmounted a Volume with the {\bf
+ unmount} console command, which causes Bacula to close the drive. If
+ you have an autoloader, the mount command will not cause Bacula to
+ operate the autoloader. The various forms of the mount command are:
mount storage=\lt{}storage-name\gt{}
mount [ jobid=\lt{}id\gt{} | job=\lt{}job-name\gt{} ]
-If you have specified {\bf Automatic Mount = yes} in the Storage daemon's
-Device resource, under most circumstances, Bacula will automatically access
-the Volume unless you have explicitly {\bf unmount}ed it in the Console
-program.
-\label{ManualPruning}
+ If you have specified {\bf Automatic Mount = yes} in the Storage daemon's
+ Device resource, under most circumstances, Bacula will automatically access
+ the Volume unless you have explicitly {\bf unmount}ed it in the Console
+ program.
+
+\item[python]
+ \index[console]{python}
+ The python command takes a single argument {\bf restart}:
+
+python restart
+ This causes the Python interpreter in the Director to be reinitialized.
+ This can be helpful for testing because once the Director starts and the
+ Python interpreter is initialized, there is no other way to make it
+ accept any changes to the startup script {\bf DirStartUp.py}. For more
+ details on Python scripting, please see the \ilink{Python
+ Scripting}{_ChapterStart60} chapter of this manual.
+
+\label{ManualPruning}
\item [prune]
- \index[console]{prune }
- The Prune command allows you to safely remove expired database records from
-Jobs and Volumes. This command works only on the Catalog database and does
-not affect data written to Volumes. In all cases, the Prune command applies
-a retention period to the specified records. You can Prune expired File
-entries from Job records; you can Prune expired Job records from the
-database, and you can Prune both expired Job and File records from specified
-Volumes.
+ \index[console]{prune}
+ The Prune command allows you to safely remove expired database records
+ from Jobs and Volumes. This command works only on the Catalog database
+ and does not affect data written to Volumes. In all cases, the Prune
+ command applies a retention period to the specified records. You can
+ Prune expired File entries from Job records; you can Prune expired Job
+ records from the database, and you can Prune both expired Job and File
+ records from specified Volumes.
prune files|jobs|volume client=\lt{}client-name\gt{}
volume=\lt{}volume-name\gt{}
-For a Volume to be pruned, the {\bf VolStatus} must be Full, Used, or Append,
-otherwise the pruning will not take place.
+ For a Volume to be pruned, the {\bf VolStatus} must be Full, Used, or
+ Append, otherwise the pruning will not take place.
\item [purge]
- \index[console]{purge }
- The Purge command will delete associated Catalog database records from Jobs
-and Volumes without considering the retention period. {\bf Purge} works only
-on the Catalog database and does not affect data written to Volumes. This
-command can be dangerous because you can delete catalog records associated
-with current backups of files, and we recommend that you do not use it
-unless you know what you are doing. The permitted forms of {\bf purge} are:
-purge files
-jobid=\lt{}jobid\gt{}|job=\lt{}job-name\gt{}|client=\lt{}client-name\gt{}
+ \index[console]{purge}
+ The Purge command will delete associated Catalog database records from
+ Jobs and Volumes without considering the retention period. {\bf Purge}
+ works only on the Catalog database and does not affect data written to
+ Volumes. This command can be dangerous because you can delete catalog
+ records associated with current backups of files, and we recommend that
+ you do not use it unless you know what you are doing. The permitted
+ forms of {\bf purge} are:
+
+purge files jobid=\lt{}jobid\gt{}|job=\lt{}job-name\gt{}|client=\lt{}client-name\gt{}
purge jobs client=\lt{}client-name\gt{} (of all jobs)
The actual data written to the Volume will be unaffected by this command.
\item [relabel]
- \index[console]{relabel }
- This command is used to label physical volumes. The full form of this command
-is:
-
-relabel storage=\lt{}storage-name\gt{} volume=\lt{}newvolume-name\gt{}
-name=\lt{}old-volume-name\gt{}
+ \index[console]{relabel}
+ \index[general]{relabel}
+ This command is used to label physical volumes. The full form of this
+ command is:
-If you leave out any part, you will be prompted for it. In order for the
-Volume (old-volume-name) to be relabeled, it must be in the catalog, and the
-volume status must be marked {\bf Purged} or {\bf Recycle}. This happens
-automatically as a result of applying retention periods, or you may
-explicitly purge the volume using the {\bf purge} command.
+relabel storage=\lt{}storage-name\gt{} oldvolume=\lt{}old-volume-name\gt{}
+ volume=\lt{}newvolume-name\gt{}
+
+ If you leave out any part, you will be prompted for it. In order for
+ the Volume (old-volume-name) to be relabeled, it must be in the catalog,
+ and the volume status must be marked {\bf Purged} or {\bf Recycle}.
+ This happens automatically as a result of applying retention periods, or
+ you may explicitly purge the volume using the {\bf purge} command.
-Once the volume is physically relabeled, the old data written on the Volume
-is lost and cannot be recovered.
+ Once the volume is physically relabeled, the old data previously written
+ on the Volume is lost and cannot be recovered.
\item [release]
- \index[console]{release }
- This command is used to cause the Storage daemon to rewind (release) the
-current tape in the drive, and to re-read the Volume label the next time the
-tape is used.
+ \index[console]{release}
+ This command is used to cause the Storage daemon to rewind (release) the
+ current tape in the drive, and to re-read the Volume label the next time
+ the tape is used.
release storage=\lt{}storage-name\gt{}
-After a release command, the device is still kept open by Bacula (unless
-Always Open is set to No in the Storage Daemon's configuration) so it cannot
-be used by another program. However, with some tape drives, the operator can
-remove the current tape and to insert a different one, and when the next Job
-starts, Bacula will know to re-read the tape label to find out what tape is
-mounted. If you want to be able to use the drive with another program (e.g.
-{\bf mt}), you must use the {\bf unmount} command to cause Bacula to
-completely release (close) the device.
+ After a release command, the device is still kept open by Bacula (unless
+ Always Open is set to No in the Storage Daemon's configuration) so it
+ cannot be used by another program. However, with some tape drives, the
+ operator can remove the current tape and to insert a different one, and
+ when the next Job starts, Bacula will know to re-read the tape label to
+ find out what tape is mounted. If you want to be able to use the drive
+ with another program (e.g. {\bf mt}), you must use the {\bf unmount}
+ command to cause Bacula to completely release (close) the device.
+
+\item [reload]
+ \index[console]{reload}
+ The reload command causes the Director to re-read its configuration
+ file and apply the new values. The new values will take effect
+ immediately for all new jobs. However, if you change schedules,
+ be aware that the scheduler pre-schedules jobs up to two hours in
+ advance, so any changes that are to take place during the next two
+ hours may be delayed. Jobs that have already been scheduled to run
+ (i.e. surpassed their requested start time) will continue with the
+ old values. New jobs will use the new values. Each time you issue
+ a reload command while jobs are running, the prior config values
+ will queued until all jobs that were running before issuing
+ the reload terminate, at which time the old config values will
+ be released from memory. The Directory permits keeping up to
+ 10 prior set of configurations before it will refuse a reload
+ command. Once at least one old set of config values has been
+ released it will again accept new reload commands.
+
+ While it is possible to reload the Director's configuration on the fly,
+ even while jobs are executing, this is a complex operation and not
+ without side effects. Accordingly, if you have to reload the Director's
+ configuration while Bacula is running, it is advisable to restart the
+ Director at the next convenient opportunity.
+
\item [restore]
- \index[console]{restore }
- The restore command allows you to select one or more Jobs (JobIds) to be
-restored using various methods. Once the JobIds are selected, the File
-records for those Jobs are placed in an internal Bacula directory tree, and
-the restore enters a file selection mode that allows you to interactively
-walk up and down the file tree selecting individual files to be restored.
-This mode is somewhat similar to the standard Unix {\bf restore} program's
-interactive file selection mode.
+ \index[console]{restore}
+ The restore command allows you to select one or more Jobs (JobIds) to be
+ restored using various methods. Once the JobIds are selected, the File
+ records for those Jobs are placed in an internal Bacula directory tree,
+ and the restore enters a file selection mode that allows you to
+ interactively walk up and down the file tree selecting individual files
+ to be restored. This mode is somewhat similar to the standard Unix {\bf
+ restore} program's interactive file selection mode.
restore storage=\lt{}storage-name\gt{} client=\lt{}client-name\gt{}
-where=\lt{}path\gt{} pool=\lt{}pool-name\gt{} fileset=\lt{}fileset-name\gt{}
-select current all done
+ where=\lt{}path\gt{} pool=\lt{}pool-name\gt{} fileset=\lt{}fileset-name\gt{}
+ select current all done
-Where {\bf current}, if specified, tells the restore command to automatically
-select a restore to the most current backup. If not specified, you will be
-prompted. The {\bf all} specification tells the restore command to restore
-all files. If it is not specified, you will be prompted for the files to
-restore. For details of the {\bf restore} command, please see the
-\ilink{Restore Chapter}{_ChapterStart13} of this manual.
+ Where {\bf current}, if specified, tells the restore command to
+ automatically select a restore to the most current backup. If not
+ specified, you will be prompted. The {\bf all} specification tells the
+ restore command to restore all files. If it is not specified, you will
+ be prompted for the files to restore. For details of the {\bf restore}
+ command, please see the \ilink{Restore Chapter}{_ChapterStart13} of this
+ manual.
\item [run]
- \index[fd]{run }
+ \index[console]{run}
This command allows you to schedule jobs to be run immediately. The full form
-of the command is:
+ of the command is:
run job=\lt{}job-name\gt{} client=\lt{}client-name\gt{}
-fileset=\lt{}FileSet-name\gt{} level=\lt{}level-keyword\gt{}
-storage=\lt{}storage-name\gt{} where=\lt{}directory-prefix\gt{}
-when=\lt{}universal-time-specification\gt{} yes
+ fileset=\lt{}FileSet-name\gt{} level=\lt{}level-keyword\gt{}
+ storage=\lt{}storage-name\gt{} where=\lt{}directory-prefix\gt{}
+ when=\lt{}universal-time-specification\gt{} yes
-Any information that is needed but not specified will be listed for
-selection, and before starting the job, you will be prompted to accept,
-reject, or modify the parameters of the job to be run, unless you have
-specified {\bf yes}, in which case the job will be immediately sent to the
-scheduler.
+ Any information that is needed but not specified will be listed for
+ selection, and before starting the job, you will be prompted to accept,
+ reject, or modify the parameters of the job to be run, unless you have
+ specified {\bf yes}, in which case the job will be immediately sent to
+ the scheduler.
-On my system, when I enter a run command, I get the following prompt:
+ On my system, when I enter a run command, I get the following prompt:
\footnotesize
\begin{verbatim}
desired start time in YYYY-MM-DD HH:MM:SS format.
\item [setdebug]
- \index[dir]{setdebug }
+ \index[dir]{setdebug}
This command is used to set the debug level in each daemon. The form of this
-command is:
+ command is:
setdebug level=nn [trace=0/1 client=\lt{}client-name\gt{} | dir | director |
-storage=\lt{}storage-name\gt{} | all]
+ storage=\lt{}storage-name\gt{} | all]
-If trace=1 is set, then the tracing will be enabled, and the daemon where the
-setdebug applies will be placed in trace mode, and all debug output will go
-to the file {\bf bacula.trace} in the current directory of the daemon.
-Normally, tracing is used only for Win32 clients where the debug output
-cannot be written to a terminal or redirected to a file. When tracing, each
-debug output message is appended to the trace file. You must explicitly
-delete the file when you are done.
+ If trace=1 is set, then the tracing will be enabled, and the daemon
+ where the setdebug applies will be placed in trace mode, and all debug
+ output will go to the file {\bf bacula.trace} in the current directory
+ of the daemon. Normally, tracing is used only for Win32 clients where
+ the debug output cannot be written to a terminal or redirected to a
+ file. When tracing, each debug output message is appended to the trace
+ file. You must explicitly delete the file when you are done.
\item [show]
- \index[fd]{show }
- The show command will list the Director's resource records as defined in the
-Director's configuration file (normally {\bf bacula-dir.conf}). This command
-is used mainly for debugging purposes by developers. The following keywords
-are accepted on the show command line: directors, clients, counters, jobs,
-storages, catalogs, schedules, filesets, groups, pools, messages, all, help.
-Please don't confuse this command with the {\bf list}, which displays the
-contents of the catalog.
+ \index[console]{show}
+ The show command will list the Director's resource records as defined in
+ the Director's configuration file (normally {\bf bacula-dir.conf}).
+ This command is used mainly for debugging purposes by developers. The
+ following keywords are accepted on the show command line: directors,
+ clients, counters, jobs, storages, catalogs, schedules, filesets,
+ groups, pools, messages, all, help. Please don't confuse this command
+ with the {\bf list}, which displays the contents of the catalog.
\item [sqlquery]
- \index[dir]{sqlquery }
- The sqlquery command puts the Console program into SQL query mode where each
-line you enter is concatenated to the previous line until a semicolon (;) is
-seen. The semicolon terminates the command, which is then passed directly to
-the SQL database engine. When the output from the SQL engine is displayed,
-the formation of a new SQL command begins. To terminate SQL query mode and
-return to the Console command prompt, you enter a period (.) in column 1.
-
-Using this command, you can query the SQL catalog database directly. Note you
-should really know what you are doing otherwise you could damage the catalog
-database. See the {\bf query} command below for simpler and safer way of
-entering SQL queries.
-
-Depending on what database engine you are using (MySQL or SQLite), you will
-have somewhat different SQL commands available. For more detailed
-information, please refer to the MySQL or SQLite documentation.
+ \index[dir]{sqlquery}
+ The sqlquery command puts the Console program into SQL query mode where
+ each line you enter is concatenated to the previous line until a
+ semicolon (;) is seen. The semicolon terminates the command, which is
+ then passed directly to the SQL database engine. When the output from
+ the SQL engine is displayed, the formation of a new SQL command begins.
+ To terminate SQL query mode and return to the Console command prompt,
+ you enter a period (.) in column 1.
+
+ Using this command, you can query the SQL catalog database directly.
+ Note you should really know what you are doing otherwise you could
+ damage the catalog database. See the {\bf query} command below for
+ simpler and safer way of entering SQL queries.
+
+ Depending on what database engine you are using (MySQL, PostgreSQL or
+ SQLite), you will have somewhat different SQL commands available. For
+ more detailed information, please refer to the MySQL, PostgreSQL or
+ SQLite documentation.
\item [status]
- \index[dir]{status }
- This command will display the status of the next jobs that are scheduled
-during the next twenty-four hours as well as the status of currently running
-jobs. The full form of this command is:
+ \index[dir]{status}
+ This command will display the status of the next jobs that are scheduled
+ during the next twenty-four hours as well as the status of currently
+ running jobs. The full form of this command is:
status [all | dir=\lt{}dir-name\gt{} | director |
-client=\lt{}client-name\gt{} | storage=\lt{}storage-name\gt{}]
+ client=\lt{}client-name\gt{} | storage=\lt{}storage-name\gt{}]
-If you do a {\bf status dir}, the console will list any currently running
-jobs, a summary of all jobs scheduled to be run in the next 24 hours, and a
-listing of the last 10 terminated jobs with their statuses. The scheduled
-jobs summary will include the Volume name to be used. You should be aware of
-two things: 1. to obtain the volume name, the code goes through the same code
-that will be used when the job runs, which means that it may prune or recycle
-a Volume; 2. The Volume listed is only a best guess. The Volume actually
-used may be different because of the time difference (more durations may
-expire when the job runs) and another job could completely fill the Volume
-requiring a new one.
+ If you do a {\bf status dir}, the console will list any currently
+ running jobs, a summary of all jobs scheduled to be run in the next 24
+ hours, and a listing of the last 10 terminated jobs with their statuses.
+ The scheduled jobs summary will include the Volume name to be used. You
+ should be aware of two things: 1. to obtain the volume name, the code
+ goes through the same code that will be used when the job runs, which
+ means that it may prune or recycle a Volume; 2. The Volume listed is
+ only a best guess. The Volume actually used may be different because of
+ the time difference (more durations may expire when the job runs) and
+ another job could completely fill the Volume requiring a new one.
-In the Running Jobs listing, you may find the following types of information:
+ In the Running Jobs listing, you may find the following types of
+ information:
\footnotesize
\end{verbatim}
\normalsize
-Looking at the above listing from bottom to top, obviously JobId 5343 (Rufus)
-is running. JobId 5348 (Minou) is waiting for JobId 5343 to finish because it
-is using the Storage resource, hence the ``waiting on max Storage jobs''.
-JobId 5349 has a lower priority than all the other jobs so it is waiting for
-higher priority jobs to finish, and finally, JobId 2508 (MatouVerify) is
-waiting because only one job can run at a time, hence it is simply ``waiting
-execution\".</dd>
+ Looking at the above listing from bottom to top, obviously JobId 5343
+ (Rufus) is running. JobId 5348 (Minou) is waiting for JobId 5343 to
+ finish because it is using the Storage resource, hence the "waiting on
+ max Storage jobs". JobId 5349 has a lower priority than all the other
+ jobs so it is waiting for higher priority jobs to finish, and finally,
+ JobId 2508 (MatouVerify) is waiting because only one job can run at a
+ time, hence it is simply "waiting execution"
\item [unmount]
- \index[console]{unmount }
+ \index[console]{unmount}
This command causes the indicated Bacula Storage daemon to unmount the
-specified device. The forms of the command are the same as the mount command:
-
+ specified device. The forms of the command are the same as the mount command:
+\footnotesize
+\begin{verbatim}
unmount storage=\lt{}storage-name\gt{}
unmount [ jobid=\lt{}id\gt{} | job=\lt{}job-name\gt{} ]
+\end{verbatim}
+\normalsize
+\label{UpdateCommand}
\item [update]
- \index[console]{update }
- This command will update catalog for either a specific Pool record, a Volume
-record, or the Slots in an autochanger with barcode capability. In the case
-of updating a Pool record, the new information will be automatically taken
-from the corresponding Director's configuration resource record. It can be
-used to increase the maximum number of volumes permitted or to set a maximum
-number of volumes. The following main keywords may be specified:
-
-media, volume, pool, slots
+ \index[console]{update}
+ This command will update the catalog for either a specific Pool record, a Volume
+ record, or the Slots in an autochanger with barcode capability. In the case
+ of updating a Pool record, the new information will be automatically taken
+ from the corresponding Director's configuration resource record. It can be
+ used to increase the maximum number of volumes permitted or to set a maximum
+ number of volumes. The following main keywords may be specified:
+\footnotesize
+\begin{verbatim}
+ media, volume, pool, slots
+\end{verbatim}
+\normalsize
In the case of updating a Volume, you will be prompted for which value you
wish to change. The following Volume parameters may be changed:
\footnotesize
\begin{verbatim}
- Volume Status
- Volume Retention Period
- Volume Use Duration
- Maximum Volume Jobs
- Maximum Volume Files
- Maximum Volume Bytes
- Recycle Flag
- Slot
- InChanger Flag
- Pool
- Volume Files
- Volume from Pool
- All Volumes from Pool
-
+ Volume Status
+ Volume Retention Period
+ Volume Use Duration
+ Maximum Volume Jobs
+ Maximum Volume Files
+ Maximum Volume Bytes
+ Recycle Flag
+ Slot
+ InChanger Flag
+ Pool
+ Volume Files
+ Volume from Pool
+ All Volumes from Pool
+
\end{verbatim}
\normalsize
-For slots {\bf update slots}, Bacula will obtain a list of slots and their
-barcodes from the Storage daemon, and for each barcode found, it will
-automatically update the slot in the catalog Media record to correspond to
-the new value. This is very useful if you have moved cassettes in the
-magazine, or if you have removed the magazine and inserted a different one.
-As the slot of each Volume is updated, the InChanger flag for that Volume
-will also be set, and any other Volumes in the Pool will have their InChanger
-flag turned off. This permits Bacula to know what magazine (tape holder) is
-currently in the autochanger.
+ For slots {\bf update slots}, Bacula will obtain a list of slots and
+ their barcodes from the Storage daemon, and for each barcode found, it
+ will automatically update the slot in the catalog Media record to
+ correspond to the new value. This is very useful if you have moved
+ cassettes in the magazine, or if you have removed the magazine and
+ inserted a different one. As the slot of each Volume is updated, the
+ InChanger flag for that Volume will also be set, and any other Volumes
+ in the Pool will have their InChanger flag turned off. This permits
+ Bacula to know what magazine (tape holder) is currently in the
+ autochanger.
-If you do not have barcodes, you can accomplish the same thing in version
-1.33 and later by using the {\bf update slots scan} command. The {\bf scan}
-keyword tells Bacula to physically mount each tape and to read its
-VolumeName.
+ If you do not have barcodes, you can accomplish the same thing in
+ version 1.33 and later by using the {\bf update slots scan} command.
+ The {\bf scan} keyword tells Bacula to physically mount each tape and to
+ read its VolumeName.
-For Pool {\bf update pool}, Bacula will move the Volume record from its
-existing poole to the pool specified.
+ For Pool {\bf update pool}, Bacula will move the Volume record from its
+ existing pool to the pool specified.
-For {\bf Volume from Pool} and {\bf All Volumes from Pool}, the following
-values are updated from the Pool record: Recycle, VolRetention,
-VolUseDuration, MaxVolJobs, MaxVolFiles, and MaxVolBytes.
+ For {\bf Volume from Pool} and {\bf All Volumes from Pool}, the
+ following values are updated from the Pool record: Recycle,
+ VolRetention, VolUseDuration, MaxVolJobs, MaxVolFiles, and MaxVolBytes.
-The full form of the update command with all command line arguments is:
+ The full form of the update command with all command line arguments is:
\footnotesize
\begin{verbatim}
use \lt{}database-name\gt{}
-\item [
+\item [var]
\label{var}
- var]
-\index[console]{a name }
-This command takes a string or quoted string and does variable expansion on
-it the same way variable expansion is done on the {\bf LabelFormat} string.
-Thus, for the most part, you can test your LabelFormat strings. The
-difference between the {\bf var} command and the actual LabelFormat process
-is that during the var command, no job is running so ''dummy`` values are
-used in place of Job specific variables. Generally, however, you will get a
-good idea of what is going to happen in the real case.
+ \index[console]{var name }
+ This command takes a string or quoted string and does variable expansion on
+ it the same way variable expansion is done on the {\bf LabelFormat} string.
+ Thus, for the most part, you can test your LabelFormat strings. The
+ difference between the {\bf var} command and the actual LabelFormat process
+ is that during the var command, no job is running so "dummy" values are
+ used in place of Job specific variables. Generally, however, you will get a
+ good idea of what is going to happen in the real case.
\item [version]
\index[console]{version }
\item [query]
\index[console]{query }
This command reads a predefined SQL query from the query file (the name and
-location of the query file is defined with the QueryFile resource record in
-the Director's configuration file). You are prompted to select a query from
-the file, and possibly enter one or more parameters, then the command is
-submitted to the Catalog database SQL engine.
+ location of the query file is defined with the QueryFile resource record in
+ the Director's configuration file). You are prompted to select a query from
+ the file, and possibly enter one or more parameters, then the command is
+ submitted to the Catalog database SQL engine.
The following queries are currently available (version 1.24):
\normalsize
\item [exit]
- \index[fd]{exit }
+ \index[console]{exit }
This command terminates the console program.
\item [wait]
\footnotesize
\begin{verbatim}
-.die cause the Director to segment fault (for debugging)
-.jobs list all job names
-.filesets list all fileset names
-.clients list all client names
-.msgs return any queued messages
-.quit quit
-.exit quit
+.backups job=xxx list backups for specified job
+.defaults client=xxx fileset=yyy list defaults for specified client
+.die cause the Director to segment fault (for debugging)
+.dir when in tree mode prints the equivalent to the dir command,
+ but with fields separated by commas rather than spaces.
+.jobs list all job names
+.levels list all levels
+.filesets list all fileset names
+.clients list all client names
+.pools list all pool names
+.types list job types
+.msgs return any queued messages
+.messages get quick messages
+.help help command output
+.quit quit
+.status get status output
+.exit quit
\end{verbatim}
\normalsize
Normally, all commands entered to the Console program are immediately
forwarded to the Director, which may be on another machine, to be executed.
-However, there is a small list of {\bf at} commands, all beginning with a at
+However, there is a small list of {\bf at} commands, all beginning with an at
character (@), that will not be sent to the Director, but rather interpreted
by the Console program directly. Note, these commands are implemented only in
the tty console program and not in the GNOME Console. These commands are:
Read and execute the commands contained in the file specified.
\item [@output \lt{}filename\gt{} w/a]
- \index[fd]{@output \lt{}filename\gt{} w/a }
+ \index[console]{@output \lt{}filename\gt{} w/a }
Send all following output to the filename specified either overwriting the
file (w) or appending to the file (a). To redirect the output to the
terminal, simply enter {\bf @output} without a filename specification.
\normalsize
\item [@tee \lt{}filename\gt{} w/a]
- \index[fd]{@tee \lt{}filename\gt{} w/a }
+ \index[console]{@tee \lt{}filename\gt{} w/a }
Send all subsequent output to both the specified file and the terminal. It is
-turned off by specifying {\bf @tee} or {\bf @output} without a filename.
+ turned off by specifying {\bf @tee} or {\bf @output} without a filename.
\item [@sleep \lt{}seconds\gt{}]
- \index[fd]{@sleep \lt{}seconds\gt{} }
+ \index[console]{@sleep \lt{}seconds\gt{} }
Sleep the specified number of seconds.
\item [@time]
- \index[fd]{@time }
+ \index[console]{@time }
Print the current time and date.
\item [@version]
- \index[fd]{@version }
+ \index[console]{@version }
Print the console's version.
\item [@quit]
Before adding a volume, you must know the following information:
\begin{enumerate}
-\item The name of the Pool (normally ''Default``)
+\item The name of the Pool (normally "Default")
\item The Media Type as specified in the Storage Resource in the Director's
- configuration file (e.g. ''DLT8000``)
+ configuration file (e.g. "DLT8000")
\item The number and names of the Volumes you wish to create.
- \end{enumerate}
+\end{enumerate}
For example, to add media to a Pool, you would issue the following commands to
the console program:
Notice that the console program automatically appended a number to the base
Volume name that you specify (Save in this case). If you don't want it to
-append a number, you can simply answer 0 (zero) to the question ''Enter number
-of Media volumes to create. Max=1000:``, and in this case, it will create a
+append a number, you can simply answer 0 (zero) to the question "Enter number
+of Media volumes to create. Max=1000:", and in this case, it will create a
single Volume with the exact name you specify.
\section*{Console Configuration}
\label{_ChapterStart36}
-\index[general]{Configuration!Console }
-\index[general]{Console Configuration }
+\index[general]{Configuration!Console}
+\index[general]{Console Configuration}
\addcontentsline{toc}{section}{Console Configuration}
\subsection*{General}
-\index[general]{General }
+\index[general]{General}
\addcontentsline{toc}{subsection}{General}
The Console configuration file is the simplest of all the configuration files,
\subsection*{The Director Resource}
\label{DirectorResource3}
-\index[general]{Director Resource }
-\index[general]{Resource!Director }
+\index[general]{Director Resource}
+\index[general]{Resource!Director}
\addcontentsline{toc}{subsection}{Director Resource}
The Director resource defines the attributes of the Director running on the
\begin{description}
\item [Director]
- \index[console]{Director }
+ \index[console]{Director}
Start of the Director records.
\item [Name = \lt{}name\gt{}]
- \index[console]{Name }
+ \index[console]{Name}
The director name used to select among different Directors, otherwise, this
name is not used.
\item [DIRPort = \lt{}port-number\gt{}]
- \index[dir]{DIRPort }
+ \index[dir]{DIRPort}
Specify the port to use to connect to the Director. This value will most
likely already be set to the value you specified on the {\bf
-\verb{--{with-base-port} option of the {\bf ./configure} command. This port must be
+\verb:--:with-base-port} option of the {\bf ./configure} command. This port must be
identical to the {\bf DIRport} specified in the {\bf Director} resource of
the
\ilink{Director's configuration}{_ChapterStart40} file. The
default is 9101 so this record is not normally specified.
\item [Address = \lt{}address\gt{}]
- \index[dir]{Address }
+ \index[dir]{Address}
Where the address is a host name, a fully qualified domain name, or a network
address used to connect to the Director.
\item [Password = \lt{}password\gt{}]
- \index[dir]{Password }
+ \index[dir]{Password}
Where the password is the password needed for the Director to accept the
Console connection. This password must be identical to the {\bf Password}
specified in the {\bf Director} resource of the
\normalsize
\subsection*{The ConsoleFont Resource}
-\index[general]{Resource!ConsoleFont }
-\index[general]{ConsoleFont Resource }
+\index[general]{Resource!ConsoleFont}
+\index[general]{ConsoleFont Resource}
\addcontentsline{toc}{subsection}{ConsoleFont Resource}
The ConsoleFont resource is available only in the GNOME version of the
\begin{description}
\item [ConsoleFont]
- \index[console]{ConsoleFont }
+ \index[console]{ConsoleFont}
Start of the ConsoleFont records.
\item [Name = \lt{}name\gt{}]
- \index[console]{Name }
+ \index[console]{Name}
The name of the font.
-\item [Font = \lt{}X-Window Font Specification\gt{}]
- \index[console]{Font }
+\item [Font = \lt{}Pango Font Name\gt{}]
+ \index[console]{Font}
The string value given here defines the desired font. It is specified in the
-standard cryptic X Window format. For example, the default specification is:
+Pango format. For example, the default specification is:
\footnotesize
\begin{verbatim}
-Font = "-misc-fixed-medium-r-normal-*-*-130-*-*-c-*-iso8859-1"
+Font = "LucidaTypewriter 9"
\end{verbatim}
\normalsize
Thanks to Phil Stracchino for providing the code for this feature.
-An actual example might be:
+An different example might be:
\footnotesize
\begin{verbatim}
ConsoleFont {
Name = Default
-Font = "-misc-fixed-medium-r-normal-*-*-130-*-*-c-*-iso8859-1"
+Font = "Monospace 10"
}
\end{verbatim}
\normalsize
\subsection*{The Console Resource}
\label{ConsoleResource}
-\index[general]{Console Resource }
-\index[general]{Resource!Console }
+\index[general]{Console Resource}
+\index[general]{Resource!Console}
\addcontentsline{toc}{subsection}{Console Resource}
As of Bacula version 1.33 and higher, there are three different kinds of
kind of console that was initially implemented in versions prior to 1.33 and
remains valid. Typically you would use it only for administrators.
\item The second type of console, and new to version 1.33 and higher is a
- ``named'' console defined within a Console resource in both the Director's
+ "named" console defined within a Console resource in both the Director's
configuration file and in the Console's configuration file. Both the names
and the passwords in these two entries must match much as is the case for
Client programs.
permitted to use the {\bf SetIP} command to change the Address directive in
the Director's client resource to the IP address of the Console. This permits
portables or other machines using DHCP (non-fixed IP addresses) to
-``notify'' the Director of their current IP address.
+"notify" the Director of their current IP address.
\end{itemize}
The Console resource is optional and need not be specified. However, if it is
DIRport = 9101
Address = myserver
Password = "XXXXXXXXXXX" # no, really. this is not obfuscation.
- }
+}
Console {
Name = restricted-user
Password = "UntrustedUser"
- }
+}
\end{verbatim}
\normalsize
and do with Bacula.
\subsection*{Console Commands}
-\index[general]{Console Commands }
-\index[general]{Commands!Console }
+\index[general]{Console Commands}
+\index[general]{Commands!Console}
\addcontentsline{toc}{subsection}{Console Commands}
For more details on running the console and its commands, please see the
-\ilink{Bacula Console}{_ChapterStart23} chapter of this manual.
+\ilink{Bacula Console}{_ConsoleChapter} chapter of this manual.
\subsection*{Sample Console Configuration File}
\label{SampleConfiguration2}
-\index[general]{File!Sample Console Configuration }
-\index[general]{Sample Console Configuration File }
+\index[general]{File!Sample Console Configuration}
+\index[general]{Sample Console Configuration File}
\addcontentsline{toc}{subsection}{Sample Console Configuration File}
-A example Console configuration file might be the following:
+An example Console configuration file might be the following:
\footnotesize
\begin{verbatim}
\vspace*{6cm}
\begin{center}
- \copyright\ Copyright 2000-2004 --\pubyear\ \company
+ \copyright\ Copyright 2000-2005 --\pubyear\ \company
\end{center}
\begin{center}
\company\ makes no warranty, either express or implied, including but not
limited to any implied warranties of merchantability and fitness for a
particular purpose, regarding these materials and makes such materials
-available solely on an ``as-is'' basis.
+available solely on an "as-is" basis.
In no event shall \company\ be liable to anyone for special, collateral,
incidental, or consequential damages in connection with or arising out of
We recommend you take your time before implementing a Bacula backup system
since Bacula is a rather complex program, and if you make a mistake, you may
-suddenly find that you cannot restore the your files in case of a disaster.
+suddenly find that you cannot restore your files in case of a disaster.
This is especially true if you have not previously used a major backup
product.
If you follow the instructions in this chapter, you will have covered most of
-the major problems that can occur. It goes without saying that if ever you
-find that we have left out an important point, please point it out to us, so
+the major problems that can occur. It goes without saying that if you ever
+find that we have left out an important point, please inform us, so
that we can document it to the benefit of everyone.
+\label{Critical}
\subsection*{Critical Items}
\index[general]{Critical Items }
\index[general]{Items!Critical }
The following assumes that you have installed Bacula, you more or less
understand it, you have at least worked through the tutorial or have
-equivalent experience, and that you have setup a basic production
-configuration. If you haven't done the above, please do so then come back
-here. The following is a sort of checklist that points you elsewhere in the
-manual with perhaps a brief explaination of why you should do it. The order is
-more or less the order you would use in setting up a production system (if you
-already are in production, use the checklist anyway).
+equivalent experience, and that you have set up a basic production
+configuration. If you haven't done the above, please do so and then come back
+here. The following is a sort of checklist that points with perhaps a brief
+explanation of why you should do it. You will find the details elsewhere in the
+manual. The order is more or less the order you would use in setting up a
+production system (if you already are in production, use the checklist anyway).
\begin{itemize}
-\item Test your tape drive with compatibility with Bacula by using the test
- command in the
- \ilink{btape}{btape} program.
+\item Test your tape drive for compatibility with Bacula by using the test
+ command in the \ilink{btape}{btape} program.
\item Better than doing the above is to walk through the nine steps in the
\ilink{Tape Testing}{_ChapterStart27} chapter of the manual. It
may take you a bit of time, but it will eliminate surprises.
-\item Make sure that /lib/tls is disabled. Bacula does not work with this
- library. See the second point under
+\item Test your the end of tape handling of your tape drive by using the
+ fill command in the \ilink{btape}{btape} program.
+\item If you are using a 2.4 kernel, make sure that /lib/tls is disabled. Bacula
+ does not work with this library. See the second point under
\ilink{ Supported Operating Systems.}{SupportedOSes}
\item Do at least one restore of files. If you backup both Unix and Win32
systems, restore files from each system type. The
\item Write a bootstrap file to a separate system for each backup job. The
Write Bootstrap directive is described in the
\ilink{Director Configuration}{writebootstrap} chapter of the
-manual, and more details are available in the
-\ilink{Bootstrap File}{_ChapterStart43} chapter. Also, the default
-bacula-dir.conf comes with a Write Bootstrap directive defined. This allows
-you to recover the state of your system as of the last backup.
+ manual, and more details are available in the
+ \ilink{Bootstrap File}{_ChapterStart43} chapter. Also, the default
+ bacula-dir.conf comes with a Write Bootstrap directive defined. This allows
+ you to recover the state of your system as of the last backup.
\item Backup your catalog. An example of this is found in the default
bacula-dir.conf file. The backup script is installed by default and should
handle any database, though you may want to make your own local
-modifications.
-\item Write a bootstrap file for the catalog. An example of this is found in
- the default bacula-dir.conf file. This will allow you to quickly restore your
+ modifications.
+\item Write a bootstrap file for the catalog. An example of this is found in
+ the default bacula-dir.conf file. This will allow you to quickly restore your
catalog in the event it is wiped out -- otherwise it is many excruciating
-hours of work.
+ hours of work.
\item Make a Bacula Rescue CDROM! See the
\ilink{Disaster Recovery Using a Bacula Rescue
CDROM}{_ChapterStart38} chapter. It is trivial to make such a CDROM,
-and it can make system recovery in the event of a lost hard disk infinitely
-easier.
+ and it can make system recovery in the event of a lost hard disk infinitely
+ easier.
+\item After doing your first backup restore some or all the data. Do this for
+ at least one client on each different OS (e.g. Linux, FreeBSD, Solaris, Win32).
\end{itemize}
\subsection*{Recommended Items}
you avoid problems.
\begin{itemize}
-\item Read the
- \ilink{Quick Start Guide to Bacula}{_ChapterStart37}
+\item Read the \ilink{Quick Start Guide to Bacula}{_ChapterStart37}
\item After installing and experimenting with Bacula, read and work carefully
through the examples in the
\ilink{Tutorial}{_ChapterStart1} chapter of this manual.
-\item Learn what each of the
- \ilink{Bacula Utility Programs}{_ChapterStart9} does.
+\item Learn what each of the \ilink{Bacula Utility Programs}{_ChapterStart9}
+does.
\item Set up reasonable retention periods so that your catalog does not grow
- to be too big. See the following three chapters:
- \ilink{Recycling your Volumes}{_ChapterStart22},
-\ilink{Basic Volume Management}{_ChapterStart39},
-\ilink{Using Pools to Manage Volumes}{_ChapterStart11}.
+ to be too big. See the following three chapters:\\
+ \ilink{Recycling your Volumes}{_ChapterStart22},\\
+ \ilink{Basic Volume Management}{_ChapterStart39},\\
+ \ilink{Using Pools to Manage Volumes}{_ChapterStart11}.
\item Perform a bare metal recovery using the Bacula Rescue CDROM. See the
- \ilink{Disaster Recovery Using a Bacula Rescue
- CDROM}{_ChapterStart38} chapter.
+ \ilink{Disaster Recovery Using a Bacula Rescue CDROM}{_ChapterStart38}
+ chapter.
+\end{itemize}
+
+If you absolutely must implement a system where you write a different
+tape each night and take it offsite in the morning. We recommend that you do
+several things:
+\begin{itemize}
+\item Write a bootstrap file of your backed up data and a bootstrap file
+ of your catalog backup to a floppy disk or a CDROM, and take that with
+ the tape. If this is not possible, try to write those files to another
+ computer or offsite computer, or send them as email to a friend. If none
+ of that is possible, at least print the bootstrap files and take that
+ offsite with the tape. Having the bootstrap files will make recovery
+ much easier.
+\item It is better not to force Bacula to load a particular tape each day.
+ Instead, let Bacula choose the tape. If you need to know what tape to
+ mount, you can print a list of recycled and appendable tapes daily, and
+ select any tape from that list. Bacula may propose a particular tape
+ for use that it considers optimal, but it will accept any valid tape
+ from the correct pool.
\end{itemize}
\section*{Basic Volume Management}
\label{_ChapterStart39}
-\index[general]{Basic Volume Management }
-\index[general]{Management!Basic Volume }
+\index[general]{Basic Volume Management}
+\index[general]{Management!Basic Volume}
+\index[general]{Disk Volumes}
\addcontentsline{toc}{section}{Basic Volume Management}
This chapter presents most all the features needed to do Volume management.
Most of the concepts apply equally well to both tape and disk Volumes.
However, the chapter was originally written to explain backing up to disk, so
-you will see it is slanted in that direction, but that all the directives
+you will see it is slanted in that direction, but all the directives
presented here apply equally well whether your volume is disk or tape.
If you have a lot of hard disk storage or you absolutely must have your
backup to disk Volumes rather than tape Volumes. This chapter is intended to
give you some of the options that are available to you so that you can manage
either disk or tape volumes.
-\label{Concepts}
+\label{Concepts}
\subsection*{Key Concepts and Resource Records}
\index[general]{Key Concepts and Resource Records }
\index[general]{Records!Key Concepts and Resource }
label, and the internal label must agree with the system filename before
Bacula will use it.
-Although this is quite simple, there are a number of problems, the first is
+Although this is quite simple, there are a number of problems. The first is
that unless you specify otherwise, Bacula will always write to the same volume
-until you run out of disk space.
+until you run out of disk space. This problem is addressed below.
+
+In addition, if you want to use concurrent jobs that write to several
+different volumes at the same time, you will need to understand a number
+of other details. An example of such a configuration is given
+at the end of this chapter under \ilink{Concurrent Disk
+Jobs}{ConcurrentDiskJobs}.
\subsubsection*{Pool Options to Limit the Volume Usage}
\index[general]{Usage!Pool Options to Limit the Volume }
For example, the above directives can allow you to ensure that you rotate
through a set of daily Volumes if you wish.
-As mentioned above, each of those directives are specified in the Pool or
+As mentioned above, each of those directives is specified in the Pool or
Pools that you use for your Volumes. In the case of {\bf Maximum Volume Job},
{\bf Maximum Volume Bytes}, and {\bf Volume Use Duration}, you can actually
specify the desired value on a Volume by Volume basis. The value specified in
-the Pool record becomes the default when labeling new Volumes. As an example
+the Pool record becomes the default when labeling new Volumes. Once a Volume
+has been created, it gets its own copy of the Pool defaults, and subsequently
+changing the Pool will have no effect on existing Volumes. You can either
+manually change the Volume values, or refresh them from the Pool defaults using
+the {\bf update volume} command in the Console. As an example
of the use of one of the above, suppose your Pool resource contains:
\footnotesize
\normalsize
then if you run a backup once a day (every 24 hours), Bacula will use a new
-Volume each backup because each Volume it writes can only be used for 23 hours
-after the first write.
-\label{AutomaticLabeling}
+Volume for each backup, because each Volume it writes can only be used for 23 hours
+after the first write. Note, setting the use duration to 23 hours is not a very
+good solution for tapes unless you have someone on-site during the weekends,
+because Bacula will want a new Volume and no one will be present to mount it,
+so no weekend backups will be done until Monday morning.
+\label{AutomaticLabeling}
\subsubsection*{Automatic Volume Labeling}
\index[general]{Automatic Volume Labeling }
\index[general]{Labeling!Automatic Volume }
bit simplistic, but it does allow for automation, the features added in
version 1.31 permit automatic creation of a wide variety of labels including
information from environment variables and special Bacula Counter variables.
-
-Please note that automatic Volume can also be used with tapes, but it is not
-nearly so practical since the tapes must be pre-mounted. This requires some
-user interaction. Automatic labeling from templates does NOT work with
-autochangers since Bacula will not access unknown slots. There are several
-methods of labeling all volumes in an autochanger magazine. For more
-information on this, please see the
-\ilink{ Autochanger}{_ChapterStart18} chapter of this manual.
+In version 1.37 and later, it is probably much better to use Python scripting
+and the NewVolume event since generating Volume labels in a Python script is
+much easier than trying to figure out Counter variables. See the
+\ilink{Python Scripting}{_ChapterStart60} chapter of this manual for more
+details.
+
+Please note that automatic Volume labeling can also be used with tapes, but
+it is not nearly so practical since the tapes must be pre-mounted. This
+requires some user interaction. Automatic labeling from templates does NOT
+work with autochangers since Bacula will not access unknown slots. There
+are several methods of labeling all volumes in an autochanger magazine.
+For more information on this, please see the \ilink{
+Autochanger}{_ChapterStart18} chapter of this manual.
Automatic Volume labeling is enabled by making a change to both the Pool
resource (Director) and to the Device resource (Storage daemon) shown above.
You can find more details of the {\bf Label Format} Pool record in
\ilink{Label Format}{Label} description of the Pool resource
records.
-\label{Recycling1}
+\label{Recycling1}
\subsubsection*{Restricting the Number of Volumes and Recycling}
\index[general]{Recycling!Restricting the Number of Volumes and }
\index[general]{Restricting the Number of Volumes and Recycling }
\item The
\ilink{ Recycle = yes}{PoolRecycle} record in the Pool resource
to permit automatic recycling of Volumes whose Volume retention period has
-expired.
+ expired.
\item The
\ilink{ Recycle Oldest Volume = yes}{RecycleOldest} record in the
Pool resource tells Bacula to Prune the oldest volume in the Pool, and if all
-files were pruned to recyle this volume and use it.
+ files were pruned to recycle this volume and use it.
\item The
\ilink{ Recycle Current Volume = yes}{RecycleCurrent} record in
the Pool resource tells Bacula to Prune the currently mounted volume in the
-Pool, and if all files were pruned to recyle this volume and use it.
+ Pool, and if all files were pruned to recycle this volume and use it.
\item The
\ilink{ Purge Oldest Volume = yes}{PurgeOldest} record in the
Pool resource permits a forced recycling of the oldest Volume when a new one
-is needed. {\bf N.B. This record ignores retention periods! We highly
-recommend not to use this record, but instead use Recycle Oldest Volume}
+ is needed. {\bf N.B. This record ignores retention periods! We highly
+ recommend not to use this record, but instead use Recycle Oldest Volume}
\item The
\ilink{ Maximum Volumes = nnn}{MaxVolumes} record in the Pool
resource to limit the number of Volumes that can be created.
Volume Retention, AutoPrune, and Recycle determine how long Bacula will keep
your Volumes before reusing them, and they are also discussed in detail in the
-
\ilink{Automatic Volume Recycling}{_ChapterStart22} chapter of
this manual.
also be done by setting {\bf Recycle Oldest Volume = yes} or {\bf Recycle
Current Volume = yes}. In this case, when Bacula needs a new Volume, it will
prune the specified volume.
-\label{Example2}
+\label{ConcurrentDiskJobs}
+\subsection*{Concurrent Disk Jobs}
+\index[general]{Concurrent Disk Jobs}
+\addcontentsline{toc}{subsection}{Concurrent Disk Jobs}
+Above, we discussed how you could have a single device named {\bf
+FileBackup} that writes to volumes in {\bf /home/bacula/backups}.
+You can, in fact, run multiple concurrent jobs using the
+Storage definition given with this example, and all the jobs will
+simultaneously write into the Volume that is being written.
+
+Now suppose you want to use multiple Pools, which means multiple
+Volumes, or suppose you want each client to have its own Volume
+and perhaps its own directory such as {\bf /home/bacula/client1}
+and {\bf /home/bacula/client2} ... With the single Storage and Device
+definition above, neither of these two is possible. Why? Because
+Bacula disk storage follows the same rules as tape devices. Only
+one Volume can be mounted on any Device at any time. If you want
+to simultaneously write multiple Volumes, you will need multiple
+Device resources in your bacula-sd.conf file, and thus multiple
+Storage resources in your bacula-dir.conf.
+
+OK, so now you should understand that you need multiple Device definitions
+in the case of different directorys or different Pools, but you also
+need to know that the catalog data that Bacula keeps contains only
+the Media Type and not the specific storage device. This permits a tape
+for example to be re-read on any compatible tape drive. The compatibility
+being determined by the Media Type. The same applies to disk storage.
+Since a volume that is written by a Device in say directory {\bf
+/home/bacula/backups} cannot be read by a Device with an Archive Device
+definition of {\bf /home/bacula/client1}, you will not be able to
+restore all your files if you give both those devices
+{\bf Media Type = File}. During the restore, Bacula will simply choose
+the first available device, which may not be the correct one. If this
+is confusing, just remember that the Directory has only the Media Type
+and the Volume name. It does not know the {\bf Archive Device} (or the
+full path) that is specified in the Storage daemon. Thus you must
+explicitly tie your Volumes to the correct Device by using the Media Type.
+
+The example shown below shows a case where there are two clients, each
+using its own Pool and storing their Volumes in different directories.
+
+
+\label{Example2}
\subsection*{An Example}
\index[general]{Example }
\addcontentsline{toc}{subsection}{Example}
The following example is not very practical, but can be used to demonstrate
the proof of concept in a relatively short period of time. The example
-consists of a single client that is backed up to a set of 12 archive files
-(Volumes). Each Volume is used (written) only once, and there are four Full
-saves done every hour (so the whole thing cycles around after three hours).
+consists of a two clients that are backed up to a set of 12 archive files
+(Volumes) for each client into different directories on the Storage
+maching. Each Volume is used (written) only once, and there are four Full
+saves done every hour (so the whole thing cycles around after three hours).
+
+What is key here is that each physical device on the Storage daemon
+has a different Media Type. This allows the Director to choose the
+correct device for restores ...
The Director's configuration file is as follows:
}
Schedule {
Name = "FourPerHour"
- Run = Level=Full Pool=Recycle Storage=File hourly at 0:05
- Run = Level=Full Pool=Recycle Storage=File hourly at 0:20
- Run = Level=Full Pool=Recycle Storage=File hourly at 0:35
- Run = Level=Full Pool=Recycle Storage=File hourly at 0:50
+ Run = Level=Full hourly at 0:05
+ Run = Level=Full hourly at 0:20
+ Run = Level=Full hourly at 0:35
+ Run = Level=Full hourly at 0:50
}
Job {
Name = "RecycleExample"
Pool = Recycle
Schedule = FourPerHour
}
+
+Job {
+ Name = "RecycleExample2"
+ Type = Backup
+ Level = Full
+ Client = Roxie
+ FileSet= "Example FileSet"
+ Messages = Standard
+ Storage = FileStorage1
+ Pool = Recycle1
+ Schedule = FourPerHour
+}
+
FileSet {
Name = "Example FileSet"
Include = compression=GZIP signature=SHA1 {
Catalog = BackupDB
Password = client_password
}
+
+Client {
+ Name = Roxie
+ Address = roxie
+ Catalog = BackupDB
+ Password = client1_password
+}
+
Storage {
Name = FileStorage
Address = rufus
Device = RecycleDir
Media Type = File
}
+
+Storage {
+ Name = FileStorage1
+ Address = rufus
+ Password = local_storage_password
+ Device = RecycleDir1
+ Media Type = File1
+}
+
Catalog {
Name = BackupDB
dbname = bacula; user = bacula; password = ""
Name = Recycle
Use Volume Once = yes
Pool Type = Backup
- LabelFormat = "Vol"
+ LabelFormat = "Recycle-"
+ AutoPrune = yes
+ VolumeRetention = 2h
+ Maximum Volumes = 12
+ Recycle = yes
+}
+
+Pool {
+ Name = Recycle1
+ Use Volume Once = yes
+ Pool Type = Backup
+ LabelFormat = "Recycle1-"
AutoPrune = yes
VolumeRetention = 2h
Maximum Volumes = 12
Recycle = yes
}
+
\end{verbatim}
\normalsize
RemovableMedia = no;
AlwaysOpen = no;
}
+
+Device {
+ Name = RecycleDir1
+ Media Type = File1
+ Archive Device = /home/bacula/backups1
+ LabelMedia = yes;
+ Random Access = Yes;
+ AutomaticMount = yes;
+ RemovableMedia = no;
+ AlwaysOpen = no;
+}
+
Messages {
Name = Standard
director = my-dir = all
\end{verbatim}
\normalsize
-In this example, the Jobs will be backed up to directory {\bf
-/home/bacula/backups} with Volume names Vol0001, Vol0002, ... Vol0012. Every
-backup Job will write a new volume cycling through the volume numbers, and two
-hours after a job has started, the volume will be pruned {\bf Volume Retention
-= 2h}.
-
With a little bit of work, you can change the above example into a weekly or
monthly cycle (take care about the amount of archive disk space used).
-\label{MultipleDisks}
+\label{MultipleDisks}
\subsection*{Backing up to Multiple Disks}
\index[general]{Disks!Backing up to Multiple }
\index[general]{Backing up to Multiple Disks }
Bacula can, of course, use multiple disks, but in general, each disk must be a
separate Device specification in the Storage daemon's conf file, and you must
-then select what clients to backup to each disk.
+then select what clients to backup to each disk. You will also want to
+give each Device specification a different Media Type so that during
+a restore, Bacula will be able to find the appropriate drive.
-The situation is a bit more complicated if you want to treat two disk drives
-logically as a single drive, which Bacula does not directly support. However,
-it is possible to back up your data to multiple disks as if they were a single
-drive by linking the Volumes from the first disk to the second disk.
+The situation is a bit more complicated if you want to treat two different
+physical disk drives (or partitions) logically as a single drive, which
+Bacula does not directly support. However, it is possible to back up your
+data to multiple disks as if they were a single drive by linking the
+Volumes from the first disk to the second disk.
For example, assume that you have two disks named {\bf /disk1} and {\bf
-/disk2>}. If you then create a standard Storage daemon Device resource for
+/disk2}. If you then create a standard Storage daemon Device resource for
backing up to the first disk, it will look like the following:
\footnotesize
method is that you must explicitly name the disks and cannot use automatic
labeling unless you arrange to have the labels exactly match the links you
have created.
-\label{MultipleClients}
+An important thing to know is that Bacula treats disks like tape drives
+as much as it can. This means that you can only have a single Volume
+mounted at one time on a disk as defined in your Device resource in
+the Storage daemon's conf file. You can have multiple concurrent
+jobs running that all write to the one Volume that is being used, but
+if you want to have multiple concurrent jobs that are writting to
+separate disks drives (or partitions), you will need to define
+separate Device resources for each one, exactly as you would do for
+two different tape drives. There is one fundamental difference, however.
+The Volumes that you creat on the two drives cannot be easily exchanged
+as they can for a tape drive, because they are physically resident (already
+mounted in a sense) on the particular drive. As a consequence, you will
+probably want to give them different Media Types so that Bacula can
+distinguish what Device resource to use during a restore.
+An example would be the following:
+
+\footnotesize
+\begin{verbatim}
+Device {
+ Name = Disk1
+ Media Type = File1
+ Archive Device = /disk1
+ LabelMedia = yes;
+ Random Access = Yes;
+ AutomaticMount = yes;
+ RemovableMedia = no;
+ AlwaysOpen = no;
+}
+
+Device {
+ Name = Disk2
+ Media Type = File2
+ Archive Device = /disk2
+ LabelMedia = yes;
+ Random Access = Yes;
+ AutomaticMount = yes;
+ RemovableMedia = no;
+ AlwaysOpen = no;
+}
+\end{verbatim}
+\normalsize
+
+With the above device definitions, you can run two concurrent
+jobs each writing at the same time, one to {\bf /disk2} and the
+other to {\bf /disk2}. The fact that you have given them different
+Media Types will allow Bacula to quickly choose the correct
+Storage resource in the Director when doing a restore.
+
+\label{MultipleClients}
\subsection*{Considerations for Multiple Clients}
\index[general]{Clients!Considerations for Multiple }
-\index[general]{Considerations for Multiple Clients }
+\index[general]{Multiple Clients}
\addcontentsline{toc}{subsection}{Considerations for Multiple Clients}
If we take the above example and add a second Client, here are a few
Catalog = BackupDB
Password = client2_password
}
-# Two Storage definitions permits different directories
+# Two Storage definitions with differen Media Types
+# permits different directories
Storage {
Name = File1
Address = rufus
Password = local_storage_password
Device = client1
- Media Type = File
+ Media Type = File1
}
Storage {
Name = File2
Address = rufus
Password = local_storage_password
Device = client2
- Media Type = File
+ Media Type = File2
}
Catalog {
Name = BackupDB
# Archive directory for Client1
Device {
Name = client1
- Media Type = File
+ Media Type = File1
Archive Device = /home/bacula/client1
LabelMedia = yes;
Random Access = Yes;
# Archive directory for Client2
Device {
Name = client2
- Media Type = File
+ Media Type = File2
Archive Device = /home/bacula/client2
LabelMedia = yes;
Random Access = Yes;
\index[general]{Bacula Frequently Asked Questions }
\addcontentsline{toc}{section}{Bacula Frequently Asked Questions}
-See
+These are questions that have been submitted over time by the
+Bacula users.
+
+Please also see
\ilink{the bugs section}{_ChapterStart4} of this document for a list
of known bugs and solutions.
\begin{description}
\label{what}
-
-\item [What is {\bf Bacula}? ]
-\index[dir]{What is Bacula? }
-{\bf Bacula} is a network backup and restore program.
-
-\item [Does Bacula support Windows? ]
-\index[dir]{Does Bacula support Windows? }
-Yes, Bacula compiles and runs on Windows machines (Win98, WinMe, WinXP,
-WinNT, and Win2000). We provide a binary version of the Client (bacula-fd),
-but have not tested the Director nor the Storage daemon. Note, Win95 is no
-longer supported because it doesn't have the GetFileAttributesExA API call.
+\subsection*{What is Bacula?}
+\item [What is {\bf Bacula}? ]
+ \index[general]{What is Bacula? }
+ {\bf Bacula} is a network backup and restore program.
+
+\subsection*{Does Bacula support Windows?}
+\item [Does Bacula support Windows?]
+ \index[general]{Does Bacula support Windows? }
+ Yes, Bacula compiles and runs on Windows machines (Win98, WinMe, WinXP,
+ WinNT, and Win2000). We provide a binary version of the Client (bacula-fd),
+ but have not tested the Director nor the Storage daemon. Note, Win95 is no
+ longer supported because it doesn't have the GetFileAttributesExA API call.
+
\label{lang}
-
-\item [What language is Bacula written in? ]
-\index[fd]{What language is Bacula written in? }
-It is written in C++, but it is mostly C code using only a limited set of the
-C++ extensions over C. Thus Bacula is completely compiled using the C++
-compiler. There are several modules, including the Win32 interface that are
-written using the object oriented C++ features. Over time, we are slowly
-adding a larger subset of C++.
+\subsection*{What language is Bacula written in?}
+\item [What language is Bacula written in?]
+ \index[general]{What language is Bacula written in? }
+ It is written in C++, but it is mostly C code using only a limited set of
+ the C++ extensions over C. Thus Bacula is completely compiled using the
+ C++ compiler. There are several modules, including the Win32 interface, that
+ are written using the object oriented C++ features. Over time, we are slowly
+ adding a larger subset of C++.
\label{run}
-
-\item [On what machines does Bacula run? ]
-\index[fd]{On what machines does Bacula run? }
-{\bf Bacula} builds and executes on RedHat Linux (versions RH7.1-RHEL 3.0,
-SuSE, Gentoo, Debian, Mandrake, ...), FreeBSD, Solaris, Alpha, SGI (client),
-NetBSD, OpenBSD, Mac OS X (client), and Win32 (client).
-
-Bacula has been my only backup tool for over four years backing up 5 machines
-nightly (3 Linux boxes running RedHat, a WinXP machine, and a WinNT machine).
+\subsection*{On what machines does Bacula run?}
+\item [On what machines does Bacula run? ]
+ \index[general]{On what machines does Bacula run? }
+ {\bf Bacula} builds and executes on RedHat Linux (versions RH7.1-RHEL 3.0,
+ SuSE, Gentoo, Debian, Mandriva, ...), FreeBSD, Solaris, Alpha, SGI (client),
+ NetBSD, OpenBSD, Mac OS X (client), and Win32 (client).
+
+ Bacula has been my only backup tool for over four years backing up 5
+ machines nightly (3 Linux boxes running RedHat, a WinXP machine, and a WinNT
+ machine).
\label{stable}
+\subsection*{Is Bacula Stable?}
+\item [Is Bacula Stable? ]
+ \index[general]{Is Bacula Stable? }
+ Yes, it is remarkably stable, but remember, there are still a lot of
+ unimplemented or partially implemented features. With a program of this size
+ (100,000+ lines of C++ code not including the SQL programs) there are bound
+ to be bugs. The current test environment (a twisted pair local network and a
+ HP DLT backup tape) is not exactly ideal, so additional testing on other
+sites is
+ necessary. The File daemon has never crashed -- running months at a time
+with
+ no intervention. The Storage daemon is remarkably stable with most of the
+ problems arising during labeling or switching tapes. Storage daemon crashes
+ are rare. The Director, given the multitude of functions it fulfills is
+also
+ relatively stable. In a production environment, it rarely if ever crashes. Of
+ the three daemons, the Director is the most prone to having problems. Still,
+it
+ frequently runs several months with no problems.
+
+ There are a number of reasons for this stability.
+
+ \begin{enumerate}
+ \item The program was largely written by one person to date
+ (Kern).\\
+ \item The program is constantly checking the chain of allocated
+ memory buffers to ensure that no overruns have occurred. \\
+ \item All memory leaks (orphaned buffers) are reported each time the
+ program terminates.\\
+ \item Any signal (segmentation fault, ...) generates a
+ traceback that is emailed to the developer. This permits quick resolution
+of
+ bugs even if they only show up rarely in a production system.\\
+ \item There is a reasonably comprehensive set of regression tests
+ that avoids re-creating the most common errors in new versions of
+ Bacula.
+ \end{enumerate}
-\item [Is Bacula Stable? ]
-\index[fd]{Is Bacula Stable? }
-Yes, it is remarkably stable, but remember, there are still a lot of
-unimplemented or partially implemented features. With a program of this size
-(100,000+ lines of C++ code not including the SQL programs) there are bound
-to be bugs. The current test environment (a twisted pair local network and a
-HP DLT backup tape) is rather ideal, so additional testing on other sites is
-necessary. The File daemon has never crashed -- running months at a time with
-no intervention. The Storage daemon is remarkably stable with most of the
-problems arising during labeling or switching tapes. Storage daemon crashes
-are rare. The Director, given the multitude of functions it fulfills is also
-relatively stable. In a production environment, it rarely if ever crashes. Of
-the three daemons, the Director is the most prone to having problems. It
-frequently runs several months with no problems.
-
-There are a number of reasons for this stability. 1. The program was largely
-written by one person to date (Kern). 2. The program constantly is checking
-the chain of allocated memory buffers to ensure that no overruns have
-occurred. 3. All memory leaks (orphaned buffers) are reported each time the
-program terminates. 4. Any signal (segmentation fault, ...) generates a
-traceback that is emailed to the developer. This permits quick resolution of
-bugs even if they only show up rarely in a production system, 5. There is a
-reasonably comprehensive set of regression tests that avoids re-creating the
-most common errors in new versions of Bacula.
\label{AuthorizationErrors}
-
-\item [I'm Getting Authorization Errors. What is Going On? ]
-\index[fd]{I'm Getting Authorization Errors. What is Going On? }
-For security reasons, Bacula requires that both the File daemon and the
-Storage daemon know the name of the Director as well as his password. As a
-consequence, if you change the Director's name or password, you must make
-the corresponding change in the Storage daemon and in the File daemon
-configuration files.
-
-During the authorization process, the Storage daemon and File daemon also
-require that the Director authenticate itself, so both ends require the other
-to have the correct name and password.
-
-If you have edited the conf files and modified any name or any password, and
-you are getting authentication errors, then your best bet is to go back to
-the original conf files generated by the Bacula installation process. Make
-only the absolutely necessary modifications to these files -- e.g. add the
-correct email address. Then follow the instructions in the
-\ilink{ Running Bacula}{_ChapterStart1} chapter of this manual. You
-will run a backup to disk and a restore. Only when that works, should you
-begin customization of the conf files.
-
-Another reason that you can get authentication errors is if you are running
-Multiple Concurrent Jobs in the Director, but you have not set them in the
-File daemon or the Storage daemon. Once you reach their limit, they will
-reject the connection producing authentication (or connection) errors.
-
-Here is sort of a picture of what names/passwords in which files/Resources
-must match up:
-
-\includegraphics{./Conf-Diagram.eps}
-
-In the left column, you will find the Director, Storage, and Client
-resources, with their names and passwords -- these are all in {\bf
-bacula-dir.conf}. In the right column are where the corresponding values
-should be found in the Console, Storage daemon (SD), and File daemon (FD)
-configuration files.
+\subsection*{I'm Getting Authorization Errors. What is Going On? }
+\item [I'm Getting Authorization Errors. What is Going On? ]
+\index[general]{Authorization Errors}
+\index[general]{Concurrent Jobs}
+ For security reasons, Bacula requires that both the File daemon and the
+ Storage daemon know the name of the Director as well as its password. As a
+ consequence, if you change the Director's name or password, you must make
+ the corresponding change in the Storage daemon's and in the File daemon's
+ configuration files.
+
+ During the authorization process, the Storage daemon and File daemon
+ also require that the Director authenticates itself, so both ends
+ require the other to have the correct name and password.
+
+ If you have edited the conf files and modified any name or any password,
+ and you are getting authentication errors, then your best bet is to go
+ back to the original conf files generated by the Bacula installation
+ process. Make only the absolutely necessary modifications to these
+ files -- e.g. add the correct email address. Then follow the
+ instructions in the \ilink{ Running Bacula}{_ChapterStart1} chapter of
+ this manual. You will run a backup to disk and a restore. Only when
+ that works, should you begin customization of the conf files.
+
+ Another reason that you can get authentication errors is if you are
+ running Multiple Concurrent Jobs in the Director, but you have not set
+ them in the File daemon or the Storage daemon. Once you reach their
+ limit, they will reject the connection producing authentication (or
+ connection) errors.
+
+ If you are having problems connecting to a Windows machine that
+ previously worked, you might try restarting the Bacula service since
+ Windows frequently encounters networking connection problems.
+
+ Some users report that authentication fails if there is not a proper
+ reverse DNS lookup entry for the machine. This seems to be a
+ requirement of gethostbyname(), which is what Bacula uses to translate
+ names into IP addresses. If you cannot add a reverse DNS entry, or you
+ don't know how to do so, you can avoid the problem by specifying an IP
+ address rather than a machine name in the appropriate Bacula conf file.
+
+ Here is a picture that indicates what names/passwords in which
+ files/Resources must match up:
+
+ \includegraphics{./Conf-Diagram.eps}
+
+ In the left column, you will find the Director, Storage, and Client
+ resources, with their names and passwords -- these are all in {\bf
+ bacula-dir.conf}. The right column is where the corresponding values
+ should be found in the Console, Storage daemon (SD), and File daemon (FD)
+ configuration files.
+
+ Another thing to check is to ensure that the Bacula component you are
+ trying to access has {\bf Maximum Concurrent Jobs} set large enough to
+ handle each of the Jobs and the Console that want to connect
+ simultaneously. Once the maximum connections has been reached, each
+ Bacula component will reject all new connections.
+
+ Finally, make sure you have no {\bf hosts.allow} or {\bf hosts.deny}
+ file that is not permitting access to the site trying to connect.
\label{AccessProblems}
-
+\subsection*{Bacula Runs Fine but Cannot Access a Client on a Different Machine.
+ Why? }
\item [Bacula Runs Fine but Cannot Access a Client on a Different Machine.
- Why? ]
-\index[dir]{Bacula Runs Fine but Cannot Access a Client on a Different
-Machine. Why? }
-There are several reasons why Bacula could not contact a client on a
-different machine. They are:
+ Why? ]
+\index[general]{Cannot Access a Client}
+ There are several reasons why Bacula could not contact a client on a
+ different machine. They are:
\begin{itemize}
\item It is a Windows Client, and the client died because of an improper
configuration file. Check that the Bacula icon is in the system tray and the
the menu items work. If the client has died, the icon will disappear only
-when you move the mouse over the icon.
+ when you move the mouse over the icon.
\item The Client address or port is incorrect or not resolved by DNS. See if
you can ping the client machine using the same address as in the Client
record.
\item You have a firewall, and it is blocking traffic on port 9102 between
- the Director's machine and the Clients machine (or on port 9103 between the
+ the Director's machine and the Client's machine (or on port 9103 between the
Client and the Storage daemon machines).
\item Your password or names are not correct in both the Director and the
Client machine. Try configuring everything identical to how you run the
client on the same machine as the Director, but just change the Address. If
-that works, make the other changes one step at a time until it works.
+ that works, make the other changes one step at a time until it works.
+\item You may also be having problems betwen your File daemon and your
+ Storage daemon. The name you use in the Storage resource of your
+ Director's conf file must be known (resolvable) by the File daemon,
+ because it is passed symbolically to the File daemon, which then
+ resolves it to get an IP address used to contact the Storage daemon.
+\item You may have a {\bf hosts.allow} or {\bf hosts.deny} file that is
+ not permitting access.
\end{itemize}
\label{startover}
-
-\item [My Catalog is Full of Test Runs, How Can I Start Over? ]
-\index[dir]{My Catalog is Full of Test Runs, How Can I Start Over? }
-If you are using MySQL do the following:
+\subsection*{My Catalog is Full of Test Runs, How Can I Start Over?}
+\item [My Catalog is Full of Test Runs, How Can I Start Over? ]
+ \index[general]{My Catalog is Full of Test Runs, How Can I Start Over? }
+ If you are using MySQL do the following:
\footnotesize
\begin{verbatim}
where you need to adjust the device name for your system.
\label{restorehang}
-
-\item [I Run a Restore Job and Bacula Hangs. What do I do? ]
-\index[dir]{I Run a Restore Job and Bacula Hangs. What do I do? }
-On Bacula version 1.25 and prior, it expects you to have the correct tape
-mounted prior to a restore. On Bacula version 1.26 and higher, it will ask
-you for the tape, and if the wrong one it mounted, it will inform you.
-
-If you have previously done an {\bf unmount} command, all Storage daemon
-sessions (jobs) will be completely blocked from using the drive unmounted, so
-be sure to do a {\bf mount} after your unmount. If in doubt, do a second {\bf
-mount}, it won't cause any harm.
+\subsection*{I Run a Restore Job and Bacula Hangs. What do I do?}
+\item [I Run a Restore Job and Bacula Hangs. What do I do?]
+ \index[general]{I Run a Restore Job and Bacula Hangs. What do I do? }
+ On Bacula version 1.25 and prior, it expects you to have the correct tape
+ mounted prior to a restore. On Bacula version 1.26 and higher, it will ask
+ you for the tape, and if the wrong one is mounted, it will inform you.
+
+ If you have previously done an {\bf unmount} command, all Storage daemon
+ sessions (jobs) will be completely blocked from using the drive unmounted,
+so
+ be sure to do a {\bf mount} after your unmount. If in doubt, do a second
+ {\bf mount}, it won't cause any harm.
\label{windowstart}
-
-\item [I Cannot Get My Windows Client to Start Automatically? ]
-\index[dir]{I Cannot Get My Windows Client to Start Automatically? }
-You are probably having one of two problems: either the Client is dying due
-to an incorrect configuration file, or you didn't do the Installation
-commands necessary to install it as a Windows Service.
-
-For the first problem, see the next FAQ question. For the second problem,
-please review the
-\ilink{ Windows Installation instructions}{_ChapterStart7} in this
-manual.
+\subsection*{I Cannot Get My Windows Client to Start Automatically? }
+\item [I Cannot Get My Windows Client to Start Automatically? ]
+ \index[general]{I Cannot Get My Windows Client to Start Automatically? }
+ You are probably having one of two problems: either the Client is dying due
+ to an incorrect configuration file, or you didn't do the Installation
+ commands necessary to install it as a Windows Service.
+
+ For the first problem, see the next FAQ question. For the second problem,
+ please review the
+ \ilink{ Windows Installation instructions}{_ChapterStart7} in this
+ manual.
\label{windowsdie}
-
+\subsection*{My Windows Client Immediately Dies When I Start It}
\item [My Windows Client Immediately Dies When I Start It ]
-\index[dir]{My Windows Client Immediately Dies When I Start It }
+\index[general]{My Windows Client Immediately Dies When I Start It }
The most common problem is either that the configuration file is not where it
expects it to be, or that there is an error in the configuration file. You
must have the configuration file in {\bf
\normalsize
This will cause the FD to write a file {\bf bacula.trace} in the current
-directory, which you can examine and determine the problem.
+directory, which you can examine and thereby determine the problem.
\label{scroll}
-
\item [When I Start the Console, the Error Messages Fly By. How can I see
- them? ]
-\index[dir]{When I Start the Console, the Error Messages Fly By. How can I see
-them? }
-Either use a shell window with a scroll bar, or use the gnome-console. In any
-case, you probably should be logging all output to a file, and then you can
-simply view the file using an editor or the {\bf less} program. To log all
-output, I have the following in my Director's Message resource definition:
+ them? ]
+ \index[general]{When I Start the Console, the Error Messages Fly By. How can
+I see them? }
+ Either use a shell window with a scroll bar, or use the gnome-console. In
+any
+ case, you probably should be logging all output to a file, and then you can
+ simply view the file using an editor or the {\bf less} program. To log all
+ output, I have the following in my Director's Message resource definition:
\footnotesize
\begin{verbatim}
system.
\label{nobackup}
+\subsection*{My backups are not working on my Windows
+ Client. What should I do?}
\item [I didn't realize that the backups were not working on my Windows
- Client. What should I do? ]
-\index[fd]{I didn't realize that the backups were not working on my Windows
+ Client. What should I do? ]
+\index[general]{I didn't realize that the backups were not working on my Windows
Client. What should I do? }
You should be sending yourself an email message for each job. This will avoid
the possibility of not knowing about a failed backup. To do so put something
FAQ for how to do so.
\label{sched}
-
+\subsection*{All my Jobs are scheduled for the same time. Will this cause
+ problems?}
\item [All my Jobs are scheduled for the same time. Will this cause
- problems? ]
-\index[fd]{All my Jobs are scheduled for the same time. Will this cause
-problems? }
-No, not at all. Bacula will schedule all the Jobs at the same time, but will
-run them one after another unless you have increased the number of
-simultaneous jobs in the configuration files for the Director, the File
-daemon, and the Storage daemon. The appropriate configuration record is {\bf
-Maximum Concurrent Jobs = nn}. At the current time, we recommend that you
-leave this set to {\bf 1} for the Director.
+ problems? ]
+\index[general]{Schedule problems}
+ No, not at all. Bacula will schedule all the Jobs at the same time, but will
+ run them one after another unless you have increased the number of
+ simultaneous jobs in the configuration files for the Director, the File
+ daemon, and the Storage daemon. The appropriate configuration record is {\bf
+ Maximum Concurrent Jobs = nn}. At the current time, we recommend that you
+ leave this set to {\bf 1} for the Director.
\label{disk}
-
-\item [Can Bacula Backup My System To Files instead of Tape? ]
-\index[fd]{Can Bacula Backup My System To Files instead of Tape? }
-Yes, in principle, Bacula can backup to any storage medium as long as you
-have correctly defined that medium in the Storage daemon's Device resource.
-For an example of how to backup to files, please see the
-\ilink{Pruning Example}{PruningExample} in the Recycling
-chapter of this manual. Also, there is a whole chapter devoted to
-\ilink{Backing Up to Disk}{_ChapterStart39}.
+\subsection*{Can Bacula Backup My System To Files instead of Tape?}
+\item [Can Bacula Backup My System To Files instead of Tape? ]
+ \index[general]{Can Bacula Backup My System To Files instead of Tape? }
+ Yes, in principle, Bacula can backup to any storage medium as long as you
+ have correctly defined that medium in the Storage daemon's Device resource.
+ For an example of how to backup to files, please see the
+ \ilink{Pruning Example}{PruningExample} in the Recycling
+ chapter of this manual. Also, there is a whole chapter devoted to
+ \ilink{Basic Volume Management}{_ChapterStart39}. This chapter was
+ originally written to explain how to write to disk, but was expanded
+ to include volume management. It is, however, still quite a good
+ chapter to read.
\label{bigfiles}
-
-\item [Can Bacula Backup and Restore Files Greater than 2 Giga bytes in
+\subsection*{Can Bacula Backup and Restore Files Greater than 2 Gigabytes?}
+\item [Can Bacula Backup and Restore Files Greater than 2 Gigabytes in
Size? ]
-\index[sd]{Can Bacula Backup and Restore Files Greater than 2 Giga bytes in
-Size? }
+\index[general]{Large file support}
If your operating system permits it, and you are running Bacula version 1.26
or later, the answer is yes. To the best of our knowledge all client system
-supported by Bacula can handle files larger than 2 Giga bytes.
+supported by Bacula can handle files larger than 2 Gigabytes.
\label{cancel}
-
+\subsection*{I want to stop a job. Is
+ there a better way than {\bf ./bacula stop} to stop it?}
\item [I Started A Job then Decided I Really Did Not Want to Run It. Is
- there a better way than {\bf ./bacula stop} to stop it? ]
-\index[sd]{I Started A Job then Decided I Really Did Not Want to Run It. Is
-there a better way than ./bacula stop to stop it? }
-Yes, you normally should use the Console command {\bf cancel} to cancel a Job
-that is either scheduled or running. If the Job is scheduled, it will be
-marked for cancellation and will be canceled when it is scheduled to start.
-If it is running, it will normally terminate after a few minutes. If the Job
-is waiting on a tape mount, you may need to do a {\bf mount} command before
-it will be canceled.
+ there a better way than {\bf ./bacula stop} to stop it?]
+\index[general]{Cancelling jobs}
+ Yes,
+ you normally should use the Console command {\bf cancel} to cancel a Job
+ that is either scheduled or running. If the Job is scheduled, it will
+ be marked for cancellation and will be canceled when it is scheduled to
+ start. If it is running, it will normally terminate after a few
+ minutes. If the Job is waiting on a tape mount, you may need to do a
+ {\bf mount} command before it will be canceled.
\label{trademark}
-
+\subsection*{Why have You Trademarked the Name
+ Bacula\raisebox{.6ex}{{\footnotesize \textsuperscript{\textregistered}}}?}
\item [Why have You Trademarked the Name
- Bacula\raisebox{.6ex}{{\footnotesize \textsuperscript{\textregistered}}}? ]
-\index[sd]{Why have You Trademarked the Name
-Bacula\textsuperscript{\textregistered}? }
+ Bacula\raisebox{.6ex}{{\footnotesize \textsuperscript{\textregistered}}}?]
+\index[general]{Bacula Trademark}
We have trademarked the name Bacula to ensure that all media written by any
program named Bacula will always be compatible. Anyone may use the name
Bacula, even in a derivative product as long as it remains totally compatible
in all respects with the program defined here.
\label{docversion}
-
-\item [Why is Your Online Document for Version 1.35 of Bacula when the
- Currently Release Version is 1.34? ]
-\index[sd]{Why is Your Online Document for Version 1.35 of Bacula when the
-Currently Release Version is 1.34? }
+\subsection*{Why is Your Online Document for Version 1.37 but the Released Version is 1.36?}
+\item [Why is Your Online Document for Version 1.37 of Bacula when the
+ Currently Release Version is 1.36?]
+\index[general]{Multiple manuals}
As Bacula is being developed, the document is also being enhanced, more often
than not it has clarifications of existing features that can be very useful
to our users, so we publish the very latest document. Fortunately it is rare
please use the one distributed in the source code.
\label{sure}
-
-\item [How Can I Be Sure that Bacula Really Saves and Restores All Files? ]
-\index[sd]{How Can I Be Sure that Bacula Really Saves and Restores All Files?
-}
-It is really quite simple, but took me awhile to figure out how to ``prove''
-it. First make a Bacula Rescue disk, see the
-\ilink{Disaster Recovery Using Bacula}{_ChapterStart38} of this
-manual. Second, you run a full backup of all your files on all partitions.
-Third, you run an Verify InitCatalog Job on the same FileSet, which
-effectively makes a record of all the files on your system. Fourth, you run a
-Verify Catalog job and assure yourself that nothing has changed (well,
-between an InitCatalog and Catalog one doesn't expect anything). Then do the
-unthinkable, write zeros on your MBR (master boot record) wiping out your
-hard disk. Now, restore your whole system using your Bacula Rescue disk and
-the Full backup you made, and finally re-run the Verify Catalog job. You will
-see that with the exception of the directory modification and access dates
-and the files changed during the boot, your system is identical to what it
-was before you wiped your hard disk.
+\subsection*{Does Bacula really save and restore all files?}
+\item [How Can I Be Sure that Bacula Really Saves and Restores All Files? ]
+ \index[general]{How Can I Be Sure that Bacula Really Saves and Restores
+ All Files? } It is really quite simple, but took me a while to figure
+ out how to "prove" it. First make a Bacula Rescue disk, see the
+ \ilink{Disaster Recovery Using Bacula}{_ChapterStart38} of this manual.
+ Second, you run a full backup of all your files on all partitions.
+ Third, you run an Verify InitCatalog Job on the same FileSet, which
+ effectively makes a record of all the files on your system. Fourth, you
+ run a Verify Catalog job and assure yourself that nothing has changed
+ (well, between an InitCatalog and Catalog one doesn't expect anything).
+ Then do the unthinkable, write zeros on your MBR (master boot record)
+ wiping out your hard disk. Now, restore your whole system using your
+ Bacula Rescue disk and the Full backup you made, and finally re-run the
+ Verify Catalog job. You will see that with the exception of the
+ directory modification and access dates and the files changed during the
+ boot, your system is identical to what it was before you wiped your hard
+ disk.
+ Alternatively you could do the wiping and restoring to another computer
+ of the same type.
\label{upgrade}
-
+\subsection*{I want an Incremental but Bacula runs it as a Full backup. Why?}
\item [I did a Full backup last week, but now in running an Incremental,
- Bacula says it did not find a FULL backup time, so it did a FULL backup. Why? ]
-\index[dir]{I did a Full backup last week, but now in running an Incremental,
-Bacula says it did not find a FULL backup time, so it did a FULL backup. Why?
-}
-Before doing an Incremental or a Differential backup, Bacula checks to see if
-there was a prior Full backup of the same Job that terminated successfully.
-If so, it uses the date that full backup started as the time for comparing if
-files have changed. If Bacula does not find a successfully full backup, it
-proceeds to do one. Perhaps you canceled the full backup, or it terminated in
-error. In such cases, the full backup will not be successful. You can check
-by entering {\bf list jobs} and look to see if there is a prior Job with the
-same Name that has Level F and JobStatus T (normal termination).
-
-Another reason why Bacula may not find a suitable Full backup is that every
-time you change the FileSet, Bacula will require a new Full backup. This is
-necessary to ensure that all files are properly backed up in the case where
-you have added more files to the FileSet. Beginning with version 1.31, the
-FileSets are also dated when they are created, and this date is displayed
-with the name when you are listing or selecting a FileSet. For more on backup
-levels see below.
+ Bacula says it did not find a FULL backup, so it did a FULL backup. Why?]
+ \index[general]{I did a Full backup last week, but now in running an
+ Incremental, Bacula says it did not find a FULL backup, so it did a
+ FULL backup. Why? } Before doing an Incremental or a Differential
+ backup, Bacula checks to see if there was a prior Full backup of the
+ same Job that terminated successfully. If so, it uses the date that
+ full backup started as the time for comparing if files have changed. If
+ Bacula does not find a successful full backup, it proceeds to do one.
+ Perhaps you canceled the full backup, or it terminated in error. In
+ such cases, the full backup will not be successful. You can check by
+ entering {\bf list jobs} and look to see if there is a prior Job with
+ the same Name that has Level F and JobStatus T (normal termination).
+
+ Another reason why Bacula may not find a suitable Full backup is that
+ every time you change the FileSet, Bacula will require a new Full
+ backup. This is necessary to ensure that all files are properly backed
+ up in the case where you have added more files to the FileSet.
+ Beginning with version 1.31, the FileSets are also dated when they are
+ created, and this date is displayed with the name when you are listing
+ or selecting a FileSet. For more on backup levels see below.
\label{filenamelengths}
-
+\subsection*{Do you really handle unlimited path lengths?}
\item [How Can You Claim to Handle Unlimited Path and Filename Lengths
- when All Other Programs Have Fixed Limits? ]
-\index[dir]{How Can You Claim to Handle Unlimited Path and Filename Lengths
-when All Other Programs Have Fixed Limits? }
-Most of those other programs have been around for a long time, in fact since
-the beginning of Unix, which means that they were designed for rather small
-fixed length path and filename lengths. Over the years, these restrictions
-have been relaxed allowing longer names. Bacula on the other hand was
-designed in 2000, and so from the start, Path and Filenames have been keep in
-buffers that start at 256 bytes in length but can grow as needed to handle
-any length. Most of the work is carried out by lower level routines making
-the coding rather easy.
+ when All Other Programs Have Fixed Limits?]
+ \index[general]{How Can You Claim to Handle Unlimited Path and Filename
+ Lengths when All Other Programs Have Fixed Limits? } Most of those
+ other programs have been around for a long time, in fact since the
+ beginning of Unix, which means that they were designed for rather small
+ fixed length path and filename lengths. Over the years, these
+ restrictions have been relaxed allowing longer names. Bacula on the
+ other hand was designed in 2000, and so from the start, Path and
+ Filenames have been kept in buffers that start at 256 bytes in length,
+ but can grow as needed to handle any length. Most of the work is
+ carried out by lower level routines making the coding rather easy.
+
+ Note that due to limitations Win32 path and filenames cannot exceed
+ 260 characters. By using Win32 Unicode functions, we will remove this
+ restriction in later versions of Bacula.
\label{unique}
-
-\item [What Is the Really Unique Feature of Bacula? ]
-\index[dir]{What Is the Really Unique Feature of Bacula? }
-Well, it is hard to come up with unique features when backup programs for
-Unix machines have been around since the 1960s. That said, I believe that
-Bacula is the first and only program to use a standard SQL interface to its
-catalog database. Although this adds a bit of complexity and possibly
-overhead, it provides an amazingly rich set of features that are easy to
-program and enhance. The current code has barely scratched the surface in
-this regard (version 1.31).
-
-The second feature, which gives a lot of power and flexibility to Bacula is
-the Bootstrap record definition.
-
-The third unique feature, which is currently (1.30) unimplemented, and thus
-can be called vaporware :-), is Base level saves. When implemented, this will
-enormously reduce tape usage.
+\subsection*{What Is the Really Unique Feature of Bacula?}
+\item [What Is the Really Unique Feature of Bacula?]
+ \index[general]{What Is the Really Unique Feature of Bacula? } Well, it
+ is hard to come up with unique features when backup programs for Unix
+ machines have been around since the 1960s. That said, I believe that
+ Bacula is the first and only program to use a standard SQL interface to
+ catalog its database. Although this adds a bit of complexity and
+ possibly overhead, it provides an amazingly rich set of features that
+ are easy to program and enhance. The current code has barely scratched
+ the surface in this regard (version 1.31).
+
+ The second feature, which gives a lot of power and flexibility to Bacula
+ is the Bootstrap record definition.
+
+ The third unique feature, which is currently (1.30) unimplemented, and
+ thus can be called vaporware :-), is Base level saves. When
+ implemented, this will enormously reduce tape usage.
\label{sequence}
-
-\item [If I Do Run Multiple Simultaneous Jobs, How Can I Force One
- Particular Job to Run After Another Job? ]
-\index[dir]{If I Do Run Multiple Simultaneous Jobs, How Can I Force One
+\subsection*{How can I force one job to run after another?}
+\item [If I Run Multiple Simultaneous Jobs, How Can I Force One
+ Particular Job to Run After Another Job? ]
+\index[general]{If I Run Multiple Simultaneous Jobs, How Can I Force One
Particular Job to Run After Another Job? }
Yes, you can set Priorities on your jobs so that they run in the order you
specify. Please see:
\ilink{the Priority record}{Priority} in the Job resource.
\label{nomail}
+\subsection*{I Am Not Getting Email Notification, What Can I Do? }
+\item [I Am Not Getting Email Notification, What Can I Do? ]
-\item [I Am Not Getting Email Notification, What Can I Do? ]
-\index[dir]{I Am Not Getting Email Notification, What Can I Do? }
+\index[general]{I Am Not Getting Email Notification, What Can I Do? }
The most common problem is that you have not specified a fully qualified
email address and your bsmtp server is rejecting the mail. The next most
common problem is that your bsmtp server doesn't like the syntax on the From
manual.
\label{periods}
-
+\subsection*{My retention periods don't work}
\item [I Change Recycling, Retention Periods, or File Sizes in my Pool
- Resource and they Still Don``t Work. ]
-\index[dir]{I Change Recycling, Retention Periods, or File Sizes in my Pool
-Resource and they Still Don"t Work. }
-The different variables associated with a Pool are defined in the Pool
-Resource, but are actually read by Bacula from the Catalog database. On
-Bacula versions prior to 1.30, after changing your Pool Resource, you must
-manually update the corresponding values in the Catalog by using the {\bf
-update pool} command in the Console program. In Bacula version 1.30, Bacula
-does this for you automatically every time it starts.
-
-When Bacula creates a Media record (Volume), it uses many default values from
-the Pool record. If you subsequently change the Pool record, the new values
-will be used as a default for the next Volume that is created, but if you
-want the new values to apply to existing Volumes, you must manually update
-the Volume Catalog entry using the {\bf update volume} command in the Console
-program.
+ Resource and they Still Don't Work.]
+\index[general]{Recycling}
+\index[general]{Retention Periods}
+\index[general]{Pool changes}
+ The different variables associated with a Pool are defined in the Pool
+ Resource, but are actually read by Bacula from the Catalog database. On
+ Bacula versions prior to 1.30, after changing your Pool Resource, you must
+ manually update the corresponding values in the Catalog by using the {\bf
+ update pool} command in the Console program. In Bacula version 1.30, Bacula
+ does this for you automatically every time it starts.
+
+ When Bacula creates a Media record (Volume), it uses many default values from
+ the Pool record. If you subsequently change the Pool record, the new values
+ will be used as a default for the next Volume that is created, but if you
+ want the new values to apply to existing Volumes, you must manually update
+ the Volume Catalog entry using the {\bf update volume} command in the Console
+ program.
\label{CompressionNotWorking}
-
+\subsection*{Why aren't my files compressed?}
\item [I Have Configured Compression On, But None of My Files Are
- Compressed. Why? ]
-\index[dir]{I Have Configured Compression On, But None of My Files Are
-Compressed. Why? }
-There are two kinds of compression. One is tape compression. This is done by
-the tape drive hardware, and you either enable or disable it with system
-tools such as {\bf mt}. This compression works independently of Bacula.
-
-Bacula also has compression code, which is normally used only when backing up
-to file Volumes. There are two conditions for this ''software`` to be
-enabled.
+ Compressed. Why?]
+\index[general]{Compression}
+ There are two kinds of compression. One is tape compression. This is done by
+ the tape drive hardware, and you either enable or disable it with system
+ tools such as {\bf mt}. This compression works independently of Bacula.
+
+ Bacula also has compression code, which is normally used only when backing
+up
+ to file Volumes. There are two conditions for this "software" to become
+ enabled.
\begin{enumerate}
\item You must have the zip development libraries loaded on your system when
building Bacula and Bacula must find this library, normally {\bf
/usr/lib/libz.a}. On RedHat systems, this library is provided by the {\bf
-zlib-devel} rpm.
+ zlib-devel} rpm.
-If the library is found by Bacula during the {\bf ./configure} it will be
-indicated on the {\bf config.out} line by:
+ If the library is found by Bacula during the {\bf ./configure} it will be
+ mentioned in the {\bf config.out} line by:
\footnotesize
\begin{verbatim}
\item You must add the {\bf compression=gzip} option on your Include
statement in the Director's configuration file.
- \end{enumerate}
+\end{enumerate}
\label{NewTape}
-
\item [Bacula is Asking for a New Tape After 2 GB of Data but My Tape
- holds 33 GB. Why? ]
-\index[fd]{Bacula is Asking for a New Tape After 2 GB of Data but My Tape
-holds 33 GB. Why? }
+ holds 33 GB. Why?]
+\index[general]{Tape capacity}
There are several reasons why Bacula will request a new tape.
\begin{itemize}
\item There is an I/O error on the tape. Bacula prints an error message and
- requests a new tape. Bacula does not attempt to continue writing after an I/O
+ requests a new tape. Bacula does not attempt to continue writing after an
+I/O
error.
\item Bacula encounters and end of medium on the tape. This is not always
distinguishable from an I/O error.
\item You have specifically set some size limitation on the tape. For example
the {\bf Maximum Volume Bytes} or {\bf Maximum Volume Files} in the
Director's Pool resource, or {\bf Maximum Volume Size} in the Storage
-daemon's Device resource.
+ daemon's Device resource.
\end{itemize}
\label{LevelChanging}
-
+\subsection*{Incremental backups are not working}
\item [Bacula is Not Doing the Right Thing When I Request an Incremental
- Backup. Why? ]
-\index[fd]{Bacula is Not Doing the Right Thing When I Request an Incremental
-Backup. Why? }
-As explained in one of the previous questions, Bacula will automatically
-upgrade an Incremental or Differential job to a Full backup if it cannot find
-a prior Full backup or a suitable Full backup. For the gory details on
-how/when Bacula decides to upgrade levels please see the
-\ilink{Level record}{Level} in the Director's configuration
-chapter of this manual.
-
-If after reading the above mentioned section, you believe that Bacula is not
-correctly handling the level (Differential/Incremental), please send us the
-following information for analysis:
+ Backup. Why?]
+ \index[general]{Incremental backups}
+ As explained in one of the previous questions, Bacula will automatically
+ upgrade an Incremental or Differential job to a Full backup if it cannot
+find
+ a prior Full backup or a suitable Full backup. For the gory details on
+ how/when Bacula decides to upgrade levels please see the
+ \ilink{Level record}{Level} in the Director's configuration
+ chapter of this manual.
+
+ If after reading the above mentioned section, you believe that Bacula is not
+ correctly handling the level (Differential/Incremental), please send us the
+ following information for analysis:
\begin{itemize}
\item Your Director's configuration file.
there is not much we can do.
\label{WaitForever}
-
+\subsection*{I am waiting forever for a backup of an offsite machine}
\item [I am Backing Up an Offsite Machine with an Unreliable Connection.
- The Director Waits Forever for the Client to Contact the SD. What Can I Do. ]
-\index[fd]{I am Backing Up an Offsite Machine with an Unreliable Connection.
-The Director Waits Forever for the Client to Contact the SD. What Can I Do. }
-Bacula was written on the assumption that it will have a good TCP/IP
-connection between all the daemons. As a consequence, the current Bacula
-doesn't deal with faulty connection very well. This situation is slowly being
-corrected over time.
-
-There are several things you can do to improve the situation.
+ The Director Waits Forever for the Client to Contact the SD. What Can I
+Do?]
+ \index[general]{I am Backing Up an Offsite Machine with an Unreliable
+Connection.
+ The Director Waits Forever for the Client to Contact the SD. What Can I Do?}
+ Bacula was written on the assumption that it will have a good TCP/IP
+ connection between all the daemons. As a consequence, the current Bacula
+ doesn't deal with faulty connections very well. This situation is slowly
+being
+ corrected over time.
+
+ There are several things you can do to improve the situation.
\begin{itemize}
\item Upgrade to version 1.32 and use the new SDConnectTimeout record. For
\end{itemize}
\label{sshHanging}
-
+\subsection*{SSH hangs forever after starting Bacula}
\item [When I ssh into a machine and start Bacula then attempt to exit,
- ssh hangs forever. ]
-\index[fd]{When I ssh into a machine and start Bacula then attempt to exit,
-ssh hangs forever. }
-This happens because Bacula leaves stdin, stdout, and stderr open for debug
-purposes. To avoid it, the simplest thing to do is to redirect the output of
-those files to {\bf /dev/null} or another file in your startup script (the
-RedHat autostart scripts do this automatically). For example, you start the
-Director with:
-
+ ssh hangs forever.]
+ \index[general]{When I ssh into a machine and start Bacula then attempt to
+exit,
+ ssh hangs forever. }
+ This happens because Bacula leaves stdin, stdout, and stderr open for debug
+ purposes. To avoid it, the simplest thing to do is to redirect the output of
+ those files to {\bf /dev/null} or another file in your startup script (the
+ RedHat autostart scripts do this automatically). For example, you start the
+ Director with:
+
\footnotesize
\begin{verbatim}
bacula-dir -c bacula-dir.conf ... 0>\&1 2>\&1 >/dev/null
and likewise for the other daemons.
\label{RetentionPeriods}
-
+\subsection*{I'm confused by retention periods}
\item [I'm confused by the different Retention periods: File Retention,
- Job Retention, Volume Retention. Why are there so many? ]
-\index[dir]{I'm confused by the different Retention periods: File Retention,
-Job Retention, Volume Retention. Why are there so many? }
-Yes, this certainly can be confusing. The basic reason for so many is to
-allow flexibility. The File records take quite a lot of space in the catalog,
-so they are typically records you want to remove rather quickly. The Job
-records, take very little space, and they can be useful even without the File
-records to see what Jobs actually ran and when. One must understand that if
-the File records are removed from the catalog, you cannot use the {\bf
-restore} command to restore an individual file since Bacula no longer knows
-where it is. However, as long as the Volume Retention period has not expired,
-the data will still be on the tape, and can be recovered from the tape.
-
-For example, I keep a 30 day retention period for my Files to keep my catalog
-from getting too big, but I keep my tapes for a minimum of one year, just in
-case.
+ Job Retention, Volume Retention. Why are there so many?]
+ \index[general]{I'm confused by the different Retention periods: File
+Retention,
+ Job Retention, Volume Retention. Why are there so many? }
+ Yes, this certainly can be confusing. The basic reason for so many is to
+ allow flexibility. The File records take quite a lot of space in the
+catalog,
+ so they are typically records you want to remove rather quickly. The Job
+ records, take very little space, and they can be useful even without the
+File
+ records to see what Jobs actually ran and when. One must understand that if
+ the File records are removed from the catalog, you cannot use the {\bf
+ restore} command to restore an individual file since Bacula no longer knows
+ where it is. However, as long as the Volume Retention period has not
+expired,
+ the data will still be on the tape, and can be recovered from the tape.
+
+ For example, I keep a 30 day retention period for my Files to keep my
+catalog
+ from getting too big, but I keep my tapes for a minimum of one year, just in
+ case.
\label{MaxVolumeSize}
-
-\item [Why Does Bacula Ignore the MaxVolumeSize Set in my Pool? ]
-\index[fd]{Why Does Bacula Ignore the MaxVolumeSize Set in my Pool? }
-The MaxVolumeSize that Bacula uses comes from the Media record, so most
-likely you changed your Pool, which is used as the default for creating Media
-records, {\bf after} you created your Volume. Check what is in the Media
-record by doing:
+\subsection*{MaxVolumeSize is ignored}
+\item [Why Does Bacula Ignore the MaxVolumeSize Set in my Pool?]
+ \index[general]{Why Does Bacula Ignore the MaxVolumeSize Set in my Pool? }
+ The MaxVolumeSize that Bacula uses comes from the Media record, so most
+ likely you changed your Pool, which is used as the default for creating
+Media
+ records, {\bf after} you created your Volume. Check what is in the Media
+ record by doing:
\footnotesize
\begin{verbatim}
to change it.
\label{ConnectionRefused}
-
-\item [In connecting to my Client, I get ''ERR:Connection Refused. Packet
- Size too big from File daemon:192.168.1.4:9102`` Why? ]
-\index[fd]{In connecting to my Client, I get ``ERR:Connection Refused.
-Packet Size too big from File daemon:192.168.1.4:9102'' Why? }
-This is typically a communications error resulting from one of the following:
+\subsection*{I get a Connection refused when connecting to my Client}
+\item [In connecting to my Client, I get "ERR:Connection Refused. Packet
+ Size too big from File daemon:192.168.1.4:9102" Why?]
+ \index[general]{In connecting to my Client, I get "ERR:Connection
+Refused.
+ Packet Size too big from File daemon:192.168.1.4:9102" Why? }
+ This is typically a communications error resulting from one of the
+following:
\begin{itemize}
using the same I/O packet. Fixed in more recent versions. Please upgrade.
\item Some other program such as an HP Printer using the same port (9102 in
this case).
- \end{itemize}
+\end{itemize}
If it is neither of the above, please submit a bug report at
\elink{bugs.bacula.org}{http://bugs.bacula.org}.
\normalsize
This will cause the FD to write a file {\bf bacula.trace} in the current
-directory, which you can examine and determine the problem.
+directory, which you can examine to determine the problem.
+
+\subsection*{Long running jobs die with Pipe Error}
+\item [During long running jobs my File daemon dies with Pipe Error, or
+ some other communications error. Why?]
+ \index[general]{Communications Errors}
+ \index[general]{Pipe Errors}
+ There are a number of reasons why a connection might break.
+ Most often, it is a router between your two computers that times out
+ inactive lines (not respecting the keepalive feature that Bacula uses).
+ In that case, you can use the {\bf Heartbeat Interval} directive in
+ both the Storage daemon and the File daemon.
+
+ In at least one case, the problem has been a bad driver for a Win32
+ NVidia NForce 3 ethernet card with driver (4.4.2 17/05/2004).
+ In this case, a good driver is (4.8.2.0 06/04/2005). Moral of
+ the story, make sure you have the latest ethernet drivers
+ loaded, or use the following workaround as suggested by Thomas
+ Simmons for Win32 machines:
+
+ Browse to:
+ Start \gt{} Control Panel \gt{} Network Connections
+
+ Right click the connection for the nvidia adapter and select properties.
+ Under the General tab, click "Configure...". Under the Advanced tab set
+ "Checksum Offload" to disabled and click OK to save the change.
+
+ Lack of communications, or communications that get interrupted can
+ also be caused by Linux firewalls where you have a rule that throttles
+ connections or traffic. For example, if you have:
+
+\footnotesize
+\begin{verbatim}
+iptables -t filter -A INPUT -m limit --limit 3/second --limit-burst 3 -j DROP
+\end{verbatim}
+\normalsize
+
+ you will want to add the following rules {\bf before} the above rule:
+\footnotesize
+\begin{verbatim}
+iptables -t filter -A INPUT --dport 9101 -j ACCEPT
+iptables -t filter -A INPUT --dport 9102 -j ACCEPT
+iptables -t filter -A INPUT --dport 9103 -j ACCEPT
+\end{verbatim}
+\normalsize
+ This will ensure that any Bacula traffic will not get terminated because
+ of high usage rates.
+
+\subsection*{How to I tell the Job which Volume to use?}
+\item[I can't figure out how to tell the job which volume to use]
+ \index[general]{What tape to mount}
+ This is an interesting statement. I now see that a number of people new to
+ Bacula have the same problem as you, probably from using programs like tar.
+
+ In fact, you do not tell Bacula what tapes to use. It is the inverse. Bacula
+ tells you want tapes it wants. You put tapes at its disposition and it
+ chooses.
+
+ Now, if you *really* want to be tricky and try to tell Bacula what to do, it
+ will be reasonable if for example you mount a valid tape that it can use on a
+ drive, it will most likely go ahead and use it. It also has a documented
+ algorithm for choosing tapes -- but you are asking for problems ...
+
+ So, the trick is to invert your concept of things and put Bacula in charge of
+ handling the tapes. Once you do that, you will be fine. If you want to
+ anticipate what it is going to do, you can generally figure it out correctly
+ and get what you want.
+
+ If you start with the idea that you are going to force or tell Bacula to use
+ particular tapes or you insist on trying to run in that kind of mode, you will
+ probably not be too happy.
+
+ I don't want to worry about what tape has what data. That is what Bacula is
+ designed for.
+
+ If you have an application where you *really* need to remove a tape each day
+ and insert a new one, it can be done the directives exist to accomplish that.
+ In such a case, one little "trick" to knowing what tape Bacula will want at
+ 2am while you are asleep is to run a tiny job at 4pm while you are still at
+ work that backs up say one directory, or even one file. You will quickly find
+ out what tape it wants, and you can mount it before you go home ...
\end{description}
\item [Name = \lt{}name\gt{}]
\index[fd]{Name }
The client name that must be used by the Director when connecting. Generally,
-it is a good idea to use a name related to the machine so that error messages
-can be easily identified if you have multiple Clients. This record is
-required.
+ it is a good idea to use a name related to the machine so that error messages
+ can be easily identified if you have multiple Clients. This directive is
+ required.
\item [Working Directory = \lt{}Directory\gt{}]
\index[fd]{Working Directory }
This directive is mandatory and specifies a directory in which the File
-daemon may put its status files. This directory should be used only by {\bf
-Bacula}, but may be shared by other Bacula daemons. This record is required
+ daemon may put its status files. This directory should be used only by {\bf
+ Bacula}, but may be shared by other Bacula daemons provided the daemon
+ names on the {\bf Name} definition are unique for each daemon. This directive
+ is required.
+
+ On Win32 systems, in some circumstances you may need to specify a drive
+ letter in the specified working directory path. Also, please be sure
+ that this directory is writable by the SYSTEM user otherwise restores
+ may fail (the bootstrap file that is transferred to the File daemon from
+ the Director is temporarily put in this directory before being passed
+ to the Storage daemon).
\item [Pid Directory = \lt{}Directory\gt{}]
- \index[dir]{Pid Directory }
+ \index[fd]{Pid Directory }
This directive is mandatory and specifies a directory in which the Director
may put its process Id file files. The process Id file is used to shutdown
Bacula and to prevent multiple copies of Bacula from running simultaneously.
Directory} as defined above.
\item [Heartbeat Interval = \lt{}time-interval\gt{}]
- \index[dir]{Heartbeat Interval }
- This record defines an interval of time. For each heartbeat that the File
-daemon receives from the Storage daemon, it will forward it to the Director.
-In addition, if no heartbeat has been received from the Storage daemon and
-thus forwarded the File daemon will send a heartbeat signal to the Director
-and to the Storage daemon to keep the channels active. The default interval
-is zero which disables the heartbeat. This feature is particularly useful if
-you have a router such as 3Com that does not follow Internet standards and
-times out an inactive connection after a short duration.
+ \index[fd]{Heartbeat Interval }
+ \index[general]{Heartbeat Interval}
+ \index[general]{Broken pipe}
+ This record defines an interval of time. For each heartbeat that the
+ File daemon receives from the Storage daemon, it will forward it to the
+ Director. In addition, if no heartbeat has been received from the
+ Storage daemon and thus forwarded the File daemon will send a heartbeat
+ signal to the Director and to the Storage daemon to keep the channels
+ active. The default interval is zero which disables the heartbeat.
+ This feature is particularly useful if you have a router such as 3Com
+ that does not follow Internet standards and times out a valid
+ connection after a short duration despite the fact that keepalive is
+ set. This usually results in a broken pipe error message.
+
+ If you continue getting broken pipe error messages despite using the
+ Heartbeat Interval, and you are using Windows, you should consider
+ upgrading your ethernet driver. This is a known problem with NVidia
+ NForce 3 drivers (4.4.2 17/05/2004), or try the following workaround
+ suggested by Thomas Simmons for Win32 machines:
+
+ Browse to:
+ Start \gt{} Control Panel \gt{} Network Connections
+
+ Right click the connection for the nvidia adapter and select properties.
+ Under the General tab, click "Configure...". Under the Advanced tab set
+ "Checksum Offload" to disabled and click OK to save the change.
+
+ Lack of communications, or communications that get interrupted can
+ also be caused by Linux firewalls where you have a rule that throttles
+ connections or traffic.
+
\item [Maximum Concurrent Jobs = \lt{}number\gt{}]
- \index[dir]{Maximum Concurrent Jobs }
- where \lt{}number\gt{} is the maximum number of Jobs that should run
-concurrently. The default is set to 2, but you may set it to a larger number.
-Each contact from the Director (e.g. status request, job start request) is
-considered as a Job, so if you want to be able to do a {\bf status} request
-in the console at the same time as a Job is running, you will need to set
-this value greater than 1.
+ \index[fd]{Maximum Concurrent Jobs }
+ where \lt{}number\gt{} is the maximum number of Jobs that should run
+ concurrently. The default is set to 2, but you may set it to a larger
+ number. Each contact from the Director (e.g. status request, job start
+ request) is considered as a Job, so if you want to be able to do a {\bf
+ status} request in the console at the same time as a Job is running, you
+ will need to set this value greater than 1.
\item [FDAddresses = \lt{}IP-address-specification\gt{}]
\index[console]{FDAddresses }
- Specify the ports and addresses on which the Director daemon will listen for
-Bacula Console connections. Probably the simplest way to explain is to show
-an example:
+ Specify the ports and addresses on which the Director daemon will listen
+ for Bacula Console connections. Probably the simplest way to explain is
+ to show an example:
\footnotesize
\begin{verbatim}
connect to the Storage daemon. The default is 30 minutes. If no connection
is made in the specified time interval, the File daemon cancels the Job.
-\item [Maximum Network Buffer Size = \lt{}bytes\gt{} ]
+\item [Maximum Network Buffer Size = \lt{}bytes\gt{}]
\index[console]{Maximum Network Buffer Size }
where \lt{}bytes\gt{} specifies the initial network buffer size to use with
the File daemon. This size will be adjusted down if it is too large until it
daemon or client, and SD the Storage daemon. The numbers that follow those
names are the standard ports used by Bacula, and the -\gt{} represents the
left side making a connection to the right side (i.e. the right side is the
-``server'' or is listening on the specified port), and the left side is the
-``client'' who initiates the conversation.
+"server" or is listening on the specified port), and the left side is the
+"client" who initiates the conversation.
Note, port 9103 serves both the Director and the File daemon, each having its
own independent connection.
firewall.mydomain.tld:9103 MUST be forwarded using the firewall's
configuration software to server.int.mydomain.tld:9103. Some firewalls call
this 'Server Publication'. Others may call it 'Port Forwarding'.
+
+\subsubsection*{Firewall Problems}
+\index[general]{Firewall Problems}
+\index[general]{Problems!Firewalls}
+\addcontentsline{toc}{subsubsection}{Firewall Problems}
+Either a firewall or a router may decide to timeout and terminate
+open connections if they are not active for a short time. By Internet
+standards the period should be two hours, and should be indefinitely
+extended if KEEPALIVE is set as is the case by Bacula. If your firewall
+or router does not respect these rules, you may find Bacula connections
+terminated. In that case, the first thing to try is turning on the
+{\bf Heart Beat Interval} both in the File daemon and the Storage daemon
+and set an interval of say five minutes.
+
+Also, if you have denial of service rate limiting in your firewall, this
+too can cause Bacula disconnects since Bacula can at times use very high
+access rates. To avoid this, you should implement default accept
+rules for the Bacula ports involved before the rate limiting rules.
+
+Finally, if you have a Windows machine, it will most likely by default
+disallow connections to the Bacula Windows File daemon. See the
+Windows chapter of this manual for additional details.
spending too much time on trying to get the traceback to work as it can be
very difficult.
-The changes that might needed are to add a correct path to the {\bf gdb}
+The changes that might be needed are to add a correct path to the {\bf gdb}
program, correct the path to the {\bf btraceback.gdb} file, change the {\bf
mail} program or its path, or change your email address. The key line in the
{\bf btraceback} file is:
\index[general]{Testing The Traceback }
\addcontentsline{toc}{subsection}{Testing The Traceback}
-To ``manually'' test the traceback feature, you simply start {\bf Bacula} then
+To "manually" test the traceback feature, you simply start {\bf Bacula} then
obtain the {\bf PID} of the main daemon thread (there are multiple threads).
Unfortunately, the output had to be split to fit on this page:
modifications (actually additions) are described in the source file LICENSE,
and their purpose is not to alter the essential qualities of the GPL but to
permit more freedom in linking certain third party software supposedly non-GPL
-compatable, provide termination for Patent (and IP) actions, clarify
+compatible, provide termination for Patent (and IP) actions, clarify
contributors IP and Copyright claims and non-infringment intentions. The
details and governing text are in the file LICENSE in the main source
directory.
-Most of this code is copyrighted: Copyright (C) 2000-2004 Kern Sibbald and
-John Walker. or Copyright (C) 2000-2004 Kern Sibbald
+Most of this code is copyrighted: Copyright \copyright 2000-2004 Kern Sibbald and
+John Walker or Copyright \copyright 2000-2005 Kern Sibbald.
Portions may be copyrighted by other people (ATT, the Free Software
-Foundation, ...).
+Foundation, ...). Generally these portions are released under a
+non-modified GPL 2 license.
\subsection*{LGPL}
\index[general]{LGPL }
\index[general]{Public Domain }
\addcontentsline{toc}{subsection}{Public Domain}
-Some of the Bacula code has been released to the public domain. E.g. md5.c,
-SQLite.
+Some of the Bacula code, or code that Bacula references, has been released
+to the public domain. E.g. md5.c, SQLite.
\subsection*{Trademark}
\index[general]{Trademark }
Bacula\raisebox{.6ex}{\textsuperscript{\textregistered}}is a registered
trademark of Kern Sibbald and John Walker.
-We have trademarked the Bacula name to ensure that any variant of Bacula will
-be exactly compatible with the program that we have released. The use of the
-name Bacula is restricted to software systems that agree exactly with the
-program presented here.
+We have trademarked the Bacula name to ensure that any program using the
+name Bacula will be exactly compatible with the program that we have
+released. The use of the name Bacula is restricted to software systems
+that agree exactly with the program presented here.
\subsection*{Disclaimer}
\index[general]{Disclaimer }
BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE
PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE
STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE
-PROGRAM ``AS IS'' WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED,
+PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND
PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE,
DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR
A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH
HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
-
message-type} is one of a predefined set of keywords that define the type of
message generated by {\bf Bacula} ({\bf ERROR}, {\bf WARNING}, {\bf FATAL},
...), and {\bf address} varies according to the {\bf destination} keyword, but
-is typically and email address or a filename.
+is typically an email address or a filename.
\end{description}
The following are the list of the possible record definitions that can be used
In the absence of this resource, Bacula will send all mail using the
following command:
-{\bf mail -s ``Bacula Message'' \lt{}recipients\gt{}}
+{\bf mail -s "Bacula Message" \lt{}recipients\gt{}}
In many cases, depending on your machine, this command may not work. Using
the {\bf MailCommand}, you can specify exactly how to send the mail. During
appear on a single line in the configuration file rather than split as is
done here for presentation:
-{\bf mailcommand = ``/home/kern/bacula/bin/bsmtp -h mail.whitehouse.com -f
-\textbackslash{}''\textbackslash{}(Bacula\textbackslash{})
-\%r\textbackslash{}`` -s \textbackslash{}''Bacula: \%t \%e of \%c
-\%l\textbackslash{}`` \%r'' }
+{\bf mailcommand = "/home/kern/bacula/bin/bsmtp -h mail.example.com -f
+\textbackslash{}"\textbackslash{}(Bacula\textbackslash{})
+\%r\textbackslash{}" -s \textbackslash{}"Bacula: \%t \%e of \%c
+\%l\textbackslash{}" \%r" }
Note, the {\bf bsmtp} program is provided as part of {\bf Bacula}. For
additional details, please see the
\ilink{ bsmtp -- Customizing Your Email Messages}{bsmtp} section of
the Bacula Utility Programs chapter of this manual. Please test any {\bf
mailcommand} that you use to ensure that your bsmtp gateway accepts the
-addressing form that you use. Certain program such as Exim can be very
+addressing form that you use. Certain programs such as Exim can be very
selective as to what forms are permitted particularly in the from part.
\item [OperatorCommand = \lt{}command\gt{}]
requested not to use this record since it will be deprecated.
\item [\lt{}destination\gt{} = \lt{}message-type1\gt{},
- \lt{}message-type2\>, ...]
+ \lt{}message-type2\gt{}, ...]
\index[fd]{\lt{}destination\gt{} }
Where {\bf destination} may be one of the following:
\end{description}
\item {\bf \lt{}destination\gt{} = \lt{}address\gt{} =
- \lt{}message-type1\gt{}, \lt{}message-type2\>, ...}
+ \lt{}message-type1\gt{}, \lt{}message-type2\gt{}, ...}
\index[console]{\lt{}destination\gt{} }
Where {\bf address} depends on the {\bf destination}, which may be one of the
\begin{verbatim}
Messages {
Name = Standard
- mailcommand = "bacula/bin/bsmtp -h mail.whitehouse.com \
+ mailcommand = "bacula/bin/bsmtp -h mail.example.com \
-f \"\(Bacula\) %r\" -s \"Bacula: %t %e of %c %l\" %r"
- operatorcommand = "bacula/bin/bsmtp -h mail.whitehouse.com \
+ operatorcommand = "bacula/bin/bsmtp -h mail.example.com \
-f \"\(Bacula\) %r\" -s \"Bacula: Intervention needed \
for %j\" %r"
- MailOnError = security@whitehouse.com = all, !skipped, \
+ MailOnError = security@example.com = all, !skipped, \
!terminate
append = "bacula/bin/log" = all, !skipped, !terminate
- operator = security@whitehouse.com = mount
+ operator = security@example.com = mount
console = all, !skipped, !saved
}
\end{verbatim}
%%
\section*{Monitor Configuration}
-\label{_ChapterStart35}
+\label{_MonitorChapter}
\index[general]{Monitor Configuration }
\index[general]{Configuration!Monitor }
\addcontentsline{toc}{section}{Monitor Configuration}
\ilink{Director's configuration}{_ChapterStart40} file, using the
Console Name and Password defined in the Monitor resource. To avoid security
problems, you should configure this Console resource to allow access to no
-others daemon, and permit the use of only two commands: {\bf status} and {\bf
+other daemons, and permit the use of only two commands: {\bf status} and {\bf
.status} (see below for an example).
You may have multiple Director resource specifications in a single Monitor
\item [Name = \lt{}name\gt{}]
\index[fd]{Name }
The Director name used to identify the Director in the list of monitored
-daemons. It is not required to be the same as defined in the Director's
+daemons. It is not required to be the same as the one defined in the Director's
configuration file. This record is required.
\item [DIRPort = \lt{}port-number\gt{}]
\index[fd]{DIRPort }
Specify the port to use to connect to the Director. This value will most
likely already be set to the value you specified on the {\bf
-\verb{--{with-base-port} option of the {\bf ./configure} command. This port must be
+\verb:--:with-base-port} option of the {\bf ./configure} command. This port must be
identical to the {\bf DIRport} specified in the {\bf Director} resource of
the
\ilink{Director's configuration}{_ChapterStart40} file. The
\item [Name = \lt{}name\gt{}]
\index[fd]{Name }
The Client name used to identify the Director in the list of monitored
-daemons. It is not required to be the same as defined in the Client's
+daemons. It is not required to be the same as the one defined in the Client's
configuration file. This record is required.
\item [Address = \lt{}address\gt{}]
\item [Name = \lt{}name\gt{}]
\index[fd]{Name }
The Storage name used to identify the Director in the list of monitored
-daemons. It is not required to be the same as defined in the Storage's
+daemons. It is not required to be the same as the one defined in the Storage's
configuration file. This record is required.
\item [Address = \lt{}address\gt{}]
\end{description}
-\subsection*{Sample Monitor configuration file and related daemons'
-configuration records.}
+\subsection*{Tray Monitor Security}
+\index[general]{Tray Monitor Security}
+\addcontentsline{toc}{subsection}{Tray Monitor Security}
+
+There is no security problem in relaxing the permissions on
+tray-monitor.conf as long as FD, SD and DIR are configured properly, so
+the passwords contained in this file only gives access to the status of
+the daemons. It could be a security problem if you consider the status
+information as potentially dangereous (I don't think it is the case).
+
+Concerning Director's configuration: \\
+In tray-monitor.conf, the password in the Monitor resource must point to
+a restricted console in bacula-dir.conf (see the documentation). So, if
+you use this password with bconsole, you'll only have access to the
+status of the director (commands status and .status).
+It could be a security problem if there is a bug in the ACL code of the
+director.
+
+Concerning File and Storage Daemons' configuration:\\
+In tray-monitor.conf, the Name in the Monitor resource must point to a
+Director resource in bacula-fd/sd.conf, with the Monitor directive set
+to Yes (once again, see the documentation).
+It could be a security problem if there is a bug in the code which check
+if a command is valid for a Monitor (this is very unlikely as the code
+is pretty simple).
+
+
+\subsection*{Sample Tray Monitor configuration}
\label{SampleConfiguration1}
-\index[general]{Sample Monitor configuration file and related daemons'
-configuration records. }
-\index[general]{Records!Sample Monitor configuration file and related daemons'
-configuration }
-\addcontentsline{toc}{subsection}{Sample Monitor configuration file and
-related daemons' configuration records.}
-
-A example Monitor configuration file might be the following:
+\index[general]{Sample Tray Monitor configuration}
+\addcontentsline{toc}{subsection}{Sample Tray Monitor configuration}
+
+An example Tray Monitor configuration file might be the following:
\footnotesize
\begin{verbatim}
\index[general]{Phase I!Installing and Configuring MySQL -- }
\addcontentsline{toc}{subsection}{Installing and Configuring MySQL -- Phase I}
-If you use the ./configure \verb{--{with-mysql=mysql-directory statement for
-configuring {\bf Bacula}, you will need MySQL version 3.23.33 or later
-installed in the {\bf mysql-directory} (we are currently using 3.23.56). If
-MySQL is installed in the standard system location, you need only enter {\bf
-\verb{--{with-mysql} since the configure program will search all the standard
-locations. If you install MySQL in your home directory or some other
-non-standard directory, you will need to provide the full path to it.
+If you use the ./configure \verb:--:with-mysql=mysql-directory statement for
+configuring {\bf Bacula}, you will need MySQL version 3.23.53 or later
+installed in the {\bf mysql-directory}.
+Bacula has been tested on MySQL version 4.1.12 and works providing
+you are running it in the default installation that is compatible
+with MySQL 3.23.x. If you are using one of the new modes such
+as ANSI/ISO compatibility, you may experience problems.
+
+If MySQL is installed in the standard system location, you need only enter
+{\bf \verb:--:with-mysql} since the configure program will search all the
+standard locations. If you install MySQL in your home directory or some
+other non-standard directory, you will need to provide the full path to it.
Installing and Configuring MySQL is not difficult but can be confusing the
first time. As a consequence, below, we list the steps that we used to install
any user passwords. This may be an undesirable situation if you have other
users on your system.
-Please note that as of Bacula version 1.31, the thread safe version of the
+Beginning with Bacula version 1.31, the thread safe version of the
MySQL client library is used, and hence you must add the {\bf
-\verb{--{enable-thread-safe-client} option to the {\bf ./configure} as shown below:
+\verb:--:enable-thread-safe-client} option to the {\bf ./configure} as shown below:
\begin{enumerate}
\item Download MySQL source code from
\item cd {\bf mysql-source-directory}
where you replace {\bf mysql-source-directory} with the directory name where
-you put the MySQL source code.
+ you put the MySQL source code.
-\item ./configure \verb{--{enable-thread-safe-client \verb{--{prefix=mysql-directory
+\item ./configure \verb:--:enable-thread-safe-client \verb:--:prefix=mysql-directory
where you replace {\bf mysql-directory} with the directory name where you
-want to install mysql. Normally for system wide use this is /usr/local/mysql.
-In my case, I use \~{}kern/mysql.
+ want to install mysql. Normally for system wide use this is /usr/local/mysql.
+ In my case, I use \~{}kern/mysql.
\item make
\item make install
This will put all the necessary binaries, libraries and support files into
-the {\bf mysql-directory} that you specified above.
+ the {\bf mysql-directory} that you specified above.
\item ./scripts/mysql\_install\_db
complete the installation. Please note, the installation files used in the
second phase of the MySQL installation are created during the Bacula
Installation.
-\label{mysql_phase2}
+\label{mysql_phase2}
\subsection*{Installing and Configuring MySQL -- Phase II}
\index[general]{Installing and Configuring MySQL -- Phase II }
\index[general]{Phase II!Installing and Configuring MySQL -- }
Bacula}. If not, please complete these items before proceeding.
Please note that the {\bf ./configure} used to build {\bf Bacula} will need to
-include {\bf \verb{--{with-mysql=mysql-directory}, where {\bf mysql-directory} is the
+include {\bf \verb:--:with-mysql=mysql-directory}, where {\bf mysql-directory} is the
directory name that you specified on the ./configure command for configuring
MySQL. This is needed so that Bacula can find the necessary include headers
and library files for interfacing to MySQL.
\begin{enumerate}
\item Start {\bf mysql}. You might want to use the {\bf startmysql} script
provided in the Bacula release.
-\item cd \lt{}install-directory\gt{}
+\item cd \lt{}install-directory\gt{}
This directory contains the Bacula catalog interface routines.
\item ./grant\_mysql\_privileges
-
- This script creates unrestricted access rights for {\bf kern}, {\bf kelvin},
-and {\bf bacula}. You may want to modify it to suit your situation. Please
-note that none of these userids including root are password protected.
+ This script creates unrestricted access rights for the user {\bf bacula}.
+ You may want to modify it to suit your situation. Please
+ note that none of the userids, including root, are password protected.
+ If you need more security, please assign a password to the root user
+ and to bacula. The program {\bf mysqladmin} can be used for this.
\item ./create\_mysql\_database
-
- This script creates the MySQL {\bf bacula} database. The databases you create
-as well as the access databases will be located in \lt{}install-dir\gt{}/var/
-in a subdirectory with the name of the database, where \lt{}install-dir\gt{}
-is the directory name that you specified on the {\bf \verb{--{prefix} option. This
-can be important to know if you want to make a special backup of the Bacula
-database or to check its size.
+ This script creates the MySQL {\bf bacula} database. The databases you
+ create as well as the access databases will be located in
+ \lt{}install-dir\gt{}/var/ in a subdirectory with the name of the
+ database, where \lt{}install-dir\gt{} is the directory name that you
+ specified on the {\bf \verb:--:prefix} option. This can be important to
+ know if you want to make a special backup of the Bacula database or to
+ check its size.
\item ./make\_mysql\_tables
-
This script creates the MySQL tables used by {\bf Bacula}.
\end{enumerate}
\normalsize
Please note that all information in the database will be lost and you will be
-starting from scratch. If you have written on any Volumes, you must write and
+starting from scratch. If you have written on any Volumes, you must write an
end of file mark on the volume so that Bacula can reuse it. Do so with:
\footnotesize
After configuring Bacula with
-./configure \verb{--{enable-thread-safe-client \verb{--{prefix=\lt{}mysql-directory\gt{}
+./configure \verb:--:enable-thread-safe-client \verb:--:prefix=\lt{}mysql-directory\gt{}
where \lt{}mysql-directory\gt{} is in my case {\bf /home/kern/mysql}, you may
have to configure the loader so that it can find the MySQL shared libraries.
If you have previously followed this procedure and later add the {\bf
-\verb{--{enable-thread-safe-client} options, you will need to rerun the {\bf
+\verb:--:enable-thread-safe-client} options, you will need to rerun the {\bf
ldconfig} program shown below. If you put MySQL in a standard place such as
{\bf /usr/lib} or {\bf /usr/local/lib} this will not be necessary, but in my
case it is. The description that follows is Linux specific. For other
/home/kern/mysql/lib/mysql then rebuild the loader's cache with:
/sbin/ldconfig If you upgrade to a new version of {\bf MySQL}, the shared
-library names will probably changes, and you must re-run the {\bf
+library names will probably change, and you must re-run the {\bf
/sbin/ldconfig} command so that the runtime loader can find them.
Alternatively, your system my have a loader environment variable that can be
<your-options>
\end{verbatim}
\normalsize
+
+\subsection*{Installing MySQL from RPMs}
+\index[general]{MySQL!Installing from RPMs}
+\index[general]{Installing MySQL from RPMs}
+\addcontentsline{toc}{subsection}{Installing MySQL from RPMs}
+If you are installing MySQL from RPMs, you will need to install
+both the MySQL binaries and the client libraries. The client
+libraries are ususally found in a devel package, so you must
+install:
+
+\footnotesize
+\begin{verbatim}
+ mysql
+ mysql-devel
+\end{verbatim}
+\normalsize
+
+This will be the same with most other package managers too.
+
+\subsection*{Upgrading MySQL}
+\index[general]{Upgrading MySQL }
+\index[general]{Upgrading!MySQL }
+\addcontentsline{toc}{subsection}{Upgrading MySQL}
+If you upgrade MySQL, you must reconfigure, rebuild, and re-install
+Bacula otherwise you are likely to get bizarre failures. If you
+install from rpms and you upgrade MySQL, you must also rebuild Bacula.
+You can do so by rebuilding from the source rpm. To do so, you may need
+to modify the bacula.spec file to account for the new MySQL version.
%%
%%
-\section*{Using Pools to Manage Volumes}
+\section*{Automated Disk Backup}
\label{_ChapterStart11}
\index[general]{Volumes!Using Pools to Manage }
+\index[general]{Disk!Automated Backup}
\index[general]{Using Pools to Manage Volumes }
+\index[general]{Automated Disk Backup}
\addcontentsline{toc}{section}{Using Pools to Manage Volumes}
+\addcontentsline{toc}{section}{Automated Disk Backup}
If you manage 5 or 10 machines and have a nice tape backup, you don't need
Pools, and you may wonder what they are good for. In this chapter, you will
various different Volumes to meet their needs.
The rest of this chapter will give an example involving backup to disk
-Volumes, but most of the information applies equally well for tape Volumes.
-\label{TheProblem}
+Volumes, but most of the information applies equally well to tape Volumes.
+\label{TheProblem}
\subsection*{The Problem}
\index[general]{Problem }
\addcontentsline{toc}{subsection}{Problem}
They want to maintain 6 months of backup data, and be able to access the old
files on a daily basis for a week, a weekly basis for a month, then monthly
-for 6 months. In addition, and offsite capability was not needed (well perhaps
+for 6 months. In addition, offsite capability was not needed (well perhaps
it really is, but it was never used). Their daily changes amount to about
300MB on the average, or about 2GB per week.
\normalsize
As you can see, the Differential Pool can grow to a maximum of six volumes,
-and the Volumes are retained 40 days and there after can be recycled. Finally
+and the Volumes are retained 40 days and thereafter they can be recycled. Finally
there is one job per volume. This, of course, could be tightened up a lot, but
the expense here is a few GB which is not too serious.
\label{IncPool}
}
\end{verbatim}
\normalsize
-
developers in dealing with Volumes external to Bacula.
\subsection*{Specifying the Configuration File}
-\index[general]{File!Specifying the Configuration }
\index[general]{Specifying the Configuration File }
\addcontentsline{toc}{subsection}{Specifying the Configuration File}
bacula-sd.conf} in the current directory, but you may specify a different
configuration file using the {\bf -c} option.
+
\subsection*{Specifying a Device Name For a Tape}
\index[general]{Tape!Specifying a Device Name For a }
\index[general]{Specifying a Device Name For a Tape }
work, it must find the identical name in the Device resource of the
configuration file. See below for specifying Volume names.
+Please note that if you have Bacula running and you ant to use
+one of these programs, you will either need to stop the Storage daemon, or
+{\bf unmount} any tape drive you want to use, otherwise the drive
+will {\bf busy} because Bacula is using it.
+
+
\subsection*{Specifying a Device Name For a File}
\index[general]{File!Specifying a Device Name For a }
\index[general]{Specifying a Device Name For a File }
\subsection*{bls}
\label{bls}
-\index[general]{Bls }
+\index[general]{bls }
\addcontentsline{toc}{subsection}{bls}
{\bf bls} can be used to do an {\bf ls} type listing of a {\bf Bacula} tape or
\footnotesize
\begin{verbatim}
-Usage: bls [-d debug_level] <device-name>
+Usage: bls [options] <device-name>
-b <file> specify a bootstrap file
- -c <file> specify a configuration file
- -d <level> specify a debug level
+ -c <file> specify a config file
+ -d <level> specify debug level
-e <file> exclude list
-i <file> include list
-j list jobs
-k list blocks
- -L list tape label
- (none of above) list saved files
- -p proceed inspite of I/O errors
- -t use default tape device
+ (no j or k option) list saved files
+ -L dump label
+ -p proceed inspite of errors
-v be verbose
-V specify Volume names (separated by |)
-? print this message
\end{verbatim}
\normalsize
-\subsubsection*{Listing Bacula Jobs}
-\index[general]{Listing Bacula Jobs }
-\index[general]{Jobs!Listing Bacula }
-\addcontentsline{toc}{subsubsection}{Listing Bacula Jobs}
+\subsubsection*{Listing Jobs}
+\index[general]{Listing Jobs with bls }
+\index[general]{bls!Listing Jobs }
+\addcontentsline{toc}{subsubsection}{bls Listing Jobs}
If you are listing a Volume to determine what Jobs to restore, normally the
{\bf -j} option provides you with most of what you will need as long as you
\footnotesize
\begin{verbatim}
-./bls -j /tmp/test1
-Volume Record: SessId=2 SessTime=1033762386 JobId=0 DataLen=144
-Begin Session Record: SessId=2 SessTime=1033762386 JobId=1 Level=F Type=B
-End Session Record: SessId=2 SessTime=1033762386 JobId=1 Level=F Type=B
-Begin Session Record: SessId=3 SessTime=1033762386 JobId=2 Level=I Type=B
-End Session Record: SessId=3 SessTime=1033762386 JobId=2 Level=I Type=B
-Begin Session Record: SessId=4 SessTime=1033762386 JobId=3 Level=I Type=B
-End Session Record: SessId=4 SessTime=1033762386 JobId=3 Level=I Type=B
-bls: Got EOF on device /tmp
+./bls -j -V Test1 -c stored.conf DDS-4
+bls: butil.c:258 Using device: "DDS-4" for reading.
+11-Jul 11:54 bls: Ready to read from volume "Test1" on device "DDS-4" (/dev/nst0).
+Volume Record: File:blk=0:1 SessId=4 SessTime=1121074625 JobId=0 DataLen=165
+Begin Job Session Record: File:blk=0:2 SessId=4 SessTime=1121074625 JobId=1 Level=F Type=B
+Begin Job Session Record: File:blk=0:3 SessId=5 SessTime=1121074625 JobId=5 Level=F Type=B
+Begin Job Session Record: File:blk=0:6 SessId=3 SessTime=1121074625 JobId=2 Level=F Type=B
+Begin Job Session Record: File:blk=0:13 SessId=2 SessTime=1121074625 JobId=4 Level=F Type=B
+End Job Session Record: File:blk=0:99 SessId=3 SessTime=1121074625 JobId=2 Level=F Type=B
+ Files=168 Bytes=1,732,978 Errors=0 Status=T
+End Job Session Record: File:blk=0:101 SessId=2 SessTime=1121074625 JobId=4 Level=F Type=B
+ Files=168 Bytes=1,732,978 Errors=0 Status=T
+End Job Session Record: File:blk=0:108 SessId=5 SessTime=1121074625 JobId=5 Level=F Type=B
+ Files=168 Bytes=1,732,978 Errors=0 Status=T
+End Job Session Record: File:blk=0:109 SessId=4 SessTime=1121074625 JobId=1 Level=F Type=B
+ Files=168 Bytes=1,732,978 Errors=0 Status=T
+11-Jul 11:54 bls: End of Volume at file 1 on device "DDS-4" (/dev/nst0), Volume "Test1"
+11-Jul 11:54 bls: End of all volumes.
\end{verbatim}
\normalsize
Adding the {\bf -v} option will display virtually all information that is
available for each record:
-\subsubsection*{Listing Bacula Blocks}
-\index[general]{Listing Bacula Blocks }
-\index[general]{Blocks!Listing Bacula }
-\addcontentsline{toc}{subsubsection}{Listing Bacula Blocks}
+\subsubsection*{Listing Blocks}
+\index[general]{Listing Blocks with bls }
+\index[general]{bls!Listing Blocks }
+\addcontentsline{toc}{subsubsection}{bls Listing Blocks}
Normally, except for debugging purposes, you will not need to list Bacula
-blocks (the ``primitive'' unit of Bacula data on the Volume). However, you can
+blocks (the "primitive" unit of Bacula data on the Volume). However, you can
do so with:
\footnotesize
\subsection*{bscan}
\label{bscan}
-\index[general]{Bscan }
+\index[general]{bscan }
\addcontentsline{toc}{subsection}{bscan}
The {\bf bscan} program can be used to re-create a database (catalog) from the
that the records on the Volume are no longer in the catalog.
With some care, it can also be used to synchronize your existing catalog with
-a Volume. Since {\bf bscan} modifies your catalog, we strongly recommend that
+a Volume. Although we have never seen a case of bscan damaging a
+catalog, since bscan modifies your catalog, we recommend that
you do a simple ASCII backup of your database before running {\bf bscan} just
to be sure. See
\ilink{Compacting Your Database}{CompactingMySQL}.
database name ({\bf -b} option), the user name ({\bf -u} option), and/or the
password ({\bf -p}) options.
-As an example, let's suppose that you did a backup to Volume ``Vol001'' and
-that sometime later all record of that Volume was pruned or purged from the
-database. By using {\bf bscan} you can recreate the catalog entries for that
-Volume and then use the {\bf restore} command in the Console to restore
+As an example, let's suppose that you did a backup to Volumes "Vol001"
+and "Vol002", then sometime later all records of one or both those
+Volumes
+were pruned or purged from the
+database. By using {\bf bscan} you can recreate the catalog entries for
+those Volumes and then use the {\bf restore} command in the Console to restore
whatever you want. A command something like:
\footnotesize
\begin{verbatim}
-bscan -c bacula-sd.conf -v -V Vol001 /dev/nst0
+bscan -c bacula-sd.conf -v -V Vol001\|Vol002 /dev/nst0
\end{verbatim}
\normalsize
-will give you a give you an idea of what is going to happen without changing
+will give you an idea of what is going to happen without changing
your catalog. Of course, you may need to change the path to the Storage
daemon's conf file, the Volume name, and your tape (or disk) device name. This
command must read the entire tape, so if it has a lot of data, it may take a
long time, and thus you might want to immediately use the command listed
below. Note, if you are writing to a disk file, replace the device name with
-the path to the directory that contains the Volume. This must correspond to
+the path to the directory that contains the Volumes. This must correspond to
the Archive Device in the conf file.
Then to actually write or store the records in the catalog, add the {\bf -s}
\footnotesize
\begin{verbatim}
- bscan -s -m -c bacula-sd.conf -v -V Vol001 /dev/nst0
+ bscan -s -m -c bacula-sd.conf -v -V Vol001\|Vol002 /dev/nst0
\end{verbatim}
\normalsize
When writing to the database, if bscan finds existing records, it will
generally either update them if something is wrong or leave them alone. Thus
-if the Volume you are scanning is all or partially in the catalog already, no
+if the Volumes you are scanning are all or partially in the catalog already, no
harm will be done to that existing data. Any missing data will simply be
added.
-If you have multiple tapes, you can scan them with:
+If you have multiple tapes, you should scan them with:
\footnotesize
\begin{verbatim}
\end{verbatim}
\normalsize
-You should, where ever possible try to specify the tapes in the order they are
-written. However, bscan can handle scanning tapes that are not sequential. Any
-incomplete records at the end of the tape will simply be ignored in that case.
+You should, always try to specify the tapes in the order they are written.
+However, bscan can handle scanning tapes that are not sequential. Any
+incomplete records at the end of the tape will simply be ignored in that
+case. If you are simply reparing an existing catalog, this may be OK, but
+if you are creating a new catalog from scratch, it will leave your database
+in an incorrect state. If you do not specify all necessary Volumes on a
+single bscan command, bscan will not be able to correctly restore the
+records that span two volumes. In other words, it is much better to
+specify two or three volumes on a single bscan command rather than run
+bscan two or three times, each with a single volume.
Note, the restoration process using bscan is not identical to the original
\addcontentsline{toc}{subsubsection}{Using bscan to Correct the Volume File
Count}
-If the Storage daemon crashes during a backup Job, the catalog will no be
+If the Storage daemon crashes during a backup Job, the catalog will not be
properly updated for the Volume being used at the time of the crash. This
means that the Storage daemon will have written say 20 files on the tape, but
the catalog record for the Volume indicates only 19 files.
If you use {\bf bscan} to enter the contents of the Volume into an existing
catalog, you should be aware that the records you entered may be immediately
-pruned during the next job particularly if the Volume is very old or had been
+pruned during the next job, particularly if the Volume is very old or had been
previously purged. To avoid this, after running {\bf bscan}, you can manually
set the volume status (VolStatus) to {\bf Read-Only} by using the {\bf update}
command in the catalog. This will allow you to restore from the volume without
directory. If your configuration file is elsewhere, please use the {\bf -c}
option to specify where.
-The physical device name must be specified on the command line, and that this
+The physical device name must be specified on the command line, and this
same device name must be present in the Storage daemon's configuration file
read by {\bf btape}
\begin{itemize}
\item test -- test writing records and EOF marks and reading them back.
\item fill -- completely fill a volume with records, then write a few records
- on a second volume, and finally, both volumes will be read back. Please be
- aware that the data written will be quite similar every record, so you might
-want to turn compression off. One user found that the fill command wrote
-750Gb to a tape that can hold 35Gb -- so you can see that the hardware
-compression really worked well!
+ on a second volume, and finally, both volumes will be read back.
+ This command writes blocks containing random data, so your drive will
+ not be able to compress the data, and thus it is a good test of
+ the real physical capacity of your tapes.
\item readlabel -- read and dump the label on a Bacula tape.
\item cap -- list the device capabilities as defined in the configuration
file and as perceived by the Storage daemon.
database, and optionally fix them. The {\bf dbcheck} program can be found in
the {\bf \lt{}bacula-source\gt{}/src/tools} directory of the source
distribution. Though it is built with the make process, it is not normally
-``installed''.
+"installed".
It is called:
database. If this is the case, you will receive error messages during Jobs
warning of duplicate database records. If you are not getting these error
messages, there is no reason to run this check.
-\item Repair bad Filename records. This checkes and corrects filenames that
+\item Repair bad Filename records. This checks and corrects filenames that
have a trailing slash. They should not.
\item Repair bad Path records. This checks and corrects path names that do
not have a trailing slash. They should.
However, you may find it useful to see what bacula would do with a given {\bf
Include} resource. The {\bf testfind} program can be found in the {\bf
\lt{}bacula-source\gt{}/src/tools} directory of the source distribution.
-Though it is built with the make process, it is not normally ``installed''.
+Though it is built with the make process, it is not normally "installed".
It is called:
internal file type, or the link (if any). Debug levels of 10 or greater cause
the filename and the path to be separated using the same algorithm that is
used when putting filenames into the Catalog database.
-
-\subsection*{bimagemgr}
-\label{bimagemgr}
-\index[general]{Bimagemgr }
-\addcontentsline{toc}{subsection}{bimagemgr}
-
-{\bf bimagemgr} is a utility for those who backup to disk volumes in order to
-commit them to CDR disk, rather than tapes. It is a web based interface
-written in perl, used to monitor when a volume file needs to be burned to
-disk. It requires:
-
-\begin{itemize}
-\item A web server running on the bacula server
-\item A CD recorder installed and configured on the bacula server
-\item The cdrtools package installed on the bacula server.
-\item perl, perl-DBI module, and either DBD-MySQL or DBD-PostgreSQL modules
- \end{itemize}
-
-SQLite databases and DVD burning are not supported by {\bf bimagemgr} at this
-time, but both planned for future releases.
-
-\subsubsection*{Installation}
-\index[general]{Installation }
-\addcontentsline{toc}{subsubsection}{Installation}
-
-Please see the README file in the bimagemgr directory of the distribution for
-instructions.
-
-\subsubsection*{Usage}
-\index[general]{Usage }
-\addcontentsline{toc}{subsubsection}{Usage}
-
-Calling the program in your web browser, e.g. {\tt
-http://localhost/cgi-bin/bimagemgr.pl} will produce a display as shown below
-in Figure 1. The program will query the bacula database and display all volume
-files with the date last written and the date last burned to disk. If a volume
-needs to be burned (last written is newer than last burn date) a ``Burn''
-button will be displayed in the right most column.
-
-\addcontentsline{lof}{figure}{Bacula CD Image Manager}
-\includegraphics{./bimagemgr1.eps} Figure 1
-
-Place a blank CDR disk in your recorder and click a ``Burn'' button. This will
-cause a pop up window as shown in Figure 2 to display the burn progress.
-
-\addcontentsline{lof}{figure}{Bacula CD Image Burn Progress Window}
-\includegraphics{./bimagemgr2.eps} Figure 2
-
-When the burn finishes the pop up window will display the results of cdrecord
-as shown in Figure 3. Close the pop up window and refresh the main window. The
-last burn date will be updated and the ``Burn'' button for that volume will
-disappear. Should you have a failed burn you can reset the last burn date of
-that volume by clicking it's ``Reset'' link.
-
-\addcontentsline{lof}{figure}{Bacula CD Image Burn Results}
-\includegraphics{./bimagemgr3.eps} Figure 3
-
-In the bottom row of the main display window are two more buttons labeled
-``Burn Catalog'' and ``Blank CDRW''. ``Burn Catalog'' will place a copy of
-your bacula catalog on a disk. If you use CDRW disks rather than CDR then
-``Blank CDRW'' allows you to erase the disk before re-burning it. Regularly
-committing your backup volume files and your catalog to disk with {\bf
-bimagemgr} insures that you can rebuild easily in the event of some disaster
-on the bacula server itself.
\index[general]{Bacula Projects }
\addcontentsline{toc}{section}{Bacula Projects}
-Please see the projects page on the web site at:
-\elink{www.bacula.org.projects.html}{http://www.bacula.org/projects.html}, or
-see the {\bf projects} file in the main source directory. For a current list
-of tasks you can see {\bf kernstodo} in the main source directory.
+Once a new major version of Bacula is released, the Bacula
+users will vote on a list of new features. This vote is used
+as the main element determining what new features will be
+implemented for the next version. Generally, the development time
+for a new release is between 4 to 9 months.
+
+For the current list of project, please see the projects page in the CVS
+at: \elink{http://cvs.sourceforge.net/viewcvs.py/*checkout*/bacula/bacula/projects}
+{http://cvs.sourceforge.net/viewcvs.py/*checkout*/bacula/bacula/projects}
+see the {\bf projects} file in the main source directory. The projects
+file is updated approximately once every six months.
+
+Separately from the project list, Kern maintains a current list of
+tasks as well as ideas, feature requests, and occassionally design
+notes. This list is updated roughly weekly (sometimes more often).
+For a current list of tasks you can see {\bf kernstodo} in the Source Forge
+CVS at \elink{http://cvs.sourceforge.net/viewcvs.py/*checkout*/bacula/bacula/kernstodo}
+{http://cvs.sourceforge.net/viewcvs.py/*checkout*/bacula/bacula/kernstodo}.
\index[general]{Automatic Volume Recycling }
\addcontentsline{toc}{section}{Automatic Volume Recycling}
-Normally, Bacula will write on a volume, and once the tape is written, it can
-append to the volume, but it will never overwrite the data thus destroying it.
-When we speak of {\bf recycling} volumes, we mean that {\bf Bacula} can write
-over the previous contents of a volume. Thus all previous data will be lost.
-
-You may not want Bacula to automatically recycle (reuse) tapes. This requires
-a large number of tapes, and in such a case, it is possible to manually
-recycle tapes. For more on manual recycling, see the section entitled
-\ilink{ Manually Recycling Volumes}{manualrecycling} below in
-this chapter.
+By default, once Bacula starts writing a Volume, it can
+append to the volume, but it will not overwrite the existing
+data thus destroying it.
+However when Bacula {\bf recycles} a Volume, the Volume becomes
+available for being reused, and Bacula can at some later time
+over write the previous contents of that Volume.
+Thus all previous data will be lost. If the Volume is a tape,
+the tape will be rewritten from the beginning. If the Volume is
+a disk file, the file will be truncated before being rewritten.
+
+You may not want Bacula to automatically recycle (reuse) tapes. This would
+require a large number of tapes though, and in such a case, it is possible
+to manually recycle tapes. For more on manual recycling, see the section
+entitled \ilink{ Manually Recycling Volumes}{manualrecycling} below in this
+chapter.
Most people prefer to have a Pool of tapes that are used for daily backups and
recycled once a week, another Pool of tapes that are used for Full backups
once a week and recycled monthly, and finally a Pool of tapes that are used
-once a month and recycled after a year or two. With a scheme like this, your
-pool of tapes remains constant.
+once a month and recycled after a year or two. With a scheme like this, the
+number of tapes in your pool or pools remains constant.
By properly defining your Volume Pools with appropriate Retention periods,
Bacula can manage the recycling (such as defined above) automatically.
Automatic recycling of Volumes is controlled by three records in the {\bf
Pool} resource definition in the Director's configuration file. These three
-records are: {\bf
+records are:
\begin{itemize}
\item AutoPrune = yes
\item Recycle = yes
\end{itemize}
-} Automatic recycling of Volumes is performed by Bacula only when it wants a
+Automatic recycling of Volumes is performed by Bacula only when it wants a
new Volume and no appendable Volumes are available in the Pool. It will then
search the Pool for any Volumes with the {\bf Recycle} flag set and whose
Volume Status is {\bf Full}. At that point, the recycling occurs in two steps.
expired. When a Volume is marked as Purged, it means that no Catalog records
reference that Volume, and the Volume can be recycled. Until recycling
actually occurs, the Volume data remains intact. If no Volumes can be found
-for recycline for any of the reasons stated above, Bacula will request
+for recycling for any of the reasons stated above, Bacula will request
operator intervention (i.e. it will ask you to label a new volume).
-A key point mentioned above that can be a source of frustration is that Bacula
+A key point mentioned above, that can be a source of frustration, is that Bacula
will only recycle purged Volumes if there is no other appendable Volume
available, otherwise, it will always write to an appendable Volume before
recycling even if there are Volume marked as Purged. This preserves your data
-as long as possible. So, if you wish to ``force'' Bacula to use a purged
+as long as possible. So, if you wish to "force" Bacula to use a purged
Volume, you must first ensure that no other Volume in the Pool is marked {\bf
Append}. If necessary, you can manually set a volume to {\bf Full}. The reason
for this is that Bacula wants to preserve the data on your old tapes (even
though purged from the catalog) as long as absolutely possible before
overwriting it.
-\label{AutoPruning}
+\label{AutoPruning}
\subsection*{Automatic Pruning}
\index[general]{Automatic Pruning }
\index[general]{Pruning!Automatic }
cannot use the Console restore command to restore the files.
When a Job record is pruned, the Volume (Media record) for that Job can still
-remain in the database, and if you do a ``list volumes'', you will see the
+remain in the database, and if you do a "list volumes", you will see the
volume information, but the Job records (and its File records) will no longer
be available.
also prevents the catalog from growing to be too large. You choose the
retention periods in function of how many files you are backing up and the
time periods you want to keep those records online, and the size of the
-database.You can always re-insert the records (with 98\% of the original data)
-by using ``bscan'' to scan in a whole Volume or any part of the volume that
+database. You can always re-insert the records (with 98\% of the original data)
+by using "bscan" to scan in a whole Volume or any part of the volume that
you want.
By setting {\bf AutoPrune} to {\bf yes} you will permit {\bf Bacula} to
automatically prune all Volumes in the Pool when a Job needs another Volume.
Volume pruning means removing records from the catalog. It does not shrink the
-size of the Volume or effect the Volume data until the Volume gets
+size of the Volume or affect the Volume data until the Volume gets
overwritten. When a Job requests another volume and there are no Volumes with
Volume Status {\bf Append} available, Bacula will begin volume pruning. This
means that all Jobs that are older than the {\bf VolumeRetention} period will
\item [AutoPrune = \lt{}yes|no\gt{}]
\index[console]{AutoPrune }
- If AutoPrune is set to {\bf yes} (default), Bacula (version 1.20 or greater)
-will automatically apply the Volume retention period when running a Job and
-it needs a new Volume but no appendable volumes are available. At that point,
-Bacula will prune all Volumes that can be pruned (i.e. AutoPrune set) in an
-attempt to find a usable volume. If during the autoprune, all files are
-pruned from the Volume, it will be marked with VolStatus {\bf Purged}. The
-default is {\bf yes}.
+ If AutoPrune is set to {\bf yes} (default), Bacula
+ will automatically apply the Volume retention period when running a Job and
+ it needs a new Volume but no appendable volumes are available. At that point,
+ Bacula will prune all Volumes that can be pruned (i.e. AutoPrune set) in an
+ attempt to find a usable volume. If during the autoprune, all files are
+ pruned from the Volume, it will be marked with VolStatus {\bf Purged}. The
+ default is {\bf yes}. Note, that although the File and Job records may be
+ pruned from the catalog, a Volume will be marked Purged (and hence
+ ready for recycling) if the Volume status is Append, Full, Used, or Error.
+ If the Volume has another status, such as Archive, Read-Only, Disabled,
+ Busy, or Cleaning, the Volume status will not be changed to Purged.
\item [Volume Retention = \lt{}time-period-specification\gt{}]
\index[console]{Volume Retention }
The Volume Retention record defines the length of time that Bacula will
-guarantee that the Volume is not reused counting from the time the last job
-stored on the Volume terminated.
-
-When this time period expires, and if {\bf AutoPrune} is set to {\bf yes},
-and a new Volume is needed, but no appendable Volume is available, Bacula
-will prune (remove) Job records that are older than the specified Volume
-Retention period.
-
-The Volume Retention period takes precedence over any Job Retention period
-you have specified in the Client resource. It should also be noted, that the
-Volume Retention period is obtained by reading the Catalog Database Media
-record rather than the Pool resource record. This means that if you change
-the VolumeRetention in the Pool resource record, you must ensure that the
-corresponding change is made in the catalog by using the {\bf update pool}
-command. Doing so will insure that any new Volumes will be created with the
-changed Volume Retention period. Any existing Volumes will have their own
-copy of the Volume Retention period that can only be changed on a Volume by
-Volume basis using the {\bf update volume} command.
-
-When all file catalog entries are removed from the volume, its VolStatus is
-set to {\bf Purged}. The files remain physically on the Volume until the
-volume is overwritten.
-
-Retention periods are specified in seconds, minutes, hours, days, weeks,
-months, quarters, or years on the record. See the
-\ilink{Configuration chapter}{Time} of this manual for
-additional details of time specification.
+ guarantee that the Volume is not reused counting from the time the last job
+ stored on the Volume terminated.
+
+ When this time period expires, and if {\bf AutoPrune} is set to {\bf yes},
+ and a new Volume is needed, but no appendable Volume is available, Bacula
+ will prune (remove) Job records that are older than the specified Volume
+ Retention period.
+
+ The Volume Retention period takes precedence over any Job Retention period
+ you have specified in the Client resource. It should also be noted, that the
+ Volume Retention period is obtained by reading the Catalog Database Media
+ record rather than the Pool resource record. This means that if you change
+ the VolumeRetention in the Pool resource record, you must ensure that the
+ corresponding change is made in the catalog by using the {\bf update pool}
+ command. Doing so will insure that any new Volumes will be created with the
+ changed Volume Retention period. Any existing Volumes will have their own
+ copy of the Volume Retention period that can only be changed on a Volume by
+ Volume basis using the {\bf update volume} command.
+
+ When all file catalog entries are removed from the volume, its VolStatus is
+ set to {\bf Purged}. The files remain physically on the Volume until the
+ volume is overwritten.
+
+ Retention periods are specified in seconds, minutes, hours, days, weeks,
+ months, quarters, or years on the record. See the
+ \ilink{Configuration chapter}{Time} of this manual for
+ additional details of time specification.
The default is 1 year.
\item [Recycle = \lt{}yes|no\gt{}]
\index[fd]{Recycle }
This statement tells Bacula whether or not the particular Volume can be
-recycled (i.e. rewritten). If Recycle is set to {\bf no} (the default), then
-even if Bacula prunes all the Jobs on the volume and it is marked {\bf
-Purged}, it will not consider the tape for recycling. If Recycle is set to
-{\bf yes} and all Jobs have been pruned, the volume status will be set to
-{\bf Purged} and the volume may then be reused when another volume is needed.
-If the volume is reused, it is relabeled with the same Volume Name, however
-all previous data will be lost.
-\end{description}
-
-Note, it is also possible to ``force'' pruning of all Volumes in the Pool
-associated with a Job by adding {\bf Prune Files = yes} to the Job resource.
-\label{Recycling}
+ recycled (i.e. rewritten). If Recycle is set to {\bf no} (the default), then
+ even if Bacula prunes all the Jobs on the volume and it is marked {\bf
+ Purged}, it will not consider the tape for recycling. If Recycle is set to
+ {\bf yes} and all Jobs have been pruned, the volume status will be set to
+ {\bf Purged} and the volume may then be reused when another volume is needed.
+ If the volume is reused, it is relabeled with the same Volume Name, however
+ all previous data will be lost.
+ \end{description}
+
+ It is also possible to "force" pruning of all Volumes in the Pool
+ associated with a Job by adding {\bf Prune Files = yes} to the Job resource.
+\label{Recycling}
\subsection*{Recycling Algorithm}
\index[general]{Algorithm!Recycling }
\index[general]{Recycling Algorithm }
and if the {\bf Recycle} flag is on (Recycle=yes) for that Volume, Bacula will
relabel it and write new data on it.
-The full recycling algorithm that Bacula uses when it needs a new Volume is:
+The full algorithm that Bacula uses when it needs a new Volume is:
\begin{itemize}
-\item Search the Pool for a Volume with VolStatus=Append (if there is more
- than one, the Volume with the oldest date last written is chosen. If two have
- the same date then the one with the lowest MediaId is chosen).
-\item Search the Pool for a Volume with VolStatus=Recycle (if there is more
- than one, the Volume with the oldest date last written is chosen. If two have
- the same date then the one with the lowest MediaId is chosen).
+\item Search the Pool for a Volume with VolStatus=Append (if there is more
+ than one, the Volume with the oldest date last written is chosen. If
+ two have the same date then the one with the lowest MediaId is chosen).
+\item Search the Pool for a Volume with VolStatus=Recycle and the InChanger
+ flag is set true (if there is more than one, the Volume with the oldest
+ date last written is chosen. If two have the same date then the one
+ with the lowest MediaId is chosen).
+\item Try recycling any purged Volumes.
\item Prune volumes applying Volume retention period (Volumes with VolStatus
Full, Used, or Append are pruned).
\item Search the Pool for a Volume with VolStatus=Purged
+\item If InChanger was set, go back to the first step above, but
+ this second time, ignore the InChanger flag in step 2.
\item Attempt to create a new Volume if automatic labeling enabled
+ If Python is enabled, a Python NewVolume even is generated before
+ the Label Format check is used.
+\item If a Pool named "Scratch" exists, search for a Volume and if found
+ move it to the current Pool for the Job and use it.
\item Prune the oldest Volume if RecycleOldestVolume=yes (the Volume with the
oldest LastWritten date and VolStatus equal to Full, Recycle, Purged, Used,
or Append is chosen). This record ensures that all retention periods are
-properly respected.
+ properly respected.
\item Purge the oldest Volume if PurgeOldestVolume=yes (the Volume with the
oldest LastWritten date and VolStatus equal to Full, Recycle, Purged, Used,
or Append is chosen). We strongly recommend against the use of {\bf
-PurgeOldestVolume} as it can quite easily lead to loss of current backup
-data.
+ PurgeOldestVolume} as it can quite easily lead to loss of current backup
+ data.
\item Give up and ask operator.
- \end{itemize}
+\end{itemize}
The above occurs when Bacula has finished writing a Volume or when no Volume
is present in the drive.
the Director to use this Volume. In this case, if you have set {\bf Recycle
Current Volume = yes} and the Volume is marked as Used or Full, Bacula will
prune the volume and if all jobs were removed during the pruning (respecting
-the retention periods), the Volume will be recycled and used. For this to
-work, you must have {\bf Accept Any Volume = yes} in the Pool. The recycling
-algorithm in this case is:
+the retention periods), the Volume will be recycled and used.
+The recycling algorithm in this case is:
\begin{itemize}
\item If the VolStatus is {\bf Append} or {\bf Recycle} and {\bf Accept Any
Each Volume inherits the Recycle status (yes or no) from the Pool resource
record when the Media record is created (normally when the Volume is labeled).
-This Recycle status is stored in the Media record of the Catalog. Using the
+This Recycle status is stored in the Media record of the Catalog. Using
the Console program, you may subsequently change the Recycle status for each
Volume. For example in the following output from {\bf list volumes}:
all the volumes are marked as recyclable, and the last Volume, {\bf File0007}
has been purged, so it may be immediately recycled. The other volumes are all
marked recyclable and when their Volume Retention period (14400 seconds or 4
-hours) expires, they will be eligible for pruning, and possible recycling.
+hours) expires, they will be eligible for pruning, and possibly recycling.
Even though Volume {\bf File0007} has been purged, all the data on the Volume
is still recoverable. A purged Volume simply means that there are no entries
in the Catalog. Even if the Volume Status is changed to {\bf Recycle}, the
the next day when you notice the email message, you will mount it and {\bf
Bacula} will finish the unfinished incremental backup.
-What does this give? Well, at any point, you will have a the last complete
-Full save plus several Incremental saves. For any given file your want to
+What does this give? Well, at any point, you will have the last complete
+Full save plus several Incremental saves. For any given file you want to
recover (or your whole system), you will have a copy of that file every day
for at least the last 14 days. For older versions, you will have at least 3
and probably 4 Friday full saves of that file, and going back further, you
{\bf Recycle} field is set to {\bf 1}
\item Use the {\bf purge jobs volume} command in the Console to mark the
Volume as {\bf Purged}. Check by using {\bf list volumes}.
- \end{itemize}
+\end{itemize}
Once the Volume is marked Purged, it will be recycled the next time a Volume
is needed.
Volume as {\bf Purged}. Check by using {\bf list volumes}.
\item In Bacula version 1.30 or greater, use the Console {\bf relabel}
command to relabel the Volume.
- \end{itemize}
+\end{itemize}
Please note that the relabel command applies only to tape Volumes.
\begin{itemize}
\item Use the {\bf delete volume} command in the Console to delete the Volume
from the Catalog.
-\item If the a different tape is mounted, use the {\bf unmount} command,
+\item If a different tape is mounted, use the {\bf unmount} command,
remove the tape, and insert the tape to be renamed.
\item Write an EOF mark in the tape using the following commands:
- \footnotesize
+\footnotesize
\begin{verbatim}
mt -f /dev/nst0 rewind
mt -f /dev/nst0 weof
system.
\item Use the {\bf label} command to write a new label to the tape and to
enter it in the catalog.
- \end{itemize}
+\end{itemize}
Please be aware that the {\bf delete} command can be dangerous. Once it is
done, to recover the File records, you must either restore your database as it
\index[general]{General }
\addcontentsline{toc}{subsection}{General}
-Below, we will discuss restoring files with the Console {\bf Restore} command,
+Below, we will discuss restoring files with the Console {\bf restore} command,
which is the recommended way of doing it. However, there is a standalone
program named {\bf bextract}, which also permits restoring files. For more
information on this program, please see the
a predefined {\bf restore} job in your {\bf bacula-dir.conf} (Director's
config) file. The exact parameters (Client, FileSet, ...) that you define are
not important as you can either modify them manually before running the job or
-if you use the {\bf restore} command, explained below, they will be
-automatically set for you.
+if you use the {\bf restore} command, explained below, Bacula will
+automatically set them for you. In fact, you can no longer simply run a restore
+job. You must use the restore command.
Since Bacula is a network backup program, you must be aware that when you
restore files, it is up to you to ensure that you or Bacula have selected the
the files to a different directory on client B. Normally, you will want to
avoid this, but assuming the operating systems are not too different in their
file structures, this should work perfectly well, if so desired.
-\label{Example1}
+By default, Bacula will restore data to the same Client that was backed
+up, and those data will be restored not to the original places but to
+{\bf /tmp/bacula-restores}. You may modify any of these defaults when the
+restore command prompts you to run the job by selecting the {\bf mod}
+option.
+\label{Example1}
\subsection*{The Restore Command}
\index[general]{Command!Restore }
\index[general]{Restore Command }
date), and what files to restore. Bacula will then do the rest.
This is accomplished using the {\bf restore} command in the Console. First you
-select the kind of restore you want, then Bacula Once the JobIds are selected,
+select the kind of restore you want, then the JobIds are selected,
the File records for those Jobs are placed in an internal Bacula directory
tree, and the restore enters a file selection mode that allows you to
interactively walk up and down the file tree selecting individual files to be
restored. This mode is somewhat similar to the standard Unix {\bf restore}
program's interactive file selection mode.
+If your Files have been pruned, the {\bf restore} command will be unable
+to find any files to restore. See below for more details on this.
+
Within the Console program, after entering the {\bf restore} command, you are
presented with the following selection prompt:
To select the JobIds, you have the following choices:
1: List last 20 Jobs run
2: List Jobs where a given File is saved
- 3: Enter list of JobIds to select
+ 3: Enter list of comma separated JobIds to select
4: Enter SQL list command
5: Select the most recent backup for a client
6: Select backup for a client before a specified time
7: Enter a list of files to restore
8: Enter a list of files to restore before a specified time
- 9: Cancel
-Select item: (1-9):
-
+ 9: Find the JobIds of the most recent backup for a client
+ 10: Find the JobIds for a backup for a client before a specified time
+ 11: Enter a list of directories to restore for found JobIds
+ 12: Cancel
+Select item: (1-12):
\end{verbatim}
\normalsize
\begin{itemize}
-\item Item 1 will list the last 20 jobs run. If you find the Job you want,
- you can then select item 3 and enter its JobId(s).
+\item Item 1 will list the last 20 jobs run. If you find the Job you want,
+ you can then select item 3 and enter its JobId(s).
+
\item Item 2 will list all the Jobs where a specified file is saved. If you
- find the Job you want, you can then select item 3 and enter the JobId.
+ find the Job you want, you can then select item 3 and enter the JobId.
+
\item Item 3 allows you the enter a list of comma separated JobIds whose
- files will be put into the directory tree.
+ files will be put into the directory tree. You may then select which
+ files from those JobIds to restore.
+
\item Item 4 allows you to enter any arbitrary SQL command. This is probably
the most primitive way of finding the desired JobIds, but at the same time,
the most flexible. Once you have found the JobId(s), you can select item 3
-and enter them.
+ and enter them.
+
\item Item 5 will automatically select the most recent Full backup and all
- subsequent incremental and differential backups for a specified Client. These
- are the Jobs and Files which if reloaded will restore your system to the most
-current saved state. It automatically enters the JobIds found into the
-directory tree. This is probably the most convenient of all the above options
-to use if you wish to restore a selected Client to its most recent state.
-\item Item 6 allows you to specify a date and time then Bacula will
+ subsequent incremental and differential backups for a specified Client.
+ These are the Jobs and Files which, if reloaded, will restore your
+ system to the most current saved state. It automatically enters the
+ JobIds found into the directory tree. This is probably the most
+ convenient of all the above options to use if you wish to restore a
+ selected Client to its most recent state.
+
+ There are two important things to note. First, this automatic selection
+ will never select a job that failed (terminated with an error status).
+ If you have such a job and want to recover one or more files from it,
+ you will need to explicitly enter the JobId in item 3, then choose the
+ files to restore.
+
+ If some of the Jobs that are needed to do the restore have had their
+ File records pruned, the restore will be incomplete. Bacula currently
+ does not correctly detect this condition. You can however, check for
+ this by looking carefully at the list of Jobs that Bacula selects and
+ prints. If you find Jobs with the JobFiles column set to zero, when
+ files should have been backed up, then you should expect problems.
+
+ If all the File records have been pruned, Bacula will realize that there
+ are no file records in any of the JobIds chosen and will inform you. It
+ will then propose doing a full restore (non-selective) of those JobIds.
+ This is possible because Bacula still knows where the beginning of the
+ Job data is on the Volumes, even if it does not know where particular
+ files are located.
+
+\item Item 6 allows you to specify a date and time, after which Bacula will
automatically select the most recent Full backup and all subsequent
incremental and differential backups that started before the specified date
-and time.
+ and time.
+
\item Item 7 allows you to specify one or more filenames (complete path
required) to be restored. Each filename is entered one at a time or if you
prefix a filename with the less-than symbol (\lt{}) Bacula will read that
-file and assume it is a list of filenames to be restored. The filename entry
-mode is terminated by entering a blank line.
+ file and assume it is a list of filenames to be restored. The filename entry
+ mode is terminated by entering a blank line.
+
\item Item 8 allows you to specify a date and time before entering the
- filenames. See Item 7 above for more details.
-\item Item 9 allows you to cancel the restore command.
- \end{itemize}
+ filenames. See Item 7 above for more details.
+
+\item Item 9 allows you find the JobIds of the most recent backup for
+ a client. This is much like option 5 (it uses the same code), but
+ those JobIds are retained internally as if you had entered them
+ manually. You may then select item 11 (see below) to restore one
+ or more directories.
+
+\item Item 10 is the same as item 9, except that it allows you to enter
+ a before date (as with item 6). These JobIds will then be retained
+ internally.
+
+\index[general]{Restore Directories}
+\item Item 11 allows you to enter a list of JobIds from which you can
+ select directories to be restored. The list of JobIds can have been
+ previously created by using either item 9 or 10 on the menu. You
+ may then enter a full path to a directory name or a filename preceded
+ by a less than sign (\lt{}). The filename should contain a list
+ of directories to be restored. All files in those directories will
+ be restored, but if the directory contains subdirectories, nothing
+ will be restored in the subdirectory unless you explicitly enter its
+ name.
+
+\item Item 12 allows you to cancel the restore command.
+\end{itemize}
As an example, suppose that we select item 5 (restore to most recent state).
It will then ask for the desired Client, which on my system, will print all
\end{verbatim}
\normalsize
-You will probably have fare fewer Clients than this example, and if you have
-only one Client, it will be automatically selected, but in this case, I enter
+You will probably have far fewer Clients than this example, and if you have
+only one Client, it will be automatically selected. In this case, I enter
{\bf Rufus} to select the Client. Then Bacula needs to know what FileSet is
to be restored, so it prompts with:
\footnotesize
\begin{verbatim}
-+-------+------+----------+-------------+-------------+------+-------+------------+
-| JobId | Levl | JobFiles | StartTime | VolumeName | File | SesId | VolSesTime |
-+-------+------+----------+-------------+-------------+------+-------+------------+
-| 1,792 | F | 128,374 | 08-03 01:58 | DLT-19Jul02 | 67 | 18 | 1028042998 |
-| 1,792 | F | 128,374 | 08-03 01:58 | DLT-04Aug02 | 0 | 18 | 1028042998 |
-| 1,797 | I | 254 | 08-04 13:53 | DLT-04Aug02 | 5 | 23 | 1028042998 |
-| 1,798 | I | 15 | 08-05 01:05 | DLT-04Aug02 | 6 | 24 | 1028042998 |
-+-------+------+----------+-------------+-------------+------+-------+------------+
++-------+------+----------+-------------+-------------+------+-------+----------
+--+
+| JobId | Levl | JobFiles | StartTime | VolumeName | File | SesId |
+VolSesTime |
++-------+------+----------+-------------+-------------+------+-------+----------
+--+
+| 1,792 | F | 128,374 | 08-03 01:58 | DLT-19Jul02 | 67 | 18 |
+1028042998 |
+| 1,792 | F | 128,374 | 08-03 01:58 | DLT-04Aug02 | 0 | 18 |
+1028042998 |
+| 1,797 | I | 254 | 08-04 13:53 | DLT-04Aug02 | 5 | 23 |
+1028042998 |
+| 1,798 | I | 15 | 08-05 01:05 | DLT-04Aug02 | 6 | 24 |
+1028042998 |
++-------+------+----------+-------------+-------------+------+-------+----------
+--+
You have selected the following JobId: 1792,1792,1797
Building directory tree for JobId 1792 ...
Building directory tree for JobId 1797 ...
\normalsize
Depending on the number of {\bf JobFiles} for each JobId, the {\bf Building
-directory tree ...``} can take a bit of time.
+directory tree ..."} can take a bit of time. If you notice ath all the
+JobFiles are zero, your Files have probably been pruned and you will not be
+able to select any individual files -- it will be restore everything or
+nothing.
In our example, Bacula found four Jobs that comprise the most recent backup of
the specified Client and FileSet. Two of the Jobs have the same JobId because
Next Bacula entered those Jobs into the directory tree, with no files marked
to be restored as a default, tells you how many files are in the tree, and
-tells you what the current working directory ({\bf cwd}) is /. Finally, Bacula
+tells you that the current working directory ({\bf cwd}) is /. Finally, Bacula
prompts with the dollar sign (\$) to indicate that you may enter commands to
move around the directory tree and to select files.
+
+If you want all the files to automatically be marked when the directory
+tree is built, enter the command {\bf restore all}.
Instead of choosing item 5 on the first menu (Select the most recent backup
for a client), if we had chosen item 3 (Enter list of JobIds to select) and we
had entered the JobIds {\bf 1792,1797,1798} we would have arrived at the same
-point.
+point.
-One point to note if you are manually entering JobIds is that you must enter
+One point to note, if you are manually entering JobIds, is that you must enter
them in the order they were run (generally in increasing JobId order). If you
enter them out of order and the same file was saved in two or more of the
Jobs, you may end up with an old version of that file (i.e. not the most
recent).
+Directly entering the JobIds can also permit you to recover data from
+a Job that wrote files to tape but that terminated with an error status.
+
While in file selection mode, you can enter {\bf help} or a question mark (?)
to produce a summary of the available commands:
\footnotesize
\begin{verbatim}
- Command Description
+ Command Description
======= ===========
cd change current directory
count count marked files in and below the cd
- dir list current directory
+ dir long list current directory, wildcards allowed
done leave file selection mode
estimate estimate restore size
- exit exit = done
- find find files -- wildcards allowed
+ exit same as done command
+ find find files, wildcards allowed
help print help
- ls list current directory -- wildcards allowed
+ ls list current directory, wildcards allowed
lsmark list the marked files in and below the cd
- mark mark file to be restored
- markdir mark directory entry to be restored -- nonrecursive
+ mark mark dir/file to be restored recursively in dirs
+ markdir mark directory name to be restored (no files)
pwd print current working directory
- unmark unmark file to be restored
- unmarkdir unmark directory -- no recursion
- quit quit
+ unmark unmark dir/file to be restored recursively in dir
+ unmarkdir unmark directory name only no recursion
+ quit quit and do not do restore
? print help
-
\end{verbatim}
\normalsize
-As a default no files have been selected for restore. If you want to restore
+As a default no files have been selected for restore (unless you
+added {\bf all} to the command line. If you want to restore
everything, at this point, you should enter {\bf mark *}, and then {\bf done}
and {\bf Bacula} will write the bootstrap records to a file and request your
approval to start a restore job.
If you do not enter the above mentioned {\bf mark *} command, you will start
with an empty slate. Now you can simply start looking at the tree and {\bf
-mark} particular files or directories if you want restored. It is easy to make
+mark} particular files or directories you want restored. It is easy to make
a mistake in specifying a file to mark or unmark, and Bacula's error handling
is not perfect, so please check your work by using the {\bf ls} or {\bf dir}
commands to see what files are actually selected. Any selected file has its
\normalsize
Please examine each of the items very carefully to make sure that they are
-correct. In particular, look at {\bf Where}, which tells you where in the
-directory structure the files will be restored, and {\bf Client}, which tells
-you which client will receive the files. These items will not always be
-completed with the correct values depending on which of the restore options
-you chose.
+correct. In particular, look at {\bf Where}, which tells you where in the
+directory structure the files will be restored, and {\bf Client}, which
+tells you which client will receive the files. Note that by default the
+Client which will receive the files is the Client that was backed up.
+These items will not always be completed with the correct values depending
+on which of the restore options you chose. You can change any of these
+default items by entering {\bf mod} and responding to the prompts.
The above assumes that you have defined a {\bf Restore} Job resource in your
Director's configuration file. Normally, you will only need one Restore Job
originally backed up the files).
Finally before running the job, please note that the default location for
-restoring files is {\bf not} their original locations, rather the directory
+restoring files is {\bf not} their original locations, but rather the directory
{\bf /tmp/bacula-restores}. You can change this default by modifying your {\bf
bacula-dir.conf} file, or you can modify it using the {\bf mod} option. If you
want to restore the files to their original location, you must have {\bf
To select the JobIds, you have the following choices:
1: List last 20 Jobs run
2: List Jobs where a given File is saved
- 3: Enter list of JobIds to select
+ 3: Enter list of comma separated JobIds to select
4: Enter SQL list command
5: Select the most recent backup for a client
6: Select backup for a client before a specified time
7: Enter a list of files to restore
8: Enter a list of files to restore before a specified time
- 9: Cancel
-Select item: (1-9): 7
+ 9: Find the JobIds of the most recent backup for a client
+ 10: Find the JobIds for a backup for a client before a specified time
+ 11: Enter a list of directories to restore for found JobIds
+ 12: Cancel
+Select item: (1-12):
\end{verbatim}
\normalsize
-which then prompts you with for the client name:
+which then prompts you for the client name:
\footnotesize
\begin{verbatim}
If you want Bacula to read the filenames from a file, you simply precede the
filename with a less-than symbol (\lt{}). When you have entered all the
filenames, you enter a blank line, and Bacula will write the bootstrap file,
-tell you what tapes will be used, and propose a Restore job to be run:
+tells you what tapes will be used, and proposes a Restore job to be run:
\footnotesize
\begin{verbatim}
\normalsize
If in modifying the parameters for the Run Restore job, you find that Bacula
-asks you to enter a Job number, this is because you have no yet specified
+asks you to enter a Job number, this is because you have not yet specified
either a Job number or a Bootstrap file. Simply entering zero will allow you
to continue and to select another option to be modified.
\label{CommandArguments}
Incremental saves run before the date you specify. Note, this command is not
too user friendly in that you must specify the date/time exactly as shown.
\item {\bf file=filename} -- specify a filename to be restored. You must
- specify the full path and filename. Prefixing the entry with a less-than sign
+ specify the full path and filename. Prefixing the entry with a less-than
+sign
(\lt{}) will cause Bacula to assume that the filename is on your system and
contains a list of files to be restored. Bacula will thus read the list from
that file. Multiple file=xxx specifications may be specified on the command
\item You are restoring into a directory that is already created and has file
creation restrictions. Bacula tries to reset everything but without walking
up the full chain of directories and modifying them all during the restore,
-which Bacula does and will not do, getting permissions back correctly in this
-situation depends to a large extent on your OS.
+ which Bacula does and will not do, getting permissions back correctly in
+this
+ situation depends to a large extent on your OS.
\item You selected one or more files in a directory, but did not select the
- directory entry to be restored. In that case, if the directory is not on disk
+ directory entry to be restored. In that case, if the directory is not on
+disk
Bacula simply creates the directory with some default attributes which may
-not be the same as the original. If you do not select a directory and all its
-contents to be restored, you can still select items within the directory to
-be restored by individually marking those files, but in that case, you should
-individually use the ''markdir`` command to select all higher level
-directory entries (one at a time) to be restored if you want the directory
-entries properly restored.
+ not be the same as the original. If you do not select a directory and all
+its
+ contents to be restored, you can still select items within the directory to
+ be restored by individually marking those files, but in that case, you
+should
+ individually use the "markdir" command to select all higher level
+ directory entries (one at a time) to be restored if you want the directory
+ entries properly restored.
\end{itemize}
\label{Windows}
\addcontentsline{toc}{subsection}{Restoring on Windows}
If you are restoring on WinNT/2K/XP systems, Bacula will restore the files
-with the original ownerships and permissions as would be expected. This is
+with the original ownerships and permissions as would be expected. This is
also true if you are restoring those files to an alternate directory (using
-the Where option in restore). However, if the alternate directory does not
-already exist, the Bacula File daemon (Client) will create it, and since the
-File daemon runs under the SYSTEM account, the directory will be created with
-SYSTEM ownership and permissions. In this case, you may have problems
-accessing the newly restored files.
-
-To avoid this problem, you can create the alternate directory before doing the
+the Where option in restore). However, if the alternate directory does not
+already exist, the Bacula File daemon (Client) will try to create it. In
+some cases, it may not create the directories, and if it does since the
+File daemon runs under the SYSTEM account, the directory will be created
+with SYSTEM ownership and permissions. In this case, you may have problems
+accessing the newly restored files.
+
+To avoid this problem, you should create any alternate directory before doing
+the
restore. Bacula will not change the ownership and permissions of the directory
if it is already created as long as it is not one of the directories being
restored (i.e. written to tape).
+The default restore location is {\bf /tmp/bacula-restores/} and if you are
+restoring from drive {\bf E:}, the default will be
+{\bf /tmp/bacula-restores/e/}, so you should ensure that this directory
+exists before doing the restore, or use the {\bf mod} option to
+select a different {\bf where} directory that does exist.
+
+Some users have experienced problems restoring files that participate in
+the Active Directory. They also report that changing the userid under which
+Bacula (bacula-fd.exe) runs, from SYSTEM to a Domain Admin userid, resolves
+the problem.
+
+
\subsection*{Restoring Files Can Be Slow}
\index[general]{Slow!Restoring Files Can Be }
\index[general]{Restoring Files Can Be Slow }
\addcontentsline{toc}{subsection}{Restoring Files Can Be Slow}
-Restoring files is generally {\bf much} slower than backing it up for several
+Restoring files is generally {\bf much} slower than backing them up for several
reasons. The first is that during a backup the tape is normally already
-positioned and Bacula need only write. On the other hand, because restoring
-files is done so rarely, Bacula keeps only the he start file and block on the
+positioned and Bacula only needs to write. On the other hand, because restoring
+files is done so rarely, Bacula keeps only the start file and block on the
tape for the whole job rather than on a file by file basis which would use
quite a lot of space in the catalog.
-Bacula versions 1.31a and older would seek to the first file on the first
-tape, then sequentially search the tape for the specified files. If you were
-doing a full restore, this is OK, but if you want to restore one or two files,
-the process could be quite long.
-
-This deficiency has been corrected in version 1.32. The consequence is that
Bacula will forward space to the correct file mark on the tape for the Job,
then forward space to the correct block, and finally sequentially read each
record until it gets to the correct one(s) for the file or files you want to
restore. Once the desired files are restored, Bacula will stop reading the
-tape. For restoring a small number of files, version 1.32 and greater are
-hundreds of times faster than previous versions.
+tape.
Finally, instead of just reading a file for backup, during the restore, Bacula
must create the file, and the operating system must allocate disk space for
the file as Bacula is restoring it.
For all the above reasons the restore process is generally much slower than
-backing up.
+backing up (sometimes it takes three times as long).
\subsection*{Problems Restoring Files}
\index[general]{Files!Problems Restoring }
drive in fixed block mode rather than variable block mode. Fixed block mode
will work with any program that reads tapes sequentially such as tar, but
Bacula repositions the tape on a block basis when restoring files because this
-will speed up the restore by orders of magnitude when only a few files are
-restore. There are several ways that you can attempt to recover from this
+will speed up the restore by orders of magnitude when only a few files are being
+restored. There are several ways that you can attempt to recover from this
unfortunate situation.
-Try the following things each separately, and reset your Device resource to
+Try the following things, each separately, and reset your Device resource to
what it is now after each individual test:
\begin{enumerate}
-\item Set ''Block Positioning = no`` in your Device resource and try the
+\item Set "Block Positioning = no" in your Device resource and try the
restore. This is a new directive and untested.
-\item Set ''Minimum Block Size = 512`` and ''Maximum Block Size = 512`` and
- try the restore. Again send me the full job report output. If you are able to
+\item Set "Minimum Block Size = 512" and "Maximum Block Size = 512" and
+ try the restore. Again send me the full job report output. If you are able
+ to
determine the block size your drive was previously using, you should try
-that size if 512 does not work.
+ that size if 512 does not work.
\item Try editing the restore.bsr file at the Run xxx yes/mod/no prompt
- before starting the restore job and remove all the VolBlock statements. These
+ before starting the restore job and remove all the VolBlock statements.
+ These
are what causes Bacula to reposition the tape, and where problems occur if
-you have a fixed block size set for your drive. The VolFile commands also
-cause repositioning, but this will work regardless of the block size.
+ you have a fixed block size set for your drive. The VolFile commands also
+ cause repositioning, but this will work regardless of the block size.
\item Use bextract to extract the files you want -- it reads the Volume
sequentially if you use the include list feature, or if you use a .bsr file,
- but remove all the VolBlock statements after the .bsr file is created (at the
-Run yes/mod/no) prompt but before you start the restore.
+ but remove all the VolBlock statements after the .bsr file is created (at
+ the
+ Run yes/mod/no) prompt but before you start the restore.
\end{enumerate}
\subsection*{Example Restore Job Resource}
\begin{description}
\item [cd]
- The {\bf cd} command changes the current directory to the argument specified.
+ The {\bf cd} command changes the current directory to the argument
+ specified.
It operates much like the Unix {\bf cd} command. Wildcard specifications are
-not permitted.
+ not permitted.
-Note, on Windows systems, the various drives (c:, d:, ...) are treated like a
-directory within the file tree while in the file selection mode. As a
-consequence, you must do a {\bf cd c:} or possibly in some cases a {\bf cd
-C:} (note upper case) to get down to the first directory.
+ Note, on Windows systems, the various drives (c:, d:, ...) are treated like
+ a
+ directory within the file tree while in the file selection mode. As a
+ consequence, you must do a {\bf cd c:} or possibly in some cases a {\bf cd
+ C:} (note upper case) to get down to the first directory.
\item [dir]
\index[dir]{dir }
The {\bf dir} command is similar to the {\bf ls} command, except that it
-prints it in long format (all details). This command can be a bit slower than
-the {\bf ls} command because it must access the catalog database for the
-detailed information for each file.
+ prints it in long format (all details). This command can be a bit slower
+ than
+ the {\bf ls} command because it must access the catalog database for the
+ detailed information for each file.
\item [estimate]
\index[dir]{estimate }
The {\bf estimate} command prints a summary of the total files in the tree,
-how many are marked to be restored, and an estimate of the number of bytes to
-be restored. This can be useful if you are short on disk space on the machine
-where the files will be restored.
+ how many are marked to be restored, and an estimate of the number of bytes
+ to
+ be restored. This can be useful if you are short on disk space on the
+ machine
+ where the files will be restored.
\item [find]
\index[dir]{find }
The {\bf find} command accepts one or more arguments and displays all files
-in the tree that match that argument. The argument may have wildcards. It is
-somewhat similar to the Unix command {\bf find / -name arg}.
+ in the tree that match that argument. The argument may have wildcards. It is
+ somewhat similar to the Unix command {\bf find / -name arg}.
\item [ls]
The {\bf ls} command produces a listing of all the files contained in the
current directory much like the Unix {\bf ls} command. You may specify an
-argument containing wildcards, in which case only those files will be listed.
-Any file that is marked to be restored will have its name preceded by an
-asterisk ({\bf *}). Directory names will be terminated with a forward slash
-({\bf /}) to distinguish them from filenames.
+ argument containing wildcards, in which case only those files will be
+listed.
+ Any file that is marked to be restored will have its name preceded by an
+ asterisk ({\bf *}). Directory names will be terminated with a forward slash
+ ({\bf /}) to distinguish them from filenames.
\item [lsmark]
\index[fd]{lsmark }
The {\bf lsmark} command is the same as the {\bf ls} except that it will
-print only those files marked for extraction. The other distinction is that
-it will recursively descend into any directory selected.
+ print only those files marked for extraction. The other distinction is that
+ it will recursively descend into any directory selected.
\item [mark]
\index[dir]{mark }
- The {\bf mark} command allows you to mark files to be restored. It takes a
-single argument which is the filename or directory name in the current
-directory to be marked for extraction. The argument may be a wildcard
-specification, in which case all files that match in the current directory
-are marked to be restored. If the argument matches a directory rather than a
-file, then the directory and all files contained in that directory
-(recursively) are marked to be restored. Any marked file will have its name
-preceded with an asterisk ({\bf *}) in the output produced by the {\bf ls} or
-{\bf dir} commands. Note, supplying a full path on the mark command does not
-work as expected to select a file or directory in the current directory.
-Also, the {\bf mark} command works on the current and lower directories but
-does not touch higher level directories.
-
-After executing the {\bf mark} command, it will print a brief summary:
+ The {\bf mark} command allows you to mark files to be restored. It takes a
+ single argument which is the filename or directory name in the current
+ directory to be marked for extraction. The argument may be a wildcard
+ specification, in which case all files that match in the current directory
+ are marked to be restored. If the argument matches a directory rather than a
+ file, then the directory and all the files contained in that directory
+ (recursively) are marked to be restored. Any marked file will have its name
+ preceded with an asterisk ({\bf *}) in the output produced by the {\bf ls}
+or
+ {\bf dir} commands. Note, supplying a full path on the mark command does not
+ work as expected to select a file or directory in the current directory.
+ Also, the {\bf mark} command works on the current and lower directories but
+ does not touch higher level directories.
+
+ After executing the {\bf mark} command, it will print a brief summary:
\footnotesize
\begin{verbatim}
\end{verbatim}
\normalsize
-If no files were marked, or:
+ If no files were marked, or:
\footnotesize
\begin{verbatim}
\end{verbatim}
\normalsize
-if some files are marked.
+ if some files are marked.
\item [unmark]
\index[dir]{unmark }
The {\bf unmark} is identical to the {\bf mark} command, except that it
-unmarks the specified file or files so that they will not be restored. Note:
-the {\bf unmark} command works from the current directory, so it does not
-unmark any files at a higher level. First do a {\bf cd /} before the {\bf
-unmark *} command if you want to unmark everything.
+ unmarks the specified file or files so that they will not be restored. Note:
+ the {\bf unmark} command works from the current directory, so it does not
+ unmark any files at a higher level. First do a {\bf cd /} before the {\bf
+ unmark *} command if you want to unmark everything.
\item [pwd]
\index[dir]{pwd }
The {\bf pwd} command prints the current working directory. It accepts no
-arguments.
+ arguments.
\item [count]
\index[dir]{count }
The {\bf count} command prints the total files in the directory tree and the
-number of files marked to be restored.
+ number of files marked to be restored.
\item [done]
\index[dir]{done }
\item [quit]
\index[fd]{quit }
- This command terminates the file selection and does not run the restore job.
+ This command terminates the file selection and does not run the restore
+job.
\item [help]
\item [?]
This command is the same as the {\bf help} command.
- \end{description}
+\end{description}
+
+\subsection*{Restoring When Things Go Wrong}
+\index[general]{Restoring When Things Go Wrong }
+\addcontentsline{toc}{subsection}{Restoring When Things Go Wrong}
+
+This and the following sections will try to present a few of the kinds of
+problems that can come up making restoring more difficult. I'll try to
+provide a few ideas how to get out of these problem situations.
+
+\begin{description}
+\item [Problem]
+ Your catalog has been damaged and Bacula either doesn't work or prints
+ errors.
+\item[Solution]
+ For SQLite, use the vacuum command to try to fix the database. For either
+ MySQL or PostgreSQL, see the vendor's documentation. They have specific tools
+ that check and repair databases.
+
+ Assuming the above does not resolve the problem, you will need to restore
+ or rebuild your catalog.
+\item[Problem]
+ How do I restore my catalog?
+\item[Solution]
+ If you have backed up your database nightly (as you should) and you
+ have made a bootstrap file, you can immediately load back your
+ database (or the ASCII SQL output). Make a copy of your current
+ database, then re-initialize it, by running the following scripts:
+\begin{verbatim}
+ ./drop_bacula_tables
+ ./make_bacula_tables
+\end{verbatim}
+ After re-initializing the database, you should be able to run
+ Bacula. If you now try to use the restore command, it will not
+ work because the database will be empty. However, you can manually
+ run a restore job and specify your bootstrap file. You do so
+ by entering the {bf run} command in the console and selecting the
+ restore job. If you are using the default bacula-dir.conf, this
+ Job will be named {\bf RestoreFiles}. Most likely it will prompt
+ you with something such as:
+\footnotesize
+\begin{verbatim}
+Run Restore job
+JobName: RestoreFiles
+Bootstrap: /home/kern/bacula/working/restore.bsr
+Where: /tmp/bacula-restores
+Replace: always
+FileSet: Full Set
+Client: rufus-fd
+Storage: File
+When: 2005-07-10 17:33:40
+Catalog: MyCatalog
+Priority: 10
+OK to run? (yes/mod/no):
+\end{verbatim}
+\normalsize
+ A number of the items will be different in your case. What you want
+ to do is: to use the mod option to change the Bootstrap to point to
+ your saved bootstrap file; and to make sure all the other items
+ such as Client, Storage, Catalog, and Where are correct. The
+ FileSet is not used when you specify a bootstrap file.
+ Once you have set all the correct values, run the Job and
+ it will restore the backup of your database. You will then
+ need to follow the instructions for your database type to
+ recreate the database from the ASCII backup file.
+
+
+\item[Solution]
+ If you did save your database but did not make a bootstrap file, then
+ recovering the database
+ is more difficult. You will probably need to use bextract to extract the
+ backup copy.
+ First you should locate the listing of the job report from the last catalog
+ backup. It has important information that will allow you to quickly find
+ your database file. For example, in the job report for the CatalogBackup
+ shown below, the critical items are the Volume name(s), the Volume Session Id
+ and the Volume Session Time. If you know those, you can easily restore your
+ Catalog.
+\footnotesize
+\begin{verbatim}
+
+22-Apr 10:22 HeadMan: Start Backup JobId 7510,
+Job=CatalogBackup.2005-04-22_01.10.0
+22-Apr 10:23 HeadMan: Bacula 1.37.14 (21Apr05): 22-Apr-2005 10:23:06
+ JobId: 7510
+ Job: CatalogBackup.2005-04-22_01.10.00
+ Backup Level: Full
+ Client: Polymatou
+ FileSet: "CatalogFile" 2003-04-10 01:24:01
+ Pool: "Default"
+ Storage: "DLTDrive"
+ Start time: 22-Apr-2005 10:21:00
+ End time: 22-Apr-2005 10:23:06
+ FD Files Written: 1
+ SD Files Written: 1
+ FD Bytes Written: 210,739,395
+ SD Bytes Written: 210,739,521
+ Rate: 1672.5 KB/s
+ Software Compression: None
+ Volume name(s): DLT-22Apr05
+ Volume Session Id: 11
+ Volume Session Time: 1114075126
+ Last Volume Bytes: 1,428,240,465
+ Non-fatal FD errors: 0
+ SD Errors: 0
+ FD termination status: OK
+ SD termination status: OK
+ Termination: Backup OK
+
+\end{verbatim}
+\normalsize
+ From the above information, you can manually create a bootstrap file,
+ and then follow the instructions given above for restoring your database.
+ A reconstructed bootstrap file for the above backup Job would look
+ like the following:
+\footnotesize
+\begin{verbatim}
+Volume="DLT-22Apr05"
+VolSessionId=11
+VolSessionTime=1114075126
+FileIndex=1-1
+\end{verbatim}
+\normalsize
+ Where we have inserted the Volume name, Volume Session Id, and Volume Session
+Time that
+ correspond to the values in the job report. We've also used a FileIndex of
+one,
+ which will always be the case providing that there was only one file
+ backed up in the job.
+
+ The disadvantage of this bootstrap file compared to what is created when you
+ ask for one to be written, is that there is no File and Block specified, so
+ the restore code must search all data in the Volume to find the requested
+ file. A fully specified bootstrap file would have the File and Blocks
+specified
+ as follows:
+\footnotesize
+\begin{verbatim}
+Volume="DLT-22Apr05"
+VolSessionId=11
+VolSessionTime=1114075126
+VolFile=118-118
+VolBlock=0-4053
+FileIndex=1-1
+\end{verbatim}
+\normalsize
+\item [Problem]
+ You don't have a bootstrap file, and you don't have the Job report for
+ the backup of your database, but you did backup the database, and you
+ know the Volume to which it was backed up.
+
+\item [Solution]
+ Use {\bf bls} to indicate where it is on the tape. For example:
+
+\footnotesize
+\begin{verbatim}
+./bls -j -V DLT-22Apr05 /dev/nst0
+\end{verbatim}
+\normalsize
+ Might produce the following output:
+\footnotesize
+\begin{verbatim}
+bls: butil.c:258 Using device: "/dev/nst0" for reading.
+21-Jul 18:34 bls: Ready to read from volume "DLT-22Apr05" on device "DLTDrive"
+(/dev/nst0).
+Volume Record: File:blk=0:0 SessId=11 SessTime=1114075126 JobId=0 DataLen=164
+...
+Begin Job Session Record: File:blk=118:0 SessId=11 SessTime=1114075126
+JobId=7510
+ Job=CatalogBackup.2005-04-22_01.10.0 Date=22-Apr-2005 10:21:00 Level=F Type=B
+End Job Session Record: File:blk=118:4053 SessId=11 SessTime=1114075126
+JobId=7510
+ Date=22-Apr-2005 10:23:06 Level=F Type=B Files=1 Bytes=210,739,395 Errors=0
+Status=T
+...
+21-Jul 18:34 bls: End of Volume at file 201 on device "DLTDrive" (/dev/nst0),
+Volume "DLT-22Apr05"
+21-Jul 18:34 bls: End of all volumes.
+\end{verbatim}
+\normalsize
+ Of course, there will be many more records printed, but we have indicated
+ the essential lines of output. From the information on the Begin Job and End
+ Job Session Records, you can reconstruct a bootstrap file such as the one
+ shown above.
+
+\item[Problem]
+ How can I find where a file is stored.
+\item[Solution]
+ Normally, it is not necessary, you just use the {\bf restore} command to
+restore the
+ most recently saved version (menu option 5), or a version saved before a given
+date (menu
+ option 8). If you know the JobId of the job in which it was saved, you can
+use menu
+ option 3 to enter that JobId.
+
+ If you would like to know the JobId where a file was saved, select restore
+menu option
+ 2.
+
+ You can also use the {\bf query} command to find information such as:
+\footnotesize
+\begin{verbatim}
+*query
+Available queries:
+ 1: List Job totals:
+ 2: List up to 20 places where a File is saved regardless of the directory:
+ 3: List where the most recent copies of a file are saved:
+ 4: List last 20 Full Backups for a Client:
+ 5: List all backups for a Client after a specified time
+ 6: List all backups for a Client
+ 7: List Volume Attributes for a selected Volume:
+ 8: List Volumes used by selected JobId:
+ 9: List Volumes to Restore All Files:
+ 10: List Pool Attributes for a selected Pool:
+ 11: List total files/bytes by Job:
+ 12: List total files/bytes by Volume:
+ 13: List Files for a selected JobId:
+ 14: List Jobs stored in a selected MediaId:
+ 15: List Jobs stored for a given Volume name:
+Choose a query (1-15):
+\end{verbatim}
+\normalsize
+
+\end{description}
7.x (rh7), RedHat 8.0 (rh8), RedHat 9 (rh9), Fedora Core (fc1), Whitebox
Enterprise Linux (RHEL) 3.0 (wb3), Mandrake 10.x (mdk) and SuSE 9.x (su9).
The package build is controlled by a mandatory define set at the beginning of
-the file. These defines basically just control the dependancy information that
+the file. These defines basically just control the dependency information that
gets coded into the finished rpm package.
The platform define may be edited in the spec file directly (by default all
-defines are set to 0 or ``not set''). For example, to build the RedHat 7.x
+defines are set to 0 or "not set"). For example, to build the RedHat 7.x
package find the line in the spec file which reads
\footnotesize
a regular user but you must make a few changes on your system to do this. If
you are building on your own system then the simplest method is to add write
permissions for all to the build directory (/usr/src/redhat/). To accomplish
-this execute the following command as root:
+this, execute the following command as root:
\footnotesize
\begin{verbatim}
\normalsize
If you are working on a shared system where you can not use the method above
-then you need to recreate the /usr/src/redhat directory tree with all of it's
+then you need to recreate the /usr/src/redhat directory tree with all of its
subdirectories inside your home directory. Then create a file named {\tt
.rpmmacros} in your home directory (or edit the file if it already exists)
and add the following line:
\item
\label{faq5}
{\bf I'm building my own rpms but on all platforms and compiles I get an
-unresolved dependancy for something called /usr/afsws/bin/pagsh.}
+unresolved dependency for something called /usr/afsws/bin/pagsh.}
This is a shell from the OpenAFS (Andrew File System). If you are seeing this
then you chose to include the docs/examples directory in your package. One of
the example scripts in this directory is a pagsh script. Rpmbuild, when
-scanning for dependancies, looks at the shebang line of all packaged scripts
+scanning for dependencies, looks at the shebang line of all packaged scripts
in addition to checking shared libraries. To avoid this do not package the
examples directory.
\end{enumerate}
+
+\item {\bf Support for RHEL4, CentOS 4 and x86_64}
+The examples below
+explicit build support for RHEL4 (I think) and CentOS 4. Build support
+for x86_64 has also been added. Test builds have been done on CentOS but
+not RHEL4.
+
+\footnotesize
+\begin{verbatim}
+Build with one of these 3 commands:
+
+rpmbuild --rebuild \
+ --define "build_rhel4 1" \
+ --define "build_sqlite 1" \
+ bacula-1.36.2-4.src.rpm
+
+rpmbuild --rebuild \
+ --define "build_rhel4 1" \
+ --define "build_postgresql 1" \
+ bacula-1.36.2-4.src.rpm
+
+rpmbuild --rebuild \
+ --define "build_rhel4 1" \
+ --define "build_mysql 1" \
+ --define "build_mysql4 1" \
+ bacula-1.36.2-4.src.rpm
+
+For CentOS substitute '--define "build_centos4 1"' in place of rhel4.
+
+For 64 bit support add '--define "build_x86_64 1"'
+\end{verbatim}
+\normalsize
+
+\subsection*{Build Options}
+\index[general]{Build Options}
+\addcontentsline{toc}{subsection}{Build Options}
+The spec file currently supports building on the following platforms:
+\footnotesize
+\begin{verbatim}
+# RedHat builds
+--define "build_rh8 1"
+--define "build_rh9 1"
+
+# Fedora Core build
+--define "build_fc1 1"
+--define "build_fc3 1"
+
+# Whitebox Enterprise build
+--define "build_wb3 1"
+
+# RedHat Enterprise builds
+--define "build_rhel3 1"
+--define "build_rhel4 1"
+
+# CentOS build
+--define "build_centos4 1"
+
+# SuSE build
+--define "build_su9 1"
+
+# Mandrake build
+--define "build_mdk 1"
+
+MySQL support:
+
+--define "build_mysql 1"
+# if using mysql 4.x define this and mysql above
+# currently: Mandrake 10.x, SuSE 9.x, RHEL4
+--define "build_mysql4 1"
+
+PostgreSQL support:
+--define "build_postgresql 1"
+
+Sqlite support:
+--define "build_sqlite 1"
+
+\end{verbatim}
+\normalsize
+
+
\item It can take a long time for data to come in from the File daemon during
an Incremental backup. If it is directly written to tape, the tape will start
and stop or shoe-shine as it is often called causing tape wear. By first
-writing the data to disk, then writing it to tape, the tape can be kept in
-continual motion.
+ writing the data to disk, then writing it to tape, the tape can be kept in
+ continual motion.
\item While the spooled data is being written to the tape, the despooling
process has exclusive use of the tape. This means that you can spool multiple
simultaneous jobs to disk, then have them very efficiently despooled one at a
-time without having the data blocks from several jobs intermingled, thus
-substantially improving the time needed to restore files.
+ time without having the data blocks from several jobs intermingled, thus
+ substantially improving the time needed to restore files.
\item Writing to a tape can be slow. By first spooling your data to disk, you
can often reduce the time the File daemon is running on a system, thus
reducing downtime, and/or interference with users.
\end{itemize}
-Data spooling is exactly that ``spooling''. It is not a way to first write a
-``backup'' to a disk file and then to a tape. When the backup spooled to disk,
-it is not complete and cannot be restored until it is written to tape. In a
+Data spooling is exactly that "spooling". It is not a way to first write a
+"backup" to a disk file and then to a tape. When the backup has only been spooled to disk,
+it is not complete yet and cannot be restored until it is written to tape. In a
future version, Bacula will support writing a backup to disk then later {\bf
Migrating} or {\bf Copying} it to a tape.
the Director's conf file (default {\bf no}).
{\bf SpoolData = yes|no}
+
\item To override the Job specification in a Schedule Run directive in the
Director's conf file.
{\bf SpoolData = yes|no}
+
\item To limit the maximum total size of the spooled data for a particular
device. Specified in the Device resource of the Storage daemon's conf file
(default unlimited).
{\bf Maximum Spool Size = size}
+ Where size is a the maximum spool size for all jobs specified in bytes.
-Where size is a the maximum spool size for all jobs specified in bytes.
\item To limit the maximum total size of the spooled data for a particular
device for a single job. Specified in the Device Resource of the Storage
daemon's conf file (default unlimited).
{\bf Maximum Job Spool Size = size}
+ Where size is the maximum spool file size for a single job specified in
+ bytes.
-Where size is the maximum spool file size for a single job specified in
-bytes.
\item To specify the spool directory for a particular device. Specified in
the Device Resource of the Storage daemon's conf file (default, the working
directory).
otherwise, your job will write enormous amounts of data to the Volume, and
most probably terminate in error. This is because in attempting to backup the
spool file, the backup data will be written a second time to the spool file,
-and so on ad infinum.
+and so on ad infinitum.
Another advice is to always specify the maximum spool size so that your disk
doesn't completely fill up. In principle, data spooling will properly detect a
full disk, and despool data allowing the job to continue. However, attribute
spooling is not so kind to the user. If the disk on which attributes are being
-spooled fills, the job will be canceled.
-\label{points}
+spooled fills, the job will be canceled. In addition, if your working
+directory is on the same partition as the spool directory, then Bacula jobs
+will fail possibly in bizarre ways when the spool fills.
+\label{points}
\subsection*{Other Points}
\index[general]{Points!Other }
\index[general]{Other Points }
\item When data spooling is enabled, Bacula automatically turns on attribute
spooling. In other words, it also spools the catalog entries to disk. This is
done so that in case the job fails, there will be no catalog entries
-pointing to non-existent tape backups.
+ pointing to non-existent tape backups.
\item Attribute despooling is done at the end of the job, as a consequence,
after Bacula stops writing the data to the tape, there may be a pause while
the attributes are sent to the Directory and entered into the catalog before
-the job terminates.
+ the job terminates.
\item Attribute spool files are always placed in the working directory.
\item When Bacula begins despooling data spooled to disk, it takes exclusive
use of the tape. This has the major advantage that in running multiple
simultaneous jobs at the same time, the blocks of several jobs will not be
-intermingled.
+ intermingled.
\item It probably does not make a lot of sense to enable data spooling if you
are writing to disk files.
\item It is probably best to provide as large a spool file as possible to
avoid repeatedly spooling/despooling. Also, while a job is despooling to
tape, the File daemon must wait (i.e. spooling stops for the job while it is
-despooling).
+ despooling).
\item If you are running multiple simultaneous jobs, Bacula will continue
spooling other jobs while one is despooling to tape, provided there is
sufficient spool file space.
\addcontentsline{toc}{subsection}{Installing and Configuring SQLite -- Phase
I}
-If you use the {\bf ./configure \verb{--{with-sqlite} statement for configuring {\bf
-Bacula}, you will need SQLite version 2.2.3 or later installed. Our standard
+If you use the {\bf ./configure \verb:--:with-sqlite} statement for configuring {\bf
+Bacula}, you will need SQLite version 2.8.16 or later installed. Our standard
location (for the moment) for SQLite is in the dependency package {\bf
-depkgs/sqlite-2.2.3}. Please note that the version will be updated as new
+depkgs/sqlite-2.8.16}. Please note that the version will be updated as new
versions are available and tested.
+You may install and use SQLite version 3.x with Bacula by using:
+{\bf ./configure \verb:--:with-sqlite3}. You should ensure that
+when the database is created that you have used
+\begin{verbatim}
+PRAGMA synchronous = NORMAL;
+\end{verbatim}
+otherwiset SQLite version 3.x is 4 to 10 times slower than version 2.8.16.
+
Installing and Configuring is quite easy.
\begin{enumerate}
{\bf tar xvfz depkgs.tar.gz}
-Note, the above command requires GNU tar. If you do not have GNU tar, a
-command such as:
+ Note, the above command requires GNU tar. If you do not have GNU tar, a
+ command such as:
-{\bf zcat depkgs.tar.gz | tar xvf -}
+ {\bf zcat depkgs.tar.gz | tar xvf -}
-will probably accomplish the same thing.
+ will probably accomplish the same thing.
\item {\bf cd depkgs}
\item {\bf make sqlite}
- \end{enumerate}
+\end{enumerate}
At this point, you should return to completing the installation of {\bf
Bacula}.
Please note that the {\bf ./configure} used to build {\bf Bacula} will need to
-include {\bf \verb{--{with-sqlite}.
+include {\bf \verb:--:with-sqlite}.
\subsection*{Installing and Configuring SQLite -- Phase II}
\label{phase2}
\item ./make\_sqlite\_tables
This script creates the SQLite database as well as the tables used by {\bf
-Bacula}. This script will be automatically setup by the {\bf ./configure}
-program to create a database named {\bf bacula.db} in {\bf Bacula's} working
-directory.
+ Bacula}. This script will be automatically setup by the {\bf ./configure}
+ program to create a database named {\bf bacula.db} in {\bf Bacula's} working
+ directory.
\end{enumerate}
\subsection*{Linking Bacula with SQLite}
\index[general]{Testing SQLite }
\addcontentsline{toc}{subsection}{Testing SQLite}
-As of this date (20 March 2002), we have much less ``production'' experience
-using SQLite than using MySQL. That said, we should note that SQLite has
-performed flawlessly for us in all our testing.
+We have much less "production" experience
+using SQLite than using MySQL. SQLite has
+performed flawlessly for us in all our testing. However,
+several users have reported corrupted databases while using
+SQLite. For that reason, we do not recommend it for production
+use.
+
+If Bacula crashes with the following type of error when it is started:
+\footnotesize
+\begin{verbatim}
+Using default Catalog name=MyCatalog DB=bacula
+Could not open database "bacula".
+sqlite.c:151 Unable to open Database=/var/lib/bacula/bacula.db.
+ERR=malformed database schema - unable to open a temporary database file
+for storing temporary tables
+\end{verbatim}
+\normalsize
+
+this is most likely caused by the fact that some versions of
+SQLite attempt to create a temporary file in the current directory.
+If that fails, because Bacula does not have write permission on
+the current directory, then you may get this errr. The solution is
+to start Bacula in a current directory where it has write permission.
+
\subsection*{Re-initializing the Catalog Database}
\index[general]{Database!Re-initializing the Catalog }
\normalsize
Please note that all information in the database will be lost and you will be
-starting from scratch. If you have written on any Volumes, you must write and
+starting from scratch. If you have written on any Volumes, you must write an
end of file mark on the volume so that Bacula can reuse it. Do so with:
\footnotesize
+++ /dev/null
-%%
-%%
-
-\section*{Storage Daemon Design}
-\label{_ChapterStart3}
-\index{Storage Daemon Design }
-\index{Design!Storage Daemon }
-\addcontentsline{toc}{section}{Storage Daemon Design}
-
-This chapter is intended to be a technical discussion of the Storage daemon
-services and as such is not targeted at end users but rather at developers and
-system administrators that want or need to know more of the working details of
-{\bf Bacula}.
-
-\subsection*{SD Design Introduction}
-\index{Introduction!SD Design }
-\index{SD Design Introduction }
-\addcontentsline{toc}{subsection}{SD Design Introduction}
-
-The Bacula Storage daemon provides storage resources to a Bacula installation.
-An individual Storage daemon is associated with a physical permanent storage
-device (for example, a tape drive, CD writer, tape changer or jukebox, etc.),
-and may employ auxiliary storage resources (such as space on a hard disk file
-system) to increase performance and/or optimize use of the permanent storage
-medium.
-
-Any number of storage daemons may be run on a given machine; each associated
-with an individual storage device connected to it, and BACULA operations may
-employ storage daemons on any number of hosts connected by a network, local or
-remote. The ability to employ remote storage daemons (with appropriate
-security measures) permits automatic off-site backup, possibly to publicly
-available backup repositories.
-
-\subsection*{SD Development Outline}
-\index{Outline!SD Development }
-\index{SD Development Outline }
-\addcontentsline{toc}{subsection}{SD Development Outline}
-
-In order to provide a high performance backup and restore solution that scales
-to very large capacity devices and networks, the storage daemon must be able
-to extract as much performance from the storage device and network with which
-it interacts. In order to accomplish this, storage daemons will eventually
-have to sacrifice simplicity and painless portability in favor of techniques
-which improve performance. My goal in designing the storage daemon protocol
-and developing the initial prototype storage daemon is to provide for these
-additions in the future, while implementing an initial storage daemon which is
-very simple and portable to almost any POSIX-like environment. This original
-storage daemon (and its evolved descendants) can serve as a portable solution
-for non-demanding backup requirements (such as single servers of modest size,
-individual machines, or small local networks), while serving as the starting
-point for development of higher performance configurable derivatives which use
-techniques such as POSIX threads, shared memory, asynchronous I/O, buffering
-to high-speed intermediate media, and support for tape changers and jukeboxes.
-
-
-\subsection*{SD Connections and Sessions}
-\index{Sessions!SD Connections and }
-\index{SD Connections and Sessions }
-\addcontentsline{toc}{subsection}{SD Connections and Sessions}
-
-A client connects to a storage server by initiating a conventional TCP
-connection. The storage server accepts the connection unless its maximum
-number of connections has been reached or the specified host is not granted
-access to the storage server. Once a connection has been opened, the client
-may make any number of Query requests, and/or initiate (if permitted), one or
-more Append sessions (which transmit data to be stored by the storage daemon)
-and/or Read sessions (which retrieve data from the storage daemon).
-
-Most requests and replies sent across the connection are simple ASCII strings,
-with status replies prefixed by a four digit status code for easier parsing.
-Binary data appear in blocks stored and retrieved from the storage. Any
-request may result in a single-line status reply of ``{\tt 3201\ Notification\
-pending}'', which indicates the client must send a ``Query notification''
-request to retrieve one or more notifications posted to it. Once the
-notifications have been returned, the client may then resubmit the request
-which resulted in the 3201 status.
-
-The following descriptions omit common error codes, yet to be defined, which
-can occur from most or many requests due to events like media errors,
-restarting of the storage daemon, etc. These details will be filled in, along
-with a comprehensive list of status codes along with which requests can
-produce them in an update to this document.
-
-\subsubsection*{SD Append Requests}
-\index{Requests!SD Append }
-\index{SD Append Requests }
-\addcontentsline{toc}{subsubsection}{SD Append Requests}
-
-\begin{description}
-
-\item [{append open session = \lt{}JobId\gt{} [ \lt{}Password\gt{} ] }]
- \index{SPAN class }
- A data append session is opened with the Job ID given by {\it JobId} with
-client password (if required) given by {\it Password}. If the session is
-successfully opened, a status of {\tt 3000\ OK} is returned with a ``{\tt
-ticket\ =\ }{\it number}'' reply used to identify subsequent messages in the
-session. If too many sessions are open, or a conflicting session (for
-example, a read in progress when simultaneous read and append sessions are
-not permitted), a status of ``{\tt 3502\ Volume\ busy}'' is returned. If no
-volume is mounted, or the volume mounted cannot be appended to, a status of
-``{\tt 3503\ Volume\ not\ mounted}'' is returned.
-
-\item [append data = \lt{}ticket-number\gt{} ]
- \index{SPAN class }
- If the append data is accepted, a status of {\tt 3000\ OK data address =
-\lt{}IPaddress\gt{} port = \lt{}port\gt{}} is returned, where the {\tt
-IPaddress} and {\tt port} specify the IP address and port number of the data
-channel. Error status codes are {\tt 3504\ Invalid\ ticket\ number} and {\tt
-3505\ Session\ aborted}, the latter of which indicates the entire append
-session has failed due to a daemon or media error.
-
-Once the File daemon has established the connection to the data channel
-opened by the Storage daemon, it will transfer a header packet followed by
-any number of data packets. The header packet is of the form:
-
-{\tt \lt{}file-index\gt{} \lt{}stream-id\gt{} \lt{}info\gt{}}
-
-The details are specified in the
-\ilink{Daemon Protocol}{_ChapterStart2} section of this
-document.
-
-\item [*append abort session = \lt{}ticket-number\gt{} ]
- \index{SPAN class }
- The open append session with ticket {\it ticket-number} is aborted; any blocks
-not yet written to permanent media are discarded. Subsequent attempts to
-append data to the session will receive an error status of {\tt 3505\
-Session\ aborted}.
-
-\item [append end session = \lt{}ticket-number\gt{} ]
- \index{SPAN class }
- The open append session with ticket {\it ticket-number} is marked complete; no
-further blocks may be appended. The storage daemon will give priority to
-saving any buffered blocks from this session to permanent media as soon as
-possible.
-
-\item [append close session = \lt{}ticket-number\gt{} ]
- \index{SPAN class }
- The append session with ticket {\it ticket} is closed. This message does not
-receive an {\tt 3000\ OK} reply until all of the content of the session are
-stored on permanent media, at which time said reply is given, followed by a
-list of volumes, from first to last, which contain blocks from the session,
-along with the first and last file and block on each containing session data
-and the volume session key identifying data from that session in lines with
-the following format:
-
-{\tt {\tt Volume = }\lt{}Volume-id\gt{} \lt{}start-file\gt{}
-\lt{}start-block\gt{} \lt{}end-file\gt{} \lt{}end-block\gt{}
-\lt{}volume-session-id\gt{}}where {\it Volume-id} is the volume label, {\it
-start-file} and {\it start-block} are the file and block containing the first
-data from that session on the volume, {\it end-file} and {\it end-block} are
-the file and block with the last data from the session on the volume and {\it
-volume-session-id} is the volume session ID for blocks from the session
-stored on that volume.
-\end{description}
-
-\subsubsection*{SD Read Requests}
-\index{SD Read Requests }
-\index{Requests!SD Read }
-\addcontentsline{toc}{subsubsection}{SD Read Requests}
-
-\begin{description}
-
-\item [Read open session = \lt{}JobId\gt{} \lt{}Volume-id\gt{}
- \lt{}start-file\gt{} \lt{}start-block\gt{} \lt{}end-file\gt{}
- \lt{}end-block\gt{} \lt{}volume-session-id\gt{} \lt{}password\gt{} ]
-\index{SPAN class }
-where {\it Volume-id} is the volume label, {\it start-file} and {\it
-start-block} are the file and block containing the first data from that
-session on the volume, {\it end-file} and {\it end-block} are the file and
-block with the last data from the session on the volume and {\it
-volume-session-id} is the volume session ID for blocks from the session
-stored on that volume.
-
-If the session is successfully opened, a status of
-
-{\tt {\tt 3100\ OK Ticket\ =\ }{\it number}``}
-
-is returned with a reply used to identify subsequent messages in the session.
-If too many sessions are open, or a conflicting session (for example, an
-append in progress when simultaneous read and append sessions are not
-permitted), a status of ''{\tt 3502\ Volume\ busy}`` is returned. If no
-volume is mounted, or the volume mounted cannot be appended to, a status of
-''{\tt 3503\ Volume\ not\ mounted}`` is returned. If no block with the given
-volume session ID and the correct client ID number appears in the given first
-file and block for the volume, a status of ''{\tt 3505\ Session\ not\
-found}`` is returned.
-
-\item [Read data = \lt{}Ticket\gt{} \gt{} \lt{}Block\gt{} ]
- \index{SPAN class }
- The specified Block of data from open read session with the specified Ticket
-number is returned, with a status of {\tt 3000\ OK} followed by a ''{\tt
-Length\ =\ }{\it size}`` line giving the length in bytes of the block data
-which immediately follows. Blocks must be retrieved in ascending order, but
-blocks may be skipped. If a block number greater than the largest stored on
-the volume is requested, a status of ''{\tt 3201\ End\ of\ volume}`` is
-returned. If a block number greater than the largest in the file is
-requested, a status of ''{\tt 3401\ End\ of\ file}`` is returned.
-
-\item [Read close session = \lt{}Ticket\gt{} ]
- \index{SPAN class }
- The read session with Ticket number is closed. A read session may be closed
-at any time; you needn't read all its blocks before closing it.
-\end{description}
-
-{\it by
-\elink{John Walker}{http://www.fourmilab.ch/}
-January 30th, MM }
\section*{Storage Daemon Configuration}
\label{_ChapterStart31}
-\index[general]{Storage Daemon Configuration }
-\index[general]{Configuration!Storage Daemon }
+\index[general]{Storage Daemon Configuration}
+\index[general]{Configuration!Storage Daemon}
\addcontentsline{toc}{section}{Storage Daemon Configuration}
\subsection*{General}
-\index[general]{General }
+\index[general]{General}
\addcontentsline{toc}{subsection}{General}
The Storage Daemon configuration file has relatively few resource definitions.
\subsection*{Storage Resource}
\label{StorageResource}
-\index[general]{Resource!Storage }
-\index[general]{Storage Resource }
+\index[general]{Resource!Storage}
+\index[general]{Storage Resource}
\addcontentsline{toc}{subsection}{Storage Resource}
In general, the properties specified under the Storage resource define global
\begin{description}
-\item [Name = \lt{}Storage-Daemon-Name\gt{} ]
- \index[fd]{Name }
+\item [Name = \lt{}Storage-Daemon-Name\gt{}]
+ \index[sd]{Name }
Specifies the Name of the Storage daemon. This directive is required.
\item [Working Directory = \lt{}Directory\gt{}]
- \index[fd]{Working Directory }
+ \index[sd]{Working Directory }
This directive is mandatory and specifies a directory in which the Storage
-daemon may put its status files. This directory should be used only by {\bf
-Bacula}, but may be shared by other Bacula daemons. This directive is
-required
+ daemon may put its status files. This directory should be used only by {\bf
+ Bacula}, but may be shared by other Bacula daemons provided the names
+ given to each daemon are unique. This directive is
+ required
\item [Pid Directory = \lt{}Directory\gt{}]
- \index[dir]{Pid Directory }
+ \index[sd]{Pid Directory }
This directive is mandatory and specifies a directory in which the Director
-may put its process Id file files. The process Id file is used to shutdown
-Bacula and to prevent multiple copies of Bacula from running simultaneously.
-This directive is required. Standard shell expansion of the {\bf Directory}
-is done when the configuration file is read so that values such as {\bf
-\$HOME} will be properly expanded.
+ may put its process Id file files. The process Id file is used to shutdown
+ Bacula and to prevent multiple copies of Bacula from running simultaneously.
+ This directive is required. Standard shell expansion of the {\bf Directory}
+ is done when the configuration file is read so that values such as {\bf
+ \$HOME} will be properly expanded.
-Typically on Linux systems, you will set this to: {\bf /var/run}. If you are
-not installing Bacula in the system directories, you can use the {\bf Working
-Directory} as defined above.
+ Typically on Linux systems, you will set this to: {\bf /var/run}. If you are
+ not installing Bacula in the system directories, you can use the {\bf Working
+ Directory} as defined above.
\item [Heartbeat Interval = \lt{}time-interval\gt{}]
- \index[dir]{Heartbeat Interval }
- This directive defines an interval of time. When the Storage daemon is
-waiting for the operator to mount a tape, each time interval, it will send a
-heartbeat signal to the File daemon. The default interval is zero which
-disables the heartbeat. This feature is particularly useful if you have a
-router such as 3Com that does not follow Internet standards and times out an
-inactive connection after a short duration.
+ \index[sd]{Heartbeat Interval }
+ \index[general]{Heartbeat Interval}
+ \index[general]{Broken pipe}
+ This directive defines an interval of time. When the Storage daemon is
+ waiting for the operator to mount a tape, each time interval, it will
+ send a heartbeat signal to the File daemon. The default interval is
+ zero which disables the heartbeat. This feature is particularly useful
+ if you have a router such as 3Com that does not follow Internet
+ standards and times out an valid connection after a short duration
+ despite the fact that keepalive is set. This usually results
+ in a broken pipe error message.
\item [Maximum Concurrent Jobs = \lt{}number\gt{}]
- \index[dir]{Maximum Concurrent Jobs }
- where \lt{}number\gt{} is the maximum number of Jobs that should run
-concurrently. The default is set to 2, but you may set it to a larger number.
-Each contact from the Director (e.g. status request, job start request) is
-considered as a Job, so if you want to be able to do a {\bf status} request
-in the console at the same time as a Job is running, you will need to set
-this value greater than 1.
+ \index[sd]{Maximum Concurrent Jobs}
+ where \lt{}number\gt{} is the maximum number of Jobs that should run
+ concurrently. The default is set to 10, but you may set it to a larger
+ number. Each contact from the Director (e.g. status request, job start
+ request) is considered as a Job, so if you want to be able to do a {\bf
+ status} request in the console at the same time as a Job is running, you
+ will need to set this value greater than 1. To run simultaneous Jobs,
+ you will need to set a number of other directives in the Director's
+ configuration file. Which ones you set depend on what you want, but you
+ will almost certainly need to set the {\bf Maximum Concurrent Jobs} in
+ the Storage resource in the Director's configuration file and possibly
+ those in the Job and Client resources.
\item [SDAddresses = \lt{}IP-address-specification\gt{}]
- \index[console]{SDAddresses }
- Specify the ports and addresses on which the Storage daemon will listen for
-Director connections. Normally, the default is sufficient and you do not need
-to specify this directive. Probably the simplest way to explain how this
-directive works is to show an example:
+ \index[sd]{SDAddresses}
+ Specify the ports and addresses on which the Storage daemon will listen
+ for Director connections. Normally, the default is sufficient and you
+ do not need to specify this directive. Probably the simplest way to
+ explain how this directive works is to show an example:
\footnotesize
\begin{verbatim}
ip = {
addr = bluedot.thun.net
}
- }
+}
\end{verbatim}
\normalsize
Using this directive, you can replace both the SDPort and SDAddress
directives shown below.
-\item [SDPort = \lt{}port-number\gt{} ]
- \index[console]{SDPort }
+\item [SDPort = \lt{}port-number\gt{}]
+ \index[sd]{SDPort }
Specifies port number on which the Storage daemon listens for Director
-connections. The default is 9103.
-
+ connections. The default is 9103.
+
\item [SDAddress = \lt{}IP-Address\gt{}]
- \index[console]{SDAddress }
+ \index[sd]{SDAddress }
This directive is optional, and if it is specified, it will cause the Storage
-daemon server (for Director and File daemon connections) to bind to the
-specified {\bf IP-Address}, which is either a domain name or an IP address
-specified as a dotted quadruple. If this directive is not specified, the
-Storage daemon will bind to any available address (the default).
+ daemon server (for Director and File daemon connections) to bind to the
+ specified {\bf IP-Address}, which is either a domain name or an IP address
+ specified as a dotted quadruple. If this directive is not specified, the
+ Storage daemon will bind to any available address (the default).
+
\end{description}
The following is a typical Storage daemon Storage definition.
\subsection*{Director Resource}
\label{DirectorResource1}
-\index[general]{Director Resource }
-\index[general]{Resource!Director }
+\index[general]{Director Resource}
+\index[general]{Resource!Director}
\addcontentsline{toc}{subsection}{Director Resource}
-The Director resource specifies the Name of the Director which is permitted to
-use the services of the Storage daemon. There may be multiple Director
-resources. The Director Name and Password must match the corresponding values
-in the Director's configuration file.
+The Director resource specifies the Name of the Director which is permitted
+to use the services of the Storage daemon. There may be multiple Director
+resources. The Director Name and Password must match the corresponding
+values in the Director's configuration file.
\begin{description}
-\item [Name = \lt{}Director-Name\gt{} ]
- \index[console]{Name }
+\item [Name = \lt{}Director-Name\gt{}]
+ \index[sd]{Name }
Specifies the Name of the Director allowed to connect to the Storage daemon.
-This directive is required.
+ This directive is required.
-\item [Password = \lt{}Director-password\gt{} ]
- \index[console]{Password }
+\item [Password = \lt{}Director-password\gt{}]
+ \index[sd]{Password }
Specifies the password that must be supplied by the above named Director.
-This directive is required.
+ This directive is required.
\item [Monitor = \lt{}yes|no\gt{}]
- \index[console]{Monitor }
- If Monitor is set to {\bf no} (default), this director will have full access
-to this Storage daemon. If Monitor is set to {\bf yes}, this director will
-only be able to fetch the current status of this Storage daemon.
-
-Please note that if this director is being used by a Monitor, we highly
-recommend to set this directive to {\bf yes} to avoid serious security
-problems.
+ \index[sd]{Monitor }
+ If Monitor is set to {\bf no} (default), this director will have full
+ access to this Storage daemon. If Monitor is set to {\bf yes}, this
+ director will only be able to fetch the current status of this Storage
+ daemon.
+
+ Please note that if this director is being used by a Monitor, we highly
+ recommend to set this directive to {\bf yes} to avoid serious security
+ problems.
+
\end{description}
The following is an example of a valid Director resource definition:
\normalsize
\label{DeviceResource}
-
\subsection*{Device Resource}
-\index[general]{Resource!Device }
-\index[general]{Device Resource }
+\index[general]{Resource!Device}
+\index[general]{Device Resource}
\addcontentsline{toc}{subsection}{Device Resource}
The Device Resource specifies the details of each device (normally a tape
-drive) that can be used by the Storage daemon. There may be multiple Device
-resources for a single Storage daemon. In general, the properties specified
-within the Device resource are specific to the Device.
+drive) that can be used by the Storage daemon. There may be multiple
+Device resources for a single Storage daemon. In general, the properties
+specified within the Device resource are specific to the Device.
\begin{description}
-\item [Name = {\it Device-Name} ]
- \index[dir]{Name }
- Specifies the Name that the Director will use when asking to backup or
-restore to or from to this device. This is the logical Device name, and may
-be any string up to 127 characters in length. It is generally a good idea to
-make it correspond to the English name of the backup device. The physical
-name of the device is specified on the {\bf Archive Device} directive
-described below. The name you specify here is also used in your Director's
-conf file on the
-\ilink{Device directive}{StorageResource2} in its Storage
-resource.
-
-\item [Archive Device = {\it name-string} ]
- \index[fd]{Archive Device }
+\item [Name = {\it Device-Name}]
+ \index[sd]{Name }
+ Specifies the Name that the Director will use when asking to backup or
+ restore to or from to this device. This is the logical Device name, and may
+ be any string up to 127 characters in length. It is generally a good idea to
+ make it correspond to the English name of the backup device. The physical
+ name of the device is specified on the {\bf Archive Device} directive
+ described below. The name you specify here is also used in your Director's
+ conf file on the
+ \ilink{Device directive}{StorageResource2} in its Storage
+ resource.
+
+\item [Archive Device = {\it name-string}]
+ \index[sd]{Archive Device }
The specified {\bf name-string} gives the system file name of the storage
-device managed by this storage daemon. This will usually be the device file
-name of a removable storage device (tape drive), for example ``{\bf
-/dev/nst0}'' or ``{\bf /dev/rmt/0mbn}''. For a DVD-writer, it will be for
-example {\bf /dev/hdc}. It may also be a directory name if you are archiving
-to disk storage. In this case, you must supply the full absolute path to the
-directory. When specifying a tape device, it is preferable that the
-``non-rewind'' variant of the device file name be given. In addition, on
-systems such as Sun, which have multiple tape access methods, you must be
-sure to specify to use Berkeley I/O conventions with the device. The {\bf b}
-in the Solaris (Sun) archive specification {\bf /dev/rmt/0mbn} is what is
-needed in this case. Bacula does not support SysV tape drive behavior.
-
-As noted above, normally the Archive Device is the name of a tape drive, but
-you may also specify an absolute path to an existing directory. If the Device
-is a directory Bacula will write to file storage in the specified directory,
-and the filename used will be the Volume name as specified in the Catalog.
-If you want to write into more than one directory (i.e. to spread the load to
-different disk drives), you will need to define two Device resources, each
-containing an Archive Device with a different directory.
-
-In addition to a tape device name or a directory name, Bacula will accept the
-name of a FIFO. A FIFO is a special kind of file that connects two programs
-via kernel memory. If a FIFO device is specified for a backup operation, you
-must have a program that reads what Bacula writes into the FIFO. When the
-Storage daemon starts the job, it will wait for {\bf MaximumOpenWait} seconds
-for the read program to start reading, and then time it out and terminate
-the job. As a consequence, it is best to start the read program at the
-beginning of the job perhaps with the {\bf RunBeforeJob} directive. For this
-kind of device, you never want to specify {\bf AlwaysOpen}, because you want
-the Storage daemon to open it only when a job starts, so you must explicitly
-set it to {\bf No}. Since a FIFO is a one way device, Bacula will not attempt
-to read a label of a FIFO device, but will simply write on it. To create a
-FIFO Volume in the catalog, use the {\bf add} command rather than then {\bf
-label} command to avoid attempting to write a label.
-
-During a restore operation, if the Archive Device is a FIFO, Bacula will
-attempt to read from the FIFO, so you must have an external program that
-writes into the FIFO. Bacula will wait {\bf MaximumOpenWait} seconds for the
-program to begin writing and will then time it out and terminate the job. As
-noted above, you may use the {\bf RunBeforeJob} to start the writer program
-at the beginning of the job.
-
-The Archive Device directive is required.
-
-\item [Media Type = {\it name-string} ]
- \index[fd]{Media Type }
+ device managed by this storage daemon. This will usually be the device file
+ name of a removable storage device (tape drive), for example "{\bf
+ /dev/nst0}" or "{\bf /dev/rmt/0mbn}". For a DVD-writer, it will be for
+ example {\bf /dev/hdc}. It may also be a directory name if you are archiving
+ to disk storage. In this case, you must supply the full absolute path to the
+ directory. When specifying a tape device, it is preferable that the
+ "non-rewind" variant of the device file name be given. In addition, on
+ systems such as Sun, which have multiple tape access methods, you must be
+ sure to specify to use Berkeley I/O conventions with the device. The {\bf b}
+ in the Solaris (Sun) archive specification {\bf /dev/rmt/0mbn} is what is
+ needed in this case. Bacula does not support SysV tape drive behavior.
+
+ As noted above, normally the Archive Device is the name of a tape drive, but
+ you may also specify an absolute path to an existing directory. If the Device
+ is a directory Bacula will write to file storage in the specified directory,
+ and the filename used will be the Volume name as specified in the Catalog.
+ If you want to write into more than one directory (i.e. to spread the load to
+ different disk drives), you will need to define two Device resources, each
+ containing an Archive Device with a different directory.
+
+ In addition to a tape device name or a directory name, Bacula will accept the
+ name of a FIFO. A FIFO is a special kind of file that connects two programs
+ via kernel memory. If a FIFO device is specified for a backup operation, you
+ must have a program that reads what Bacula writes into the FIFO. When the
+ Storage daemon starts the job, it will wait for {\bf MaximumOpenWait} seconds
+ for the read program to start reading, and then time it out and terminate
+ the job. As a consequence, it is best to start the read program at the
+ beginning of the job perhaps with the {\bf RunBeforeJob} directive. For this
+ kind of device, you never want to specify {\bf AlwaysOpen}, because you want
+ the Storage daemon to open it only when a job starts, so you must explicitly
+ set it to {\bf No}. Since a FIFO is a one way device, Bacula will not attempt
+ to read a label of a FIFO device, but will simply write on it. To create a
+ FIFO Volume in the catalog, use the {\bf add} command rather than then {\bf
+ label} command to avoid attempting to write a label.
+
+ During a restore operation, if the Archive Device is a FIFO, Bacula will
+ attempt to read from the FIFO, so you must have an external program that
+ writes into the FIFO. Bacula will wait {\bf MaximumOpenWait} seconds for the
+ program to begin writing and will then time it out and terminate the job. As
+ noted above, you may use the {\bf RunBeforeJob} to start the writer program
+ at the beginning of the job.
+
+ The Archive Device directive is required.
+
+\item [Media Type = {\it name-string}]
+ \index[sd]{Media Type }
The specified {\bf name-string} names the type of media supported by this
-device, for example, ``DLT7000''. Media type names are arbitrary in that you
-set it to anything you want, but must be known to the volume database to keep
-track of which storage daemons can read which volumes. The same {\bf
-name-string} must appear in the appropriate Storage resource definition in
-the Director's configuration file.
-
-Even though the names you assign are arbitrary (i.e. you choose the name you
-want), you should take care in specifying them because the Media Type is used
-to determine which storage device Bacula will select during restore. Thus you
-should probably use the same Media Type specification for all drives where
-the Media can be freely interchanged. This is not generally an issue if you
-have a single Storage daemon, but it is with multiple Storage daemons,
-especially if they have incompatible media.
-
-For example, if you specify a Media Type of ``DDS-4'' then during the
-restore, Bacula will be able to choose any Storage Daemon that handles
-``DDS-4''. If you have an autochanger, you might want to name the Media Type
-in a way that is unique to the autochanger, unless you wish to possibly use
-the Volumes in other drives. You should also ensure to have unique Media
-Type names if the Media is not compatible between drives. This specification
-is required for all devices.
+ device, for example, "DLT7000". Media type names are arbitrary in that you
+ set it to anything you want, but must be known to the volume database to keep
+ track of which storage daemons can read which volumes. The same {\bf
+ name-string} must appear in the appropriate Storage resource definition in
+ the Director's configuration file.
+
+ Even though the names you assign are arbitrary (i.e. you choose the name you
+ want), you should take care in specifying them because the Media Type is used
+ to determine which storage device Bacula will select during restore. Thus you
+ should probably use the same Media Type specification for all drives where
+ the Media can be freely interchanged. This is not generally an issue if you
+ have a single Storage daemon, but it is with multiple Storage daemons,
+ especially if they have incompatible media.
+
+ For example, if you specify a Media Type of "DDS-4" then during the
+ restore, Bacula will be able to choose any Storage Daemon that handles
+ "DDS-4". If you have an autochanger, you might want to name the Media Type
+ in a way that is unique to the autochanger, unless you wish to possibly use
+ the Volumes in other drives. You should also ensure to have unique Media
+ Type names if the Media is not compatible between drives. This specification
+ is required for all devices.
\label{Autochanger}
-
-\item [Autochanger = {\it Yes|No} ]
- \index[sd]{Autochanger }
- If {\bf Yes}, this device is an automatic tape changer, and you should also
-specify a {\bf Changer Device} as well as a {\bf Changer Command}. If {\bf
-No} (default), the volume must be manually changed. You might also want to
-add an identical directive to the
-\ilink{ Storage resource}{Autochanger1} in the Director's
-configuration file so that when labeling tapes you are prompted for the slot.
-
-
-\item [Changer Device = {\it name-string} ]
- \index[fd]{Changer Device }
- The specified {\bf name-string} gives the system file name of the autochanger
-device name that corresponds to the {\bf Archive Device} specified. This
-device name is specified if you have an autochanger or if you want to use the
-{\bf Alert Command} (see below). Normally you will specify the {\bf generic
-SCSI} device name in this directive. For example, on Linux systems, for
-archive device {\bf /dev/nst0}, This directive is optional. See the
-\ilink{ Using Autochangers}{_ChapterStart18} chapter of this
-manual for more details of using this and the following autochanger
-directives.
-
-\item [Changer Command = {\it name-string} ]
- \index[fd]{Changer Command }
+\item [Autochanger = {\it Yes|No}]
+ \index[sd]{Autochanger}
+ If {\bf Yes}, this device belongs to an automatic tape changer, and you should also
+ specify a {\bf Changer Device} as well as a {\bf Changer Command}. If {\bf
+ No} (default), the volume must be manually changed. You should also
+ have an identical directive to the
+ \ilink{Storage resource}{Autochanger1} in the Director's
+ configuration file so that when labeling tapes you are prompted for the slot.
+
+\item [Changer Device = {\it name-string}]
+ \index[sd]{Changer Device }
+ The specified {\bf name-string} must be the {\bf generic SCSI} device
+ name of the autochanger that corresponds to the normal read/write
+ {\bf Archive Device} specified in the Device resource. This
+ gemeric SCSI device name should be specified if you have an autochanger
+ or if you have a standard tape drive and want to use the
+ {\bf Alert Command} (see below). For example, on Linux systems, for
+ an Archive Device name of {\bf /dev/nst0}, you would specify {\bf
+ /dev/sg0} for the Changer Device name. Depending on your exact
+ configuration, and the number of autochangers or the type of
+ autochanger, what you specify here can vary. This directive is
+ optional. See the \ilink{ Using Autochangers}{_ChapterStart18} chapter
+ of this manual for more details of using this and the following
+ autochanger directives.
+
+\item [Changer Command = {\it name-string}]
+ \index[sd]{Changer Command }
The {\bf name-string} specifies an external program to be called that will
-automatically change volumes as required by {\bf Bacula}. Most frequently,
-you will specify the Bacula supplied {\bf mtx-changer} script as follows:
+ automatically change volumes as required by {\bf Bacula}. Most frequently,
+ you will specify the Bacula supplied {\bf mtx-changer} script as follows:
\footnotesize
\begin{verbatim}
Changer Command = "/path/mtx-changer %c %o %S %a %d"
-
\end{verbatim}
\normalsize
-and you will install the {\bf mtx} on your system (found in the {\bf depkgs}
-release). An example of this command is in the default bacula-sd.conf file.
-For more details on the substitution characters that may be specified to
-configure your autochanger please see the
-\ilink{Autochangers}{_ChapterStart18} chapter of this manual.
-For FreeBSD users, you might want to see one of the several {\bf chio}
-scripts in {\bf examples/autochangers}.
+ and you will install the {\bf mtx} on your system (found in the {\bf depkgs}
+ release). An example of this command is in the default bacula-sd.conf file.
+ For more details on the substitution characters that may be specified to
+ configure your autochanger please see the
+ \ilink{Autochangers}{_ChapterStart18} chapter of this manual.
+ For FreeBSD users, you might want to see one of the several {\bf chio}
+ scripts in {\bf examples/autochangers}.
-\item [Alert Command = {\it name-string} ]
- \index[sd]{Alert Command }
+\item [Alert Command = {\it name-string}]
+ \index[sd]{Alert Command }
The {\bf name-string} specifies an external program to be called at the
-completion of each Job after the device is released. The purpose of this
-command is to check for Tape Alerts, which are present when something is
-wrong with your tape drive (at least for most modern tape drives). The same
-substitution characters that may be specified in the Changer Command may also
-be used in this string. For more information, please see the
-\ilink{Autochangers}{_ChapterStart18} chapter of this manual.
-
-
-Note, it is not necessary to have an autochanger to use this command. The
-example below uses the {\bf tapeinfo} program that comes with the {\bf mtx}
-package, but it can be used on any tape drive. However, you will need to
-specify a {\bf Changer Device} directive in your Device resource (see above)
-so that the generic SCSI device name can be edited into the command (with the
-\%c).
-
-An example of the use of this command to print Tape Alerts in the Job report
-is:
+ completion of each Job after the device is released. The purpose of this
+ command is to check for Tape Alerts, which are present when something is
+ wrong with your tape drive (at least for most modern tape drives). The same
+ substitution characters that may be specified in the Changer Command may also
+ be used in this string. For more information, please see the
+ \ilink{Autochangers}{_ChapterStart18} chapter of this manual.
+
+
+ Note, it is not necessary to have an autochanger to use this command. The
+ example below uses the {\bf tapeinfo} program that comes with the {\bf mtx}
+ package, but it can be used on any tape drive. However, you will need to
+ specify a {\bf Changer Device} directive in your Device resource (see above)
+ so that the generic SCSI device name can be edited into the command (with the
+ \%c).
+
+ An example of the use of this command to print Tape Alerts in the Job report
+ is:
\footnotesize
\begin{verbatim}
\end{verbatim}
\normalsize
-\item [Drive Index = {\it number} ]
- \index[sd]{Drive Index }
+\item [Drive Index = {\it number}]
+ \index[sd]{Drive Index}
The {\bf Drive Index} that you specify is passed to the {\bf mtx-changer}
-script and is thus passed to the {\bf mtx} program. By default, the Drive
-Index is zero, so if you have only one drive in your autochanger, everything
-will work normally. However, if you have multiple drives, you may specify two
-Bacula Device resources. The first will either set Drive Index to zero, or
-leave it unspecified, and the second Device Resource should contain a Drive
-Index set to 1. This will then permit you to use two or more drives in your
-autochanger. However, you must ensure that Bacula does not request the same
-Volume on both drives at the same time. You may also need to modify the
-mtx-changer script to do locking so that two jobs don't attempt to use the
-autochanger at the same time. An example script can be found in {\bf
-examples/autochangers/locking-mtx-changer}.
-
-\item [Maximum Changer Wait = {\it time} ]
- \index[sd]{Maximum Changer Wait }
+ script and is thus passed to the {\bf mtx} program. By default, the Drive
+ Index is zero, so if you have only one drive in your autochanger, everything
+ will work normally. However, if you have multiple drives, you may specify two
+ Bacula Device resources. The first will either set Drive Index to zero, or
+ leave it unspecified, and the second Device Resource should contain a Drive
+ Index set to 1. This will then permit you to use two or more drives in your
+ autochanger. However, you must ensure that Bacula does not request the same
+ Volume on both drives at the same time. You may also need to modify the
+ mtx-changer script to do locking so that two jobs don't attempt to use the
+ autochanger at the same time. An example script can be found in {\bf
+ examples/autochangers/locking-mtx-changer}.
+
+\item [Autoselect = {\it Yes|No}]
+ \index[sd]{Autoselect}
+ If this directive is set to {\bf yes} (default), and the Device
+ belongs to an autochanger, then when the Autochanger is referenced
+ by the Director, this device can automatically be selected. If this
+ directive is set to {\bf no}, then the Device can only be referenced
+ by directly using the Device name in the Director. This is useful
+ for reserving a drive for something special such as a high priority
+ backup or restore operations.
+
+\item [Maximum Changer Wait = {\it time}]
+ \index[sd]{Maximum Changer Wait }
This directive specifies the maximum time for Bacula to wait for an
-autochanger to change the volume. If this time is exceeded, Bacula will
-invalidate the Volume slot number stored in the catalog and try again. If no
-additional changer volumes exist, Bacula will ask the operator to intervene.
-The default time out is 5 minutes.
+ autochanger to change the volume. If this time is exceeded, Bacula will
+ invalidate the Volume slot number stored in the catalog and try again. If no
+ additional changer volumes exist, Bacula will ask the operator to intervene.
+ The default time out is 5 minutes.
-\item [Always Open = {\it Yes|No} ]
- \index[sd]{Always Open }
+\item [Always Open = {\it Yes|No}]
+ \index[sd]{Always Open }
If {\bf Yes} (default), Bacula will always keep the device open unless
-specifically {\bf unmounted} by the Console program. This permits Bacula to
-ensure that the tape drive is always available. If you set {\bf AlwaysOpen}
-to {\bf no} {\bf Bacula} will only open the drive when necessary, and at the
-end of the Job if no other Jobs are using the drive, it will be freed. To
-minimize unnecessary operator intervention, it is highly recommended that
-{\bf Always Open = yes}. This also ensures that the drive is available when
-Bacula needs it.
-
-If you have {\bf Always Open = yes} (recommended) and you want to use the
-drive for something else, simply use the {\bf unmount} command in the Console
-program to release the drive. However, don't forget to remount the drive with
-{\bf mount} when the drive is available or the next Bacula job will block.
-
-For File storage, this directive is ignored. For a FIFO storage device, you
-must set this to {\bf No}.
-
-Please note that if you set this directive to {\bf No} Bacula will release
-the tape drive between each job, and thus the next job will rewind the tape
-and position it to the end of the data. This can be a very time consuming
-operation.
-
-\item [Volume Poll Interval = {\it time} ]
- \index[sd]{Volume Poll Interval }
- If a non-zero time interval is specified, Bacula will poll the device after
-asking the operator to mount a new volume to see if the new volume has been
-mounted. If the time interval is zero (the default), no polling will occur.
-This directive can be useful if you want to avoid operator intervention via
-the console. The operator can simply remove the old volume and insert the
-requested one, and Bacula will continue. Please be aware that if you set this
-interval to small, you may excessively wear your tape drive if the old tape
-remains in the drive since Bacula will read it on each poll. This could be
-avoided by using the {\bf Offline On Unmount} and the {\bf Close on Poll}
-directives.
-
-\item [Close on Poll= {\it Yes|No} ]
- \index[console]{Close on Poll }
+ specifically {\bf unmounted} by the Console program. This permits Bacula to
+ ensure that the tape drive is always available. If you set {\bf AlwaysOpen}
+ to {\bf no} {\bf Bacula} will only open the drive when necessary, and at the
+ end of the Job if no other Jobs are using the drive, it will be freed. The
+ next time Bacula wants to append to a tape on a drive that was freed, Bacula
+ must rewind the tape and position to the end. To avoid unnecessary tape positioning
+ and to minimize unnecessary operator intervention, it is highly recommended that
+ {\bf Always Open = yes}. This also ensures that the drive is available when
+ Bacula needs it.
+
+ If you have {\bf Always Open = yes} (recommended) and you want to use the
+ drive for something else, simply use the {\bf unmount} command in the Console
+ program to release the drive. However, don't forget to remount the drive with
+ {\bf mount} when the drive is available or the next Bacula job will block.
+
+ For File storage, this directive is ignored. For a FIFO storage device, you
+ must set this to {\bf No}.
+
+ Please note that if you set this directive to {\bf No} Bacula will release
+ the tape drive between each job, and thus the next job will rewind the tape
+ and position it to the end of the data. This can be a very time consuming
+ operation.
+
+\item [Volume Poll Interval = {\it time}]
+ \index[sd]{Volume Poll Interval }
+ If the time specified on this directive is non-zero, after asking the
+ operator to mount a new volume Bacula will periodically poll (or read) the
+ drive at the specified interval to see if a new volume has been mounted. If
+ the time interval is zero (the default), no polling will occur. This
+ directive can be useful if you want to avoid operator intervention via the
+ console. Instead, the operator can simply remove the old volume and insert
+ the requested one, and Bacula on the next poll will recognize the new tape
+ and continue. Please be aware that if you set this interval too small, you
+ may excessively wear your tape drive if the old tape remains in the drive,
+ since Bacula will read it on each poll. This can be avoided by ejecting the
+ tape using the {\bf Offline On Unmount} and the {\bf Close on Poll}
+ directives.
+ However, if you are using a Linux 2.6 kernel or other OSes
+ such as FreeBSD or Solaris, the Offline On Unmount will leave the drive
+ with no tape, and Bacula will not be able to properly open the drive and
+ may fail the job. For more information on this problem, please see the
+ \ilink{description of Offline On Unmount}{NoTapeInDrive} in the Tape
+ Testing chapter.
+
+\item [Close on Poll= {\it Yes|No}]
+ \index[sd]{Close on Poll}
If {\bf Yes}, Bacula close the device (equivalent to an unmount except no
-mount is required) and reopen it at each poll. Normally this is not too
-useful unless you have the {\bf Offline on Unmount} directive set, in which
-case the drive will be taken offline preventing wear on the tape during any
-future polling. Once the operator inserts a new tape, Bacula will recognize
-the drive on the next poll and automatically continue with the backup.
-
-\item [Maximum Open Wait = {\it time} ]
- \index[console]{Maximum Open Wait }
+ mount is required) and reopen it at each poll. Normally this is not too
+ useful unless you have the {\bf Offline on Unmount} directive set, in which
+ case the drive will be taken offline preventing wear on the tape during any
+ future polling. Once the operator inserts a new tape, Bacula will recognize
+ the drive on the next poll and automatically continue with the backup.
+ Please see above more more details.
+
+\item [Maximum Open Wait = {\it time}]
+ \index[sd]{Maximum Open Wait }
This directive specifies the maximum amount of time that Bacula will wait for
-a device that is busy. The default is 5 minutes. If the device cannot be
-obtained, the current Job will be terminated in error. Bacula will re-attempt
-to open the drive the next time a Job starts that needs the the drive.
+ a device that is busy. The default is 5 minutes. If the device cannot be
+ obtained, the current Job will be terminated in error. Bacula will re-attempt
+ to open the drive the next time a Job starts that needs the the drive.
-\item [Removable media = {\it Yes|No} ]
- \index[console]{Removable media }
+\item [Removable media = {\it Yes|No}]
+ \index[sd]{Removable media }
If {\bf Yes}, this device supports removable media (for example, tapes or
-CDs). If {\bf No}, media cannot be removed (for example, an intermediate
-backup area on a hard disk).
+ CDs). If {\bf No}, media cannot be removed (for example, an intermediate
+ backup area on a hard disk).
-\item [Random access = {\it Yes|No} ]
- \index[console]{Random access }
+\item [Random access = {\it Yes|No}]
+ \index[sd]{Random access }
If {\bf Yes}, the archive device is assumed to be a random access medium
-which supports the {\bf lseek} (or {\bf lseek64} if Largefile is enabled
-during configuration) facility.
-
-\item [Minimum block size = {\it size-in-bytes} ]
- \index[console]{Minimum block size }
- On most modern tape drives, you will not need to specify this directive, and
-if you do so, it will be to make Bacula use fixed block sizes. This
-statement applies only to non-random access devices (e.g. tape drives).
-Blocks written by the storage daemon to a non-random archive device will
-never be smaller than the given {\bf size-in-bytes}. The Storage daemon will
-attempt to efficiently fill blocks with data received from active sessions
-but will, if necessary, add padding to a block to achieve the required
-minimum size.
-
-To force the block size to be fixed, as is the case for some non-random
-access devices (tape drives), set the {\bf Minimum block size} and the {\bf
-Maximum block size} to the same value (zero included). The default is that
-both the minimum and maximum block size are zero and the default block size
-is 64,512 bytes. If you wish the block size to be fixed and different from
-the default, specify the same value for both {\bf Minimum block size} and
-{\bf Maximum block size}.
-
-For example, suppose you want a fixed block size of 100K bytes, then you
-would specify:
+ which supports the {\bf lseek} (or {\bf lseek64} if Largefile is enabled
+ during configuration) facility.
+
+\item [Minimum block size = {\it size-in-bytes}]
+ \index[sd]{Minimum block size }
+ On most modern tape drives, you will not need or wamt to specify this directive, and
+ if you do so, it will be to make Bacula use fixed block sizes. This
+ statement applies only to non-random access devices (e.g. tape drives).
+ Blocks written by the storage daemon to a non-random archive device will
+ never be smaller than the given {\bf size-in-bytes}. The Storage daemon will
+ attempt to efficiently fill blocks with data received from active sessions
+ but will, if necessary, add padding to a block to achieve the required
+ minimum size.
+
+ To force the block size to be fixed, as is the case for some non-random
+ access devices (tape drives), set the {\bf Minimum block size} and the {\bf
+ Maximum block size} to the same value (zero included). The default is that
+ both the minimum and maximum block size are zero and the default block size
+ is 64,512 bytes. If you wish the block size to be fixed and different from
+ the default, specify the same value for both {\bf Minimum block size} and
+ {\bf Maximum block size}.
+
+ For example, suppose you want a fixed block size of 100K bytes, then you
+ would specify:
\footnotesize
\begin{verbatim}
\end{verbatim}
\normalsize
-Please note that if you specify a fixed block size as shown above, the tape
-drive must either be in variable block size mode, or if it is in fixed block
-size mode, the block size (generally defined by {\bf mt}) {\bf must} be
-identical to the size specified in Bacula -- otherwise when you attempt to
-re-read your Volumes, you will get an error.
-
-If you want the block size to be variable but with a 64K minimum and 200K
-maximum (and default as well), you would specify:
+ Please note that if you specify a fixed block size as shown above, the tape
+ drive must either be in variable block size mode, or if it is in fixed block
+ size mode, the block size (generally defined by {\bf mt}) {\bf must} be
+ identical to the size specified in Bacula -- otherwise when you attempt to
+ re-read your Volumes, you will get an error.
+
+ If you want the block size to be variable but with a 64K minimum and 200K
+ maximum (and default as well), you would specify:
\footnotesize
\begin{verbatim}
\end{verbatim}
\normalsize
-\item [Maximum block size = {\it size-in-bytes} ]
- \index[sd]{Maximum block size }
+\item [Maximum block size = {\it size-in-bytes}]
+ \index[sd]{Maximum block size }
On most modern tape drives, you will not need to specify this directive. If
-you do so, it will most likely be to use fixed block sizes (see Minimum block
-size above). The Storage daemon will aways attempt to write blocks of the
-specified {\bf size-in-bytes} to the archive device. As a consequence, this
-statement specifies both the default block size and the maximum block size.
-The size written never exceed the given {\bf size-in-bytes}. If adding data
-to a block would cause it to exceed the given maximum size, the block will be
-written to the archive device, and the new data will begin a new block.
-
-If no value is specified or zero is specified, the Storage daemon will use a
-default block size of 64,512 bytes (126 * 512).
-
-\item [Hardware End of Medium = {\it Yes|No} ]
- \index[sd]{Hardware End of Medium }
+ you do so, it will most likely be to use fixed block sizes (see Minimum block
+ size above). The Storage daemon will aways attempt to write blocks of the
+ specified {\bf size-in-bytes} to the archive device. As a consequence, this
+ statement specifies both the default block size and the maximum block size.
+ The size written never exceed the given {\bf size-in-bytes}. If adding data
+ to a block would cause it to exceed the given maximum size, the block will be
+ written to the archive device, and the new data will begin a new block.
+
+ If no value is specified or zero is specified, the Storage daemon will use a
+ default block size of 64,512 bytes (126 * 512).
+
+\item [Hardware End of Medium = {\it Yes|No}]
+ \index[sd]{Hardware End of Medium }
If {\bf No}, the archive device is not required to support end of medium
-ioctl request, and the storage daemon will use the forward space file
-function to find the end of the recorded data. If {\bf Yes}, the archive
-device must support the {\tt ioctl} {\tt MTEOM} call, which will position the
-tape to the end of the recorded data. In addition, your SCSI driver must keep
-track of the file number on the tape and report it back correctly by the
-{\bf MTIOCGET} ioctl. Note, some SCSI drivers will correctly forward space to
-the end of the recorded data, but they do not keep track of the file number.
-On Linux machines, the SCSI driver has a {\bf fast-eod} option, which if set
-will cause the driver to lose track of the file number. You should ensure
-that this option is always turned off using the {\bf mt} program.
-
-Default setting for Hardware End of Medium is {\bf Yes}. This function is
-used before appending to a tape to ensure that no previously written data is
-lost. We recommend if you have a non standard or unusual tape drive that you
-use the {\bf btape} program to test your drive to see whether or not it
-supports this function. All modern (after 1998) tape drives support this
-feature.
-
-If you set Hardware End of Medium = no, you should also set {\bf Fast Forward
-Space File = no}. If you do not, Bacula will most likely be unable to
-correctly find the end of data on the tape.
-
-\item [Fast Forward Space File = {\it Yes|No} ]
- \index[fd]{Fast Forward Space File }
+ ioctl request, and the storage daemon will use the forward space file
+ function to find the end of the recorded data. If {\bf Yes}, the archive
+ device must support the {\tt ioctl} {\tt MTEOM} call, which will position the
+ tape to the end of the recorded data. In addition, your SCSI driver must keep
+ track of the file number on the tape and report it back correctly by the
+ {\bf MTIOCGET} ioctl. Note, some SCSI drivers will correctly forward space to
+ the end of the recorded data, but they do not keep track of the file number.
+ On Linux machines, the SCSI driver has a {\bf fast-eod} option, which if set
+ will cause the driver to lose track of the file number. You should ensure
+ that this option is always turned off using the {\bf mt} program.
+
+ Default setting for Hardware End of Medium is {\bf Yes}. This function is
+ used before appending to a tape to ensure that no previously written data is
+ lost. We recommend if you have a non-standard or unusual tape drive that you
+ use the {\bf btape} program to test your drive to see whether or not it
+ supports this function. All modern (after 1998) tape drives support this
+ feature.
+
+\item [Fast Forward Space File = {\it Yes|No}]
+ \index[sd]{Fast Forward Space File }
If {\bf No}, the archive device is not required to support keeping track of
-the file number ({\bf MTIOCGET} ioctl) during forward space file. If {\bf
-Yes}, the archive device must support the {\tt ioctl} {\tt MTFSF} call, which
-virtually all drivers support, but in addition, your SCSI driver must keep
-track of the file number on the tape and report it back correctly by the
-{\bf MTIOCGET} ioctl. Note, some SCSI drivers will correctly forward space,
-but they do not keep track of the file number or more seriously, they do not
-report end of meduim.
-
-Default setting for Fast Forward Space File is {\bf Yes}. If you disable
-Hardware End of Medium, most likely you should also disable Fast Forward
-Space file. The {\bf test} command in the program {\bf btape} will test this
-feature and advise you if it should be turned off.
-
-\item [BSF at EOM = {\it Yes|No} ]
- \index[fd]{BSF at EOM }
+ the file number ({\bf MTIOCGET} ioctl) during forward space file. If {\bf
+ Yes}, the archive device must support the {\tt ioctl} {\tt MTFSF} call, which
+ virtually all drivers support, but in addition, your SCSI driver must keep
+ track of the file number on the tape and report it back correctly by the
+ {\bf MTIOCGET} ioctl. Note, some SCSI drivers will correctly forward space,
+ but they do not keep track of the file number or more seriously, they do not
+ report end of meduim.
+
+ Default setting for Fast Forward Space File is {\bf Yes}.
+
+\item [Use MTIOCGET = {\it Yes|No}]
+ \index[sd]{Fast Forward Space File }
+ If {\bf No}, the operating system is not required to support keeping track of
+ the file number and reporting it in the ({\bf MTIOCGET} ioctl). The default
+ is {\bf Yes}. If you must set this to No, Bacula will do the proper file
+ position determination, but it is very unfortunate because it means that
+ tape movement is very inefficient.
+ Fortunately, this operation system deficiency seems to be the case only
+ on a few *BSD systems. Operating systems known to work correctly are
+ Solaris, Linux and FreeBSD.
+
+\item [BSF at EOM = {\it Yes|No}]
+ \index[sd]{BSF at EOM }
If {\bf No}, the default, no special action is taken by Bacula with the End
-of Medium (end of tape) is reached because the tape will be positioned after
-the last EOF tape mark, and Bacula can append to the tape as desired.
-However, on some systems, such as FreeBSD, when Bacula reads the End of
-Medium (end of tape), the tape will be positioned after the second EOF tape
-mark (two successive EOF marks indicated End of Medium). If Bacula appends
-from that point, all the appended data will be lost. The solution for such
-systems is to specify {\bf BSF at EOM} which causes Bacula to backspace over
-the second EOF mark. Determination of whether or not you need this directive
-is done using the {\bf test} command in the {\bf btape} program.
-
-\item [TWO EOF = {\it Yes|No} ]
- \index[fd]{TWO EOF }
+ of Medium (end of tape) is reached because the tape will be positioned after
+ the last EOF tape mark, and Bacula can append to the tape as desired.
+ However, on some systems, such as FreeBSD, when Bacula reads the End of
+ Medium (end of tape), the tape will be positioned after the second EOF tape
+ mark (two successive EOF marks indicated End of Medium). If Bacula appends
+ from that point, all the appended data will be lost. The solution for such
+ systems is to specify {\bf BSF at EOM} which causes Bacula to backspace over
+ the second EOF mark. Determination of whether or not you need this directive
+ is done using the {\bf test} command in the {\bf btape} program.
+
+\item [TWO EOF = {\it Yes|No}]
+ \index[sd]{TWO EOF }
If {\bf Yes}, Bacula will write two end of file marks when terminating a tape
-- i.e. after the last job or at the end of the medium. If {\bf No}, the
default, Bacula will only write one end of file to terminate the tape.
-\item [Backward Space Record = {\it Yes|No} ]
- \index[fd]{Backward Space Record }
+\item [Backward Space Record = {\it Yes|No}]
+ \index[sd]{Backward Space Record}
If {\it Yes}, the archive device supports the {\tt MTBSR ioctl} to backspace
-records. If {\it No}, this call is not used and the device must be rewound
-and advanced forward to the desired position. Default is {\bf Yes} for non
-random-access devices.
-
-\item [Backward Space File = {\it Yes|No} ]
- \index[fd]{Backward Space File }
+ records. If {\it No}, this call is not used and the device must be rewound
+ and advanced forward to the desired position. Default is {\bf Yes} for non
+ random-access devices. This function if enabled is used at the end of a
+ Volume after writing the end of file and any ANSI/IBM labels to determine whether
+ or not the last block was written correctly. If you turn this function off,
+ the test will not be done. This causes no harm as the re-read process is
+ precautionary rather than required.
+
+\item [Backward Space File = {\it Yes|No}]
+ \index[sd]{Backward Space File }
If {\it Yes}, the archive device supports the {\bf MTBSF} and {\bf MTBSF
-ioctl}s to backspace over an end of file mark and to the start of a file. If
-{\it No}, these calls are not used and the device must be rewound and
-advanced forward to the desired position. Default is {\bf Yes} for non
-random-access devices.
+ ioctl}s to backspace over an end of file mark and to the start of a file. If
+ {\it No}, these calls are not used and the device must be rewound and
+ advanced forward to the desired position. Default is {\bf Yes} for non
+ random-access devices.
-\item [Forward Space Record = {\it Yes|No} ]
- \index[fd]{Forward Space Record }
+\item [Forward Space Record = {\it Yes|No}]
+ \index[sd]{Forward Space Record }
If {\it Yes}, the archive device must support the {\bf MTFSR ioctl} to
-forward space over records. If {\bf No}, data must be read in order to
-advance the position on the device. Default is {\bf Yes} for non
-random-access devices.
+ forward space over records. If {\bf No}, data must be read in order to
+ advance the position on the device. Default is {\bf Yes} for non
+ random-access devices.
-\item [Forward Space File = {\it Yes|No} ]
- \index[fd]{Forward Space File }
+\item [Forward Space File = {\it Yes|No}]
+ \index[sd]{Forward Space File }
If {\bf Yes}, the archive device must support the {\tt MTFSF ioctl} to
-forward space by file marks. If {\it No}, data must be read to advance the
-position on the device. Default is {\bf Yes} for non random-access devices.
+ forward space by file marks. If {\it No}, data must be read to advance the
+ position on the device. Default is {\bf Yes} for non random-access devices.
-\item [Offline On Unmount = {\it Yes|No} ]
- \index[fd]{Offline On Unmount }
+\item [Offline On Unmount = {\it Yes|No}]
+ \index[sd]{Offline On Unmount }
The default for this directive is {\bf No}. If {\bf Yes} the archive device
-must support the {\tt MTOFFL ioctl} to rewind and take the volume offline. In
-this case, Bacula will issue the offline (eject) request before closing the
-device during the {\bf unmount} command. If {\bf No} Bacula will not attempt
-to offline the device before unmounting it. After an offline is issued, the
-cassette will be ejected thus {\bf requiring operator intervention} to
-continue, and on some systems require an explicit load command to be issued
-({\bf mt -f /dev/xxx load}) before the system will recognize the tape. If you
-are using an autochanger, some devices require an offline to be issued prior
-to changing the volume. However, most devices do not and may get very
-confused.
-
-\item [Maximum Volume Size = {\it size} ]
- \index[fd]{Maximum Volume Size }
+ must support the {\tt MTOFFL ioctl} to rewind and take the volume offline. In
+ this case, Bacula will issue the offline (eject) request before closing the
+ device during the {\bf unmount} command. If {\bf No} Bacula will not attempt
+ to offline the device before unmounting it. After an offline is issued, the
+ cassette will be ejected thus {\bf requiring operator intervention} to
+ continue, and on some systems require an explicit load command to be issued
+ ({\bf mt -f /dev/xxx load}) before the system will recognize the tape. If you
+ are using an autochanger, some devices require an offline to be issued prior
+ to changing the volume. However, most devices do not and may get very
+ confused.
+
+ If you are using a Linux 2.6 kernel or other OSes
+ such as FreeBSD or Solaris, the Offline On Unmount will leave the drive
+ with no tape, and Bacula will not be able to properly open the drive and
+ may fail the job. For more information on this problem, please see the
+ \ilink{description of Offline On Unmount}{NoTapeInDrive} in the Tape
+ Testing chapter.
+
+
+\item [Maximum Volume Size = {\it size}]
+ \index[sd]{Maximum Volume Size }
No more than {\bf size} bytes will be written onto a given volume on the
-archive device. This directive is used mainly in testing Bacula to simulate a
-small Volume. It can also be useful if you wish to limit the size of a File
-Volume to say less than 2GB of data. In some rare cases of really antiquated
-tape drives that do not properly indicate when the end of a tape is reached
-during writing (though I have read about such drives, I have never personally
-encountered one). Please note, this directive is deprecated (being phased
-out) in favor of the {\bf Maximum Volume Bytes} defined in the Director's
-configuration file.
-
-\item [Maximum File Size = {\it size} ]
- \index[fd]{Maximum File Size }
+ archive device. This directive is used mainly in testing Bacula to simulate a
+ small Volume. It can also be useful if you wish to limit the size of a File
+ Volume to say less than 2GB of data. In some rare cases of really antiquated
+ tape drives that do not properly indicate when the end of a tape is reached
+ during writing (though I have read about such drives, I have never personally
+ encountered one). Please note, this directive is deprecated (being phased
+ out) in favor of the {\bf Maximum Volume Bytes} defined in the Director's
+ configuration file.
+
+\item [Maximum File Size = {\it size}]
+ \index[sd]{Maximum File Size }
No more than {\bf size} bytes will be written into a given logical file on
-the volume. Once this size is reached, an end of file mark is written on the
-volume and subsequent data are written into the next file. Breaking long
-sequences of data blocks with file marks permits quicker positioning to the
-start of a given stream of data and can improve recovery from read errors on
-the volume. The default is one Gigabyte.
-
-\item [Block Positioning = {\it yes|no} ]
- \index[fd]{Block Positioning }
+ the volume. Once this size is reached, an end of file mark is written on the
+ volume and subsequent data are written into the next file. Breaking long
+ sequences of data blocks with file marks permits quicker positioning to the
+ start of a given stream of data and can improve recovery from read errors on
+ the volume. The default is one Gigabyte.
+
+\item [Block Positioning = {\it yes|no}]
+ \index[sd]{Block Positioning }
This directive is not normally used (and has not yet been tested). It will
-tell Bacula not to use block positioning when it is reading tapes. This can
-cause Bacula to be {\bf extremely} slow when restoring files. You might use
-this directive if you wrote your tapes with Bacula in variable block mode
-(the default), but your drive was in fixed block mode. If it then works as I
-hope, Bacula will be able to re-read your tapes.
-
-\item [Maximum Network Buffer Size = {\it bytes} ]
- \index[fd]{Maximum Network Buffer Size }
+ tell Bacula not to use block positioning when it is reading tapes. This can
+ cause Bacula to be {\bf extremely} slow when restoring files. You might use
+ this directive if you wrote your tapes with Bacula in variable block mode
+ (the default), but your drive was in fixed block mode. If it then works as I
+ hope, Bacula will be able to re-read your tapes.
+
+\item [Maximum Network Buffer Size = {\it bytes}]
+ \index[sd]{Maximum Network Buffer Size }
where {\it bytes} specifies the initial network buffer size to use with the
-File daemon. This size will be adjusted down if it is too large until it is
-accepted by the OS. Please use care in setting this value since if it is too
-large, it will be trimmed by 512 bytes until the OS is happy, which may
-require a large number of system calls. The default value is 32,768 bytes.
-
-\item [Maximum Spool Size = {\it bytes} ]
- \index[fd]{Maximum Spool Size }
+ File daemon. This size will be adjusted down if it is too large until
+ it is accepted by the OS. Please use care in setting this value since if
+ it is too large, it will be trimmed by 512 bytes until the OS is happy,
+ which may require a large number of system calls. The default value is
+ 32,768 bytes.
+
+ The default size was chosen to be relatively large but not too big in
+ the case that you are transmitting data over Internet. It is clear that
+ on a high speed local network, you can increase this number and improve
+ performance. For example, some users have found that if you use a value
+ of 65,536 bytes they get 5-10 times the throughput. Larger values for
+ most users don't seem to improve performance. If you are interested
+ in improving your backup speeds, this is definitely a place to
+ experiment. You will probably also want to make the corresponding change
+ in each of your File daemons conf files.
+
+
+\item [Maximum Spool Size = {\it bytes}]
+ \index[sd]{Maximum Spool Size }
where the bytes specify the maximum spool size for all jobs that are running.
-The default is no limit.
+ The default is no limit.
-\item [Maximum Job Spool Size = {\it bytes} ]
- \index[fd]{Maximum Job Spool Size }
+\item [Maximum Job Spool Size = {\it bytes}]
+ \index[sd]{Maximum Job Spool Size }
where the bytes specify the maximum spool size for any one job that is
-running. The default is no limit.
+ running. The default is no limit.
+ This directive is implemented only in version 1.37 and later.
-\item [Spool Directory = {\it directory} ]
- \index[dir]{Spool Directory }
+\item [Spool Directory = {\it directory}]
+ \index[sd]{Spool Directory }
specifies the name of the directory to be used to store the spool files for
-this device. This directory is also used to store temporary part files when
-writing to a device that requires mount (DVD). The default is to use the
-working directory.
+ this device. This directory is also used to store temporary part files when
+ writing to a device that requires mount (DVD). The default is to use the
+ working directory.
-\item [Maximum Part Size = {\it bytes} ]
- \index[dir]{Maximum Part Size }
+\item [Maximum Part Size = {\it bytes}]
+ \index[sd]{Maximum Part Size }
This is the maximum size of a volume part file. The default is no limit.
+ This directive is implemented only in version 1.37 and later.
+
+ If the device requires mount, it is transfered to the device when this size
+ is reached. In this case, you must take care to have enough disk space left
+ in the spool directory.
-If the device requires mount, it is transfered to the device when this size
-is reached. In this case, you must take care to have enough disk space left
-in the spool directory.
+ Otherwise, it is left on the hard disk.
+
+ It is ignored for tape and FIFO devices.
-Otherwise, it is left on the hard disk.
-It is ignored for tape and FIFO devices.
\end{description}
-\subsection*{Devices that requires mount (DVD)}
-\index[general]{Devices that requires mount (DVD) }
-\index[general]{DVD!Devices that requires mount }
-\addcontentsline{toc}{subsection}{Devices that requires mount (DVD)}
+\subsection*{Devices that require a mount (DVD)}
+\index[general]{Devices that require a mount (DVD)}
+\index[general]{DVD!Devices that require a mount}
+\addcontentsline{toc}{subsection}{Devices that require a mount (DVD)}
+
+All the directives in this section are implemented only in
+Bacula version 1.37 and later.
\begin{description}
-\item [Requires Mount = {\it Yes|No} ]
- \index[dir]{Requires Mount }
+\item [Requires Mount = {\it Yes|No}]
+ \index[sd]{Requires Mount }
You must set this directive to {\bf yes} for DVD-writers, and to {\bf no} for
-all other devices (tapes/files). This directive indicates if the device
-require to be mounted to be read, and if it must be written in a special way.
-If it set, {\bf Mount Point}, {\bf Mount Command}, {\bf Unmount Command} and
-{\bf Write Part Command} directives must be defined.
+ all other devices (tapes/files). This directive indicates if the device
+ requires to be mounted to be read, and if it must be written in a special way.
+ If it set, {\bf Mount Point}, {\bf Mount Command}, {\bf Unmount Command} and
+ {\bf Write Part Command} directives must also be defined.
-\item [Mount Point = {\it directory} ]
- \index[dir]{Mount Point }
- Directory where the device must be mounted.
+\item [Mount Point = {\it directory}]
+ \index[sd]{Mount Point }
+ Directory where the device can be mounted.
-\item [Mount Command = {\it name-string} ]
- \index[dir]{Mount Command }
+\item [Mount Command = {\it name-string}]
+ \index[sd]{Mount Command }
Command that must be executed to mount the device. Before the command is
-executed, \%a is replaced with the Archive Device, and \%m with the Mount
-Point.
+ executed, \%a is replaced with the Archive Device, and \%m with the Mount
+ Point.
-Most frequently, you will define it as follows:
+ Most frequently, you will define it as follows:
\footnotesize
\begin{verbatim}
-Mount Command = "/bin/mount -t iso9660 -o ro %a %m"
-
+ Mount Command = "/bin/mount -t iso9660 -o ro %a %m"
\end{verbatim}
\normalsize
-\item [Unmount Command = {\it name-string} ]
- \index[dir]{Unmount Command }
+\item [Unmount Command = {\it name-string}]
+ \index[sd]{Unmount Command }
Command that must be executed to unmount the device. Before the command is
-executed, \%a is replaced with the Archive Device, and \%m with the Mount
-Point.
+ executed, \%a is replaced with the Archive Device, and \%m with the Mount
+ Point.
-Most frequently, you will define it as follows:
+ Most frequently, you will define it as follows:
\footnotesize
\begin{verbatim}
-Unmount Command = "/bin/umount %m"
-
+ Unmount Command = "/bin/umount %m"
\end{verbatim}
\normalsize
-\item [Write Part Command = {\it name-string} ]
- \index[dir]{Write Part Command }
+\item [Write Part Command = {\it name-string}]
+ \index[sd]{Write Part Command }
Command that must be executed to write a part to the device. Before the
-command is executed, \%a is replaced with the Archive Device, \%m with the
-Mount Point, \%n with the current part number (0-based), and \%v with the
-current part filename.
+ command is executed, \%a is replaced with the Archive Device, \%m with the
+ Mount Point, \%e is replaced with 1 if we are writing the first part,
+ and with 0 otherwise, and \%v with the current part filename.
-For DVD, you will most frequently specify the Bacula supplied {\bf
-dvd-writepart} script as follows:
+ For a DVD, you will most frequently specify the Bacula supplied {\bf
+ dvd-writepart} script as follows:
\footnotesize
\begin{verbatim}
-Write Part Command = "/path/dvd-writepart %n %a %v"
-
+ Write Part Command = "/path/dvd-writepart %e %a %v"
\end{verbatim}
\normalsize
-\item [Free Space Command = {\it name-string} ]
- \index[dir]{Free Space Command }
+ Where {\bf /path} is the path to your scripts install directory, and
+ dvd-writepart is the Bacula supplied script file.
+ This command will already be present, but commented out,
+ in the default bacula-sd.conf file. To use it, simply remove
+ the comment (\#) symbol.
+
+
+\item [Free Space Command = {\it name-string}]
+ \index[sd]{Free Space Command }
Command that must be executed to check how much free space is left on the
-device. Before the command is executed, \%a is replaced with the Archive
-Device, \%m with the Mount Point, \%n with the current part number (0-based),
-and \%v with the current part filename.
+ device. Before the command is executed,\%a is replaced with the Archive
+ Device, \%m with the Mount Point, \%e is replaced with 1 if we are writing
+ the first part, and with 0 otherwise, and \%v with the current part filename.
-For DVD, you will most frequently specify the Bacula supplied {\bf
-dvd-freespace} script as follows:
+ For a DVD, you will most frequently specify the Bacula supplied {\bf
+ dvd-freespace} script as follows:
\footnotesize
\begin{verbatim}
-Free Space Command = "/path/dvd-freespace %n %a"
-
+ Free Space Command = "/path/dvd-freespace %a"
\end{verbatim}
\normalsize
-If you want to specify your own command, please look at the code of
-dvd-freespace to see what output Bacula expects from this command.
+ Where {\bf /path} is the path to your scripts install directory, and
+ dvd-freespace is the Bacula supplied script file.
+ If you want to specify your own command, please look at the code of
+ dvd-freespace to see what output Bacula expects from this command.
+ This command will already be present, but commented out,
+ in the default bacula-sd.conf file. To use it, simply remove
+ the comment (\#) symbol.
-If you do not set it, Bacula will expect there is always free space on the
-device.
+ If you do not set it, Bacula will expect there is always free space on the
+ device.
\end{description}
-\subsection*{Parallelism}
-\index[general]{Parallelism }
-\addcontentsline{toc}{subsection}{Parallelism}
-
-\begin{description}
-
-\item [Maximum Concurrent Jobs = {\it positive integer} ]
- \index[dir]{Maximum Concurrent Jobs }
- The storage daemon will accept no more than the given {\bf positive integer}
-of simultaneous connections. The default is 10. It is best to set this number
-fairly large (e.g. 10 or 20) and control how many Jobs are running with the
-{\bf Maximum Concurrent Jobs} in the Storage resource in the Director's
-configuration file.
-
-\end{description}
+\label{AutochangerRes}
+\label{AutochangerResource1}
+\input{autochangerres}
\subsection*{Capabilities}
-\index[general]{Capabilities }
+\index[general]{Capabilities}
\addcontentsline{toc}{subsection}{Capabilities}
\begin{description}
-\item [Label media = {\it Yes|No} ]
- \index[sd]{Label media }
+\item [Label media = {\it Yes|No}]
+ \index[sd]{Label media }
If {\bf Yes}, permits this device to automatically label blank media without
-an explicit operator command. It does so by using an internal algorithm as
-defined on the
-\ilink{Label Format }{Label} record in each Pool resource. If
-this is {\bf No} as by default, Bacula will label tapes only by specific
-operator command ({\bf label} in the Console) or when the tape has been
-recycled. The automatic labeling feature is most useful when writing to disk
-rather than tape volumes.
-
-\item [Automatic mount = {\it Yes|No} ]
- \index[sd]{Automatic mount }
- If {\bf Yes} (the default), permits the daemon to examine the device to
-determine if it contains a Bacula labeled volume. This is done initially when
-the daemon is started, and then at the beginning of each job. This directive
-is particularly important if you have set {\bf Always Open = no} because it
-permits Bacula to attempt to read the device before asking the system
-operator to mount a tape.
+ an explicit operator command. It does so by using an internal algorithm as
+ defined on the
+ \ilink{Label Format}{Label} record in each Pool resource. If
+ this is {\bf No} as by default, Bacula will label tapes only by specific
+ operator command ({\bf label} in the Console) or when the tape has been
+ recycled. The automatic labeling feature is most useful when writing to disk
+ rather than tape volumes.
+
+\item [Automatic mount = {\it Yes|No}]
+ \index[sd]{Automatic mount }
+ If {\bf Yes} (the default), permits the daemon to examine the device to
+ determine if it contains a Bacula labeled volume. This is done
+ initially when the daemon is started, and then at the beginning of each
+ job. If the This directive is particularly important if you have set
+ {\bf Always Open = no} because it permits Bacula to attempt to read the
+ device before asking the system operator to mount a tape. However,
+ please note that the tape must be mounted before the job begins.
\end{description}
\subsection*{Messages Resource}
\label{MessagesResource1}
-\index[general]{Resource!Messages }
-\index[general]{Messages Resource }
+\index[general]{Resource!Messages}
+\index[general]{Messages Resource}
\addcontentsline{toc}{subsection}{Messages Resource}
For a description of the Messages Resource, please see the
\subsection*{Sample Storage Daemon Configuration File}
\label{SampleConfiguration}
-\index[general]{File!Sample Storage Daemon Configuration }
-\index[general]{Sample Storage Daemon Configuration File }
+\index[general]{File!Sample Storage Daemon Configuration}
+\index[general]{Sample Storage Daemon Configuration File}
\addcontentsline{toc}{subsection}{Sample Storage Daemon Configuration File}
A example Storage Daemon configuration file might be the following:
#
# Default Bacula Storage Daemon Configuration file
#
-# For Bacula release 1.35.2 (16 August 2004) -- gentoo 1.4.16
+# For Bacula release 1.37.2 (07 July 2005) -- gentoo 1.4.16
#
# You may need to change the name of your tape drive
# on the "Archive Device" directive in the Device
Address = rufus
WorkingDirectory = "$HOME/bacula/bin/working"
Pid Directory = "$HOME/bacula/bin/working"
- Maximum Concurrent Jobs = 1
+ Maximum Concurrent Jobs = 20
}
#
# List Directors who are permitted to contact Storage daemon
# To connect, the Director's bacula-dir.conf must have the
# same Name and MediaType.
#
+Autochanger {
+ Name = Autochanger
+ Device = Drive-1
+ Device = Drive-2
+ Changer Command = "/home/kern/bacula/bin/mtx-changer %c %o %S %a %d"
+ Changer Device = /dev/sg0
+}
+
+Device {
+ Name = Drive-1 #
+ Drive Index = 0
+ Media Type = DLT-8000
+ Archive Device = /dev/nst0
+ AutomaticMount = yes; # when device opened, read it
+ AlwaysOpen = yes;
+ RemovableMedia = yes;
+ RandomAccess = no;
+ AutoChanger = yes
+ Alert Command = "sh -c 'tapeinfo -f %c |grep TapeAlert|cat'"
+}
+
+Device {
+ Name = Drive-2 #
+ Drive Index = 1
+ Media Type = DLT-8000
+ Archive Device = /dev/nst1
+ AutomaticMount = yes; # when device opened, read it
+ AlwaysOpen = yes;
+ RemovableMedia = yes;
+ RandomAccess = no;
+ AutoChanger = yes
+ Alert Command = "sh -c 'tapeinfo -f %c |grep TapeAlert|cat'"
+}
+
Device {
Name = "HP DLT 80"
Media Type = DLT8000
# MountCommand = "/bin/mount -t iso9660 -o ro %a %m";
# UnmountCommand = "/bin/umount %m";
# SpoolDirectory = /tmp/backup;
-# WritePartCommand = "/etc/bacula/dvd-writepart %n %a %v"
-# FreeSpaceCommand = "/etc/bacula/dvd-freespace %a %n"
+# WritePartCommand = "/etc/bacula/dvd-writepart %e %a %v"
+# FreeSpaceCommand = "/etc/bacula/dvd-freespace %a"
#}
#
# A very old Exabyte with no end of media detection
mount the tape and resume the backup. Otherwise, you simply {\bf mount} the
tape.
-Using this strategy, one typically does a Full backup once a week following by
+Using this strategy, one typically does a Full backup once a week followed by
daily Incremental backups. To minimize the amount of data written to the tape,
-once can do (as I do) a Full backup once a month on the first Sunday of the
+one can do (as I do) a Full backup once a month on the first Sunday of the
month, a Differential backup on the 2nd-5th Sunday of the month, and
incremental backups the rest of the week.
\label{Manual}
\addcontentsline{toc}{subsection}{Manually Changing Tapes}
If you use the strategy presented above, Bacula will ask you to change the
-tape, and you will {\bf unmount} it and the remount it when you have inserted
+tape, and you will {\bf unmount} it and then remount it when you have inserted
the new tape.
If you do not wish to interact with Bacula to change each tape, there are
command would tell Bacula to rewind the tape and on the next job assume the
tape has changed. This strategy may not work on some systems, or on
autochangers because Bacula will still keep the drive open.
-\item The final strategy is the similar to the previous case except that you
+\item The final strategy is similar to the previous case except that you
would use the unmount command to force Bacula to release the drive. Then you
would eject the tape, and remount it as follows:
\index[general]{Practical Details }
\addcontentsline{toc}{subsubsection}{Practical Details}
-The simplest way to ``force'' Bacula to use a different tape each day is to
+The simplest way to "force" Bacula to use a different tape each day is to
define a different Pool for each day of the the week a backup is done. In
addition, you will need to specify appropriate Job and File retention periods
so that Bacula will relabel and overwrite the tape each week rather than
%%
%%
-\section*{Using Bacula to Encrypt Communications to Clients}
+\section*{Using stunnel to Encrypt Communications to Clients}
\label{_ChapterStart6}
\index[general]{Clients!Using Bacula to Encrypt Communications to }
\index[general]{Using Bacula to Encrypt Communications to Clients }
\addcontentsline{toc}{section}{Using Bacula to Encrypt Communications to
Clients}
-At the current time, Bacula does not have built-in communications encryption.
-However, without too much effort, it is possible to encrypt the communications
+Prior to version 1.37, Bacula did not have built-in communications encryption.
+Please see the TLS chapter if you are using Bacula 1.37 or greater.
+
+Without too much effort, it is possible to encrypt the communications
between any of the daemons. This chapter will show you how to use {\bf
stunnel} to encrypt communications to your client programs. We assume the
Director and the Storage daemon are running on one machine that will be called
First, you must know that with the standard Bacula configuration, the Director
will contact the File daemon on port 9102. The File daemon then contacts the
Storage daemon using the address and port parameters supplied by the Director.
-The standard port used will be 9103. This in the typical server/client view of
+The standard port used will be 9103. This is the typical server/client view of
the world, the File daemon is a server to the Director (i.e. listens for the
Director to contact it), and the Storage daemon is a server to the File
-daemon.
+daemon.
\subsection*{Encryption}
\index[general]{Encryption }
The encryption is accomplished between the Director and the File daemon by
using an stunnel on the Director's machine (server) to encrypt the data and to
-contact a stunnel on the File daemon's machine (client), which decrypts the
+contact an stunnel on the File daemon's machine (client), which decrypts the
data and passes it to the client.
Between the File daemon and the Storage daemon, we use an stunnel on the File
daemon's machine to encrypt the data and another stunnel on the Storage
daemon's machine to decrypt the data.
-As a consequence, there are actually four copies of stunnel running, two on
-server and two on client. This may sound a bit complicated, but it really
+As a consequence, there are actually four copies of stunnel running, two on the
+server and two on the client. This may sound a bit complicated, but it really
isn't. To accomplish this, we will need to construct four separate conf files
for stunnel, and we will need to make some minor modifications to the
Director's conf file. None of the other conf files need to be changed.
To simplify things a bit, let's for the moment consider only the data channel.
That is the connection between the File daemon and the Storage daemon, which
takes place on port 9103. In fact, in a minimalist solution, this is the only
-connection needs to be encrypted, because it is the one that transports your
+connection that needs to be encrypted, because it is the one that transports your
data. The connection between the Director and the File daemon is simply a
control channel used to start the job and get the job status.
Normally the File daemon will contact the Storage daemon on port 9103
-(supplied by the Director), so we need a stunnel that listens on port 9103 on
+(supplied by the Director), so we need an stunnel that listens on port 9103 on
the File daemon's machine, encrypts the data and sends it to the Storage
daemon. This is depicted by Stunnel 2 above. Note that this stunnel is
listening on port 9103 and sending to server:29103. We use port 29103 on the
-server because if we sent the data to port 9103, it would go directly to the
+server because if we would send the data to port 9103, it would go directly to the
Storage daemon, which doesn't understand encrypted data. On the server
machine, we run Stunnel 4, which listens on port 29103, decrypts the data and
sends it to the Storage daemon, which is listening on port 9103.
\addcontentsline{toc}{subsection}{config Files for stunnel to Encrypt the Data
Channel}
-In the diagram above, we see above Stunnel 2 that we stunnel-fd2.conf on
+In the diagram above, we see above Stunnel 2 that we use stunnel-fd2.conf on the
client. A pretty much minimal config file would look like the following:
\footnotesize
\addcontentsline{toc}{subsection}{Creating a Self-signed Certificate}
You may create a self-signed certificate for use with stunnel that will permit
-you to make it function, but will now allow certificate validation. The .pem
+you to make it function, but will not allow certificate validation. The .pem
file containing both the certificate and the key can be made with the
following, which I put in a file named {\bf makepem}:
#
OPENSSL=openssl
umask 77
- PEM1=`/bin/mktemp openssl.XXXXXX`
- PEM2=`/bin/mktemp openssl.XXXXXX`
+ PEM1="/bin/mktemp openssl.XXXXXX"
+ PEM2="/bin/mktemp openssl.XXXXXX"
${OPENSSL} req -newkey rsa:1024 -keyout $PEM1 -nodes \
-x509 -days 365 -out $PEM2
cat $PEM1 > stunnel.pem
\section*{Supported Autochangers}
\label{_ChapterStart21}
-\index[general]{Autochangers!Supported }
-\index[general]{Supported Autochangers }
\addcontentsline{toc}{section}{Supported Autochangers}
-\subsection*{Supported Autochangers}
+\subsection*{Supported Autochanger Models}
\label{Models}
-\index[general]{Autochangers!Supported }
-\index[general]{Supported Autochangers }
-\addcontentsline{toc}{subsection}{Supported Autochangers}
+\index[general]{Supported Autochanger Models}
+\index[general]{Autochangers!Supported}
+\addcontentsline{toc}{subsection}{Supported Autochanger Models}
+
+I hesitate to call these "supported" autochangers because the only
+autochangers that I have in my possession and am able to test are the HP
+SureStore DAT40X6 and the Overland PowerLoader LTO-2. All the other
+autochangers have been reported to work by Bacula users. Note, in the
+Capacity/Slot column below, I quote the Compressed capacity per tape (or
+Slot).
-I hesitate to call these ``supported'' autochangers because the only
-autochanger that I have in my possession and am able to test is the HP
-SureStore DAT40X6. All the other autochangers have been reported to work by
-Bacula users. Note, in the Capacity/Slot column below, I quote the Compressed
-capacity per tape (or Slot).
\addcontentsline{lot}{table}{Autochangers Known to Work with Bacula}
-\begin{longtable}{|p{0.6in}|p{0.8in}|p{0.9in}|p{0.8in}|p{0.5in}|p{0.75in}|}
+\begin{longtable}{|p{0.6in}|p{0.8in}|p{1.9in}|p{0.8in}|p{0.5in}|p{0.75in}|}
\hline
\multicolumn{1}{|c| }{\bf OS } & \multicolumn{1}{c| }{\bf Man. } &
\multicolumn{1}{c| }{\bf Media } & \multicolumn{1}{c| }{\bf Model } &
\multicolumn{1}{c| }{\bf Slots } & \multicolumn{1}{c| }{\bf Cap/Slot } \\
- \hline
-{Linux } & {Adic } & {LTO-1/2, SDLT 320 } & {Adic Scalar 24 } & {24} & {100GB
-} \\
- \hline
-{Linux } & {Adic } & {LTO-2 } & {Adic FastStor 2, Sun Storedge L8 } & {8} &
-{200GB } \\
- \hline
-{- } & {Dell } & {LTO-2 } & {PowerValut 132T/136T } & {-} & {100GB } \\
- \hline
-{Linux } & {Exabyte } & {VXA2 } & {VXA PacketLoader 1x10 2U } & {10} &
-{80/160GB } \\
- \hline
-{Linux Gentoo 1.4 } & {Exabyte } & {AIT-2 } & {215A } & {15 (2 drives)} &
-{50GB } \\
- \hline
-{Linux } & {HP } & {DDS-4 } & {SureStore DAT-40X6 } & {6 } & {40GB } \\
- \hline
-{Linux } & {HP } & {Ultrium-2/LTO } & {MSL 6000/ 60030/ 5052 } & {28 } &
-{200/400GB } \\
- \hline
-{- } & {HP } & {DLT } & {A4853 DLT } & {30} & {40/70GB } \\
- \hline
-{Linux } & {HP (Compaq) } & {DLT VI } & {Compaq TL-895 } & {96+4 import
-export} & {35/70GB } \\
- \hline
-{SuSE 9.0 } & {IBM } & {LTO } & {IBM 3581 Ultrium Tape Loader } & {7} &
-{200/400GB } \\
- \hline
-{- } & {Overland } & {LTO } & {Overland LoaderXpress LTO } & {10-19} & {100GB
-} \\
- \hline
-{- } & {Overland } & {LTO } & {Overland Neo2000 LTO } & {26-30} & {100GB } \\
- \hline
-{FreeBSD 4.9 } & {QUALSTAR TLS-4210 (Qualstar) } & {AIT1: 36GB, AIT2: 50GB all
-uncomp } & {QUALSTAR TLS-4210 } & {12} & {AIT1: 36GB, AIT2: 50GB all uncomp }
-\\
- \hline
-{Linux } & {Skydata } & {DLT } & {ATL-L200 } & {8} & {40/80 } \\
- \hline
-{- } & {Sony } & {DDS-4 } & {TSL-11000 } & {8} & {40GB } \\
- \hline
-{Linux } & {Sony } & {AIT-2 } & {LIB-304(SDX-500C) } & {?} & {200GB } \\
- \hline
-{FreeBSD 4.9-STABLE } & {Sony } & {AIT-1 } & {TSL-SA300C } & {4} & {45/70GB }
-\\
- \hline
-{- } & {Storagetek } & {DLT } & {Timberwolf DLT } & {6} & {40/70 } \\
- \hline
-{Solaris } & {Sun } & {4mm DLT } & {Sun Desktop Archive Python 29279 } & {4} &
-{20GB } \\
- \hline
-{Linux } & {Tandberg } & {DLT VI } & {VS 640 } & {8?} & {35/70GB } \\
- \hline
-{Linux 2.6.x } & {Tandberg Data } & {SLR100 } & {SLR100 Autoloader } & {8} &
-{50/100GB }
-\\ \hline
+ \hline {Linux } & {Adic } & {DDS-3} & {Adic 1200G } & {12} & {-} \\
+ \hline {Linux } & {Adic } & {DLT} & {FastStore 4000 } & {7} & {20GB} \\
+ \hline {Linux } & {Adic } & {LTO-1/2, SDLT 320 } & {Adic Scalar 24 } & {24} & {100GB } \\
+ \hline {Linux } & {Adic } & {LTO-2 } & {Adic FastStor 2, Sun Storedge L8 } & {8} & {200GB } \\
+ \hline {- } & {CA-VM } & {?? } & {Tape } & {??} & {?? } \\
+ \hline {Linux Gentoo} & {Dell} & {DLT VI,LTO-2} & {PowerVault 122T/132T/136T } & {-} & {100GB } \\
+ \hline {- } & {DFSMS } & {?? } & {VM RMM} & {-} & {?? } \\
+ \hline {z/VM } & {IBM } & {?? } & {IBM Tape Manager } & {-} & {?? } \\
+ \hline {z/VM } & {IBM } & {?? } & {native tape } & {-} & {?? } \\
+ \hline {Linux } & {Exabyte } & {VXA2 } & {VXA PacketLoader 1x10 2U } & {10} & {80/160GB } \\
+ \hline {- } & {Exabyte } & {LTO } & {Magnum 1x7 LTO Tape Auotloader } & {7} & {200/400GB } \\
+ \hline {Linux Gentoo 1.4 } & {Exabyte } & {AIT-2 } & {215A } & {15 (2 drives)} & {50GB } \\
+ \hline {Linux } & {HP } & {DDS-4 } & {SureStore DAT-40X6 } & {6 } & {40GB } \\
+ \hline {Linux } & {HP } & {Ultrium-2/LTO } & {MSL 6000/ 60030/ 5052 } & {28 } & {200/400GB } \\
+ \hline {- } & {HP } & {DLT } & {A4853 DLT } & {30} & {40/70GB } \\
+ \hline {Linux } & {HP (Compaq) } & {DLT VI } & {Compaq TL-895 } & {96+4 import export} & {35/70GB } \\
+ \hline {SuSE 9.0 } & {IBM } & {LTO } & {IBM 3581 Ultrium Tape Loader } & {7} & {200/400GB } \\
+ \hline {FreeBSD 5.4} & {IBM } & {DLT} & {IBM 3502-R14 -- rebranded ATL L-500} & {14} & {35/70GB } \\
+ \hline {Debian} & {Overland } & {LTO } & {Overland LoaderXpress LTO/DLT8000 } & {10-19} & {40-100GB } \\
+ \hline {Fedora} & {Overland } & {LTO } & {Overland PowerLoader LTO-2 } & {10-19} & {200/400GB } \\
+ \hline {FreeBSD 5.4-Stable} & {Overland} & {LTO-2} & {Overland Powerloader tape} & {17} & {100GB } \\
+ \hline {- } & {Overland} & {LTO } & {Overland Neo2000 LTO } & {26-30} & {100GB } \\
+ \hline {- } & {Quantum } & {?? } & {Super Loader } & {??} & {?? } \\
+ \hline {FreeBSD 4.9 } & {QUALSTAR TLS-4210 (Qualstar) } & {AIT1: 36GB, AIT2: 50GB all
+uncomp } & {QUALSTAR TLS-4210 } & {12} & {AIT1: 36GB, AIT2: 50GB all uncomp }\\
+ \hline {Linux } & {Skydata } & {DLT } & {ATL-L200 } & {8} & {40/80 } \\
+ \hline {- } & {Sony } & {DDS-4 } & {TSL-11000 } & {8} & {40GB } \\
+ \hline {Linux } & {Sony } & {AIT-2} & {LIB-304(SDX-500C) } & {?} & {200GB } \\
+ \hline {Linux } & {Sony } & {AIT-3} & {LIB-D81) } & {?} & {200GB } \\
+ \hline {FreeBSD 4.9-STABLE } & {Sony } & {AIT-1 } & {TSL-SA300C } & {4} & {45/70GB }\\
+ \hline {- } & {Storagetek } & {DLT } & {Timberwolf DLT } & {6} & {40/70 } \\
+ \hline {- } & {Storagetek } & {?? } & {ACSLS } & {??} & {?? } \\
+ \hline {Solaris } & {Sun } & {4mm DLT } & {Sun Desktop Archive Python 29279 } & {4} & {20GB } \\
+ \hline {Linux } & {Tandberg } & {DLT VI } & {VS 640 } & {8?} & {35/70GB } \\
+ \hline {Linux 2.6.x } & {Tandberg Data } & {SLR100 } & {SLR100 Autoloader } & {8} & {50/100GB }\\
+\hline
\end{longtable}
-
\section*{Testing Your Tape Drive With Bacula}
\label{_ChapterStart27}
-\index[general]{Testing Your Tape Drive With Bacula }
+\index[general]{Testing Your Tape Drive With Bacula}
\addcontentsline{toc}{section}{Testing Your Tape Drive With Bacula}
This chapter is concerned with testing and configuring your tape drive to make
\label{summary}
\subsection*{Summary of Steps to Take to Get Your Tape Drive Working}
-\index[general]{Working!Summary of Steps to Take to Get Your Tape Drive }
-\index[general]{Summary of Steps to Take to Get Your Tape Drive Working }
+\index[general]{Working!Summary of Steps to Take to Get Your Tape Drive}
+\index[general]{Summary of Steps to Take to Get Your Tape Drive Working}
\addcontentsline{toc}{subsection}{Summary of Steps to Take to Get Your Tape
Drive Working}
\normalsize
It isn't necessary to run the autochanger part of the test at this time, but
-do not go past this point until the basic test succeeds.
-\item Run the btape {\bf fill} command, preferrably with two volumes. This
+do not go past this point until the basic test succeeds. If you do have
+an autochanger, please be sure to read the
+\ilink{Autochanger chapter}{_ChapterStart18} of this manual.
+
+\item Run the btape {\bf fill} command, preferably with two volumes. This
can take a long time. If you have an autochanger and it is configured, Bacula
- will automatically use it. If you do not have it configured, you can manual
-issue the appopriate {\bf mtx} command, or press the autochanger buttons to
-change the tape when requested to do so.
+ will automatically use it. If you do not have it configured, you can manually
+ issue the appopriate {\bf mtx} command, or press the autochanger buttons to
+ change the tape when requested to do so.
\item FreeBSD users, run the {\bf tapetest} program, and make sure your
system is patched if necessary. See below for more details.
\item Run Bacula, and backup a reasonably small directory, say 60 Megabytes.
completed. In particular, you may want to look at the
\ilink{ Tips for Resolving Problems}{problems1} section below.
+\label{NoTapeInDrive}
+\subsubsection*{Problems When no Tape in Drive}
+\index[general]{Problems When no Tape in Drive}
+\addcontentsline{toc}{subsubsection}{Problems When no Tape in Drive}
+When Bacula was first written the Linux 2.4 kernel permitted opening the
+drive whether or not there was a tape in the drive. Thus the Bacula code is
+based on the concept that if the drive cannot be opened, there is a serious
+problem, and the job is failed.
+
+With version 2.6 of the Linux kernel, if there is no tape in the drive, the
+OS will wait 2 minutes (default) then return a failure, and consequently,
+Bacula version 1.36 and below will fail the job. This is important to keep
+in mind, because if you use and option such as {\bf Offline on Unmount =
+yes}, there will be a point when there is no tape in the drive, and if
+another job starts or if Bacula asks the operator to mount a tape, when
+Bacula attempts to open the drive (about a 20 minute delay), it will fail
+and Bacula will fail the job.
+
+In version 1.38.x, the Bacula code partially gets around this problem -- at
+least in the initial open of the drive. However, functions like Polling
+the drive do not work correctly if there is no tape in the drive.
+Providing you do not use {\bf Offline on Unmount = yes}, you should not
+experience job failures as mentioned above. If you do experience such
+failures, you can also increase the {\bf Maximum Open Wait} time interval,
+which will give you more time to mount the next tape before the job is
+failed.
+
+
+
\subsubsection*{Specifying the Configuration File}
-\index[general]{File!Specifying the Configuration }
-\index[general]{Specifying the Configuration File }
+\index[general]{File!Specifying the Configuration}
+\index[general]{Specifying the Configuration File}
\addcontentsline{toc}{subsubsection}{Specifying the Configuration File}
Starting with version 1.27, each of the tape utility programs including the
(actually, the only part of the configuration file that {\bf btape} needs is
the {\bf Device} resource definitions). This permits {\bf btape} to find the
configuration parameters for your archive device (generally a tape drive).
-Without those parameters, the testing and utility programs do not no how to
+Without those parameters, the testing and utility programs do not know how to
properly read and write your drive. By default, they use {\bf bacula-sd.conf}
in the current directory, but you may specify a different configuration file
using the {\bf -c} option.
\subsubsection*{Specifying a Device Name For a Tape}
-\index[general]{Tape!Specifying a Device Name For a }
-\index[general]{Specifying a Device Name For a Tape }
+\index[general]{Tape!Specifying a Device Name For a}
+\index[general]{Specifying a Device Name For a Tape}
\addcontentsline{toc}{subsubsection}{Specifying a Device Name For a Tape}
{\bf btape} {\bf device-name} where the Volume can be found. In the case of a
specifying Volume names.
\subsubsection*{Specifying a Device Name For a File}
-\index[general]{File!Specifying a Device Name For a }
-\index[general]{Specifying a Device Name For a File }
+\index[general]{File!Specifying a Device Name For a}
+\index[general]{Specifying a Device Name For a File}
\addcontentsline{toc}{subsubsection}{Specifying a Device Name For a File}
If you are attempting to read or write an archive file rather than a tape, the
\subsection*{btape}
\label{btape1}
-\index[general]{Btape }
+\index[general]{Btape}
\addcontentsline{toc}{subsection}{btape}
This program permits a number of elementary tape operations via a tty command
option to specify where.
The physical device name or the Device resource name must be specified on the
-command line, and that this same device name must be present in the Storage
+command line, and this same device name must be present in the Storage
daemon's configuration file read by {\bf btape}
\footnotesize
-b <file> specify bootstrap file
-c <file> set configuration file to file
-d <nn> set debug level to nn
+ -p proceed inspite of I/O errors
-s turn off signals
-v be verbose
-? print this message.
\normalsize
\subsubsection*{Using btape to Verify your Tape Drive}
-\index[general]{Using btape to Verify your Tape Drive }
-\index[general]{Drive!Using btape to Verify your Tape }
+\index[general]{Using btape to Verify your Tape Drive}
+\index[general]{Drive!Using btape to Verify your Tape}
\addcontentsline{toc}{subsubsection}{Using btape to Verify your Tape Drive}
An important reason for this program is to ensure that a Storage daemon
your tape drive.
\subsubsection*{Linux SCSI Tricks}
-\index[general]{Tricks!Linux SCSI }
-\index[general]{Linux SCSI Tricks }
+\index[general]{Tricks!Linux SCSI}
+\index[general]{Linux SCSI Tricks}
\addcontentsline{toc}{subsubsection}{Linux SCSI Tricks}
You can find out what SCSI devices you have by doing:
\end{verbatim}
\normalsize
+The above represents first an autochanger and second a simple
+tape drive. The HP changer (the first entry) uses the same SCSI channel
+for data and for control, so in Bacula, you would use:
+\footnotesize
+\begin{verbatim}
+Archive Device = /dev/nst0
+Changer Device = /dev/sg0
+\end{verbatim}
+\normalsize
+
If you want to remove the SDT-10000 device, you can do so as root with:
\footnotesize
where the 2 0 4 0 are the Host, Channel, Id, and Lun as seen on the output
from {\bf cat /proc/scsi/scsi}. Note, the Channel must be specified as
numeric.
-\label{problems1}
+Below is a slightly more complicated output, which is a single autochanger
+with two drives, and which operates the changer on a different channel
+from from the drives:
+
+\footnotesize
+\begin{verbatim}
+Attached devices:
+Host: scsi0 Channel: 00 Id: 00 Lun: 00
+ Vendor: ATA Model: WDC WD1600JD-75H Rev: 08.0
+ Type: Direct-Access ANSI SCSI revision: 05
+Host: scsi2 Channel: 00 Id: 04 Lun: 00
+ Vendor: HP Model: Ultrium 2-SCSI Rev: F6CH
+ Type: Sequential-Access ANSI SCSI revision: 03
+Host: scsi2 Channel: 00 Id: 05 Lun: 00
+ Vendor: HP Model: Ultrium 2-SCSI Rev: F6CH
+ Type: Sequential-Access ANSI SCSI revision: 03
+Host: scsi2 Channel: 00 Id: 06 Lun: 00
+ Vendor: OVERLAND Model: LXB Rev: 0106
+ Type: Medium Changer ANSI SCSI revision: 02
+\end{verbatim}
+\normalsize
+
+The above tape drives are accessed on /dev/nst0 and /dev/nst1, while
+the control channel for those two drives is /dev/sg3.
+
+
+
+\label{problems1}
\subsection*{Tips for Resolving Problems}
-\index[general]{Problems!Tips for Resolving }
-\index[general]{Tips for Resolving Problems }
+\index[general]{Problems!Tips for Resolving}
+\index[general]{Tips for Resolving Problems}
\addcontentsline{toc}{subsection}{Tips for Resolving Problems}
\label{CannotRestore}
-
\subsubsection*{Bacula Saves But Cannot Restore Files}
-\index[general]{Files!Bacula Saves But Cannot Restore }
-\index[general]{Bacula Saves But Cannot Restore Files }
+\index[general]{Files!Bacula Saves But Cannot Restore}
+\index[general]{Bacula Saves But Cannot Restore Files}
\addcontentsline{toc}{subsubsection}{Bacula Saves But Cannot Restore Files}
If you are getting error messages such as:
tested).
\end{enumerate}
-\label{opendevice}
+If you are getting error messages such as:
+\footnotesize
+\begin{verbatim}
+Volume data error at 0:0!
+Block checksum mismatch in block=0 len=32625 calc=345678 blk=123456
+\end{verbatim}
+\normalsize
+
+You are getting tape read errors, and this is most likely due to
+one of the following things:
+\begin{enumerate}
+\item An old or bad tape.
+\item A dirty drive that needs cleaning (particularly for DDS drives).
+\item A loose SCSI cable.
+\item Old firmware in your drive. Make sure you have the latest firmware
+ loaded.
+\item Computer memory errors.
+\item Over-clocking your CPU.
+\item A bad SCSI card.
+\end{enumerate}
+
+\label{opendevice}
\subsubsection*{Bacula Cannot Open the Device}
-\index[general]{Device!Bacula Cannot Open the }
-\index[general]{Bacula Cannot Open the Device }
+\index[general]{Device!Bacula Cannot Open the}
+\index[general]{Bacula Cannot Open the Device}
\addcontentsline{toc}{subsubsection}{Bacula Cannot Open the Device}
If you get an error message such as:
\label{IncorrectFiles}
\subsubsection*{Incorrect File Number}
-\index[general]{Number!Incorrect File }
-\index[general]{Incorrect File Number }
+\index[general]{Number!Incorrect File}
+\index[general]{Incorrect File Number}
\addcontentsline{toc}{subsubsection}{Incorrect File Number}
When Bacula moves to the end of the medium, it normally uses the {\bf
retrieve the current file position from the {\bf mt\_fileno} field. Some SCSI
tape drivers will use a fast means of seeking to the end of the medium and in
doing so, they will not know the current file position and hence return a {\bf
--1}. As a consequence, if you get {\bf ``This is NOT correct!''} in the
+-1}. As a consequence, if you get {\bf "This is NOT correct!"} in the
positioning tests, this may be the cause. You must correct this condition in
order for Bacula to work.
\subsubsection*{Incorrect Number of Blocks or Positioning Errors during btape
Testing}
\index[general]{Testing!Incorrect Number of Blocks or Positioning Errors
-during btape }
+during btape}
\index[general]{Incorrect Number of Blocks or Positioning Errors during btape
-Testing }
+Testing}
\addcontentsline{toc}{subsubsection}{Incorrect Number of Blocks or Positioning
Errors during btape Testing}
below for the details on checking and setting the default drive block size.
To recover files from tapes written in fixed block mode, see below.
-\label{TapeModes}
+\label{TapeModes}
\subsubsection*{Ensuring that the Tape Modes Are Properly Set -- {\bf Linux
Only}}
-\index[general]{Ensuring that the Tape Modes Are Properly Set -- Linux Only }
-\index[general]{Only!Ensuring that the Tape Modes Are Properly Set -- Linux }
+\index[general]{Ensuring that the Tape Modes Are Properly Set -- Linux Only}
+\index[general]{Only!Ensuring that the Tape Modes Are Properly Set -- Linux}
\addcontentsline{toc}{subsubsection}{Ensuring that the Tape Modes Are Properly
Set -- Linux Only}
If you have a modern SCSI tape drive and you are having problems with the {\bf
test} command as noted above, it may be that some program has set one or more
-of the your SCSI driver's options to non-default values. For example, if your
+of your SCSI driver's options to non-default values. For example, if your
driver is set to work in SysV manner, Bacula will not work correctly because
it expects BSD behavior. To reset your tape drive to the default values, you
can try the following, but {\bf ONLY} if you have a SCSI tape drive on a {\bf
\end{verbatim}
\normalsize
-If you would like to know what stoptions you have set before making any of the
+If you would like to know what options you have set before making any of the
changes noted above, you can now view them on Linux systems, thanks to a tip
provided by Willem Riede. Do the following:
in variable block mode, it will attempt to set your drive appropriately. All
OSes permit setting variable block mode, but some OSes do not permit setting
the other modes that Bacula needs to function properly.
-\label{compression}
+\label{compression}
\subsubsection*{Checking and Setting Tape Hardware Compression and Blocking
Size}
\index[general]{Checking and Setting Tape Hardware Compression and Blocking
-Size }
+Size}
\index[general]{Size!Checking and Setting Tape Hardware Compression and
-Blocking }
+Blocking}
\addcontentsline{toc}{subsubsection}{Checking and Setting Tape Hardware
Compression and Blocking Size}
and of course, if you use a zero instead of the one at the end, you will turn
it off.
-You may also want to ensure that no prior program has set the default block
-size, as happened to one user, by explicitly turning it off with:
-
-\footnotesize
-\begin{verbatim}
-mt -f /dev/nst0 defblksize 0
-\end{verbatim}
-\normalsize
-
If you have built the {\bf mtx} program in the {\bf depkgs} package, you can
use tapeinfo to get quite a bit of information about your tape drive even if
it is not an autochanger. This program is called using the SCSI control
\normalsize
where the {\bf DataCompEnabled: yes} means that tape hardware compression is
-turned on. You can see it turn on and off (yes|no) by using the {\bf mt}
+turned on. You can turn it on and off (yes|no) by using the {\bf mt}
commands given above. Also, this output will tell you if the {\bf BlockSize}
is non-zero and hence set for a particular block size. Bacula is not likely to
work in such a situation because it will normally attempt to write blocks of
On FreeBSD, this would be something like: {\bf mt \ -f \ /dev/nsa0 \ blocksize
\ 0}.
+On some operating systems with some tape drives, the amount of data that
+can be written to the tape and whether or not compression is enabled is
+determined by the density usually the {\bf mt \ -f \ /dev/nst0 setdensity xxx} command.
+Often {\bf mt \ -f \ /dev/nst0 \ status} will print out the current
+density code that is used with the drive. Most systems, but unfortunately
+not all, set the density to the maximum by default. On some systems, you
+can also get a list of all available density codes with:
+{\bf mt \ -f \ /dev/nst0 \ densities} or a similar {\bf mt} command.
+Note, for DLT and SDLT devices, no-compression versus compression is very
+often controlled by the density code. On FreeBSD systems, the compression
+mode is set using {\bf mt \ -f \ /dev/nsa0 \ comp xxx} where xxx is the
+mode you want. In general, see {\bf man mt} for the options available on
+your system.
+
+
If your tape drive requires fixed block sizes (very unusual), you can use the
following records:
\label{FreeBSDTapes}
\subsubsection*{Tape Modes on FreeBSD}
-\index[general]{FreeBSD!Tape Modes on }
-\index[general]{Tape Modes on FreeBSD }
+\index[general]{FreeBSD!Tape Modes on}
+\index[general]{Tape Modes on FreeBSD}
\addcontentsline{toc}{subsubsection}{Tape Modes on FreeBSD}
On most FreeBSD systems such as 4.9 and most tape drives, Bacula should run
configuration is shown below, but does not work with all tape drives. Please
test carefully before putting either into production.
-Note, for FreeBSD 4.10-RELEASE, using a Sony TSL11000 L100 DDS4 w/Autochanger
-set to variable block size and DCLZ compression, Brian McDonald reports that
-to get Bacula to append correctly between Bacula executions, the correct
-values to use are:
+Note, for FreeBSD 4.10-RELEASE, using a Sony TSL11000 L100 DDS4 with an
+autochanger set to variable block size and DCLZ compression, Brian McDonald
+reports that to get Bacula to append correctly between Bacula executions,
+the correct values to use are:
\footnotesize
\begin{verbatim}
at the end of the tape, which works much more efficiently and reliably with
modern tape drives.
+Finally, here is a Device configuration that Danny Butroyd reports to work
+correctly with the Overland Powerloader tape library using LT0-2 and
+FreeBSD 5.4-Stable:
+
+\footnotesize
+\begin{verbatim}
+# Overland Powerloader LT02 - 17 slots single drive
+Device {
+ Name = Powerloader
+ Media Type = LT0-2
+ Archive Device = /dev/nsa0
+ AutomaticMount = yes;
+ AlwaysOpen = yes;
+ RemovableMedia = yes;
+ RandomAccess = no;
+ Changer Command = "/usr/local/sbin/mtx-changer %c %o %S %a %d"
+ Changer Device = /dev/pass2
+ AutoChanger = yes
+ Alert Command = "sh -c 'tapeinfo -f %c |grep TapeAlert|cat'"
+
+ # FreeBSD Specific Settings
+ Offline On Unmount = no
+ Hardware End of Medium = no
+ BSF at EOM = yes
+ Backward Space Record = no
+ Fast Forward Space File = no
+ TWO EOF = yes
+}
+\end{verbatim}
+\normalsize
+
+
\subsubsection*{Determining What Tape Drives and Autochangers You Have on
FreeBSD}
\index[general]{FreeBSD!Determining What Tape Drives and Autochangers You Have
-on }
+}
\index[general]{Determining What Tape Drives and Autochangers You Have on
-FreeBSD }
+FreeBSD}
\addcontentsline{toc}{subsubsection}{Determining What Tape Drives and
Autochangers You Have on FreeBSD}
\label{onstream}
\subsubsection*{Using the OnStream driver on Linux Systems}
-\index[general]{Using the OnStream driver on Linux Systems }
-\index[general]{Systems!Using the OnStream driver on Linux }
+\index[general]{Using the OnStream driver on Linux Systems}
+\index[general]{Systems!Using the OnStream driver on Linux}
\addcontentsline{toc}{subsubsection}{Using the OnStream driver on Linux
Systems}
Bacula version 1.33 (not 1.32x) is now working and ready for testing with the
OnStream kernel osst driver version 0.9.14 or above. Osst is available from:
-\elink{http://sourceforge.net/projects/osst/}{http://sourceforge.net/projects/%
-osst/}.
+\elink{http://sourceforge.net/projects/osst/}
+{http://sourceforge.net/projects/osst/}.
To make Bacula work you must first load the new driver then, as root, do:
\end{verbatim}
\normalsize
-\label{fill}
+\subsection*{Hardware Compresson on EXB-8900}
+\index[general]{Hardware Compression on EXB-8900}
+\index[general]{EXB-8900!Hardware Compression}
+\addcontentsline{to}{subsection}{Hardware Compression on EXB-8900}
+To active, check, or disable the hardware compression feature
+on an EXB-8900, use the exabyte MammothTool. You can get it here:
+\elink{http://www.exabyte.com/support/online/downloads/index.cfm}
+{http://www.exabyte.com/support/online/downloads/index.cfm}.
+There is a solaris version of this tool. With option -C 0 or 1 you
+can disable or activate compression. Start this tool without any
+options for a small reference.
-\subsubsection*{Using btape to Simulate Bacula Filling a Tape}
-\index[general]{Using btape to Simulate Bacula Filling a Tape }
-\index[general]{Tape!Using btape to Simulate Bacula Filling a }
-\addcontentsline{toc}{subsubsection}{Using btape to Simulate Bacula Filling a
+\label{fill}
+\subsubsection*{Using btape to Simulate Filling a Tape}
+\index[general]{Using btape to Simulate Filling a Tape}
+\index[general]{Tape!Using btape to Simulate Filling a}
+\addcontentsline{toc}{subsubsection}{Using btape to Simulate Filling a
Tape}
Because there are often problems with certain tape drives or systems when end
recover it. Note, there is also a single tape option as noted below, which you
should use rather than the two tape test. See below for more details.
-This can be an extremely time consuming process (here is is about 6 hours) to
+This can be an extremely time consuming process (here it is about 6 hours) to
fill a full tape. Note, that btape writes random data to the tape when it is
filling it. This has two consequences: 1. it takes a bit longer to generate
the data, especially on slow CPUs. 2. the total amount of data is
\label{RecoveringFiles}
\subsection*{Recovering Files Written to Tape With Fixed Block Sizes}
-\index[general]{Recovering Files Written to Tape With Fixed Block Sizes }
-\index[general]{Sizes!Recovering Files Written to Tape With Fixed Block }
+\index[general]{Recovering Files Written to Tape With Fixed Block Sizes}
+\index[general]{Sizes!Recovering Files Written to Tape With Fixed Block}
\addcontentsline{toc}{subsection}{Recovering Files Written to Tape With Fixed
Block Sizes}
VolBlock} lines in the file. When the file is re-written, answer the question,
and Bacula will run without using block positioning, and it should recover
your files.
-\label{BlockModes}
+\label{BlockModes}
\subsection*{Tape Blocking Modes}
-\index[general]{Modes!Tape Blocking }
-\index[general]{Tape Blocking Modes }
+\index[general]{Modes!Tape Blocking}
+\index[general]{Tape Blocking Modes}
\addcontentsline{toc}{subsection}{Tape Blocking Modes}
SCSI tapes may either be written in {\bf variable} or {\bf fixed} block sizes.
the Job to the correct size. Bacula expects variable tape block size drives to
behave as follows: Each write to the drive results in a single record being
written to the tape. Each read returns a single record. If you request less
-byte than are in the record, only those number of bytes will be returned, but
+bytes than are in the record, only those number of bytes will be returned, but
the entire logical record will have been read (the next read will retrieve the
next record). Thus data from a single write is always returned in a single
read, and sequentially written records are returned by sequential reads.
Bacula expects fixed block size tape drives to behave as follows: If a write
length is greater than the physical block size of the drive, the write will be
-written as two blocks each of the fixed physical size. This a single write may
+written as two blocks each of the fixed physical size. This single write may
become multiple physical records on the tape. (This is not a good situation).
According to the documentation, one may never write an amount of data that is
not the exact multiple of the blocksize (it is not specified if an error
assumes that each write causes a single record to be written, and that it can
sequentially recover each of the blocks it has written by using the same
number of sequential reads as it had written.
+
+\subsection*{Details of Tape Modes}
+\index[general]{Modes!Details}
+\index[general]{Details of Tape Modes}
+\addcontentsline{toc}{subsection}{Details of Tape Modes}
+Rudolf Cejka has provided the following information concerning
+certain tape modes and MTEOM.
+
+\begin{description}
+\item[Tape level]
+ It is always possible to position filemarks or blocks, whereas
+ positioning to the end-of-data is only optional feature, however it is
+ implemented very often. SCSI specification also talks about optional
+ sequential filemarks, setmarks and sequential setmarks, but these are not
+ implemented so often. Modern tape drives keep track of file positions in
+ built-in chip (AIT, LTO) or at the beginning of the tape (SDLT), so there
+ is not any speed difference, if end-of-data or filemarks is used (I have
+ heard, that LTO-1 from all 3 manufacturers do not use its chip for file
+ locations, but a tape as in SDLT case, and I'm not sure about LTO-2 and
+ LTO-3 case). However there is a big difference, that end-of-data ignores
+ file position, whereas filemarks returns the real number of skipped
+ files, so OS can track current file number just in filemarks case.
+
+\item[OS level]
+ Solaris does use just SCSI SPACE Filemarks, it does not support SCSI
+ SPACE End-of-data. When MTEOM is called, Solaris does use SCSI SPACE
+ Filemarks with count = 1048576 for fast mode, and combination of SCSI
+ SPACE Filemarks with count = 1 with SCSI SPACE Blocks with count = 1 for
+ slow mode, so EOD mark on the tape on some older tape drives is not
+ skipped. File number is always tracked for MTEOM.
+
+ Linux does support both SCSI SPACE Filemarks and End-of-data: When MTEOM
+ is called in MT_ST_FAST_MTEOM mode, SCSI SPACE Filemarks with count =
+ 8388607 is used. In the other case, SCSI SPACE End-of-data is used.
+ There is no real slow mode like in Solaris - I just expect, that for
+ older tape drives Filemarks may be slower than End-of-data, but not so
+ much as in Solaris slow mode. File number is tracked for MTEOM just
+ without MT_ST_FAST_MTEOM - when MT_ST_FAST_MTEOM is used, it is not.
+
+ FreeBSD does support both SCSI SPACE Filemarks and End-of-data, but when
+ MTEOD (MTEOM) is called, SCSI SPACE End-of-data is always used. FreeBSD
+ never use SCSI SPACE Filemarks for MTEOD. File number is never tracked
+ for MTOED.
+
+\item[Bacula level]
+ When {\bf Hardware End of Medium = Yes} is used, MTEOM is called, but it
+ does not mean, that hardware End-of-data must be used. When Hardware End
+ of Medium = No, if Fast Forward Space File = Yes, MTFSF with count =
+ 32767 is used, else Block Read with count = 1 with Forward Space File
+ with count = 1 is used, which is really very slow.
+
+\item [Hardware End of Medium = Yes|No]
+ The name of this option is misleading and is the source of confusion,
+ because it is not the hardware EOM, what is really switched here.
+
+ If I use Yes, OS must not use SCSI SPACE End-of-data, because Bacula
+ expects, that there is tracked file number, which is not supported by
+ SCSI specification. Instead, the OS have to use SCSI SPACE Filemarks.
+
+ If I use No, an action depends on Fast Forward Space File.
+
+ Considering {\bf Hardware End of Medium = no}
+ and {\bf Fast Forward Space File = no}
+ When I set the two to no, file positioning was very slow
+ on my LTO-3:
+\begin{verbatim}
+ HEOM = no, FFSF = no: ~ 10 - 100 minutes
+\end{verbatime}
+
+while even with {\bf Hardware End of Medium = no} but
+{\bf Fast Forward Space File = yes}, the time is 10 to
+100 times faster.
+\begin{verbatim}
+ HEOM = no, FFSF = yes: ~ 1 minute
+\end{verbatim}
+
+\end{description}
+
+\subsection*{Autochanger Errors}
+\index[general]{Errors!Autochanger}
+\index[general]{Autochanger Errors}
+\addcontentsline{toc}{subsection}{Autochanger Errors}
+
+If you are getting errors such as:
+
+\footnotesize
+\begin{verbatim}
+3992 Bad autochanger "load slot 1, drive 1": ERR=Child exited with code 1.
+\end{verbatim}
+\normalsize
+
+and you are running your Storage daemon as non-root, then most likely
+you are having permissions problems with the control channel. Running
+as root, set permissions on /dev/sgX so that the userid and group of
+your Storage daemon can access the device. You need to ensure that you
+all access to the proper control device, and if you don't have any
+SCSI disk drives (including SATA drives), you might want to change
+the permissions on /dev/sg*.
\addcontentsline{toc}{section}{Thanks}
Thanks to Richard Stallman for starting the Free Software movement and for
-bringing us gcc and all the other GNU tools.
+bringing us gcc and all the other GNU tools as well as the GPL license.
-Thanks to Linus Torvalds for bring us Linux.
+Thanks to Linus Torvalds for bringing us Linux.
Thanks to all the Free Software programmers. Without being able to peek at
your code, and in some cases, take parts of it, this project would have been
Special thanks to D. Scott Barninger for writing the bacula RPM spec file,
building all the RPM files and loading them onto Source Forge. This has been a
-tremendous help.
+tremendous help.
+
+Many thanks to Karl Cunningham for converting the manual from html format to
+LaTeX. It was a major effort flawlessly done that will benefit the Bacula
+users for many years to come. Thanks Karl.
Thanks to Dan Langille for the {\bf incredible} amount of testing he did on
FreeBSD. His perseverance is truly remarkable. Thanks also for the many
Thanks to Nicolas Boichat for writing wx-console and the bacula-tray-monitor.
These are very nice GUI additions to Bacula.
+Thanks to Thorsten Engel for his excellent knowledge of Win32 systems, and
+for making the Win32 File daemon Unicode compatible, as well as making
+the Win32 File daemon interface to Microsoft's Volume Shadow Copy (VSS).
+These two are big pluses for Bacula!
+
Thanks to Nic Bellamy for providing the bacula-dir.conf file that he uses to
implement daily tape rotation using multiple Pools.
-Thanks to Johan Decock for providing numerous corrections to the manual.
+Thanks also to Jo Simoens for finding and correcting so many typos and
+other problems with the manual.
+
+Thanks to Arno Lehmann for his excellent and infatigable help and advice
+to users.
Thanks to all the Bacula users, especially those of you who have contributed
ideas, bug reports, patches, and new features.
\addcontentsline{toc}{subsection}{Upgrading Bacula Versions}
The first thing to do before upgrading from one version to another is to
-ensure that don't overwrite your production (current) version of Bacula until
+ensure that you don't overwrite or delete your production (current) version of Bacula until
you have tested that the new version works.
If you have installed Bacula into a single directory, this is simple: simply
If you have done a more typical Unix installation where the binaries are
placed in one directory and the configuration files are placed in another,
then the simplest way is to configure your new Bacula to go into a single
-file.
+file. Alternatively, make copies of all your binaries and especially your
+conf files.
Whatever your situation may be (one of the two just described), you should
probably start with the {\bf defaultconf} script that can be found in the {\bf
When installing a new Bacula you need not worry about losing the changes you
made to your configuration files as the installation process will not
-overwrite them.
+overwrite them providing that you do not do a {\bf make uninstall}.
+
+If the new version of Bacula requires an upgrade to the database,
+you can upgrade it with the script {\bf update_bacula_tables}, which
+will be installed in your scripts directory (default {\bf /etc/bacula}),
+or alternatively, you can find it in the
+{\bf \lt{}bacula-source\gt{}/src/cats} directory.
\subsection*{Getting Notified of Job Completion}
\label{notification}
\normalsize
You will need to ensure that the {\bf /home/bacula/bin} path on the {\bf
-mailcommand} and the {\bf operatorcommand} lines points to your {\bf Bacula}
+mailcommand} and the {\bf operatorcommand} lines point to your {\bf Bacula}
binary directory where the {\bf bsmtp} program will be installed. You will
also want to ensure that the {\bf your-email-address} is replaced by your
email address, and finally, you will also need to ensure that the {\bf
\end{verbatim}
\normalsize
-which runs my ``watchdog'' script. As an example, I have added the Job codes
+which runs my "watchdog" script. As an example, I have added the Job codes
\%c and \%d which will cause the Client name and the Director's name to be
passed to the script. For example, if the Client's name is {\bf Watchdog} and
the Director's name is {\bf main-dir} then referencing \$1 in the script would
having the script know the Client and Director's name is not really useful,
but in other situations it may be.
-You can put anything in the watchdog scrip. In my case, I like to monitor the
+You can put anything in the watchdog script. In my case, I like to monitor the
size of my catalog to be sure that {\bf Bacula} is really pruning it. The
following is my watchdog script:
each {\bf Incremental} backup, and the file is totally rewritten during each
{\bf Full} backup.
-Note, one major disadvantage of writing to an NFS mounted volume as I do is
+Note, one disadvantage of writing to an NFS mounted volume as I do is
that if the other machine goes down, the OS will wait forever on the fopen()
call that Bacula makes. As a consequence, Bacula will completely stall until
-the machine exporting the NSF mounts comes back up. The solution to this
+the machine exporting the NSF mounts comes back up. A possible solution to this
problem was provided by Andrew Hilborne, and consists of using the {\bf soft}
option instead of the {\bf hard} option when mounting the NFS volume, which is
typically done in {\bf /etc/fstab}/. The NFS documentation explains these
-options in detail.
+options in detail. However, I found that with the {\bf soft} option
+NFS disconnected frequently causing even more problems.
If you are starting off in the middle of a cycle (i.e. with Incremental
backups) rather than at the beginning (with a Full backup), the {\bf
\normalsize
Here the Bacula found fewer files on the volume than what is marked in the
-catalog. Now, in this case, you should hesitate lot before modifying the count
+catalog. Now, in this case, you should hesitate a lot before modifying the count
in the catalog, because if you force the catalog from 12 to 10, Bacula will
start writing after the file 10 on the tape, possibly overwriting valid data,
and if you ever try to restore any of the files that the catalog has marked as
You should protect your Catalog database. If you are using SQLite, make sure
that the working directory is readable only by root (or your Bacula userid),
-and ensure that {\bf bacula.db} has permissions {\bf -rw-r\verb{--{r\verb{--{} (i.e. 640) or
+and ensure that {\bf bacula.db} has permissions {\bf -rw-r\verb:--:r\verb:--:} (i.e. 640) or
more strict. If you are using MySQL or PostgreSQL, please note that the Bacula
setup procedure leaves the database open to anyone. At a minimum, you should
assign the user {\bf bacula} a userid and add it to your Director's
\index[general]{Autochanger!Automatic Labeling Using Your }
\addcontentsline{toc}{subsection}{Automatic Labeling Using Your Autochanger}
-If you have an autochanger but it does not support barcodes, using a ``trick''
+If you have an autochanger but it does not support barcodes, using a "trick"
you can make Bacula automatically label all the volumes in your autochanger's
magazine.
\normalsize
Note, I have truncated the output for presentation purposes. What is
-significant for is that I can see that my current tape has almost 10 Gbytes of
+significant, is that I can see that my current tape has almost 10 Gbytes of
data, and that the average amount of data I get on my tapes is about 60
Gbytes. So if I go on vacation now, I don't need to worry about tape capacity
(at least not for short absences).
This tip also comes from Marc Brueckner. (Note, this tip is probably outdated
by the addition of {\bf ClientRunBeforJob} and {\bf ClientRunAfterJob} Job
-records, but the technique still could be useful.) First I thought the ``Run
-Before Job'' statement in the Job-resource is for executing a script on the
+records, but the technique still could be useful.) First I thought the "Run
+Before Job" statement in the Job-resource is for executing a script on the
remote machine(the machine to be backed up). It could be usefull to execute
scripts on the remote machine e.g. for stopping databases or other services
-while doing the backup. (Of cause I have to start the services again when the
+while doing the backup. (Of course I have to start the services again when the
backup has finished) I found the following solution: Bacula could execute
scrips on the remote machine by using ssh. The authentication is done
-automatically using a private key. First You have to generate a keypair. I ve
+automatically using a private key. First You have to generate a keypair. I've
done this by:
\footnotesize
\normalsize
This statement may take a little time to run. It creates a public/private key
-pair with no pass phrase. You could save the keys in /etc/bacula. Now you have
+pair with no passphrase. You could save the keys in /etc/bacula. Now you have
two new files : Bacula\_key which contains the private key and Bacula\_key.pub
which contains the public key.
home-directory of the user (root in this case).
Assuming that your sshd is already running on the remote machine, you can now
-enter the folloing on the machine where Bacula runs:
+enter the following on the machine where Bacula runs:
\footnotesize
\begin{verbatim}
\end{verbatim}
\normalsize
-This should execute the ``ls -la'' command on the remote machine.
+This should execute the "ls -la" command on the remote machine.
Now you could add lines like the following to your Director's conf file:
This tip comes from Phil Stracchino.
If you decide to blow away your catalog and start over, the simplest way to
-re-add all your prelabelled tapes with the minimum of fuss (provided you don't
+re-add all your prelabeled tapes with a minimum of fuss (provided you don't
care about the data on the tapes) is to add the tape labels using the console
{\bf add} command, then go into the catalog and manually set the VolStatus of
every tape to {\bf Recycle}.
So you can schedule and run backups without ever having to log on or see the
console.
To make the whole thing work you need to create a Device resource which looks
-something like this (``Archive Device'', ``Maximum Changer Wait'', ``Media
-Type'' and ``Label media'' may have different values):
+something like this ("Archive Device", "Maximum Changer Wait", "Media
+Type" and "Label media" may have different values):
\footnotesize
\begin{verbatim}
\normalsize
As the script has to emulate the complete wisdom of a mtx-changer it has an
-internal ``database'' where which tape is stored, you can see this at that
-line:
+internal "database" containing where which tape is stored, you can see this on
+the following line:
\footnotesize
\begin{verbatim}
\normalsize
The above should be all on one line, and it effectivly tells Bacula that
-volume ``VOL-0001'' is located in slot 1 (which is our lowest slot), that
-volume ``VOL-0002'' is located in slot 2 and so on..
+volume "VOL-0001" is located in slot 1 (which is our lowest slot), that
+volume "VOL-0002" is located in slot 2 and so on..
The script also maintains a logfile (/var/log/mtx.log) where you can monitor
its operation.
\subsection*{Running Concurrent Jobs}
\label{ConcurrentJobs}
-\index[general]{Jobs!Running Concurrent }
-\index[general]{Running Concurrent Jobs }
+\index[general]{Jobs!Running Concurrent}
+\index[general]{Running Concurrent Jobs}
+\index[general]{Concurrent Jobs}
\addcontentsline{toc}{subsection}{Running Concurrent Jobs}
Bacula can run multiple concurrent jobs, but the default configuration files
Bacula TLS (Transport Layer Security) is built-in network
encryption code to provide secure network transport similar to
-that offered by {\bf stunnel} or {\bs ssh}. The Bacula code was
+that offered by {\bf stunnel} or {\bf ssh}. The Bacula code was
written by Landon Fuller.
Supported features of this code include:
\item Forward Secrecy Support via Diffie-Hellman Ephemeral Keying
\end{itemize}
-This document will refer to both ``server'' and ``client'' contexts. These
+This document will refer to both "server" and "client" contexts. These
terms refer to the accepting and initiating peer, respectively.
Diffie-Hellman anonymous ciphers are not supported by this code. The
openssl dhparam -out dh1024.pem -5 1024
\end{verbatim}
-\end{itemize}
+\end{description}
\subsection*{Creating a Self-signed Certificate}
\index[general]{Creating a Self-signed Certificate }
The above script will ask you a number of questions. You may simply answer
each of them by entering a return, or if you wish you may enter your own data.
+An alternative is to generate your self-signed certificates with TinyCA,
+which has a very nice Graphical User Interface. TinyCA can be found at
+\elink{http://tinyca.sm-zone.net/}{http://tinyca.sm-zone.net/}.
+
\subsection*{Getting a CA Signed Certificate}
\index[general]{Certificate!Getting a CA Signed }
http://ospkibook.sourceforge.net/docs/OSPKI-2.4.7/OSPKI-html/ospki-book.htm}
{http://ospkibook.sourceforge.net/docs/OSPKI-2.4.7/OSPKI-html/ospki-book.htm}.
Note, this link may change.
+
+\subsection*{Example TLS Configuration Files}
+\index[general]{Example!TLS Configuration Files}
+\index[general]{TLS Configuration Files}
+\addcontentsline{toc}{subsection}{Example TLS Configuration Files}
+
+Landon has supplied us with the TLS portions of his configuration
+files, which should help you setting up your own.
+
+{\bf bacula-dir.conf}
+\footnotesize
+\begin{verbatim}
+ Director { # define myself
+ Name = backup1-dir
+ ...
+ TLS Require = yes
+ TLS Verify Peer = yes
+ TLS Allowed CN = "bacula@backup1.example.com"
+ TLS Allowed CN = "administrator@example.com"
+ TLS CA Certificate File = /usr/local/etc/ssl/ca.pem
+ # This is a server certificate, used for incoming
+ # console connections.
+ TLS Certificate = /usr/local/etc/ssl/backup1/cert.pem
+ TLS Key = /usr/local/etc/ssl/backup1/key.pem
+ }
+
+ Storage {
+ Name = File
+ Address = backup1.example.com
+ ...
+ TLS Require = yes
+ TLS CA Certificate File = /usr/local/etc/ssl/ca.pem
+ # This is a client certificate, used by the director to
+ # connect to the storage daemon
+ TLS Certificate = /usr/local/etc/ssl/bacula@backup1/cert.pem
+ TLS Key = /usr/local/etc/ssl/bacula@backup1/key.pem
+ }
+\end{verbatim}
+\normalsize
+
+{\bf bacula-fd.conf}
+\footnotesize
+\begin{verbatim}
+ Director {
+ Name = backup1-dir
+ ...
+ TLS Require = yes
+ TLS Verify Peer = yes
+ # Allow only the Director to connect
+ TLS Allowed CN = "bacula@backup1.example.com"
+ TLS CA Certificate File = /usr/local/etc/ssl/ca.pem\
+ # This is a server certificate. It is used by connecting
+ # directors to verify the authenticity of this file daemon
+ TLS Certificate = /usr/local/etc/ssl/server1/cert.pem
+ TLS Key = /usr/local/etc/ssl/server1/key.pem
+ }
+\end{verbatim}
+\normalsize
+
+{\bf bacula-sd.conf}
+\footnotesize
+\begin{verbatim}
+ Storage { # definition of myself
+ Name = backup1-sd
+ ...
+ # These TLS configuration options are used for incoming
+ # file daemon connections. Director TLS settings are handled
+ # below.
+ TLS Require = yes
+ # Peer certificate is not required/requested -- peer validity
+ # is verified by the storage connection cookie provided to the
+ # File Daemon by the director.
+ TLS Verify Peer = no
+ TLS CA Certificate File = /usr/local/etc/ssl/ca.pem
+ # This is a server certificate. It is used by connecting
+ # file daemons to verify the authenticity of this storage daemon
+ TLS Certificate = /usr/local/etc/ssl/backup1/cert.pem
+ TLS Key = /usr/local/etc/ssl/backup1/key.pem
+ }
+
+ #
+ # List Directors who are permitted to contact Storage daemon
+ #
+ Director {
+ Name = backup1-dir
+ ...
+ TLS Require = yes
+ # Require the connecting director to provide a certificate
+ # with the matching CN.
+ TLS Verify Peer = yes
+ TLS Allowed CN = "bacula@backup1.example.com"
+ TLS CA Certificate File = /usr/local/etc/ssl/ca.pem
+ # This is a server certificate. It is used by the connecting
+ # director to verify the authenticity of this storage daemon
+ TLS Certificate = /usr/local/etc/ssl/backup1/cert.pem
+ TLS Key = /usr/local/etc/ssl/backup1/key.pem
+ }
+\end{verbatim}
+\normalsize
+
+
%%
%%
-\section*{A Brief Turorial}
+\section*{A Brief Tutorial}
\label{_ChapterStart1}
-\index[general]{Brief Turorial }
-\index[general]{Turorial!Brief }
-\addcontentsline{toc}{section}{Brief Turorial}
+\index[general]{Brief Tutorial }
+\index[general]{Tutorial!Brief }
+\addcontentsline{toc}{section}{Brief Tutorial}
This chapter will guide you through running Bacula. To do so, we assume you
have installed Bacula, possibly in a single file as shown in the previous
running this in production, you will probably want to find some way to
automatically start MySQL or PostgreSQL after each system reboot.
-If you are using SQLite (i.e. you specified the {\bf \verb{--{with-sqlite=xxx} option
+If you are using SQLite (i.e. you specified the {\bf \verb:--:with-sqlite=xxx} option
on the {\bf ./configure} command, you need do nothing. SQLite is automatically
started by {\bf Bacula}.
\index[general]{Daemons!Starting the }
\addcontentsline{toc}{subsection}{Starting the Daemons}
-To start the three daemons, from your installation directory, simply enter:
+Assuming you have built from source or have installed the rpms,
+to start the three daemons, from your installation directory, simply enter:
-./bacula start This script starts the Storage daemon, the File daemon, and the
+./bacula start
+
+The {\bf bacula} script starts the Storage daemon, the File daemon, and the
Director daemon, which all normally run as daemons in the background. If you
are using the autostart feature of Bacula, your daemons will either be
automatically started on reboot, or you can control them individually with the
files {\bf bacula-dir}, {\bf bacula-fd}, and {\bf bacula-sd}, which are
usually located in {\bf /etc/init.d}, though the actual location is system
dependent.
+Some distributions may do this differently.
Note, on Windows, currently only the File daemon is ported, and it must be
started differently. Please see the
./bconsole
-Note, on 1.32 versions and lower, the command name is {\bf console} rather
-than bconsole. Alternatively to running the command line console, if you have
-GNOME installed and used the {\bf \verb{--{enable-gnome} on the configure command,
+Alternatively to running the command line console, if you have
+GNOME installed and used the {\bf \verb:--:enable-gnome} on the configure command,
you may use the GNOME Console program:
./gnome-console
-For simplicity, here we will describe only the {\bf ./console} program. Most
-of what is described here applies equally well to {\bf ./gnome-console}.
+Another possibilty is to run the wxWidgets program {\bf wx-console}.
+
+For simplicity, here we will describe only the {\bf ./bconsole} program. Most
+of what is described here applies equally well to {\bf ./gnome-console}
+and to {\bf wx-console}
The {\bf ./bconsole} runs the Bacula Console program, which connects to the
Director daemon. Since Bacula is a network program, you can run the Console
\normalsize
Details of the console program's commands are explained in the
-\ilink{Console Chapter}{_ChapterStart23} of this manual.
+\ilink{Console Chapter}{_ConsoleChapter} of this manual.
\subsection*{Running a Job}
\label{Running}
At this point, we assume you have done the following:
\begin{itemize}
-\item Configured Bacula with {\bf ./configure \verb{--{your-options}
+\item Configured Bacula with {\bf ./configure \verb:--:your-options}
\item Built Bacula using {\bf make}
\item Installed Bacula using {\bf make install}
\item Have created your database with, for example, {\bf
\item Have possibly edited your {\bf bacula-dir.conf} file to personalize it
a bit. BE CAREFUL! if you change the Director's name or password, you will
need to make similar modifications in the other .conf files. For the moment
-it is probably better to make no changes.
+ it is probably better to make no changes.
\item You have started Bacula with {\bf ./bacula start}
\item You have invoked the Console program with {\bf ./bconsole}
- \end{itemize}
+\end{itemize}
Furthermore, we assume for the moment you are using the default configuration
files.
{\bf Catalog} is used for backing up Bacula's catalog and is not of interest
to us for the moment. The {\bf Inc:} entries are the files or directories that
will be included in the backup and the {\bf Exc:} are those that will be
-excluded.
+excluded. You can change what is backed up by editing {\bf bacula-dir.conf}
+and changing the {\bf File =} line in the {\bf FileSet} resource.
Now is the time to run your first backup job. We are going to backup your
Bacula source directory to a File Volume in your {\bf /tmp} directory just to
output. This is normal because we have not yet created (labeled) any Volumes.
Bacula indicates to you all the details of the volume it needs.
-At this point, the job is blocked waiting for a Volume. You can check this if
+At this point, the job is BLOCKED waiting for a Volume. You can check this if
you want by doing a {\bf status dir}. In order to continue, we must create a
Volume that Bacula can write on. We do so with:
to be restored. You will be presented several methods
of specifying the JobIds. Then you will be allowed to
select which files from those JobIds are to be restored.
+
To select the JobIds, you have the following choices:
1: List last 20 Jobs run
2: List Jobs where a given File is saved
6: Select backup for a client before a specified time
7: Enter a list of files to restore
8: Enter a list of files to restore before a specified time
- 9: Cancel
-Select item: (1-9):
+ 9: Find the JobIds of the most recent backup for a client
+ 10: Find the JobIds for a backup for a client before a specified time
+ 11: Enter a list of directories to restore for found JobIds
+ 12: Cancel
+Select item: (1-12):
\end{verbatim}
\normalsize
Client: rufus-fd
Storage: File
JobId: *None*
-When: 2003-04-28 14:53:54
+When: 2005-04-28 14:53:54
OK to run? (yes/mod/no):
\end{verbatim}
\normalsize
\footnotesize
\begin{verbatim}
-28-Apr-2003 14:56 rufus-dir: Bacula 1.30 (28Apr03): 28-Apr-2003 14:56
+28-Apr-2005 14:56 rufus-dir: Bacula 1.30 (28Apr03): 28-Apr-2003 14:56
JobId: 2
-Job: RestoreFiles.2003-04-28_14.56.06
+Job: RestoreFiles.2005-04-28_14.56.06
Client: rufus-fd
-Start time: 28-Apr-2003 14:56
-End time: 28-Apr-2003 14:56
+Start time: 28-Apr-2005 14:56
+End time: 28-Apr-2005 14:56
Files Restored: 1,444
Bytes Restored: 38,816,381
Rate: 9704.1 KB/s
FD termination status: OK
Termination: Restore OK
-28-Apr-2003 14:56 rufus-dir: Begin pruning Jobs.
-28-Apr-2003 14:56 rufus-dir: No Jobs found to prune.
-28-Apr-2003 14:56 rufus-dir: Begin pruning Files.
-28-Apr-2003 14:56 rufus-dir: No Files found to prune.
-28-Apr-2003 14:56 rufus-dir: End auto prune.
+28-Apr-2005 14:56 rufus-dir: Begin pruning Jobs.
+28-Apr-2005 14:56 rufus-dir: No Jobs found to prune.
+28-Apr-2005 14:56 rufus-dir: Begin pruning Files.
+28-Apr-2005 14:56 rufus-dir: No Files found to prune.
+28-Apr-2005 14:56 rufus-dir: End auto prune.
\end{verbatim}
\normalsize
\normalsize
Then make sure that the Address parameter in the Storage resource is set to
-the fully qualified domain name and not to something like ``localhost''. The
+the fully qualified domain name and not to something like "localhost". The
address specified is sent to the File daemon (client) and it must be a fully
-qualified domain name. If you pass something like ``localhost'' it will not
+qualified domain name. If you pass something like "localhost" it will not
resolve correctly and will result in a time out when the File daemon fails to
connect to the Storage daemon.
the new Volume.
If you have a Pool of volumes and Bacula is cycling through them, instead of
-the above message ``Cannot find any appendable volumes.'', Bacula may ask you
+the above message "Cannot find any appendable volumes.", Bacula may ask you
to mount a specific volume. In that case, you should attempt to do just that.
If you do not have the volume any more (for any of a number of reasons), you
can simply mount another volume from the same Pool, providing it is
\footnotesize
\begin{verbatim}
-./bacula start -d20
+./bacula start -d100
\end{verbatim}
\normalsize
+This can be particularly helpful if your daemons do not start correctly,
+because direct daemon output to the console is normally directed to the
+NULL device, but with the debug level greater than zero, the output
+will be sent to the starting terminal.
+
To stop the three daemons, enter the following from the install directory:
\footnotesize
\item [-d nn]
\index[sd]{-d nn }
Set the debug level to {\bf nn}. Higher levels of debug cause more
-information to displayed on STDOUT concerning what the daemon is doing.
+information to be displayed on STDOUT concerning what the daemon is doing.
\item [-f]
Run the daemon in the foreground. This option is needed to run the daemon
\index[general]{Labeling Your Volumes }
\addcontentsline{toc}{subsection}{Labeling Your Volumes}
-Bacula requires that each Volume contain a software label. There are several
+Bacula requires that each Volume contains a software label. There are several
strategies for labeling volumes. The one I use is to label them as they are
needed by {\bf Bacula} using the console program. That is when Bacula needs a
new Volume, and it does not find one in the catalog, it will send me an email
this manual.
If you run a Bacula job, and you have no labeled tapes in the Pool, Bacula
-will inform you, and you can create them ``on-the-fly'' so to speak. In my
+will inform you, and you can create them "on-the-fly" so to speak. In my
case, I label my tapes with the date, for example: {\bf DLT-18April02}. See
below for the details of using the {\bf label} command.
\end{verbatim}
\normalsize
-Once Bacula has verified that the volume does not already exist, it will then
-prompt you for the name of the Pool in which the Volume (tape) to be created.
-If there is only one Pool (Default), it will be automatically selected.
+Once Bacula has verified that the volume does not already exist, it will
+prompt you for the name of the Pool in which the Volume (tape) is to be
+created. If there is only one Pool (Default), it will be automatically
+selected.
-If the tape is successfully labeled, a media record will also be created in
+If the tape is successfully labeled, a Volume record will also be created in
the Pool. That is the Volume name and all its other attributes will appear
when you list the Pool. In addition, that Volume will be available for backup
if the MediaType matches what is requested by the Storage daemon.
It is also possible to add media to the pool without physically labeling the
Volumes. This can be done with the {\bf add} command. For more information,
please see the
-\ilink{Console Chapter}{_ChapterStart23} of this manual.
+\ilink{Console Chapter}{_ConsoleChapter} of this manual.
\index[general]{Expansion!Variable }
\addcontentsline{toc}{section}{Variable Expansion}
+Please note that as of version 1.37, the Variable Expansion
+is deprecated and replaced by Python scripting (not yet
+documented).
+
Variable expansion is somewhat similar to Unix shell variable expansion.
Currently (version 1.31), it is used only in format labels, but in the future,
it will most likely be used in more places.
controlled loop, support of arithmetic expressions in the loop start, step and
end conditions, and recursive expansion.
-When using varaiable expansion characters in a Volume Label Format record, the
-format should always be enclosed in double quotes ({\bf ``}).
+When using variable expansion characters in a Volume Label Format record, the
+format should always be enclosed in double quotes ({\bf "}).
For example, {\bf \$\{HOME\}} will be replaced by your home directory as
defined in the environment. If you have defined the variable {\bf xxx} to be
\item [Internal Variables]
\index[dir]{Internal Variables }
Internal variables are read-only, and may be related to the current job (i.e.
-Job name), or may be special variables such as the date and time. The
+Job name), or maybe special variables such as the date and time. The
following variables are available:
\begin{itemize}
array, where the elements of the array are referenced by subscripting the
variable name (e.g. {\bf \$\{Months[3]\}}). Environment variable arrays are
defined by separating the elements with a vertical bar ({\bf |}), thus {\bf
-set Months=''Jan|Feb|Mar|Apr|...``} defines an environment variable named
+set Months="Jan|Feb|Mar|Apr|..."} defines an environment variable named
{\bf Month} that will be treated as an array, and the reference {\bf
\$\{Months[3]\}} will yield {\bf Mar}. The elements of the array can have
differing lengths.
\end{verbatim}
\normalsize
-The {\bf InitCatalog} level tells {\bf Bacula} simply get the information on
+The {\bf InitCatalog} level tells {\bf Bacula} simply to get the information on
the specified files and to put it into the catalog. That is your database is
initialized and no comparison is done. The {\bf InitCatalog} is normally run
one time manually.
catalog and to report any differences. See the example below for the format of
the output.
-You decide what files you want to form your ``snapshot'' by specifying them in
+You decide what files you want to form your "snapshot" by specifying them in
a {\bf FileSet} resource, and normally, they will be system files that do not
change, or that only certain features change.
The {\bf verify=pins1} is ignored during the {\bf InitCatalog} Job, but is
used during the subsequent {\bf Catalog} Jobs to specify what attributes of
the files should be compared to those found in the catalog. {\bf pins1} is a
-reasonable set to begin with, but you may want to look at the details these
+reasonable set to begin with, but you may want to look at the details of these
and other options. They can be found in the
\ilink{FileSet Resource}{FileSetResource} section of this manual.
Briefly, however, the {\bf p} of the {\bf pins1} tells Verify to compare the
at which point you respond {\bf yes}, and the Job will begin.
-There after the Job will automatically start according to the schedule you
+Thereafter the Job will automatically start according to the schedule you
have defined. If you wish to immediately verify it, you can simply run a
Verify {\bf Catalog} which will be the default. No differences should be
found.
to modify the {\bf FileSet} to exclude that file (or not to Include it), and
then re-run the {\bf InitCatalog}.
-The FileSet that is show below is what I use on my RedHat 7.3 system. With a
+The FileSet that is shown below is what I use on my RedHat 7.3 system. With a
bit more thought, you can probably add quite a number of additional files that
should be monitored.
}
\end{verbatim}
\normalsize
-
The Windows version of the Bacula File daemon has been tested on Win98, WinMe,
WinNT, and Win2000 systems. We have coded to support Win95, but no longer have
a system for testing. The Windows version of Bacula is a native Win32 port,
-but there are very few source code changes, which means that the Windows
+but there are very few source code changes to the Unix code, which means that the Windows
version is for the most part running code that has long proved stable on Unix
systems. When running, it is perfectly integrated with Windows and displays
its icon in the system icon tray, and provides a system tray menu to obtain
immediately started by the operating system when the system is booted, and
runs in the background even if there is no user logged into the system.
-\subsubsection*{Installation}
+\subsection*{Win32 Installation}
\label{installation}
\index[general]{Installation }
-\addcontentsline{toc}{subsubsection}{Installation}
+\index[general]{Win32!Installation }
+\addcontentsline{toc}{subsection}{Win32 Installation}
Normally, you will install the Windows version of Bacula from the binaries.
This install is standard Windows .exe that runs an install wizard using the
NSIS Free Software installer, so if you have already installed Windows
software, it should be very familiar to you.
-If you have a previous version Cygwin of Bacula (1.32 or lower) installed, you
-should stop the service, uninstall it, and remove the directory possibly
-saving your bacula-fd.conf file for use with the new version you will install.
-The new native version of Bacula has far fewer files than the old Cygwin
-version.
+If you have a previous version Cygwin of Bacula (1.32 or lower) installed,
+you should stop the service, uninstall it, and remove the Bacula
+installation directory possibly saving your bacula-fd.conf file for use
+with the new version you will install. The new native version of Bacula
+has far fewer files than the old Cygwin version, so it is better to start
+with a clean directory.
Finally, proceed with the installation.
\begin{itemize}
+\item You must be logged in as Administrator to do a correct installation,
+ if not, please do so before continuing.
+
\item Simply double click on the {\bf winbacula-1.xx.0.exe} NSIS install
icon. The actual name of the icon will vary from one release version to
another.
\item If you proceed, you will be asked to select the components to be
installed. You may install the Bacula program (Bacula File Service) and or
the documentation. Both will be installed in sub-directories of the install
-location that you choose later. The components dialog looks like the
-following:
+ location that you choose later. The components dialog looks like the
+ following:
\addcontentsline{lof}{figure}{Win32 Component Selection Dialog}
\includegraphics{./win32-pkg.eps}
\item If you are installing for the first time, you will be asked if you want
to edit the bacula-fd.conf file, and if you respond with yes, it will be
- opened in notepad.
-\
-\item Then the installer will ask if wish to install Bacula as a service. You
+ opened in notepad. Note, if you have installed Bacula to a drive other
+ than C: you probably should prefix the installation drive name to each
+ of the directory references in the bacula-fd.conf file, in particular
+ the {\bf WorkingDirectory} and the {\bf Pid Directory} directives.
+
+ Also, if you do not wish to see the full listing of all files restored
+ in the job output after running a restore job, you can add {\bf ,
+ !restored} to the {\bf director} directive in the {\bf Messages}
+ resource.
+
+\item Then the installer will ask if you wish to install Bacula as a service. You
should always choose to do so:
\addcontentsline{lof}{figure}{Win32 Client Service Selection}
\includegraphics{./win32-service.eps}
-\
-\item If everything goes well, you will receive the following confirmation:
+
+\item If everything goes well, you will receive the following confirmation:
\addcontentsline{lof}{figure}{Win32 Client Service Confirmation}
-\includegraphics{./win32-service-ok.eps}
+ \includegraphics{./win32-service-ok.eps}
-\
+
\item Then you will be asked if you wish to start the service. If you respond
with yes, any running Bacula will be shutdown and the new one started. You
may see a DOS box momentarily appear on the screen as the service is started.
-It should disappear in a second or two:
+ It should disappear in a second or two:
\addcontentsline{lof}{figure}{Win32 Client Start}
\includegraphics{./win32-start.eps}
-\
-\item Finally, the finish dialog will appear:
+\item Finally, the finish dialog will appear:
\addcontentsline{lof}{figure}{Win32 Client Setup Completed}
-\includegraphics{./win32-finish.eps}
+ \includegraphics{./win32-finish.eps}
\
\end{itemize}
That should complete the installation process. When the Bacula File Server is
ready to serve files, an icon \includegraphics{./idle.eps} representing a
cassette (or tape) will appear in the system tray
-\includegraphics{./tray-icon.eps}; right click on it and a menu will appear.
-\
-\ \ \ \ \includegraphics{./menu.eps}
+\includegraphics{./tray-icon.eps}; right click on it and a menu will appear.\\
+\includegraphics{./menu.eps}\\
The {\bf Events} item is currently unimplemented, by selecting the {\bf
Status} item, you can verify whether any jobs are running or not.
warned that that tray icon does not always appear. It will always be visible
when you log into the console, but the remote desktop may not display it.
-\subsubsection*{Post Installation}
-\index[general]{Post Installation }
-\index[general]{Installation!Post }
-\addcontentsline{toc}{subsubsection}{Post Installation}
+\subsection*{Post Win32 Installation}
+\index[general]{Post Win32 Installation }
+\index[general]{Win32!Post Installation }
+\addcontentsline{toc}{subsection}{Post Win32 Installation}
After installing Bacula and before running it, you should check the contents
of {\bf
c:\textbackslash{}bacula\textbackslash{}bin\textbackslash{}bacula-fd.conf} to
ensure that it corresponds to your configuration.
-\subsubsection*{Uninstalling Bacula}
-\index[general]{Bacula!Uninstalling }
-\index[general]{Uninstalling Bacula }
-\addcontentsline{toc}{subsubsection}{Uninstalling Bacula}
+Finally, but pulling up the Task Manager (ctl-alt-del), verify that Bacula
+is running as a process (not an Application) with User Name SYSTEM. If this is
+not the case, you probably have not installed Bacula while running as
+Administrator, and hence it will be unlikely that Bacula can access
+all the system files.
+
+\subsection*{Uninstalling Bacula on Win32}
+\index[general]{Win32!Uninstalling Bacula }
+\index[general]{Uninstalling Bacula on Win32 }
+\addcontentsline{toc}{subsection}{Uninstalling Bacula on Win32}
Once Bacula has been installed, it can be uninstalled using the standard
Windows Add/Remove Programs dialog found on the Control panel.
-\subsubsection*{Dealing with Problems}
+\subsection*{Dealing with Win32 Problems}
\label{problems}
-\index[general]{Problems!Dealing with }
-\index[general]{Dealing with Problems }
-\addcontentsline{toc}{subsubsection}{Dealing with Problems}
+\index[general]{Win32!Dealing with Problems }
+\index[general]{Dealing with Win32 Problems }
+\addcontentsline{toc}{subsection}{Dealing with Win32 Problems}
The most likely source of problems is authentication when the Director
attempts to connect to the File daemon that you installed. This can occur if
the names and the passwords defined in the File daemon's configuration file
-{\bf
+{\bf
c:\textbackslash{}bacula\textbackslash{}bin\textbackslash{}bacula-fd.conf} on
the Windows machine do not match with the names and the passwords in the
Director's configuration file {\bf bacula-dir.conf} located on your Unix/Linux
trace=1 on a setdebug command in the Console, Bacula will write the debug
information to the file {\bf bacula.trace} in the directory from which Bacula
is executing.
-\label{Compatibility}
-\subsubsection*{Windows Compatibility Considerations}
+\label{Compatibility}
+\subsection*{Windows Compatibility Considerations}
\index[general]{Windows Compatibility Considerations }
\index[general]{Considerations!Windows Compatibility }
-\addcontentsline{toc}{subsubsection}{Windows Compatibility Considerations}
-
-If any applications are running during the backup and they have open files,
-Bacula will not be able to backup those files, so be sure you close your
-applications (or tell your users to close their applications) before the
-backup.
+\addcontentsline{toc}{subsection}{Windows Compatibility Considerations}
+
+If any applications are running during the backup and they have files
+opened exclusively, Bacula will not be able to backup those files, so be
+sure you close your applications (or tell your users to close their
+applications) before the backup. Fortunately,
+most Microsoft applications do not open
+files exclusively so that they can be backed up. However, you will need to
+experiment. In any case, if Bacula cannot open the file, it will print an
+error message, so you will always know which files were not backed up.
+For version 1.37.25 and greater, see the section below on
+Volume Shadow Copy Service.
During backup, Bacula doesn't know about the system registry, so you will
-either need to write it out to an ASCII file using {\bf regedit /e} or use a
+either need to write it out to an ASCII file using {\bf regedit~~/e} or use a
program specifically designed to make a copy or backup the registry.
-In Bacula versions 1.30 and earlier, we used the Cygwin emulation of Unix
-open(), read(), write(), ... calls to access files. This worked pretty well
-for Win95, Win98, and WinMe systems, but not very well for the other systems
-(NT/2K/XP) because those systems have special security and ownership
-information that was not saved. In addition on the NT/2K/XP systems, older
-versions of Bacula were not always able to access all files due to system
-permissions restrictions.
-
-As a consequence, in Bacula version 1.31 and later, we use Windows backup API
-calls by default. Typical of Windows, programming these special BackupRead and
-BackupWrite calls is a real nightmare of complications. The end result gives
-some distinct advantages and some disadvantages.
+In Bacula version 1.31 and later, we use Windows backup API calls by
+default. Typical of Windows, programming these special BackupRead and
+BackupWrite calls is a real nightmare of complications. The end result
+gives some distinct advantages and some disadvantages.
First, the advantages are that on WinNT/2K/XP systems, the security and
-ownership information is now backed up. In addition, with the exception of
-files in use by another program (a major disaster for backup programs on
-Windows), Bacula can now access all system files. This means that when you
-restore files, the security and ownership information will be restored on
-WinNT/2K/XP along with the data.
+ownership information is now backed up. In addition, with the exception of
+files in exclusive use by another program (a major disaster for backup
+programs on Windows), Bacula can now access all system files. This means
+that when you restore files, the security and ownership information will be
+restored on WinNT/2K/XP along with the data.
The disadvantage of the Windows backup API calls is that it produces
-non-portable backups. That is files and their data that are backed up on WinNT
-using the native API calls (BackupRead/BackupWrite) cannot be restored on
-Win95/98/Me or Unix systems. In principle, a file backed up on WinNT can be
-restored on WinXP, but this remains to be seen in practice (not yet tested).
-In addition, the stand-alone tools such as {\bf bls} and {\bf bextract} cannot
-be used to retrieve the data for those files because those tools are not
-available on Windows. All restores must use the Bacula {\bf restore} command.
-This restriction is mentioned for completeness, but in practice should not
-create any problems.
-
-As a default, Bacula backs up Windows systems using the Windows API calls. If
-you want to backup data on a WinNT/2K/XP system and restore it on a
-Unix/Win95/98/Me system, we have provided a special {\bf portable} option that
-backups the data in a portable fashion by using portable API calls. See the
-\ilink{portable option}{portable} on the Include statement in a
+non-portable backups. That is files and their data that are backed up on
+WinNT using the native API calls (BackupRead/BackupWrite) cannot be
+restored on Win95/98/Me or Unix systems. In principle, a file backed up on
+WinNT can be restored on WinXP, but this remains to be seen in practice
+(not yet tested). In addition, the stand-alone tools such as {\bf bls} and
+{\bf bextract} cannot be used to retrieve the data for those files because
+those tools are not available on Windows. All restores must use the Bacula
+{\bf restore} command. This restriction is mentioned for completeness, but
+in practice should not create any problems.
+
+As a default, Bacula backs up Windows systems using the Windows API calls.
+If you want to backup data on a WinNT/2K/XP system and restore it on a
+Unix/Win95/98/Me system, we have provided a special {\bf portable} option
+that backs up the data in a portable fashion by using portable API calls.
+See the \ilink{portable option}{portable} on the Include statement in a
FileSet resource in the Director's configuration chapter for the details on
-setting this option. However, using the portable option means you may have
-permissions problems accessing files, and none of the security and ownership
-information will be backed up or restored. The file data can, however, be
-restored on any system.
+setting this option. However, using the portable option means you may have
+permissions problems accessing files, and none of the security and
+ownership information will be backed up or restored. The file data can,
+however, be restored on any system.
You should always be able to restore any file backed up on Unix or Win95/98/Me
to any other system. On some systems, such as WinNT/2K/XP, you may have to
\hline
\multicolumn{1}{|c| }{\bf Backup OS } & \multicolumn{1}{c| }{\bf Restore OS }
& \multicolumn{1}{c| }{\bf Results } \\
- \hline
-{WinMe } & {WinMe } & {Works } \\
- \hline
-{WinMe } & {WinNT } & {Works (SYSTEM permissions) } \\
- \hline
-{WinMe } & {WinXP } & {Works (SYSTEM permissions) } \\
- \hline
-{WinMe } & {Linux } & {Works (SYSTEM permissions) } \\
- \hline
-{\ } & {\ } & {\ } \\
- \hline
-{WinXP } & {WinXP } & {Works } \\
- \hline
-{WinXP } & {WinNT } & {Works (all files OK, but got ``The data is invalid''
+ \hline {WinMe } & {WinMe } & {Works } \\
+ \hline {WinMe } & {WinNT } & {Works (SYSTEM permissions) } \\
+ \hline {WinMe } & {WinXP } & {Works (SYSTEM permissions) } \\
+ \hline {WinMe } & {Linux } & {Works (SYSTEM permissions) } \\
+ \hline {\ } & {\ } & {\ } \\
+ \hline {WinXP } & {WinXP } & {Works } \\
+ \hline {WinXP } & {WinNT } & {Works (all files OK, but got "The data is invalid"
message) } \\
- \hline
-{WinXP } & {WinMe } & {Error: Win32 data stream not supported. } \\
- \hline
-{WinXP } & {WinMe } & {Works if {\bf Portable=yes} specified during backup. }
-\\
- \hline
-{WinXP } & {Linux } & {Error: Win32 data stream not supported. } \\
- \hline
-{WinXP } & {Linux } & {Works if {\bf Portable=yes} specified during backup. }
-\\
- \hline
-{\ } & {\ } & {\ } \\
- \hline
-{WinNT } & {WinNT } & {Works } \\
- \hline
-{WinNT } & {WinXP } & {Works } \\
- \hline
-{WinNT } & {WinMe } & {Error: Win32 data stream not supported. } \\
- \hline
-{WinNT } & {WinMe } & {Works if {\bf Portable=yes} specified during backup. }
-\\
- \hline
-{WinNT } & {Linux } & {Error: Win32 data stream not supported. } \\
- \hline
-{WinNT } & {Linux } & {Works if {\bf Portable=yes} specified during backup. }
-\\
- \hline
-{\ } & {\ } & {\ } \\
- \hline
-{Linux } & {Linux } & {Works } \\
- \hline
-{Linux } & {WinNT } & {Works (SYSTEM permissions) } \\
- \hline
-{Linux } & {WinMe } & {Works } \\
- \hline
-{Linux } & {WinXP } & {Works (SYSTEM permissions) }
+ \hline {WinXP } & {WinMe } & {Error: Win32 data stream not supported. } \\
+ \hline {WinXP } & {WinMe } & {Works if {\bf Portable=yes} specified during backup.} \\
+ \hline {WinXP } & {Linux } & {Error: Win32 data stream not supported. } \\
+ \hline {WinXP } & {Linux } & {Works if {\bf Portable=yes} specified during backup.}\\
+ \hline {\ } & {\ } & {\ } \\
+ \hline {WinNT } & {WinNT } & {Works } \\
+ \hline {WinNT } & {WinXP } & {Works } \\
+ \hline {WinNT } & {WinMe } & {Error: Win32 data stream not supported. } \\
+ \hline {WinNT } & {WinMe } & {Works if {\bf Portable=yes} specified during backup.}\\
+ \hline {WinNT } & {Linux } & {Error: Win32 data stream not supported. } \\
+ \hline {WinNT } & {Linux } & {Works if {\bf Portable=yes} specified during backup. }\\
+ \hline {\ } & {\ } & {\ } \\
+ \hline {Linux } & {Linux } & {Works } \\
+ \hline {Linux } & {WinNT } & {Works (SYSTEM permissions) } \\
+ \hline {Linux } & {WinMe } & {Works } \\
+ \hline {Linux } & {WinXP } & {Works (SYSTEM permissions) }
\\ \hline
\end{longtable}
-\subsubsection*{Windows Firewalls}
+\label{VSS}
+\subsection*{Volume Shadow Copy Service}
+\index[general]{Volume Shadow Copy Service}
+\index[general]{VSS}
+\addcontentsline{toc}{subsection}{Volume Shadow Copy Service}
+In version 1.37.30 and greater, you can turn on Microsoft's Volume
+Shadow Copy Service (VSS).
+
+Microsoft added VSS to Windows XP and Windows 2003. From the perspective of
+a backup-solution for Windows, this is an extremely important step. VSS
+allows Bacula to backup open files and even to interact with applications like
+RDBMS to produce consistent file copies. VSS aware applications are called
+VSS Writers, they register with the OS so that when Bacula wants to do a
+Snapshot, the OS will notify the register Writer programs, which may then
+create a consistent state in their application, which will be backed up.
+Examples for these writers are "MSDE" (Microsoft database
+engine), "Event Log Writer", "Registry Writer" plus 3rd
+party-writers. If you have a non-vss aware application (e.g.
+SQL Anywhere or probably MySQL), a shadow copy is still generated
+and the open files can be backed up, but there is no guarantee
+that the file is consistent.
+
+Bacula produces a message from each of the registered writer programs
+when it is doing a VSS backup so you know which ones are correctly backed
+up.
+
+Bacula supports VSS on both Windows 2003 and Windows XP.
+Technically Bacula creates a shadow copy as soon as the backup process
+starts. It does then backup all files from the shadow copy and destroys the
+shadow copy after the backup process. Please have in mind, that VSS
+creates a snapshot and thus backs up the system at the state it had
+when starting the backup. It will disregard file changes which occur during
+the backup process.
+
+VSS can be turned on by placing an
+
+\index[dir]{Enable VSS}
+\index[general]{Enable VSS}
+\begin{verbatim}
+Enable VSS = yes
+\end{verbatim}
+
+in your FileSet resource.
+
+Important Note!! Under the current implementation, you may only
+run a single job at a time in any Win32 File daemon that has VSS
+active. Running multiple simultanous jobs in the File daemon
+will most likely cause jobs to fail. This restriction does not apply
+to the Director, Storage daemons, or any File daemons not running
+VSS.
+
+The VSS aware File daemon has the letters VSS on the signon line that
+it produces when contacted by the console. For example:
+\begin{verbatim}
+Tibs-fd Version: 1.37.32 (22 July 2005) VSS Windows XP MVS NT 5.1.2600
+\end{verbatim}
+the VSS is shown in the line above. This only means that the File daemon
+is capable of doing VSS not that VSS is turned on for a particular backup.
+There are two ways of telling if VSS is actually turned on during a backup.
+The first is to look at the status output for a job, e.g.:
+\footnotesize
+\begin{verbatim}
+Running Jobs:
+JobId 1 Job NightlySave.2005-07-23_13.25.45 is running.
+ VSS Backup Job started: 23-Jul-05 13:25
+ Files=70,113 Bytes=3,987,180,650 Bytes/sec=3,244,247
+ Files Examined=75,021
+ Processing file: c:/Documents and Settings/kern/My Documents/My Pictures/Misc1/Sans titre - 39.pdd
+ SDReadSeqNo=5 fd=352
+\end{verbatim}
+\normalsize
+Here, you see under Running Jobs that JobId 1 is "VSS Backup Job started ..."
+This means that VSS is enabled for that job. If VSS is not enabled, it will
+simply show "Backup Job started ..." without the letters VSS.
+
+The second way to know that the job was backed up with VSS is to look at the
+Job Report, which will look something like the following:
+\footnotesize
+\begin{verbatim}
+23-Jul 13:25 rufus-dir: Start Backup JobId 1, Job=NightlySave.2005-07-23_13.25.45
+23-Jul 13:26 rufus-sd: Wrote label to prelabeled Volume "TestVolume001" on device "DDS-4" (/dev/nst0)
+23-Jul 13:26 rufus-sd: Spooling data ...
+23-Jul 13:26 Tibs: Generate VSS snapshots. Driver="VSS WinXP", Drive(s)="C"
+23-Jul 13:26 Tibs: VSS Writer: "MSDEWriter", State: 1 (VSS_WS_STABLE)
+23-Jul 13:26 Tibs: VSS Writer: "Microsoft Writer (Bootable State)", State: 1 (VSS_WS_STABLE)
+23-Jul 13:26 Tibs: VSS Writer: "WMI Writer", State: 1 (VSS_WS_STABLE)
+23-Jul 13:26 Tibs: VSS Writer: "Microsoft Writer (Service State)", State: 1 (VSS_WS_STABLE)
+\end{verbatim}
+\normalsize
+In the above Job Report listing, you see that the VSS snapshot was generated for drive C (if
+other drives are backed up, they will be listed on the {\bf Drive(s)="C"} You also see the
+reports from each of the writer program. Here they all report VSS_WS_STABLE, which means
+that you will get a consistent snapshot of the data handled by that writer.
+
+\subsection*{Windows Firewalls}
\index[general]{Firewalls!Windows }
\index[general]{Windows Firewalls }
-\addcontentsline{toc}{subsubsection}{Windows Firewalls}
+\addcontentsline{toc}{subsection}{Windows Firewalls}
-If you turn on the firewalling feature on Windows (default in WinXP SR2), you
+If you turn on the firewalling feature on Windows (default in WinXP SP2), you
are likely to find that the Bacula ports are blocked and you cannot
-communicated to the other daemons. This can be deactivated through the {\bf
+communicate to the other daemons. This can be deactivated through the {\bf
Security Notification} dialog, which is apparently somewhere in the {\bf
Security Center}. I don't have this on my computer, so I cannot give the exact
details.
is purported to disable the firewall, but this command is not accepted on my
WinXP Home machine.
-\subsubsection*{Windows Port Usage}
+\subsection*{Windows Port Usage}
\index[general]{Windows Port Usage }
\index[general]{Usage!Windows Port }
-\addcontentsline{toc}{subsubsection}{Windows Port Usage}
+\addcontentsline{toc}{subsection}{Windows Port Usage}
If you want to see if the File daemon has properly opened the port and is
listening, you can enter the following command in a shell window:
\end{verbatim}
\normalsize
-\subsubsection*{Windows Disaster Recovery}
+\subsection*{Windows Disaster Recovery}
\index[general]{Recovery!Windows Disaster }
\index[general]{Windows Disaster Recovery }
-\addcontentsline{toc}{subsubsection}{Windows Disaster Recovery}
+\addcontentsline{toc}{subsection}{Windows Disaster Recovery}
We don't currently have a good solution for disaster recovery on Windows as we
do on Linux. The main piece lacking is a Windows boot floppy or a Windows boot
recovery system for Win32. This distribution can be found at
\elink{http://www.nu2.nu/pebuilder/ }{http://www.nu2.nu/pebuilder/}.
-\subsubsection*{Windows Ownership and Permissions Problems}
+\subsection*{Windows Restore Problems}
+\index[general]{Problems!Windows Restore}
+\index[general]{Windows Restore Problems}
+\addcontentsline{toc}{subsection}{Windows Restore Problems}
+Please see the
+\ilink{Restore Chapter}{Windows} of this manual for problems
+that you might encounter doing a restore.
+
+
+\subsection*{Windows Ownership and Permissions Problems}
\index[general]{Problems!Windows Ownership and Permissions }
\index[general]{Windows Ownership and Permissions Problems }
-\addcontentsline{toc}{subsubsection}{Windows Ownership and Permissions
+\addcontentsline{toc}{subsection}{Windows Ownership and Permissions
Problems}
If you restore files backed up from WinNT/XP/2K to an alternate directory,
is the program {\bf SetACL}, which can be found at
\elink{http://setacl.sourceforge.net/ }{http://setacl.sourceforge.net/}.
-\subsubsection*{Manually resetting the Permissions}
+If you have not installed Bacula while running as Administrator
+and if Bacula is not running as a Process with the userid (User Name) SYSTEM,
+then it is very unlikely that it will have sufficient permission to
+access all your files.
+
+Some users have experienced problems restoring files that participate in
+the Active Directory. They also report that changing the userid under which
+Bacula (bacula-fd.exe) runs, from SYSTEM to a Domain Admin userid, resolves
+the problem.
+
+
+\subsection*{Manually resetting the Permissions}
\index[general]{Manually resetting the Permissions }
\index[general]{Permissions!Manually resetting the }
-\addcontentsline{toc}{subsubsection}{Manually resetting the Permissions}
+\addcontentsline{toc}{subsection}{Manually resetting the Permissions}
The following solution was provided by Dan Langille \lt{}dan at langille in
the dot org domain\gt{}. The steps are performed using Windows 2000 Server but
they should apply to most Win32 platforms. The procedure outlines how to deal
with a problem which arises when a restore creates a top-level new directory.
-In this example, ``top-level'' means something like {\bf
+In this example, "top-level" means something like {\bf
c:\textbackslash{}src}, not {\bf c:\textbackslash{}tmp\textbackslash{}src}
where {\bf c:\textbackslash{}tmp} already exists. If a restore job specifies /
as the {\bf Where:} value, this problem will arise.
{\bf SYSTEM} in this example as shown below).
\includegraphics{./properties-security-advanced-owner.eps}
-\item ensure the ``Replace owner on subcontainers and objects'' box is
+\item ensure the "Replace owner on subcontainers and objects" box is
checked
\item click on OK
-\item When the message ``You do not have permission to read the contents of
- directory ''c:\textbackslash{}src\textbackslash{}basis. Do you wish to replace
- the directory permissions with permissions granting you Full Control?``, click
+\item When the message "You do not have permission to read the contents of
+ directory c:\textbackslash{}src\textbackslash{}basis. Do you wish to replace
+ the directory permissions with permissions granting you Full Control?", click
on Yes.
\includegraphics{./confirm.eps}
With the above procedure, you should now have full control over your restored
directory.
-\subsubsection*{Backing Up the WinNT/XP/2K System State}
+In addition to the above methods of changing permissions, there is a Microsoft
+program named {\bf cacls} that can perform similar functions.
+
+\subsection*{Backing Up the WinNT/XP/2K System State}
\index[general]{State!Backing Up the WinNT/XP/2K System }
\index[general]{Backing Up the WinNT/XP/2K System State }
-\addcontentsline{toc}{subsubsection}{Backing Up the WinNT/XP/2K System State}
+\addcontentsline{toc}{subsection}{Backing Up the WinNT/XP/2K System State}
A suggestion by Damian Coutts using Microsoft's NTBackup utility in
conjunction with Bacula should permit a full restore of any damaged system
To the best of my knowledge, this has not yet been tested. If you test it,
please report your results to the Bacula email list.
-\subsubsection*{Windows Considerations for Filename Specifications}
+\subsection*{Windows Considerations for Filename Specifications}
\index[general]{Specifications!Windows Considerations for Filename }
\index[general]{Windows Considerations for Filename Specifications }
-\addcontentsline{toc}{subsubsection}{Windows Considerations for Filename
+\addcontentsline{toc}{subsection}{Windows Considerations for Filename
Specifications}
Please see the
for important considerations on how to specify Windows paths in Bacula FileSet
Include and Exclude directives.
-\subsubsection*{Command Line Options Specific to the Bacula Windows File
+\index[general]{Unicode}
+Bacula versions prior to 1.37.28 do not support Windows Unicode filenames.
+As of that version, both {\bf bconsole} and {\bf wx-console} support Windows
+Unicode filenames. There may still be some problems with multiple byte
+characters (e.g. Chinese, ...) where it is a two byte character but the
+displayed character is not two characters wide.
+
+\index[general]{Win32 path length restriction}
+Path/filenames longer than 260 characters are not supported. This may be
+possible in a future version.
+
+\subsection*{Command Line Options Specific to the Bacula Windows File
Daemon (Client)}
\index[general]{Client!Command Line Options Specific to the Bacula Windows
File Daemon }
\index[general]{Command Line Options Specific to the Bacula Windows File
Daemon (Client) }
-\addcontentsline{toc}{subsubsection}{Command Line Options Specific to the
+\addcontentsline{toc}{subsection}{Command Line Options Specific to the
Bacula Windows File Daemon (Client)}
These options are not normally seen or used by the user, and are documented
Bacula} to run on Windows and the standard Bacula options, all Windows
specific options are signaled with a forward slash character (/), while as
usual, the standard Bacula options are signaled with a minus (-), or a minus
-minus (\verb{--{). All the standard Bacula options can be used on the Windows
+minus (\verb:--:). All the standard Bacula options can be used on the Windows
version. In addition, the following Windows only options are implemented:
\begin{description}
automatically once Bacula is installed. However, you may note these options in
some of the .bat files that have been created for your use.
-\subsubsection*{Shutting down Windows Systems}
+\subsection*{Shutting down Windows Systems}
\index[general]{Shutting down Windows Systems }
\index[general]{Systems!Shutting down Windows }
-\addcontentsline{toc}{subsubsection}{Shutting down Windows Systems}
+\addcontentsline{toc}{subsection}{Shutting down Windows Systems}
Some users like to shutdown their windows machines after a backup using a
Client Run After Job directive. If you want to do something similar, you might
take the shutdown program from the
\elink{apcupsd project}{http://www.apcupsd.com} or one from the
-\elink{ Sysinternals
-project}{http://www.sysinternals.com/ntw2k/freeware/psshutdown.shtml}.
+\elink{Sysinternals project}{http://www.sysinternals.com/ntw2k/freeware/psshutdown.shtml}.
\section*{Console Configuration}
\label{_ChapterStart36}
-\index[general]{Configuration!Console }
-\index[general]{Console Configuration }
+\index[general]{Configuration!Console}
+\index[general]{Console Configuration}
\addcontentsline{toc}{section}{Console Configuration}
\subsection*{General}
-\index[general]{General }
+\index[general]{General}
\addcontentsline{toc}{subsection}{General}
The Console configuration file is the simplest of all the configuration files,
\subsection*{The Director Resource}
\label{DirectorResource3}
-\index[general]{Director Resource }
-\index[general]{Resource!Director }
+\index[general]{Director Resource}
+\index[general]{Resource!Director}
\addcontentsline{toc}{subsection}{Director Resource}
The Director resource defines the attributes of the Director running on the
\begin{description}
\item [Director]
- \index[console]{Director }
+ \index[console]{Director}
Start of the Director records.
\item [Name = \lt{}name\gt{}]
- \index[console]{Name }
+ \index[console]{Name}
The director name used to select among different Directors, otherwise, this
name is not used.
\item [DIRPort = \lt{}port-number\gt{}]
- \index[dir]{DIRPort }
+ \index[dir]{DIRPort}
Specify the port to use to connect to the Director. This value will most
likely already be set to the value you specified on the {\bf
\verb:--:with-base-port} option of the {\bf ./configure} command. This port must be
default is 9101 so this record is not normally specified.
\item [Address = \lt{}address\gt{}]
- \index[dir]{Address }
+ \index[dir]{Address}
Where the address is a host name, a fully qualified domain name, or a network
address used to connect to the Director.
\item [Password = \lt{}password\gt{}]
- \index[dir]{Password }
+ \index[dir]{Password}
Where the password is the password needed for the Director to accept the
Console connection. This password must be identical to the {\bf Password}
specified in the {\bf Director} resource of the
\normalsize
\subsection*{The ConsoleFont Resource}
-\index[general]{Resource!ConsoleFont }
-\index[general]{ConsoleFont Resource }
+\index[general]{Resource!ConsoleFont}
+\index[general]{ConsoleFont Resource}
\addcontentsline{toc}{subsection}{ConsoleFont Resource}
The ConsoleFont resource is available only in the GNOME version of the
\begin{description}
\item [ConsoleFont]
- \index[console]{ConsoleFont }
+ \index[console]{ConsoleFont}
Start of the ConsoleFont records.
\item [Name = \lt{}name\gt{}]
- \index[console]{Name }
+ \index[console]{Name}
The name of the font.
-\item [Font = \lt{}X-Window Font Specification\gt{}]
- \index[console]{Font }
+\item [Font = \lt{}Pango Font Name\gt{}]
+ \index[console]{Font}
The string value given here defines the desired font. It is specified in the
-standard cryptic X Window format. For example, the default specification is:
+Pango format. For example, the default specification is:
\footnotesize
\begin{verbatim}
-Font = "-misc-fixed-medium-r-normal-*-*-130-*-*-c-*-iso8859-1"
+Font = "LucidaTypewriter 9"
\end{verbatim}
\normalsize
Thanks to Phil Stracchino for providing the code for this feature.
-An actual example might be:
+An different example might be:
\footnotesize
\begin{verbatim}
ConsoleFont {
Name = Default
-Font = "-misc-fixed-medium-r-normal-*-*-130-*-*-c-*-iso8859-1"
+Font = "Monospace 10"
}
\end{verbatim}
\normalsize
\subsection*{The Console Resource}
\label{ConsoleResource}
-\index[general]{Console Resource }
-\index[general]{Resource!Console }
+\index[general]{Console Resource}
+\index[general]{Resource!Console}
\addcontentsline{toc}{subsection}{Console Resource}
As of Bacula version 1.33 and higher, there are three different kinds of
DIRport = 9101
Address = myserver
Password = "XXXXXXXXXXX" # no, really. this is not obfuscation.
- }
+}
Console {
Name = restricted-user
Password = "UntrustedUser"
- }
+}
\end{verbatim}
\normalsize
and do with Bacula.
\subsection*{Console Commands}
-\index[general]{Console Commands }
-\index[general]{Commands!Console }
+\index[general]{Console Commands}
+\index[general]{Commands!Console}
\addcontentsline{toc}{subsection}{Console Commands}
For more details on running the console and its commands, please see the
\subsection*{Sample Console Configuration File}
\label{SampleConfiguration2}
-\index[general]{File!Sample Console Configuration }
-\index[general]{Sample Console Configuration File }
+\index[general]{File!Sample Console Configuration}
+\index[general]{Sample Console Configuration File}
\addcontentsline{toc}{subsection}{Sample Console Configuration File}
An example Console configuration file might be the following:
The name of the pool. For most applications, you will use the default
pool name {\bf Default}. This directive is required.
-\item [Number of Volumes = \lt{}number\gt{}]
- \index[dir]{Number of Volumes }
- This directive specifies the number of volumes (tapes or files)
- contained in the pool. Normally, it is defined and updated
- automatically by the Bacula catalog handling routines.
-
\label{MaxVolumes}
\item [Maximum Volumes = \lt{}number\gt{}]
\index[dir]{Maximum Volumes }
However, if you use this directive and have only one
Volume in the Pool, you will immediately recycle your Volume if you fill
it and Bacula needs another one. Thus your backup will be totally invalid.
- Please use this directive with care. The default is {\no}.
+ Please use this directive with care. The default is {\bf no}.
\label{RecycleCurrent}
However, if you use this directive and have only one Volume in the Pool,
you will immediately recycle your Volume if you fill it and Bacula needs
another one. Thus your backup will be totally invalid. Please use this
- directive with care. The default is {\no}.
+ directive with care. The default is {\bf no}.
\label{PurgeOldest}
We {\bf highly} recommend against using this directive, because it is
sure that some day, Bacula will recycle a Volume that contains current
- data. The default is {\no}.
+ data. The default is {\bf no}.
\item [Cleaning Prefix = \lt{}string\gt{}]
\index[dir]{Cleaning Prefix }
This script creates the PostgreSQL {\bf bacula} database.
If it fails, it is probably because the database is owned by a
user other than yourself. On many systems, the database owner is
- {\bf pgsql} and on others such as RedHat and Fedora it is {\bf postgre}.
+ {\bf pgsql} and on others such as RedHat and Fedora it is {\bf postgres}.
You can find out which it is by examining your /etc/passwd file.
To create a new user under either your name or with say the name
{\bf bacula}, you can do the following:
\begin{verbatim}
su
(enter root password)
- password pgsql (or postgre)
+ password pgsql (or postgres)
(enter a password for this account)
exit
- su pgsql (or postgre)
+ su pgsql (or postgres)
(enter password just created)
createuser kern (or perhaps bacula)
Shall the new user be allowed to create databases? (y/n) y
to do from a security standpoint. However, it allowed me to run
my regression scripts without having a password.
+A more secure way to perform database authentication is with md5
+password hashes. Begin by editing the {\bf pg_hba.conf} file, and
+just prior the the existing ``local'' and ``host'' lines, add the line:
+
+\footnotesize
+\begin{verbatim}
+ local bacula bacula md5
+\end{verbatim}
+\normalsize
+
+and restart the Postgres database server (frequently, this can be done
+using "/etc/init.d/postgresql restart") to put this new authentication
+rule into effect.
+
+Next, become the Postgres administrator, postgres, either by logging
+on as the postgres user, or by using su to become root and then using
+su - postgres to become postgres. Add a password to the bacula
+database for the bacula user using:
+
+\footnotesize
+\begin{verbatim}
+ \$ psql bacula
+ bacula=# alter user bacula with password 'secret';
+ ALTER USER
+ bacula=# \\q
+\end{verbatim}
+\normalsize
+
+Next, you'll have to add this password to two locations in the
+bacula-dir.conf file: once to the Catalog resource and once to the
+RunBeforeJob entry in the BackupCatalog Job resource. With the
+password in place, these two lines should look something like:
+
+\footnotesize
+\begin{verbatim}
+ dbname = bacula; user = bacula; password = "secret"
+ ... and ...
+ RunBeforeJob = "/etc/make_catalog_backup bacula bacula secret"
+\end{verbatim}
+\normalsize
+
+Naturally, you should choose your own significantly more random
+password, and ensure that the bacula-dir.conf file containing this
+password is readable only by the root.
+
+Even with the files containing the database password properly
+restricted, there is still a security problem with this approach: on
+some platforms, the environment variable that is used to supply the
+password to Postgres is unavoidable made available to all users of the
+local system. To eliminate this problem, the Postgres team have
+deprecated the use of the environment variable password-passing
+mechanism and recommend the use of a .pgpass file instead. To use
+this mechanism, create a file named .pgpass containing the single
+line:
+
+\footnotesize
+\begin{verbatim}
+ localhost:5432:bacula:bacula:secret
+\end{verbatim}
+\normalsize
+
+This file should be copied into the home directory of all accounts
+that will need to gain access to the database: typically, root,
+bacula, and any users who will make use of any of the console
+programs. The files must then have the owner and group set to match
+the user (so root:root for the copy in ~root, and so on), and the mode
+set to 600, limiting access to the owner of the file.
\subsection*{Re-initializing the Catalog Database}
\index[general]{Database!Re-initializing the Catalog }
\index[general]{Modes!Details}
\index[general]{Details of Tape Modes}
\addcontentsline{toc}{subsection}{Details of Tape Modes}
-Rudolf Cejkar has provided the following information concerning
+Rudolf Cejka has provided the following information concerning
certain tape modes and MTEOM.
\begin{description}
The above script will ask you a number of questions. You may simply answer
each of them by entering a return, or if you wish you may enter your own data.
+An alternative is to generate your self-signed certificates with TinyCA,
+which has a very nice Graphical User Interface. TinyCA can be found at
+\elink{http://tinyca.sm-zone.net/}{http://tinyca.sm-zone.net/}.
+
\subsection*{Getting a CA Signed Certificate}
\index[general]{Certificate!Getting a CA Signed }
\normalsize
-
projects / bacula / docs / commitdiff