-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 MySQL, PostgreSQL or SQLite.
-
-<h3>Bacula Configuration</h3>
-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:
-<p style="text-align: center">
- <img src="images/manual/bacula-objects.png" alt="" width="576" height="734">
-</p>
-
-<h3>Conventions Used in this Document</h3>
-<b>Bacula</b> 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.
-<p>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, <a href="/dev-manual/en/main/index.html">
-http://www.bacula.org/rel-manual/en/main/index.html</a>,
-please bear in mind that this version
-describes the current version in development (in the SVN) that may
-contain features not in the released version. Just the same,
-it generally lags behind the code a bit.
-<h3>Quick Start</h3>
-To get Bacula up and running quickly, we recommend that you first
-scan the Terminology section below, then quickly review the next chapter
-entitled <a href="rel-manual/state.html">The Current State of Bacula</a>, then the
-<a href="rel-manual/quickstart.html">Quick Start Guide to Bacula</a>, which will
-give you a quick overview of getting Bacula running. After
-which, you should proceed to the
-chapter on <a href="rel-manual/install.html"> Installing Bacula</a>, then <a
-href="rel-manual/configure.html">How to Configure Bacula</a>,
-and finally the chapter on <a href="rel-manual/running.html">
-Running Bacula</a>.
-
-<h3>Terminology</h3>
-To facilitate communication about this project, we provide here
-the definitions of the terminology that we use.
-<dl>
- <dt>Administrator</dt>
- <dd>The person or persons responsible for administrating the Bacula system.</dd>
-
- <dt>Backup</dt>
- <dd>We use the term <b>Backup</b> to refer to a Bacula Job that saves files. </dd>
-
- <dt>Bootstrap File</dt>
- <dd>The bootstrap file is an ASCII file
- containing a compact form of commands that allow Bacula or
- the stand-alone file extraction utility (<b>bextract</b>) 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.</dd>
-
- <dt>Catalog</dt>
- <dd>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. 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 in addition to the File Attributes (see below).
- <p>The catalog feature is one part of Bacula that distinguishes
- it from simple backup and archive programs such as <b>dump</b>
- and <b>tar</b>.
- </dd>
-
- <dt>Client</dt>
- <dd>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, we
- refer to it as the FD. A Client is defined in a configuration
- file resource. </dd>
-
- <dt>Console</dt>
- <dd>The program that interfaces to the Director allowing
- the user or system administrator to control Bacula.</dd>
-
- <dt>Daemon</dt>
- <dd>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 Linux systems, daemons are called <b>Services</b>.</dd>
-
- <dt>Directive</dt>
- <dd>The term directive is used to refer to a statement
- or a record within a Resource in a configuration file that
- defines one specific thing. For example, the <b>Name</b> directive
- defines the name of the Resource.</dd>
-
- <dt>Director</dt>
- <dd>The main Bacula server daemon that schedules and directs all
- Bacula operations. Occassionally, we refer to the Director as DIR.</dd>
-
- <dt>Differential</dt>
- <dd>A backup that includes all files changed since the last
- Full save started. Note, other backup programs may define this differently.</dd>
-
- <dt>File Attributes</dt>
- <dd>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.
-
- <dt>File Daemon</dt>
- <dd>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.
-
- <dt><a name="FileSetDef"></a> FileSet</dt>
- <dd>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
- <a href="rel-manual/director.html#FileSetResource">FileSet Resource definition</a>
- in the Director chapter of this document.</dd>
-
- <dt>Incremental</dt>
- <dd>A backup that includes all files changed since the
- last Full, Differential, or Incremental backup started. It is normally
- specified on the <b>Level</b> directive within the Job resource
- definition, or in a Schedule resourc. </dd>
-
- <dt><a name="JobDef"></a>Job</dt>
- <dd>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 <b>Type</b> (backup, restore, verify,
- etc), the <b>Level</b> (full, incremental,...), the <b>FileSet</b>,
- and <b>Storage</b> the files are to be backed up (Storage device,
- Media Pool). For more details, see the
- <a href="rel-manual/director.html#JobResource">Job Resource definition</a>
- in the Director chapter of this document. </dd>
-
- <dt>Monitor</dt>
- <dd>The program that interfaces to the all the daemons
- allowing the user or system administrator to monitor Bacula status.</dd>
-
- <dt>Resource</dt>
- <dd>A resource is a part of a configuration file that
- defines a specific unit of information that is available to Bacula.
- For example, the <b>Job</b> resource defines all the properties of
- a specific Job: name, schedule, Volume pool, backup type, backup
- level, ...</dd>
-
- <dt>Restore</dt>
- <dd>A restore is a configuration resource that
- describes the operation of 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 Restore of all files that were on the system. </dd>
-
- <dt>Schedule</dt>
- <dd>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 <a
- href="rel-manual/director.html#ScheduleResource">Schedule Resource
- definition</a> in the Director chapter of this document. </dd>
-
- <dt>Service</dt>
- <dd>This is Windows terminology for a <b>daemon</b> -- see
- above. It is now frequently used in Unix environments as well.</dd>
-
- <dt>Storage Coordinates</dt>
- <dd>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. </dd>
-
- <dt>Storage Daemon</dt>
- <dd>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).</dd>
-
- <dt>Session</dt>
- <dd>Normally refers to the internal conversation between
- the File daemon and the Storage daemon. The File daemon opens a
- <b>session</b> 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). </dd>
-
- <dt>Verify</dt>
- <dd>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 <b>Tripwire</b> 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.
- <p>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. </dd>
-
- <dt>*Archive</dt>
- <dd>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 many no longer be
- used to save files. All the files contained on an Archived Volume
- are removed from the Catalog. NOT YET IMPLEMENTED. </dd>
-
- <dt>*Update</dt>
- <dd>An Update operation causes the files on the remote
- system to be updated to be the same as the host system. This is
- equivalent to an <b>rdist</b> capability. NOT YET IMPLEMENTED.
- </dd>