1 <? require_once("inc/header.php"); ?>
4 <td class="contentTopic">
11 <b>Bacula</b> is a set of computer programs that permit you (or the
12 system administrator) to manage backup, recovery, and verification of
13 computer data across a network of computers of different kinds. In
14 technical terms, it is a network Client/Server based backup program.
15 Bacula is relatively easy to use and efficient, while offering many
16 advanced storage management features that make it easy to find and
17 recover lost or damaged files. Due to its modular design, Bacula is
18 scalable from small single computer systems to systems consisting of
19 hundreds of computers located over a large network.
20 <h3>Who Needs Bacula?</h3>
21 If you are currently using a program such as <b>tar</b>, <b>dump</b>, or
22 <b>bru</b> to backup your computer data, and you would like a network
23 solution, more flexibility, or catalog services, Bacula will most
24 likely provide the additional features you want. However, if you are
25 new to Unix systems or do not have offsetting experience with a sophisticated
26 backup package, we do not recommend using Bacula as it is
27 much more difficult to setup and use than <b>tar</b> or <b>dump</b>.
28 <p>If you are running <b>Amanda</b> and would like a backup program that
29 can write to multiple volumes (i.e. is not limited by your tape drive
30 capacity), Bacula can most likely fill your needs. In addition,
31 quite a number of our users report that Bacula is simpler to
32 setup and use than other equivalent programs.
34 currently using a sophisticated commercial package such as Legato
35 Networker. ARCserveIT, Arkeia, or PerfectBackup+, you may be interested
36 in Bacula, which provides many of the same features, and is free
37 software available under the GNU Version 2 software license.
39 <h3>Bacula Components or Services</h3>
40 Bacula is made up of the following five major components or services:
41 <p style="text-align: center; font-size: small">
42 <img src="images/manual/bacula-applications.png" alt="" width="576" height="734"><br>
43 thanks to Aristedes Maniatis for this graphic and the one below
47 <li><a name="DirDef"></a>
48 <b>Bacula Director</b> service consists of the program that
49 supervises all the backup, restore, verify and archive operations.
50 The system administrator uses the Bacula Director to schedule
51 backups and to recover files. For more details see the <a
52 href="rel-manual/director.html">Director Services Daemon Design Document</a>.
53 The Director runs as a daemon or a service (i.e. in the background).
55 <li><a name="UADef"></a>
56 <b>Bacula Console</b> services is the program that allows the
57 administrator or user to communicate with the <b>Bacula Director</b>
58 (see above). Currently, the Bacula Console is available in three
59 versions. The first and simplest is to run the Console program in a
60 shell window (i.e. TTY interface). Most system administrators will
61 find this completely adequate. The second version is a GNOME GUI
62 interface that for the moment (23 November 2003) is far from complete,
63 but quite functional as it has most the capabilities of the shell
64 Console. The third version is a wxWidgets GUI with an interactive file
65 restore. It also has most the capabilities of the shell console,
66 allows command completion with tabulation, and gives you instant
67 help about the command you are typing. For more details see the
68 <a href="rel-manual/console.html">Bacula Console Design Document</a>.
70 <li><a name="FDDef"></a>
71 <b>Bacula File</b> services (or Client program) is the software
72 program that is installed on the machine to be backed up. It is
73 specific to the operating system on which it runs and is responsible
74 for providing the file attributes and data when requested by the
75 Director. The File services are also responsible for the file
76 system dependent part of restoring the file attributes and data
77 during a recovery operation. For more details see the <a
78 href="rel-manual/file.html">File Services Daemon Design Document</a>. This
79 program runs as a daemon on the machine to be backed up, and in some
80 of the documentation, the File daemon is referred to as the Client
81 (for example in Bacula's configuration file). In addition to
82 Unix/Linux File daemons, there is a Windows File daemon (normally
83 distributed in binary format). The Windows File daemon runs on
84 all currently known Windows versions (95, 98, Me, NT, 2000, XP).
86 <li><a name="SDDef"></a>
87 <b>Bacula Storage</b> services consist of the software programs that
88 perform the storage and recovery of the file attributes and data to
89 the physical backup media or volumes. In other words, the Storage daemon
90 is responsible for reading and writing your tapes (or other
91 storage media, e.g. files). For more details see the <a
92 href="rel-manual/storage.html">Storage Services Daemon Design Document</a>.
93 The Storage services runs as a daemon on the machine that has the
94 backup device (usually a tape drive).
96 <li><a name="DBDefinition"></a>
97 <b>Catalog</b> services are comprised of the software programs
98 responsible for maintaining the file indexes and volume databases for
99 all files backed up. The Catalog services permit the System
100 Administrator or user to quickly locate and restore any desired
101 file. The Catalog services sets Bacula apart from simple backup
102 programs like tar and bru, because the catalog maintains a record
103 of all Volumes used, all Jobs run, and all Files saved, permitting
104 efficicient restoration and Volume management.
105 Bacula currently supports three different databases, MySQL,
106 PostgreSQL, and SQLite, one of which must be chosen when building
107 <b>Bacula</b>. There also exists an Internal database, but it is no
110 The three SQL databases currently supported (MySQL, PostgreSQL or SQLite)
111 provide quite a number of features,
112 including rapid indexing, arbitrary queries, and security. Although
113 we plan to support other major SQL databases, the current
114 Bacula implementation interfaces only to MySQL, PostgreSQL and SQLite.
115 For more details see the <a href="rel-manual/catalog.html">Catalog Services
117 <p>The RPMs for MySQL and PostgreSQL ship as part of the Linux RedHat release,
118 or building it from the source is quite easy, see the
119 <a href="rel-manual/mysql.html"> Installing and Configuring MySQL</a> chapter
120 of this document for the details. For more information on MySQL,
121 please see: <a href="http://www.mysql.com">www.mysql.com</a>.
122 Or see the <a href="rel-manual/postgresql.html"> Installing and Configuring
123 PostgreSQL</a> chapter of this document for the details. For more
124 information on PostgreSQL, please see: <a
125 href="http://www.postgresql.org">www.postgresql.org</a>.
126 <p>Configuring and building SQLite is even easier. For the details
127 of configuring SQLite, please see the <a href="rel-manual/sqlite.html">
128 Installing and Configuring SQLite</a> chapter of this document.
130 <li><a name="MonDef"></a>
131 <b>Bacula Monitor</b> services is the program that allows the
132 administrator or user to watch current status of <b>Bacula Directors</b>,
133 <b>Bacula File Daemons</b> and <b>Bacula Storage Daemons</b>
134 (see above). Currently, only a GTK+ version is available, which
135 works with Gnome and KDE (or any window manager that supports the
136 FreeDesktop.org system tray standard).
139 To perform a successful save or restore, the following four daemons
140 must be configured and running: the Director daemon, the File daemon,
141 the Storage daemon, and MySQL, PostgreSQL or SQLite.
143 <h3>Bacula Configuration</h3>
144 In order for Bacula to understand your system, what clients you
145 want backed up, and how, you must create a number of configuration
146 files containing resources (or objects). The following presents an
147 overall picture of this:
148 <p style="text-align: center">
149 <img src="images/manual/bacula-objects.png" alt="" width="576" height="734">
152 <h3>Conventions Used in this Document</h3>
153 <b>Bacula</b> is in a state of evolution, and as a consequence,
154 this manual will not always agree with the code. If an
155 item in this manual is preceded by an asterisk (*), it indicates
156 that the particular feature is not implemented. If it is preceded
157 by a plus sign (+), it indicates that the feature may be partially
159 <p>If you are reading this manual as supplied in a released version
160 of the software, the above paragraph holds true. If you are reading
161 the online version of the manual, <a href="/dev-manual">
162 http://www.bacula.org/rel-manual</a>, please bear in mind that this version
163 describes the current version in development (in the SVN) that may
164 contain features not in the released version. Just the same,
165 it generally lags behind the code a bit.
167 To get Bacula up and running quickly, we recommend that you first
168 scan the Terminology section below, then quickly review the next chapter
169 entitled <a href="rel-manual/state.html">The Current State of Bacula</a>, then the
170 <a href="rel-manual/quickstart.html">Quick Start Guide to Bacula</a>, which will
171 give you a quick overview of getting Bacula running. After
172 which, you should proceed to the
173 chapter on <a href="rel-manual/install.html"> Installing Bacula</a>, then <a
174 href="rel-manual/configure.html">How to Configure Bacula</a>,
175 and finally the chapter on <a href="rel-manual/running.html">
179 To facilitate communication about this project, we provide here
180 the definitions of the terminology that we use.
182 <dt>Administrator</dt>
183 <dd>The person or persons responsible for administrating the Bacula system.</dd>
186 <dd>We use the term <b>Backup</b> to refer to a Bacula Job that saves files. </dd>
188 <dt>Bootstrap File</dt>
189 <dd>The bootstrap file is an ASCII file
190 containing a compact form of commands that allow Bacula or
191 the stand-alone file extraction utility (<b>bextract</b>) to
192 restore the contents of one or more Volumes, for example, the
193 current state of a system just backed up. With a bootstrap file,
194 Bacula can restore your system without a Catalog. You can
195 create a bootstrap file from a Catalog to extract any file or
199 <dd>The Catalog is used to store summary information
200 about the Jobs, Clients, and Files that were backed up and on
201 what Volume or Volumes. The information saved in the Catalog
202 permits the administrator or user to determine what jobs were
203 run, their status as well as the important characteristics
204 of each file that was backed up. The Catalog is an online resource,
205 but does not contain the data for the files backed up. Most of
206 the information stored in the catalog is also stored on the
207 backup volumes (i.e. tapes). Of course, the tapes will also have
208 a copy of the file in addition to the File Attributes (see below).
209 <p>The catalog feature is one part of Bacula that distinguishes
210 it from simple backup and archive programs such as <b>dump</b>
215 <dd>In Bacula's terminology, the word Client
216 refers to the machine being backed up, and it is synonymous
217 with the File services or File daemon, and quite often, we
218 refer to it as the FD. A Client is defined in a configuration
222 <dd>The program that interfaces to the Director allowing
223 the user or system administrator to control Bacula.</dd>
226 <dd>Unix terminology for a program that is always present in
227 the background to carry out a designated task. On Windows systems, as
228 well as some Linux systems, daemons are called <b>Services</b>.</dd>
231 <dd>The term directive is used to refer to a statement
232 or a record within a Resource in a configuration file that
233 defines one specific thing. For example, the <b>Name</b> directive
234 defines the name of the Resource.</dd>
237 <dd>The main Bacula server daemon that schedules and directs all
238 Bacula operations. Occassionally, we refer to the Director as DIR.</dd>
240 <dt>Differential</dt>
241 <dd>A backup that includes all files changed since the last
242 Full save started. Note, other backup programs may define this differently.</dd>
244 <dt>File Attributes</dt>
245 <dd>The File Attributes are all the information
246 necessary about a file to identify it and all its properties such as
247 size, creation date, modification date, permissions, etc. Normally, the
248 attributes are handled entirely by Bacula so that the user never
249 needs to be concerned about them. The attributes do not include the
253 <dd>The daemon running on the client
254 computer to be backed up. This is also referred to as the File
255 services, and sometimes as the Client services or the FD.
257 <dt><a name="FileSetDef"></a> FileSet</dt>
258 <dd>A FileSet is a Resource contained in a configuration
259 file that defines the files to be backed up. It consists
260 of a list of included files or directories, a list of excluded files, and
261 how the file is to be stored (compression, encryption, signatures).
262 For more details, see the
263 <a href="rel-manual/director.html#FileSetResource">FileSet Resource definition</a>
264 in the Director chapter of this document.</dd>
267 <dd>A backup that includes all files changed since the
268 last Full, Differential, or Incremental backup started. It is normally
269 specified on the <b>Level</b> directive within the Job resource
270 definition, or in a Schedule resourc. </dd>
272 <dt><a name="JobDef"></a>Job</dt>
273 <dd>A Bacula Job is a configuration resource that defines
274 the work that Bacula must perform to backup or restore a particular
275 Client. It consists of the <b>Type</b> (backup, restore, verify,
276 etc), the <b>Level</b> (full, incremental,...), the <b>FileSet</b>,
277 and <b>Storage</b> the files are to be backed up (Storage device,
278 Media Pool). For more details, see the
279 <a href="rel-manual/director.html#JobResource">Job Resource definition</a>
280 in the Director chapter of this document. </dd>
283 <dd>The program that interfaces to the all the daemons
284 allowing the user or system administrator to monitor Bacula status.</dd>
287 <dd>A resource is a part of a configuration file that
288 defines a specific unit of information that is available to Bacula.
289 For example, the <b>Job</b> resource defines all the properties of
290 a specific Job: name, schedule, Volume pool, backup type, backup
294 <dd>A restore is a configuration resource that
295 describes the operation of recovering a file (lost or damaged) from
296 backup media. It is the inverse of a save, except that in most
297 cases, a restore will normally have a small set of files to restore,
298 while normally a Save backs up all the files on the system. Of
299 course, after a disk crash, Bacula can be called upon to do
300 a full Restore of all files that were on the system. </dd>
303 <dd>A Schedule is a configuration resource that
304 defines when the Bacula Job will be scheduled for
305 execution. To use the Schedule, the Job resource will refer to
306 the name of the Schedule. For more details, see the <a
307 href="rel-manual/director.html#ScheduleResource">Schedule Resource
308 definition</a> in the Director chapter of this document. </dd>
311 <dd>This is Windows terminology for a <b>daemon</b> -- see
312 above. It is now frequently used in Unix environments as well.</dd>
314 <dt>Storage Coordinates</dt>
315 <dd>The information returned from the
316 Storage Services that uniquely locates a file on a backup medium. It
317 consists of two parts: one part pertains to each file saved, and the
318 other part pertains to the whole Job. Normally, this information is
319 saved in the Catalog so that the user doesn't need specific knowledge
320 of the Storage Coordinates. The Storage Coordinates include the
321 File Attributes (see above) plus the unique location of the information on
322 the backup Volume. </dd>
324 <dt>Storage Daemon</dt>
325 <dd>The Storage daemon, sometimes referred to as
326 the SD, is the code that writes the attributes and data to a storage
327 Volume (usually a tape or disk).</dd>
330 <dd>Normally refers to the internal conversation between
331 the File daemon and the Storage daemon. The File daemon opens a
332 <b>session</b> with the Storage daemon to save a FileSet, or to restore
333 it. A session has a one to one correspondence to a Bacula Job (see
337 <dd>A verify is a job that compares the current file
338 attributes to the attributes that have previously been stored in the
339 Bacula Catalog. This feature can be used for detecting changes to
340 critical system files similar to what <b>Tripwire</b> does. One
341 of the major advantages of using Bacula to do this is that
342 on the machine you want protected such as a server, you can run
343 just the File daemon, and the Director, Storage daemon, and Catalog
344 reside on a different machine. As a consequence, if your server is
345 ever compromised, it is unlikely that your verification database
346 will be tampered with.
347 <p>Verify can also be used to check that the most recent Job
348 data written to a Volume agrees with what is stored in the Catalog
349 (i.e. it compares the file attributes), *or it can check the
350 Volume contents against the original files on disk. </dd>
353 <dd>An Archive operation is done after a Save, and it
354 consists of removing the Volumes on which data is saved from active
355 use. These Volumes are marked as Archived, and many no longer be
356 used to save files. All the files contained on an Archived Volume
357 are removed from the Catalog. NOT YET IMPLEMENTED. </dd>
360 <dd>An Update operation causes the files on the remote
361 system to be updated to be the same as the host system. This is
362 equivalent to an <b>rdist</b> capability. NOT YET IMPLEMENTED.
365 <dt>Retention Period</dt>
366 <dd>There are various kinds of retention
367 periods that Bacula recognizes. The most important are the
368 <b>File</b> Retention Period, <b>Job</b> Retention Period, and the
369 <b>Volume</b> Retention Period. Each of these retention periods
370 applies to the time that specific records will be kept in the
371 Catalog database. This should not be confused with the time that
372 the data saved to a Volume is valid. <p>The File Retention Period
373 determines the time that File records are kept in the catalog
374 database. This period is important because the volume of the
375 database File records by far use the most storage space in the
376 database. As a consequence, you must ensure that regular
377 "pruning" of the database file records is done. (See
378 the Console <b>retention</b> command for more details on this
379 subject). <p>The Job Retention Period is the length of time that
380 Job records will be kept in the database. Note, all the File
381 records are tied to the Job that saved those files. The File
382 records can be purged leaving the Job records. In this case,
383 information will be available about the jobs that ran, but not the
384 details of the files that were backed up. Normally, when a Job
385 record is purged, all its File records will also be purged. <p>The
386 Volume Retention Period is the minimum of time that a Volume will be
387 kept before it is reused. Bacula will normally never
388 overwrite a Volume that contains the only backup copy of a file.
389 Under ideal conditions, the Catalog would retain entries for all
390 files backed up for all current Volumes. Once a Volume is
391 overwritten, the files that were backed up on that Volume are
392 automatically removed from the Catalog. However, if there is a very
393 large pool of Volumes or a Volume is never overwritten, the Catalog
394 database may become enormous. To keep the Catalog to a manageable
395 size, the backup information should removed from the Catalog after
396 the defined File Retention Period. Bacula provides the
397 mechanisms for the catalog to be automatically pruned according to
398 the retention periods defined. </dd>
401 <dd>A Scan operation causes the contents of a Volume or a
402 series of Volumes to be scanned. These Volumes with the information
403 on which files they contain are restored to the Bacula Catalog.
404 Once the information is restored to the Catalog, the files contained
405 on those Volumes may be easily restored. This function is
406 particularly useful if certain Volumes or Jobs have exceeded
407 their retention period and have been pruned or purged from the
408 Catalog. Scanning data from Volumes into the Catalog is done
409 by using the <b>bscan</b> program. See the <a href="rel-manual/progs.html#bscan">
410 bscan section</a> of the Bacula Utilities Chapter of this manual
411 for more details.</dd>
414 <dd>A Volume is an archive unit, normally a tape or
415 a named disk file where Bacula stores the data from one or more
416 backup jobs. All Bacula Volumes have a software label written to
417 the Volume by Bacula so that it identify what Volume it is really
418 reading. (Normally there should be no confusion with disk files,
419 but with tapes, it is easy to mount the wrong one).</dd>
422 <h3>What Bacula is Not</h3>
423 <b>Bacula</b> is a backup, restore and verification program and is not a
424 complete disaster recovery system in itself, but it can be a key part
425 of one if you plan carefully and follow the instructions included in the <a
426 href="rel-manual/rescue.html"> Disaster Recovery</a> Chapter of this manual.
428 With proper planning, as mentioned in the Disaster Recovery chapter
429 <b>Bacula</b> can be a central component of your disaster recovery
430 system. For example, if you have created an emergency boot disk, a
431 Bacula Rescue disk to save the current partitioning information of your
432 hard disk, and maintain a complete Bacula backup, it is possible to
433 completely recover your system from "bare metal".
435 If you have used the <b>WriteBootstrap</b> record in your job or some
436 other means to save a valid bootstrap file, you will be able to use it
437 to extract the necessary files (without using the catalog or manually
438 searching for the files to restore).
440 <h3>Interactions Between the Bacula Services</h3>
441 The following block diagram shows the typical interactions
442 between the Bacula Services for a backup job. Each block
443 represents in general a separate process (normally a daemon).
444 In general, the Director oversees the flow of information. It also
445 maintains the Catalog.
446 <p style="text-align: center">
447 <img src="images/manual/flow.jpeg" border="0" alt="Interactions between Bacula Services" width="480" height="370">
453 <? require_once("inc/header.php"); ?>