\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
+ compiler. There are several modules, including the Win32 interface that is
written using the object oriented C++ features. Over time, we are slowly
adding a larger subset of C++.
\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, Mandrake, ...), FreeBSD, Solaris, Alpha, SGI (client),
+ 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
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
+ 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. It
- frequently runs several months with no problems.
+ 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 constantly is checking the chain of allocated
+ \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 [I'm Getting Authorization Errors. What is Going On? ]
\index[general]{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
+ 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 and in the File daemon
+ 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 authenticate itself, so both ends require the other
+ 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
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
+ 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.
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
\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 it mounted, it will inform you.
+ 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
\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[general]{When I Start the Console, the Error Messages Fly By. How can I seethem? }
+ \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
\ilink{Backing Up to Disk}{_ChapterStart39}.
\label{bigfiles}
-\item [Can Bacula Backup and Restore Files Greater than 2 Giga bytes in
+\item [Can Bacula Backup and Restore Files Greater than 2 Gigabytes in
Size? ]
-\index[general]{Can Bacula Backup and Restore Files Greater than 2 Giga bytes in
+\index[general]{Can Bacula Backup and Restore Files Greater than 2 Gigabytes in
Size? }
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}
\item [I Started A Job then Decided I Really Did Not Want to Run It. Is
\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 awhile to figure
+ 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.
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}
\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?]
+ 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 time, so it did a
+ 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 successfully full backup, it proceeds to do one.
+ 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
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
+ 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.
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
+ 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).
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
+ to file Volumes. There are two conditions for this ''software`` to become
enabled.
\begin{enumerate}
zlib-devel} rpm.
If the library is found by Bacula during the {\bf ./configure} it will be
- in dicated on the {\bf config.out} line by:
+ mentioned in the {\bf config.out} line by:
\footnotesize
\begin{verbatim}
\label{WaitForever}
\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.]
+ 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. }
+ 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
+ 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.
\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.
\end{description}
projects / bacula / docs / commitdiff