--- /dev/null
+%%
+%%
+
+\chapter{What is Bacula?}
+\label{GeneralChapter}
+\index[general]{Bacula!What is }
+\index[general]{What is Bacula? }
+
+Bacula is a set of computer programs that permits 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
+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
+design, Bacula is scalable from small single computer systems to systems
+consisting of hundreds of computers located over a large network.
+
+\section{Who Needs Bacula?}
+\index[general]{Who Needs Bacula? }
+\index[general]{Bacula!Who Needs }
+
+If you are currently using a program such as tar, dump, or
+bru to backup your computer data, and you would like a network solution, more
+flexibility, or catalog services, Bacula will most likely provide the
+additional features you want. However, if you are new to Unix systems or do
+not have offsetting experience with a sophisticated backup package, the Bacula project does not
+recommend using Bacula as it is much more difficult to setup and use than
+tar or dump.
+
+If you want Bacula to behave like the above mentioned simple
+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
+over any tape in the drive, but it is easier and more efficient to use a
+simpler program for that kind of operation.
+
+If you would like a backup program that can write
+to multiple volumes (i.e. is not limited by your tape drive capacity), Bacula
+can most likely fill your needs. In addition, quite a number of Bacula users
+report that Bacula is simpler to setup and use than other equivalent programs.
+
+If you are currently using a sophisticated commercial package such as Legato
+Networker. ARCserveIT, Arkeia, or PerfectBackup+, you may be interested in
+Bacula, which provides many of the same features and is free software
+available under the GNU Version 2 software license.
+
+\section{Bacula Components or Services}
+\index[general]{Bacula Components or Services }
+\index[general]{Services!Bacula Components or }
+
+Bacula is made up of the following five major components or services:
+Director, Console, File, Storage, and Monitor services.
+
+
+\addcontentsline{lof}{figure}{Bacula Applications}
+\includegraphics{\idir bacula-applications.eps}
+(thanks to Aristedes Maniatis for this graphic and the one below)
+% TODO: move the thanks to Credits section in preface
+
+\subsection*{Bacula Director}
+ \label{DirDef}
+ The Bacula Director service is 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 service) in the background.
+% TODO: tell reader where this Developer's Guide is at?
+ \label{UADef}
+
+\subsection*{Bacula Console}
+
+ The Bacula Console service is the program that allows the
+ administrator or user to communicate with the Bacula Director
+ Currently, the Bacula Console is available in three versions:
+ text-based console interface, QT-based interface, and a
+ wxWidgets graphical interface.
+ 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 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}.
+
+\subsection*{Bacula File}
+ \label{FDDef}
+ The Bacula File service (also known as the Client program) is the software
+ program that is installed on the machine to be backed up.
+ It is specific to the
+ operating system on which it runs and is responsible for providing the
+ file attributes and data when requested by the Director. The File
+ services are also responsible for the file system dependent part of
+ restoring the file attributes and data during a recovery operation. For
+ more details see the File Services Daemon Design Document in the Bacula
+ Developer's Guide. This program runs as a daemon on the machine to be
+ backed up.
+ 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).
+% TODO: maybe do not list Windows here as that is listed elsewhere
+% TODO: remove "possibly"?
+% TODO: mention Vista?
+
+\subsection*{Bacula Storage}
+ \label{SDDef}
+ The Bacula Storage services consist of the software programs that
+ perform the storage and recovery of the file attributes and data to the
+ physical backup media or volumes. In other words, the Storage daemon is
+ responsible for reading and writing your tapes (or other storage media,
+ e.g. files). For more details see the Storage Services Daemon Design
+ Document in the Bacula Developer's Guide. The Storage services runs as
+ a daemon on the machine that has the backup device (usually a tape
+ drive).
+% TODO: may switch e.g. to "for example" or "such as" as appropriate
+% TODO: is "usually" correct? Maybe "such as" instead?
+
+\subsection*{Catalog}
+ \label{DBDefinition}
+ The 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 three different databases,
+ MySQL, PostgreSQL, and SQLite, one of which must be chosen when building
+ Bacula.
+
+ The three SQL databases currently supported (MySQL, PostgreSQL or
+ SQLite) provide quite a number of features, including rapid indexing,
+ arbitrary queries, and security. Although the Bacula project plans 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.
+
+ The packages for MySQL and PostgreSQL are available for several operating
+ systems.
+ Alternatively, installing from the
+ source is quite easy, see the \ilink{ Installing and Configuring
+ MySQL}{MySqlChapter} chapter of this document for the details. For
+ more information on MySQL, please see:
+ \elink{www.mysql.com}{http://www.mysql.com}. Or see the \ilink{
+ Installing and Configuring PostgreSQL}{PostgreSqlChapter} chapter of this
+ document for the details. For more information on PostgreSQL, please
+ see: \elink{www.postgresql.org}{http://www.postgresql.org}.
+
+ Configuring and building SQLite is even easier. For the details of
+ configuring SQLite, please see the \ilink{ Installing and Configuring
+ SQLite}{SqlLiteChapter} chapter of this document.
+
+\subsection*{Bacula Monitor}
+ \label{MonDef}
+ A Bacula Monitor service is the program that allows the
+ administrator or user to watch current status of Bacula Directors,
+ Bacula File Daemons and Bacula Storage Daemons.
+ Currently, only a GTK+ version is available, which works with GNOME,
+ KDE, or any window manager that supports the FreeDesktop.org system tray
+ standard.
+
+ To perform a successful save or restore, the following four daemons must be
+ configured and running: the Director daemon, the File daemon, the Storage
+ daemon, and the Catalog service (MySQL, PostgreSQL or SQLite).
+
+\section{Bacula Configuration}
+\index[general]{Configuration!Bacula }
+\index[general]{Bacula Configuration }
+
+In order for Bacula to understand your system, what clients you want backed
+up and how, you must create a number of configuration files containing
+resources (or objects). The following presents an overall picture of this:
+
+\addcontentsline{lof}{figure}{Bacula Objects}
+\includegraphics{\idir bacula-objects.eps}
+
+\section{Conventions Used in this Document}
+\index[general]{Conventions Used in this Document }
+\index[general]{Document!Conventions Used in this }
+
+Bacula is in a state of evolution, and as a consequence, this manual
+will not always agree with the code. If an item in this manual is preceded by
+an asterisk (*), it indicates that the particular feature is not implemented.
+If it is preceded by a plus sign (+), it indicates that the feature may be
+partially implemented.
+% TODO: search for plus sign and asterisk and "IMPLEMENTED" and fix for printed book
+
+If you are reading this manual as supplied in a released version of the
+software, the above paragraph holds true. If you are reading the online
+version of the manual,
+\elink{ www.bacula.org}{http://www.bacula.org}, please bear in
+mind that this version describes the current version in development (in the
+CVS) that may contain features not in the released version. Just the same, it
+generally lags behind the code a bit.
+% TODO: is this still true? there are separate websites
+
+\section{Quick Start}
+\index[general]{Quick Start }
+\index[general]{Start!Quick }
+
+To get Bacula up and running quickly, the author recommends
+that you first scan the
+Terminology section below, then quickly review the next chapter entitled
+\ilink{The Current State of Bacula}{StateChapter}, then the
+\ilink{Getting Started with Bacula}{QuickStartChapter}, which will
+give you a quick overview of getting Bacula running. After which, you should
+proceed to the chapter on
+\ilink{Installing Bacula}{InstallChapter}, then
+\ilink{How to Configure Bacula}{ConfigureChapter}, and finally the
+chapter on
+\ilink{ Running Bacula}{TutorialChapter}.
+
+\section{Terminology}
+\index[general]{Terminology }
+
+\begin{description}
+
+\item [Administrator]
+ \index[fd]{Administrator }
+ The person or persons responsible for administrating the Bacula system.
+
+\item [Backup]
+ \index[fd]{Backup }
+ The term Backup refers to a Bacula Job that saves files.
+
+\item [Bootstrap File]
+ \index[fd]{Bootstrap File }
+ The bootstrap file is an ASCII file containing a compact form of
+ commands that allow Bacula or the stand-alone file extraction utility
+ (bextract) to restore the contents of one or more Volumes, for
+ example, the current state of a system just backed up. With a bootstrap
+ file, Bacula can restore your system without a Catalog. You can create
+ a bootstrap file from a Catalog to extract any file or files you wish.
+
+\item [Catalog]
+ \index[fd]{Catalog }
+ 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 that was backed up, and most importantly,
+ it permits you to choose what files to restore.
+ The Catalog is an
+ online resource, but does not contain the data for the files backed up.
+ Most of the information stored in the catalog is also stored on the
+ backup volumes (i.e. tapes). Of course, the tapes will also have a
+ copy of the file data in addition to the File Attributes (see below).
+
+ The catalog feature is one part of Bacula that distinguishes it from
+ simple backup and archive programs such as dump and tar.
+
+\item [Client]
+ \index[fd]{Client }
+ In Bacula's terminology, the word Client refers to the machine being
+ backed up, and it is synonymous with the File services or File daemon,
+ and quite often, it is referred to it as the FD. A Client is defined in a
+ configuration file resource.
+
+\item [Console]
+ \index[fd]{Console }
+ The program that interfaces to the Director allowing the user or system
+ administrator to control Bacula.
+
+\item [Daemon]
+ \index[fd]{Daemon }
+ Unix terminology for a program that is always present in the background to
+ carry out a designated task. On Windows systems, as well as some Unix
+ systems, daemons are called Services.
+
+\item [Directive]
+ \index[fd]{Directive }
+ The term directive is used to refer to a statement or a record within a
+ Resource in a configuration file that defines one specific setting. For
+ example, the {\bf Name} directive defines the name of the Resource.
+
+\item [Director]
+ \index[fd]{Director }
+ The main Bacula server daemon that schedules and directs all Bacula
+ operations. Occasionally, the project refers to the Director as DIR.
+
+\item [Differential]
+ \index[fd]{Differential }
+ A backup that includes all files changed since the last Full save started.
+ Note, other backup programs may define this differently.
+
+\item [File Attributes]
+ \index[fd]{File Attributes }
+ The File Attributes are all the information necessary about a file to
+ identify it and all its properties such as size, creation date, modification
+ date, permissions, etc. Normally, the attributes are handled entirely by
+ Bacula so that the user never needs to be concerned about them. The
+ attributes do not include the file's data.
+
+\item [File Daemon]
+ \index[fd]{File Daemon }
+ The daemon running on the client computer to be backed up. This is also
+ referred to as the File services, and sometimes as the Client services or the
+ FD.
+
+\label{FileSetDef}
+\item [FileSet]
+\index[fd]{a name }
+ A FileSet is a Resource contained in a configuration file that defines
+ the files to be backed up. It consists of a list of included files or
+ directories, a list of excluded files, and how the file is to be stored
+ (compression, encryption, signatures). For more details, see the
+ \ilink{FileSet Resource definition}{FileSetResource} in the Director
+ chapter of this document.
+
+\item [Incremental]
+ \index[fd]{Incremental }
+ A backup that includes all files changed since the last Full, Differential,
+ or Incremental backup started. It is normally specified on the {\bf Level}
+ directive within the Job resource definition, or in a Schedule resource.
+
+\label{JobDef}
+\item [Job]
+\index[fd]{a name }
+ A Bacula Job is a configuration resource that defines the work that
+ Bacula must perform to backup or restore a particular Client. It
+ consists of the {\bf Type} (backup, restore, verify, etc), the {\bf
+ Level} (full, incremental,...), the {\bf FileSet}, and {\bf Storage} the
+ files are to be backed up (Storage device, Media Pool). For more
+ details, see the \ilink{Job Resource definition}{JobResource} in the
+ Director chapter of this document.
+% TODO: clean up "..." for book
+
+\item [Monitor]
+ \index[fd]{Monitor }
+ The program that interfaces to 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 defines all the properties of a specific Job: name,
+ schedule, Volume pool, backup type, backup level, ...
+% TODO: clean up "..." for book
+
+\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 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 Restore of all files that were on the system.
+% TODO: Why? Why say "Of course"??
+
+% TODO: define "Save"
+% TODO: define "Full"
+
+\item [Schedule]
+ \index[fd]{Schedule }
+ A Schedule is a configuration resource that defines when the Bacula Job
+ will be scheduled for execution. To use the Schedule, the Job resource
+ will refer to the name of the Schedule. For more details, see the
+ \ilink{Schedule Resource definition}{ScheduleResource} in the Director
+ chapter of this document.
+
+\item [Service]
+ \index[fd]{Service }
+ This is a program that remains permanently in memory awaiting
+ instructions. In Unix environments, services are also known as
+ {\bf daemons}.
+
+\item [Storage Coordinates]
+ \index[fd]{Storage Coordinates }
+ The information returned from the Storage Services that uniquely locates
+ a file on a backup medium. It consists of two parts: one part pertains
+ to each file saved, and the other part pertains to the whole Job.
+ Normally, this information is saved in the Catalog so that the user
+ doesn't need specific knowledge of the Storage Coordinates. The Storage
+ Coordinates include the File Attributes (see above) plus the unique
+ location of the information on the backup Volume.
+
+\item [Storage Daemon]
+ \index[fd]{Storage Daemon }
+ The Storage daemon, sometimes referred to as the SD, is the code that
+ writes the attributes and data to a storage Volume (usually a tape or
+ disk).
+
+\item [Session]
+ \index[sd]{Session }
+ Normally refers to the internal conversation between the File daemon and
+ the Storage daemon. The File daemon opens a {\bf session} with the
+ Storage daemon to save a FileSet or to restore it. A session has a
+ one-to-one correspondence to a Bacula Job (see above).
+
+\item [Verify]
+ \index[sd]{Verify }
+ 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 a file integrity checker like Tripwire does.
+ One of the major advantages of
+ using Bacula to do this is that on the machine you want protected such
+ as a server, you can run just the File daemon, and the Director, Storage
+ daemon, and Catalog reside on a different machine. As a consequence, if
+ your server is ever compromised, it is unlikely that your verification
+ database will be tampered with.
+
+ Verify can also be used to check that the most recent Job data written
+ to a Volume agrees with what is stored in the Catalog (i.e. it compares
+ the file attributes), *or it can check the Volume contents against the
+ original files on disk.
+
+\item [*Archive]
+ \index[fd]{*Archive }
+ An Archive operation is done after a Save, and it consists of removing the
+ Volumes on which data is saved from active use. These Volumes are marked as
+ Archived, and may no longer be used to save files. All the files contained
+ on an Archived Volume are removed from the Catalog. NOT YET IMPLEMENTED.
+
+\item [Retention Period]
+ \index[fd]{Retention Period }
+ 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 database. This should not be confused with the time that
+ the data saved to a Volume is valid.
+
+ The File Retention Period determines the time that File records are kept
+ in the catalog database. This period is important for two reasons: the
+ first is that as long as File records remain in the database, you
+ can "browse" the database with a console program and restore any
+ individual file. Once the File records are removed or pruned from the
+ database, the individual files of a backup job can no longer be
+ "browsed". The second reason for carefully choosing the File Retention
+ Period is because the volume of
+ the database File records use the most storage space in the
+ database. As a consequence, you must ensure that regular "pruning" of
+ the database file records is done to keep your database from growing
+ too large. (See the Console {\bf prune}
+ command for more details on this subject).
+
+ The Job Retention Period is the length of time that Job records will be
+ kept in the database. Note, all the File records are tied to the Job
+ that saved those files. The File records can be purged leaving the Job
+ records. In this case, information will be available about the jobs
+ that ran, but not the details of the files that were backed up.
+ Normally, when a Job record is purged, all its File records will also be
+ purged.
+
+ The Volume Retention Period is the minimum of time that a Volume will be
+ kept before it is reused. Bacula will normally never overwrite a Volume
+ that contains the only backup copy of a file. Under ideal conditions,
+ the Catalog would retain entries for all files backed up for all current
+ Volumes. Once a Volume is overwritten, the files that were backed up on
+ that Volume are automatically removed from the Catalog. However, if
+ there is a very large pool of Volumes or a Volume is never overwritten,
+ the Catalog database may become enormous. To keep the Catalog to a
+ manageable size, the backup information should be removed from the
+ Catalog after the defined File Retention Period. Bacula provides the
+ mechanisms for the catalog to be automatically pruned according to the
+ retention periods defined.
+
+\item [Scan]
+ \index[sd]{Scan }
+ 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 function is particularly useful if certain
+ Volumes or Jobs have exceeded their retention period and have been
+ pruned or purged from the Catalog. Scanning data from Volumes into the
+ Catalog is done by using the {\bf bscan} program. See the \ilink{ bscan
+ section}{bscan} of the Bacula Utilities Chapter of this manual for more
+ details.
+
+\item [Volume]
+ \index[sd]{Volume }
+ A Volume is an archive unit, normally a tape or a named disk file where
+ Bacula stores the data from one or more backup jobs. All Bacula Volumes
+ have a software label written to the Volume by Bacula so that it
+ identifies what Volume it is really reading. (Normally there should be
+ no confusion with disk files, but with tapes, it is easy to mount the
+ wrong one.)
+\end{description}
+
+\section{What Bacula is Not}
+\index[general]{What Bacula is Not}
+
+Bacula is a backup, restore and verification program and is not a
+complete disaster recovery system in itself, but it can be a key part of one
+if you plan carefully and follow the instructions included in the
+\ilink{ Disaster Recovery}{RescueChapter} Chapter of this manual.
+
+With proper planning, as mentioned in the Disaster Recovery chapter,
+Bacula can be a central component of your disaster recovery system. For
+example, if you have created an emergency boot disk, and/or 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.
+
+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
+the necessary files (without using the catalog or manually searching for the
+files to restore).
+
+\section{Interactions Between the Bacula Services}
+\index[general]{Interactions Between the Bacula Services}
+\index[general]{Services!Interactions Between the Bacula}
+
+The following block diagram shows the typical interactions between the Bacula
+Services for a backup job. Each block represents in general a separate process
+(normally a daemon). In general, the Director oversees the flow of
+information. It also maintains the Catalog.
+
+\addcontentsline{lof}{figure}{Interactions between Bacula Services}
+\includegraphics{\idir flow.eps}
projects / bacula / docs / blobdiff