
Bacula 1.29 User's Guide
|
Chapter
|
|
 |
|
|
Bacula Frequently Asked Questions
See the bugs section of this document for
a list of known bugs and solutions.
- What is Bacula?
- Bacula is a network backup and restore program.
- Does Bacula support Windows?
- Yes, Bacula compiles and runs on Windows machines
(Win95, 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.
- What language is Bacula written in?
- It is written mostly in C, however, it is completely
compiled using the C++ compiler. There are several modules,
including the Win32 interface that are written in C++, and
over time, we are slowly converting to using a small
subset of C++.
- On what machines does Bacula run?
- Bacula builds and executes on RedHat Linux (versions
7.1, 7.2, and 7.3), FreeBSD, Solaris, and Win32. On
Win32 systems (Win95/98/Me/XP/NT/2000), only the client
program (File daemon) has been tested.
Bacula has been my primary (only) backup tool for over
two years backing up 5 machines nightly (3 Linux boxes
running RedHat, a Win98 machine, and a WinNT machine).
- 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 (60,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 idea, 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.
- 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
himself, so both ends require the other to have the correct
name and password.
- My Catalog is Full of Test Runs, How Can I Start Over?
- If you are using MySQL do the following:
cd <bacula-source>/src/cats
./drop_mysql_tables
./make_mysql_tables
If you are using SQLite, do the following:
Delete bacula.db from your working directory.
cd <bacula-source>/src/cats
./drop_sqlite_tables
./make_sqlite_tables
Then write an EOF on each tape you used with Bacula
- 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 unmount command, all
Storage daemon sessions (jobs) will be completely blocked
from using the drive unmounted, so be sure to do a mount
after your unmount. If in doubt, do a second mount, it
won't cause any harm.
- 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
Windows Installation instructions in this manual.
- 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
c:\bacula\bin\bacula-fd.conf.
To see what is going on when the File daemon starts
on Windows, do the following:
Start a DOS shell Window.
cd c:\bacula\bin
bacula-fd -t >out
type out
Calling bacula-fd with redirection (>) will write the
diagnostic output to the file out which you can then list.
The -t option tells Bacula to read the configuration
file and then exit.
- 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 less
program. To log all output, I have the following in my Director's
Message resource definition:
append = "/home/kern/bacula/bin/log" = all, !skipped
Obviously you will want to change the filename to be appropriate
for your system.
- 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 like:
Mail = yourname@yourdomain = all, !skipped
in your Director's message resource. You should then receive one
email for each Job that ran. When you are comfortable with what
is going on (it took me 9 months), you might change that to:
MailOnError = yourname@yourdomain = all, !skipped
then you only get email messages when a Job errors as is the case
for your Windows machine.
You should also be logging the Director's messages, please see the
previous FAQ for how to do so.
- 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 Maximum Concurrent Jobs = nn.
- 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
Pruning Example in the
Recycling chapter of this manual.
- Can Bacula Backup and Restore Files Greater than 2 Giga Bytes in Size?
- If your operating system permits it, and you are running Bacula
version 1.26 or later, the answer is yes. Unfortunately, large files
are not supported by cygwin which Bacula uses for the
Windows version client. Just the
same, when Bacula saves and restores to tape
media, it does not use seek() calls, thus there should be no problems
with file sizes.
- 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 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 will need to do a mount command before it will be canceled.
- Why have You Trademarked the Name Bacula®?
- 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.
- Why is Your Online Document for Version 1.27 of Bacula when the Currently
Release Version is 1.26?
- 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 that there are confusions with
new features.
If you want to read a document that pertains only to a specific
version, please use the one distributed in the source code.
- How Can You 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
Disaster Recovery Using Bacula 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.
- 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.
- 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
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.
The second unique feature, which is currently (1.28) unimplemented, and
thus can be called vaporware :-), is Base level saves. When implemented, this
will enormously reduce tape usage.
- Since Bacula is Multithreaded, Why Do You Recommend Not Running Multiple
Simultaneous Jobs?
- Bacula can run multiple simultaneous jobs, but being very conservative,
I do not recommend doing so at the current time for two reasons: 1. I'm
not sure that two jobs accessing the same Volume won't have catalog
conflicts. 2. Doing a restore from a Volume with records from two jobs
intermingled is complicated.
I expect to have definitive solutions to
both of those problems in a later version. In the mean time, I recommend
running one Job at a time. If you want to experiment with this as several
large shops are doing, ensure that each job is writing to a different
Volume (i.e. has a different Storage resource). This will avoid the
two problems mentioned above. Just the same, there may be other race
conditions in the Director that cause problems. Be forewarned.
- If I Do Run Multiple Simultaneous Jobs, How Can I Force One Particular
Job to Run After Another Job?
- This is possible by using the RunBeforeJob and RunAfterJob
statements. For example, assume that you want job B to start only after
job A has completely finished. First schedule Job A to start at least one
minute before job B. Then within Job A, use the RunBeforeJob to create
a "lock" file and the RunAfterJob to delete that file, and
within Job B, make the RunBeforeJob statement call a small shell script
that waits until the "lock" file does not exist. For example:
Job A:
RunBeforeJob = "touch /tmp/Bacula-run.lock"
RunAfterJob = "rm -f /tmp/Bacula-run.lock"
and in Job B use:
RunBeforeJob = "while true ; do if [ -f /tmp/Bacula-run.lock ] ;
then sleep 5; else break; fi; done"
where the above RunBeforeJob is all entered on a single line. With the
above statements, Job B will start running just after Job A runs, but it
will be blocked until a few seconds (0 - 5) after Job A terminates.
|
 |
|
|