-%%
-%%
-
\chapter{Tips and Suggestions}
\label{TipsChapter}
-\index[general]{Tips and Suggestions }
-\index[general]{Suggestions!Tips and }
+\index[general]{Tips and Suggestions}
+\index[general]{Suggestions!Tips and}
\label{examples}
-\index[general]{Examples }
+\index[general]{Examples}
There are a number of example scripts for various things that can be found in
the {\bf example} subdirectory and its subdirectories of the Bacula source
-distribution.
+distribution.
For additional tips, please see the \elink{Bacula
-wiki}{\url{http://wiki.bacula.org}}.
+wiki}{http://wiki.bacula.org}.
\section{Upgrading Bacula Versions}
\label{upgrading}
-\index[general]{Upgrading Bacula Versions }
-\index[general]{Versions!Upgrading Bacula }
+\index[general]{Upgrading Bacula Versions}
+\index[general]{Versions!Upgrading Bacula}
\index[general]{Upgrading}
The first thing to do before upgrading from one version to another is to
of Bacula until you have tested that the new version works.
If you have installed Bacula into a single directory, this is simple: simply
-make a copy of your Bacula directory.
+make a copy of your Bacula directory.
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. Alternatively, make copies of all your binaries and especially your
+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
{\bf *.conf} files from your production Bacula directory to the test Bacula
directory, start the test version, and run a few test backups. If all seems
good, then you can proceed to install the new Bacula in place of or possibly
-over the old Bacula.
+over the old Bacula.
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
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
+or alternatively, you can find it in the
{\bf \lt{}bacula-source\gt{}/src/cats} directory.
\section{Getting Notified of Job Completion}
\label{notification}
-\index[general]{Getting Notified of Job Completion }
-\index[general]{Completion!Getting Notified of Job }
+\index[general]{Getting Notified of Job Completion}
+\index[general]{Completion!Getting Notified of Job}
One of the first things you should do is to ensure that you are being properly
notified of the status of each Job run by Bacula, or at a minimum of each Job
-that terminates with an error.
+that terminates with an error.
Until you are completely comfortable with {\bf Bacula}, we recommend that you
send an email to yourself for each Job that is run. This is most easily
accomplished by adding an email notification address in the {\bf Messages}
resource of your Director's configuration file. An email is automatically
configured in the default configuration files, but you must ensure that the
-default {\bf root} address is replaced by your email address.
+default {\bf root} address is replaced by your email address.
For additional examples of how to configure a Bacula, please take a look at the
{\bf .conf} files found in the {\bf examples} sub-directory. We recommend the
following configuration (where you change the paths and email address to
correspond to your setup). Note, the {\bf mailcommand} and {\bf
operatorcommand} should be on a single line. They were split here for
-presentation:
+presentation:
\footnotesize
-\begin{verbatim}
+\begin{lstlisting}
Messages {
Name = Standard
mailcommand = "/home/bacula/bin/bsmtp -h localhost
operator = your-email-address = mount
console = all, !skipped, !saved
}
-\end{verbatim}
+\end{lstlisting}
\normalsize
You will need to ensure that the {\bf /home/bacula/bin} path on the {\bf
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
-/home/bacula/bin/log} points to the file where you want to log all messages.
+/home/bacula/bin/log} points to the file where you want to log all messages.
With the above Messages resource, you will be notified by email of every Job
that ran, all the output will be appended to the {\bf log} file you specify,
all output will be directed to the console program, and all mount messages
will be emailed to you. Note, some messages will be sent to multiple
-destinations.
+destinations.
The form of the mailcommand is a bit complicated, but it allows you to
distinguish whether the Job terminated in error or terminated normally. Please
-see the
-\ilink{Mail Command}{mailcommand} section of the Messages
-Resource chapter of this manual for the details of the substitution characters
-used above.
+see the
+\bsysxrlink{Mail}{mailcommand}{utility}{command} in the \utilityman{} for the
+ details of the substitution characters used above.
Once you are totally comfortable with Bacula as I am, or if you have a large
number of nightly Jobs as I do (eight), you will probably want to change the
{\bf Mail} command to {\bf Mail On Error} which will generate an email message
only if the Job terminates in error. If the Job terminates normally, no email
message will be sent, but the output will still be appended to the log file as
-well as sent to the Console program.
+well as sent to the Console program.
\section{Getting Email Notification to Work}
\label{email}
-\index[general]{Work!Getting Email Notification to }
-\index[general]{Getting Email Notification to Work }
+\index[general]{Work!Getting Email Notification to}
+\index[general]{Getting Email Notification to Work}
The section above describes how to get email notification of job status.
Occasionally, however, users have problems receiving any email at all. In that
-case, the things to check are the following:
+case, the things to check are the following:
\begin{itemize}
\item Ensure that you have a valid email address specified on your {\bf Mail}
record in the Director's Messages resource. The email address should be fully
qualified. Simply using {\bf root} generally will not work, rather you should
-use {\bf root@localhost} or better yet your full domain.
+use {\bf root@localhost} or better yet your full domain.
\item Ensure that you do not have a {\bf Mail} record in the Storage daemon's
or File daemon's configuration files. The only record you should have is {\bf
- director}:
+ director}:
\footnotesize
-\begin{verbatim}
+\begin{lstlisting}
director = director-name = all
-
-\end{verbatim}
+
+\end{lstlisting}
\normalsize
-\item If all else fails, try replacing the {\bf mailcommand} with
+\item If all else fails, try replacing the {\bf mailcommand} with
\footnotesize
-\begin{verbatim}
+\begin{lstlisting}
mailcommand = "mail -s test your@domain.com"
-\end{verbatim}
+\end{lstlisting}
\normalsize
\item Once the above is working, assuming you want to use {\bf bsmtp}, submit
the desired bsmtp command by hand and ensure that the email is delivered,
then put that command into {\bf Bacula}. Small differences in things such as
the parenthesis around the word Bacula can make a big difference to some
-bsmtp programs. For example, you might start simply by using:
+bsmtp programs. For example, you might start simply by using:
\footnotesize
-\begin{verbatim}
+\begin{lstlisting}
mailcommand = "/home/bacula/bin/bsmtp -f \"root@localhost\" %r"
-\end{verbatim}
+\end{lstlisting}
\normalsize
\end{itemize}
\section{Getting Notified that Bacula is Running}
\label{JobNotification}
-\index[general]{Running!Getting Notified that Bacula is }
-\index[general]{Getting Notified that Bacula is Running }
+\index[general]{Running!Getting Notified that Bacula is}
+\index[general]{Getting Notified that Bacula is Running}
If like me, you have setup Bacula so that email is sent only when a Job has
errors, as described in the previous section of this chapter, inevitably, one
day, something will go wrong and {\bf Bacula} can stall. This could be because
Bacula crashes, which is vary rare, or more likely the network has caused {\bf
-Bacula} to {\bf hang} for some unknown reason.
+Bacula} to {\bf hang} for some unknown reason.
To avoid this, you can use the {\bf RunAfterJob} command in the Job resource
to schedule a Job nightly, or weekly that simply emails you a message saying
that Bacula is still running. For example, I have setup the following Job in
-my Director's configuration file:
+my Director's configuration file:
\footnotesize
-\begin{verbatim}
+\begin{lstlisting}
Schedule {
Name = "Watchdog"
Run = Level=Full sun-sat at 6:05
Job Retention = 1 month
AutoPrune = yes
}
-\end{verbatim}
+\end{lstlisting}
\normalsize
Where I established a schedule to run the Job nightly. The Job itself is type
{\bf Admin} which means that it doesn't actually do anything, and I've defined
a FileSet, Pool, Storage, and Client, all of which are not really used (and
probably don't need to be specified). The key aspect of this Job is the
-command:
+command:
\footnotesize
-\begin{verbatim}
+\begin{lstlisting}
RunAfterJob = "/home/kern/bacula/bin/watchdog %c %d"
-\end{verbatim}
+\end{lstlisting}
\normalsize
which runs my "watchdog" script. As an example, I have added the Job codes
the Director's name is {\bf main-dir} then referencing \$1 in the script would
get {\bf Watchdog} and referencing \$2 would get {\bf main-dir}. In this case,
having the script know the Client and Director's name is not really useful,
-but in other situations it may be.
+but in other situations it may be.
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:
+following is my watchdog script:
\footnotesize
-\begin{verbatim}
+\begin{lstlisting}
#!/bin/sh
cd /home/kern/mysql/var/bacula
du . * |
/home/kern/bacula/bin/bsmtp \
-f "\(Bacula\) abuse@whitehouse.com" -h mail.yyyy.com \
-s "Bacula running" abuse@whitehouse.com
-\end{verbatim}
+\end{lstlisting}
\normalsize
-If you just wish to send yourself a message, you can do it with:
+If you just wish to send yourself a message, you can do it with:
\footnotesize
-\begin{verbatim}
+\begin{lstlisting}
#!/bin/sh
cd /home/kern/mysql/var/bacula
/home/kern/bacula/bin/bsmtp \
-s "Bacula running" abuse@whitehouse.com <<END-OF-DATA
Bacula is still running!!!
END-OF-DATA
-\end{verbatim}
+\end{lstlisting}
\normalsize
\section{Maintaining a Valid Bootstrap File}
\label{bootstrap}
-\index[general]{Maintaining a Valid Bootstrap File }
-\index[general]{File!Maintaining a Valid Bootstrap }
+\index[general]{Maintaining a Valid Bootstrap File}
+\index[general]{File!Maintaining a Valid Bootstrap}
-By using a
-\ilink{ WriteBootstrap}{writebootstrap} record in each of your
-Director's Job resources, you can constantly maintain a
-\ilink{bootstrap}{BootstrapChapter} file that will enable you to
+By using a \bsysxrlinkdocument{WriteBootstrap}{writebootstrap}{main}{chapter} record in each of your
+Director's Job resources (\mainman{}), you can constantly maintain a
+\bsysxrlinkdocument{bootstrap}{BootstrapChapter}{main}{chapter} file that will enable you to
recover the state of your system as of the last backup without having the
Bacula catalog. This permits you to more easily recover from a disaster that
-destroys your Bacula catalog.
+destroys your Bacula catalog.
When a Job resource has a {\bf WriteBootstrap} record, Bacula will maintain
the designated file (normally on another system but mounted by NFS) with up to
date information necessary to restore your system. For example, in my
-Director's configuration file, I have the following record:
+Director's configuration file, I have the following record:
\footnotesize
-\begin{verbatim}
+\begin{lstlisting}
Write Bootstrap = "/mnt/deuter/files/backup/client-name.bsr"
-\end{verbatim}
+\end{lstlisting}
\normalsize
where I replace {\bf client-name} by the actual name of the client that is
being backed up. Thus, Bacula automatically maintains one file for each of my
clients. The necessary bootstrap information is appended to this file during
each {\bf Incremental} backup, and the file is totally rewritten during each
-{\bf Full} backup.
+{\bf Full} backup.
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()
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. However, I found that with the {\bf soft} option
+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
{\bf Write Bootstrap} record. The restore bootstrap file can be found in {\bf
restore.bsr} in the working directory that you defined. In the example given
below for the client {\bf rufus}, my input is shown in bold. Note, the JobId
-output has been partially truncated to fit on the page here:
+output has been partially truncated to fit on the page here:
\footnotesize
-\begin{verbatim}
+\begin{lstlisting}
(in the Console program)
*restore
First you select one or more JobIds that contain files
quit
(in a shell window)
cp ../working/restore.bsr /mnt/deuter/files/backup/rufus.bsr
-\end{verbatim}
+\end{lstlisting}
\normalsize
\section{Rejected Volumes After a Crash}
\label{RejectedVolumes}
-\index[general]{Crash!Rejected Volumes After a }
-\index[general]{Rejected Volumes After a Crash }
+\index[general]{Crash!Rejected Volumes After a}
+\index[general]{Rejected Volumes After a Crash}
Bacula keeps a count of the number of files on each Volume in its Catalog
database so that before appending to a tape, it can verify that the number of
the Storage daemon crashes before the job has completed, the tape will contain
one more file than is noted in the Catalog, and the next time you attempt to
use the same Volume, Bacula will reject it due to a mismatch between the
-physical tape (Volume) and the catalog.
+physical tape (Volume) and the catalog.
The easiest solution to this problem is to label a new tape and start fresh.
If you wish to continue appending to the current tape, you can do so by using
the {\bf update} command in the console program to change the {\bf Volume
Files} entry in the catalog. A typical sequence of events would go like the
-following:
+following:
\footnotesize
-\begin{verbatim}
+\begin{lstlisting}
- Bacula crashes
- You restart Bacula
-\end{verbatim}
+\end{lstlisting}
\normalsize
-Bacula then prints:
+Bacula then prints:
\footnotesize
-\begin{verbatim}
+\begin{lstlisting}
17-Jan-2003 16:45 rufus-dir: Start Backup JobId 13,
Job=kernsave.2003-01-17_16.45.46
17-Jan-2003 16:45 rufus-sd: Volume test01 previously written,
Storage: SDT-10000
Media type: DDS-4
Pool: Default
-\end{verbatim}
+\end{lstlisting}
\normalsize
(note, lines wrapped for presentation)
-The key here is the line that reads:
+The key here is the line that reads:
\footnotesize
-\begin{verbatim}
+\begin{lstlisting}
The number of files mismatch! Volume=11 Catalog=10
-\end{verbatim}
+\end{lstlisting}
\normalsize
It says that Bacula found eleven files on the volume, but that the catalog
and even if the catalog contains references to files saved in file 11,
everything will be OK and nothing will be lost. Note that if the SD had
written several file marks to the volume, the difference between the Volume
-count and the Catalog count could be larger than one, but this is unusual.
+count and the Catalog count could be larger than one, but this is unusual.
If on the other hand the catalog is marked as having more files than Bacula
found on the tape, you need to consider the possible negative consequences of
modifying the catalog. Please see below for a more complete discussion of
-this.
+this.
Continuing with the example of {\bf Volume = 11 Catalog = 10}, to enable to
-Bacula to append to the tape, you do the following:
+Bacula to append to the tape, you do the following:
\footnotesize
-\begin{verbatim}
+\begin{lstlisting}
update
Update choice:
1: Volume parameters
| 1 | test01 | DDS-4 | Error | 352427156 | ... | 31536000 | 1 | 0 |
+-------+---------+--------+---------+-----------+------+----------+------+-----+
Enter MediaId or Volume name: 1
-\end{verbatim}
+\end{lstlisting}
\normalsize
(note table output truncated for presentation) First, you chose to update the
Volume parameters by entering a {\bf 1}. In the volume listing that follows,
notice how the VolStatus is {\bf Error}. We will correct that after changing
-the Volume Files. Continuing, you respond 1,
+the Volume Files. Continuing, you respond 1,
\footnotesize
-\begin{verbatim}
+\begin{lstlisting}
Updating Volume "test01"
Parameters to modify:
1: Volume Status
10: Pool
11: Done
Select parameter to modify (1-10): 1
-\end{verbatim}
+\end{lstlisting}
\normalsize
Here, you have selected {\bf 9} in order to update the Volume Files, then you
changed it from {\bf 10} to {\bf 11}, and you now answer {\bf 1} to change the
-Volume Status.
+Volume Status.
\footnotesize
-\begin{verbatim}
+\begin{lstlisting}
Current Volume status is: Error
Possible Values are:
1: Append
11: Done
Select parameter to modify (1-11): 11
Selection done.
-\end{verbatim}
+\end{lstlisting}
\normalsize
At this point, you have changed the Volume Files from {\bf 10} to {\bf 11} to
account for the last file that was written but not updated in the database,
-and you changed the Volume Status back to {\bf Append}.
+and you changed the Volume Status back to {\bf Append}.
-This was a lot of words to describe something quite simple.
+This was a lot of words to describe something quite simple.
The {\bf Volume Files} option exists only in version 1.29 and later, and you
should be careful using it. Generally, if you set the value to that which
Bacula said is on the tape, you will be OK, especially if the value is one
-more than what is in the catalog.
+more than what is in the catalog.
-Now lets consider the case:
+Now lets consider the case:
\footnotesize
-\begin{verbatim}
+\begin{lstlisting}
The number of files mismatch! Volume=10 Catalog=12
-\end{verbatim}
+\end{lstlisting}
\normalsize
Here the Bacula found fewer files on the volume than what is marked in the
saved on Files 11 and 12, all chaos will break out. In this case, you will
probably be better off using a new tape. In fact, you might want to see what
files the catalog claims are actually stored on that Volume, and back them up
-to another tape and recycle this tape.
+to another tape and recycle this tape.
\section{Security Considerations}
\label{security}
-\index[general]{Considerations!Security }
-\index[general]{Security Considerations }
+\index[general]{Considerations!Security}
+\index[general]{Security Considerations}
Only the File daemon needs to run with root permission (so that it can access
all files). As a consequence, you may run your Director, Storage daemon, and
MySQL or PostgreSQL database server as non-root processes. Version 1.30 has
the {\bf -u} and the {\bf -g} options that allow you to specify a userid and
-groupid on the command line to be used after Bacula starts.
+groupid on the command line to be used after Bacula starts.
As of version 1.33, thanks to Dan Langille, it is easier to configure the
-Bacula Director and Storage daemon to run as non-root.
+Bacula Director and Storage daemon to run as non-root.
You should protect the Bacula port addresses (normally 9101, 9102, and 9103)
from outside access by a firewall or other means of protection to prevent
-unauthorized use of your daemons.
+unauthorized use of your daemons.
You should ensure that the configuration files are not world readable since
they contain passwords that allow access to the daemons. Anyone who can access
the Director using a console program can restore any file from a backup
-Volume.
+Volume.
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),
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
-configuration file in the appropriate Catalog resource.
+configuration file in the appropriate Catalog resource.
If you use the make\_catalog\_backup script provided by Bacula, remember that
you should take care when supplying passwords on the command line. Read the
\ilink{Backing Up Your Bacula
-Database - Security Considerations }{BackingUpBaculaSecurityConsiderations}
+Database - Security Considerations}{BackingUpBaculaSecurityConsiderations}
section for more information.
\section{Creating Holiday Schedules}
\label{holiday}
-\index[general]{Schedules!Creating Holiday }
-\index[general]{Creating Holiday Schedules }
+\index[general]{Schedules!Creating Holiday}
+\index[general]{Creating Holiday Schedules}
If you normally change tapes every day or at least every Friday, but Thursday
is a holiday, you can use a trick proposed by Lutz Kittler to ensure that no
be used on Friday. To do so, define a {\bf RunJobBefore} script that normally
returns zero, so that the Bacula job will normally continue. You can then
modify the script to return non-zero on any day when you do not want Bacula to
-run the job.
+run the job.
\section{Automatic Labeling Using Your Autochanger}
\label{autolabel}
-\index[general]{Automatic Labeling Using Your Autochanger }
-\index[general]{Autochanger!Automatic Labeling Using Your }
+\index[general]{Automatic Labeling Using Your Autochanger}
+\index[general]{Autochanger!Automatic Labeling Using Your}
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.
+magazine.
First create a file containing one line for each slot in your autochanger that
has a tape to be labeled. The line will contain the slot number a colon (:)
then the Volume name you want to use. For example, create a file named {\bf
-volume-list}, which contains:
+volume-list}, which contains:
\footnotesize
-\begin{verbatim}
+\begin{lstlisting}
1:Volume001
2:TestVolume02
5:LastVolume
-\end{verbatim}
+\end{lstlisting}
\normalsize
The records do not need to be in any order and you don't need to mention all
sequential set of numbers for each slot you want labeled. In the example
above, I've left out slots 3 and 4 just as an example. Now, modify your {\bf
mtx-changer} script and comment out all the lines in the {\bf list)} case by
-putting a \# in column 1. Then add the following two lines:
+putting a \# in column 1. Then add the following two lines:
\footnotesize
-\begin{verbatim}
+\begin{lstlisting}
cat <absolute-path>/volume-list
exit 0
-\end{verbatim}
+\end{lstlisting}
\normalsize
-so that the whole case looks like:
+so that the whole case looks like:
\footnotesize
-\begin{verbatim}
+\begin{lstlisting}
list)
#
# commented out lines
cat <absolute-path>/volume-list
exit 0
;;
-\end{verbatim}
+\end{lstlisting}
\normalsize
where you replace \lt{}absolute-path\gt{} with the full path to the
-volume-list file. Then using the console, you enter the following command:
+volume-list file. Then using the console, you enter the following command:
\footnotesize
-\begin{verbatim}
+\begin{lstlisting}
label barcodes
-\end{verbatim}
+\end{lstlisting}
\normalsize
and Bacula will proceed to mount the autochanger Volumes in the list and label
them with the Volume names you have supplied. Bacula will think that the list
was provided by the autochanger barcodes, but in reality, it was you who
-supplied the \lt{}barcodes\gt{}.
+supplied the \lt{}barcodes\gt{}.
-If it seems to work, when it finishes, enter:
+If it seems to work, when it finishes, enter:
\footnotesize
-\begin{verbatim}
+\begin{lstlisting}
list volumes
-\end{verbatim}
+\end{lstlisting}
\normalsize
-and you should see all the volumes nicely created.
+and you should see all the volumes nicely created.
\section{Backing Up Portables Using DHCP}
\label{DNS}
-\index[general]{DHCP!Backing Up Portables Using }
-\index[general]{Backing Up Portables Using DHCP }
+\index[general]{DHCP!Backing Up Portables Using}
+\index[general]{Backing Up Portables Using DHCP}
You may want to backup laptops or portables that are not always connected to
the network. If you are using DHCP to assign an IP address to those machines
when they connect, you will need to use the Dynamic Update capability of DNS
to assign a name to those machines that can be used in the Address field of
-the Client resource in the Director's conf file.
+the Client resource in the Director's conf file.
\section{Going on Vacation}
\label{Vacation}
-\index[general]{Vacation!Going on }
-\index[general]{Going on Vacation }
+\index[general]{Vacation!Going on}
+\index[general]{Going on Vacation}
At some point, you may want to be absent for a week or two and you want to
make sure Bacula has enough tape left so that the backups will complete. You
-start by doing a {\bf list volumes} in the Console program:
+start by doing a {\bf list volumes} in the Console program:
\footnotesize
-\begin{verbatim}
+\begin{lstlisting}
list volumes
-
+
Using default Catalog name=BackupDB DB=bacula
Pool: Default
+---------+---------------+-----------+-----------+----------------+-
| 34 | DLT-08Aug03 | DLT8000 | Full | 64,293,941,255 |
| 35 | DLT-24Aug03 | DLT8000 | Append | 9,999,216,782 |
+---------+---------------+-----------+-----------+----------------+
-\end{verbatim}
+\end{lstlisting}
\normalsize
Note, I have truncated the output for presentation purposes. What is
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).
+(at least not for short absences).
Equally significant is the fact that I did go on vacation the 28th of June
2003, and when I did the {\bf list volumes} command, my current tape at that
time, DLT-07Jun03 MediaId 31, had 56.5 Gbytes written. I could see that the
tape would fill shortly. Consequently, I manually marked it as {\bf Used} and
replaced it with a fresh tape that I labeled as DLT-28Jun03, thus assuring
-myself that the backups would all complete without my intervention.
+myself that the backups would all complete without my intervention.
\section{Exclude Files on Windows Regardless of Case}
\label{Case}
of his files on Win32, which is case insensitive. The problem is that Bacula
thinks that {\bf /UNIMPORTANT FILES} is different from {\bf /Unimportant
Files}. Marc was aware that the file exclusion permits wild-cards. So, he
-specified:
+specified:
\footnotesize
-\begin{verbatim}
+\begin{lstlisting}
"/[Uu][Nn][Ii][Mm][Pp][Oo][Rr][Tt][Aa][Nn][Tt] [Ff][Ii][Ll][Ee][Ss]"
-\end{verbatim}
+\end{lstlisting}
\normalsize
-As a consequence, the above exclude works for files of any case.
+As a consequence, the above exclude works for files of any case.
Please note that this works only in Bacula Exclude statement and not in
-Include.
+Include.
\section{Executing Scripts on a Remote Machine}
\label{RemoteExecution}
-\index[general]{Machine!Executing Scripts on a Remote }
-\index[general]{Executing Scripts on a Remote Machine }
+\index[general]{Machine!Executing Scripts on a Remote}
+\index[general]{Executing Scripts on a Remote Machine}
This tip also comes from Marc Brueckner. (Note, this tip is probably outdated
by the addition of {\bf ClientRunBeforJob} and {\bf ClientRunAfterJob} Job
backup has finished) I found the following solution: Bacula could execute
scripts 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
-done this by:
+done this by:
\footnotesize
-\begin{verbatim}
+\begin{lstlisting}
ssh-keygen -b 4096 -t dsa -f Bacula_key
-\end{verbatim}
+\end{lstlisting}
\normalsize
This statement may take a little time to run. It creates a public/private key
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.
+which contains the public key.
Now you have to append the Bacula\_key.pub file to the file authorized\_keys
in the \textbackslash{}root\textbackslash{}.ssh directory of the remote
-machine. Then you have to add (or uncomment) the line
+machine. Then you have to add (or uncomment) the line
\footnotesize
-\begin{verbatim}
+\begin{lstlisting}
AuthorizedKeysFile %h/.ssh/authorized_keys
-\end{verbatim}
+\end{lstlisting}
\normalsize
to the sshd\_config file on the remote machine. Where the \%h stands for the
-home-directory of the user (root in this case).
+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 following on the machine where Bacula runs:
+enter the following on the machine where Bacula runs:
\footnotesize
-\begin{verbatim}
+\begin{lstlisting}
ssh -i Bacula_key -l root <machine-name-or-ip-address> "ls -la"
-\end{verbatim}
+\end{lstlisting}
\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:
+Now you could add lines like the following to your Director's conf file:
\footnotesize
-\begin{verbatim}
+\begin{lstlisting}
...
Run Before Job = ssh -i /etc/bacula/Bacula_key 192.168.1.1 \
"/etc/init.d/database stop"
Run After Job = ssh -i /etc/bacula/Bacula_key 192.168.1.1 \
"/etc/init.d/database start"
...
-\end{verbatim}
+\end{lstlisting}
\normalsize
Even though Bacula version 1.32 and later has a ClientRunBeforeJob, the ssh method still
could be useful for updating all the Bacula clients on several remote machines
-in a single script.
+in a single script.
\section{Recycling All Your Volumes}
\label{recycle}
-\index[general]{Recycling All Your Volumes }
-\index[general]{Volumes!Recycling All Your }
+\index[general]{Recycling All Your Volumes}
+\index[general]{Volumes!Recycling All Your}
-This tip comes from Phil Stracchino.
+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 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}.
+every tape to {\bf Recycle}.
The SQL command to do this is very simple, either use your vendor's
command line interface (mysql, postgres, sqlite, ...) or use the sql
command in the Bacula console:
\footnotesize
-\begin{verbatim}
+\begin{lstlisting}
update Media set VolStatus='Recycle';
-\end{verbatim}
+\end{lstlisting}
\normalsize
Bacula will then ignore the data already stored on the tapes and just re-use
-each tape without further objection.
+each tape without further objection.
\section{Backing up ACLs on ext3 or XFS filesystems}
\label{ACLs}
-\index[general]{Filesystems!Backing up ACLs on ext3 or XFS }
-\index[general]{Backing up ACLs on ext3 or XFS filesystems }
+\index[general]{Filesystems!Backing up ACLs on ext3 or XFS}
+\index[general]{Backing up ACLs on ext3 or XFS filesystems}
-This tip comes from Volker Sauer.
+This tip comes from Volker Sauer.
Note, this tip was given prior to implementation of ACLs in Bacula (version
1.34.5). It is left here because dumping/displaying ACLs can still be useful
in testing/verifying that Bacula is backing up and restoring your ACLs
-properly. Please see the
+properly. Please see the
\ilink{aclsupport}{ACLSupport} FileSet option in the
-configuration chapter of this manual.
+configuration chapter of this manual.
For example, you could dump the ACLs to a file with a script similar to the
-following:
+following:
\footnotesize
-\begin{verbatim}
+\begin{lstlisting}
#!/bin/sh
BACKUP_DIRS="/foo /bar"
STORE_ACL=/root/acl-backup
for i in $BACKUP_DIRS; do
cd $i /usr/bin/getfacl -R --skip-base .>$STORE_ACL/${i//\//_}
done
-\end{verbatim}
+\end{lstlisting}
\normalsize
-Then use Bacula to backup {\bf /root/acl-backup}.
+Then use Bacula to backup {\bf /root/acl-backup}.
The ACLs could be restored using Bacula to the {\bf /root/acl-backup} file,
-then restored to your system using:
+then restored to your system using:
\footnotesize
-\begin{verbatim}
+\begin{lstlisting}
setfacl --restore/root/acl-backup
-\end{verbatim}
+\end{lstlisting}
\normalsize
\section{Total Automation of Bacula Tape Handling}
\label{automate}
-\index[general]{Handling!Total Automation of Bacula Tape }
-\index[general]{Total Automation of Bacula Tape Handling }
+\index[general]{Handling!Total Automation of Bacula Tape}
+\index[general]{Total Automation of Bacula Tape Handling}
-This tip was provided by Alexander Kuehn.
+This tip was provided by Alexander Kuehn.
-\elink{Bacula}{\url{http://www.bacula.org/}} is a really nice backup program except
+\elink{Bacula}{http://www.bacula.org/} is a really nice backup program except
that the manual tape changing requires user interaction with the bacula
-console.
+console.
Fortunately I can fix this.
NOTE!!! This suggestion applies for people who do *NOT* have tape autochangers
-and must change tapes manually.!!!!!
+and must change tapes manually.!!!!!
Bacula supports a variety of tape changers through the use of mtx-changer
-scripts/programs. This highly flexible approach allowed me to create
-\elink{this shell script}{\url{http://www.bacula.org/en/rel-manual/mtx-changer.txt}} which does the following:
+scripts/programs. This highly flexible approach allowed me to create
+\elink{this shell script}{http://www.bacula.org/en/rel-manual/mtx-changer.txt} which does the following:
% TODO: We need to include this in book appendix and point to it.
% TODO:
Whenever a new tape is required it sends a mail to the operator to insert 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):
+Type" and "Label media" may have different values):
\footnotesize
-\begin{verbatim}
+\begin{lstlisting}
Device {
Name=DDS3
Archive Device = # use yours not mine! ;)/dev/nsa0
Offline On Unmount = Yes; # keep this too
Label media = Yes; #
}
-\end{verbatim}
+\end{lstlisting}
\normalsize
As the script has to emulate the complete wisdom of a mtx-changer it has an
the following line:
\footnotesize
-\begin{verbatim}
+\begin{lstlisting}
labels="VOL-0001 VOL-0002 VOL-0003 VOL-0004 VOL-0005 VOL-0006
VOL-0007 VOL-0008 VOL-0009 VOL-0010 VOL-0011 VOL-0012"
-\end{verbatim}
+\end{lstlisting}
\normalsize
The above should be all on one line, and it effectively tells Bacula that
Bacula can run multiple concurrent jobs, but the default configuration files
do not enable it. Using the {\bf Maximum Concurrent Jobs} directive, you
-can configure how many and which jobs can be run simultaneously.
+can configure how many and which jobs can be run simultaneously.
The Director's default value for {\bf Maximum Concurrent Jobs} is "1".
-To initially setup concurrent jobs you need to define {\bf Maximum Concurrent Jobs} in
-the Director's configuration file (bacula-dir.conf) in the
+To initially setup concurrent jobs you need to define {\bf Maximum Concurrent Jobs} in
+the Director's configuration file (bacula-dir.conf) in the
Director, Job, Client, and Storage resources.
Additionally the File daemon, and the Storage daemon each have their own
For example, if you want two different jobs to run simultaneously backing up
the same Client to the same Storage device, they will run concurrently only if
you have set {\bf Maximum Concurrent Jobs} greater than one in the Director
-resource, the Client resource, and the Storage resource in bacula-dir.conf.
+resource, the Client resource, and the Storage resource in bacula-dir.conf.
We recommend that you read the \ilink{Data
Spooling}{SpoolingChapter} of this manual first, then test your multiple
places where the the file must be modified to allow the same job {\bf
NightlySave} to run up to four times concurrently. The change to the Job
resource is not necessary if you want different Jobs to run at the same time,
-which is the normal case.
+which is the normal case.
\footnotesize
-\begin{verbatim}
+\begin{lstlisting}
#
# Bacula Director Configuration file -- bacula-dir.conf
#
Maximum Concurrent Jobs = 4
...
}
-\end{verbatim}
+\end{lstlisting}
\normalsize
projects / bacula / docs / blobdiff