{\bf Bacula} is a set of computer programs that permits you (or the system
administrator) to manage backup, recovery, and verification of computer data
-across a network of computers of different kinds. Bacula can also run entirely
-upon a single computer, and can backup to various types of media, including tape
-and disk.
-
-In technical terms, it is a
+across a network of computers of different kinds. In technical terms, it is a
network Client/Server based backup program. Bacula is relatively easy to use
and efficient, while offering many advanced storage management features that
make it easy to find and recover lost or damaged files. Due to its modular
programs and write over any tape that you put in the drive, then you will find
working with Bacula difficult. Bacula is designed to protect your data
following the rules you specify, and this means reusing a tape only
-as the last resort. It is possible to "force" Bacula to write
+as the last resort. It is possible to ``force'' Bacula to write
over any tape in the drive, but it is easier and more efficient to use a
simpler program for that kind of operation.
\begin{itemize}
\item
\label{DirDef}
- {\bf Bacula Director} service consists of the program that supervises all
-the
+ {\bf Bacula Director} service consists of the program that supervises all the
backup, restore, verify and archive operations. The system administrator uses
the Bacula Director to schedule backups and to recover files. For more
details see the Director Services Daemon Design Document in the Bacula
-Developer's Guide. The Director runs as a daemon or a service (i.e. in the
+Developer's Guild. The Director runs as a daemon or a service (i.e. in the
background).
\item
\label{UADef}
- {\bf Bacula Console} services is the program that allows the administrator
-or
+ {\bf Bacula Console} services is the program that allows the administrator or
user to communicate with the {\bf Bacula Director} (see above). Currently,
the Bacula Console is available in three versions. The first and simplest is
to run the Console program in a shell window (i.e. TTY interface). Most
system administrators will find this completely adequate. The second version
-is a GNOME GUI interface that is far from
+is a GNOME GUI interface that for the moment (23 November 2003) is far from
complete, but quite functional as it has most the capabilities of the shell
Console. The third version is a wxWidgets GUI with an interactive file
restore. It also has most of the capabilities of the shell console, allows
command completion with tabulation, and gives you instant help about the
command you are typing. For more details see the
-\ilink{Bacula Console Design Document}{_ConsoleChapter}.
+\ilink{Bacula Console Design Document}{_ChapterStart23}.
\item
\label{FDDef}
{\bf Bacula File} services (or Client program) is the software program that
documentation, the File daemon is referred to as the Client (for example in
Bacula's configuration file). In addition to Unix/Linux File daemons, there
is a Windows File daemon (normally distributed in binary format). The Windows
-File daemon runs on current Windows versions (NT,
-2000, XP, 2003, and possibly Me and 98).
+File daemon runs on all currently known Windows versions (95, 98, Me, NT,
+2000, XP).
\item
\label{SDDef}
{\bf Bacula Storage} services consist of the software programs that perform
has the backup device (usually a tape drive).
\item
\label{DBDefinition}
- {\bf Catalog} services are comprised of the software programs responsible
-for
+ {\bf Catalog} services are comprised of the software programs responsible for
maintaining the file indexes and volume databases for all files backed up.
The Catalog services permit the System Administrator or user to quickly
locate and restore any desired file. The Catalog services sets Bacula apart
from simple backup programs like tar and bru, because the catalog maintains a
record of all Volumes used, all Jobs run, and all Files saved, permitting
-efficient restoration and Volume management. Bacula currently supports
+efficicient restoration and Volume management. Bacula currently supports
three different databases, MySQL, PostgreSQL, and SQLite, one of which must
-be chosen when building {\bf Bacula}.
+be chosen when building {\bf Bacula}. There also exists an Internal database,
+but it is no longer supported.
The three SQL databases currently supported (MySQL, PostgreSQL or SQLite)
provide quite a number of features, including rapid indexing, arbitrary
queries, and security. Although we plan to support other major SQL databases,
the current Bacula implementation interfaces only to MySQL, PostgreSQL and
-SQLite. For the technical and porting details see the Catalog Services
-Design Document in the developer's documented.
+SQLite. For more details see the
+\ilink{Catalog Services Design Document}{_ChapterStart30}.
The RPMs for MySQL and PostgreSQL ship as part of the Linux RedHat
-and several other releases. Alternatively, building the rpms from the source is
+and several other releases, or building the rpms from the source is
quite easy, see the
\ilink{ Installing and Configuring MySQL}{_ChapterStart} chapter of
this document for the details. For more information on MySQL, please see:
of this document.
\item
\label{MonDef}
- {\bf Bacula Monitor} services is the program that allows the administrator
-or
+ {\bf Bacula Monitor} services is the program that allows the administrator or
user to watch current status of {\bf Bacula Directors}, {\bf Bacula File
Daemons} and {\bf Bacula Storage Daemons} (see above). Currently, only a GTK+
version is available, which works with Gnome and KDE (or any window manager
\item [Catalog]
\index[fd]{Catalog }
- The Catalog is used to store summary information about the Jobs, Clients,
-and
+ The Catalog is used to store summary information about the Jobs, Clients, and
Files that were backed up and on what Volume or Volumes. The information
saved in the Catalog permits the administrator or user to determine what jobs
were run, their status as well as the important characteristics of each file
\item [Monitor]
\index[fd]{Monitor }
- The program that interfaces to all the daemons allowing the user or
+ The program that interfaces to the all the daemons allowing the user or
system administrator to monitor Bacula status.
\item [Resource]
\index[fd]{Resource }
A resource is a part of a configuration file that defines a specific unit of
information that is available to Bacula. It consists of several directives
-(individual configuration statements). For example, the {\bf Job} resource
+(individual configuation statements). For example, the {\bf Job} resource
defines all the properties of a specific Job: name, schedule, Volume pool,
backup type, backup level, ...
\item [Restore]
\index[fd]{Restore }
A restore is a configuration resource that describes the operation of
-recovering a file from backup media. It is the inverse of a
+recovering a file (lost or damaged) from backup media. It is the inverse of a
save, except that in most cases, a restore will normally have a small set of
files to restore, while normally a Save backs up all the files on the system.
Of course, after a disk crash, Bacula can be called upon to do a full
\item [Verify]
\index[sd]{Verify }
- A verify is a job that compares the current file attributes to the
-attributes
+ A verify is a job that compares the current file attributes to the attributes
that have previously been stored in the Bacula Catalog. This feature can be
used for detecting changes to critical system files similar to what {\bf
Tripwire} does. One of the major advantages of using Bacula to do this is
\item [Retention Period]
\index[fd]{Retention Period }
- There are various kinds of retention periods that Bacula recognizes. The
-most
+ There are various kinds of retention periods that Bacula recognizes. The most
important are the {\bf File} Retention Period, {\bf Job} Retention Period,
and the {\bf Volume} Retention Period. Each of these retention periods
applies to the time that specific records will be kept in the Catalog
The File Retention Period determines the time that File records are kept in
the catalog database. This period is important because the volume of the
database File records by far use the most storage space in the database. As a
-consequence, you must ensure that regular "pruning" of the database file
+consequence, you must ensure that regular ``pruning'' of the database file
records is done. (See the Console {\bf retention} command for more details on
this subject).
\item [Scan]
\index[sd]{Scan }
- A Scan operation causes the contents of a Volume or a series of Volumes to
-be
+ A Scan operation causes the contents of a Volume or a series of Volumes to be
scanned. These Volumes with the information on which files they contain are
restored to the Bacula Catalog. Once the information is restored to the
Catalog, the files contained on those Volumes may be easily restored. This
example, if you have created an emergency boot disk, a Bacula Rescue disk to
save the current partitioning information of your hard disk, and maintain a
complete Bacula backup, it is possible to completely recover your system from
-"bare metal" that is starting from an empty disk.
+``bare metal'' that is starting from an empty disk.
If you have used the {\bf WriteBootstrap} record in your job or some other
means to save a valid bootstrap file, you will be able to use it to extract
projects / bacula / docs / blobdiff