4 \section*{What is Bacula?}
5 \label{_ChapterStart41}
6 \index[general]{Bacula!What is }
7 \index[general]{What is Bacula? }
8 \addcontentsline{toc}{section}{What is Bacula?}
10 {\bf Bacula} is a set of computer programs that permits you (or the system
11 administrator) to manage backup, recovery, and verification of computer data
12 across a network of computers of different kinds. In technical terms, it is a
13 network Client/Server based backup program. Bacula is relatively easy to use
14 and efficient, while offering many advanced storage management features that
15 make it easy to find and recover lost or damaged files. Due to its modular
16 design, Bacula is scalable from small single computer systems to systems
17 consisting of hundreds of computers located over a large network.
19 \subsection*{Who Needs Bacula?}
20 \index[general]{Who Needs Bacula? }
21 \index[general]{Bacula!Who Needs }
22 \addcontentsline{toc}{subsection}{Who Needs Bacula?}
24 If you are currently using a program such as {\bf tar}, {\bf dump}, or {\bf
25 bru} to backup your computer data, and you would like a network solution, more
26 flexibility, or catalog services, Bacula will most likely provide the
27 additional features you want. However, if you are new to Unix systems or do
28 not have offsetting experience with a sophisticated backup package, we do not
29 recommend using Bacula as it is much more difficult to setup and use than {\bf
32 If you are running {\bf Amanda} and would like a backup program that can write
33 to multiple volumes (i.e. is not limited by your tape drive capacity), Bacula
34 can most likely fill your needs. In addition, quite a number of our users
35 report that Bacula is simpler to setup and use than other equivalent programs.
38 If you are currently using a sophisticated commercial package such as Legato
39 Networker. ARCserveIT, Arkeia, or PerfectBackup+, you may be interested in
40 Bacula, which provides many of the same features, and is free software
41 available under the GNU Version 2 software license.
43 \subsection*{Bacula Components or Services}
44 \index[general]{Bacula Components or Services }
45 \index[general]{Services!Bacula Components or }
46 \addcontentsline{toc}{subsection}{Bacula Components or Services}
48 Bacula is made up of the following five major components or services:
50 \addcontentsline{lof}{figure}{Bacula Applications}
51 \includegraphics{./bacula-applications.eps}
52 (thanks to Aristedes Maniatis for this graphic and the one below)
57 {\bf Bacula Director} service consists of the program that supervises all the
58 backup, restore, verify and archive operations. The system administrator uses
59 the Bacula Director to schedule backups and to recover files. For more
60 details see the Director Services Daemon Design Document in the Bacula
61 Developer's Guild. The Director runs as a daemon or a service (i.e. in the
65 {\bf Bacula Console} services is the program that allows the administrator or
66 user to communicate with the {\bf Bacula Director} (see above). Currently,
67 the Bacula Console is available in three versions. The first and simplest is
68 to run the Console program in a shell window (i.e. TTY interface). Most
69 system administrators will find this completely adequate. The second version
70 is a GNOME GUI interface that for the moment (23 November 2003) is far from
71 complete, but quite functional as it has most the capabilities of the shell
72 Console. The third version is a wxWidgets GUI with an interactive file
73 restore. It also has most of the capabilities of the shell console, allows
74 command completion with tabulation, and gives you instant help about the
75 command you are typing. For more details see the
76 \ilink{Bacula Console Design Document}{_ChapterStart23}.
79 {\bf Bacula File} services (or Client program) is the software program that
80 is installed on the machine to be backed up. It is specific to the operating
81 system on which it runs and is responsible for providing the file attributes
82 and data when requested by the Director. The File services are also
83 responsible for the file system dependent part of restoring the file
84 attributes and data during a recovery operation. For more details see the
85 File Services Daemon Design Document in the Bacula Developer's Guide. This
86 program runs as a daemon on the machine to be backed up, and in some of the
87 documentation, the File daemon is referred to as the Client (for example in
88 Bacula's configuration file). In addition to Unix/Linux File daemons, there
89 is a Windows File daemon (normally distributed in binary format). The Windows
90 File daemon runs on all currently known Windows versions (95, 98, Me, NT,
94 {\bf Bacula Storage} services consist of the software programs that perform
95 the storage and recovery of the file attributes and data to the physical
96 backup media or volumes. In other words, the Storage daemon is responsible
97 for reading and writing your tapes (or other storage media, e.g. files). For
98 more details see the Storage Services Daemon Design Document in the Bacula
99 Developer's Guild. The Storage services runs as a daemon on the machine that
100 has the backup device (usually a tape drive).
103 {\bf Catalog} services are comprised of the software programs responsible for
104 maintaining the file indexes and volume databases for all files backed up.
105 The Catalog services permit the System Administrator or user to quickly
106 locate and restore any desired file. The Catalog services sets Bacula apart
107 from simple backup programs like tar and bru, because the catalog maintains a
108 record of all Volumes used, all Jobs run, and all Files saved, permitting
109 efficicient restoration and Volume management. Bacula currently supports
110 three different databases, MySQL, PostgreSQL, and SQLite, one of which must
111 be chosen when building {\bf Bacula}. There also exists an Internal database,
112 but it is no longer supported.
114 The three SQL databases currently supported (MySQL, PostgreSQL or SQLite)
115 provide quite a number of features, including rapid indexing, arbitrary
116 queries, and security. Although we plan to support other major SQL databases,
117 the current Bacula implementation interfaces only to MySQL, PostgreSQL and
118 SQLite. For more details see the
119 \ilink{Catalog Services Design Document}{_ChapterStart30}.
121 The RPMs for MySQL and PostgreSQL ship as part of the Linux RedHat release,
122 or building it from the source is quite easy, see the
123 \ilink{ Installing and Configuring MySQL}{_ChapterStart} chapter of
124 this document for the details. For more information on MySQL, please see:
125 \elink{www.mysql.com}{http://www.mysql.com}. Or see the
126 \ilink{ Installing and Configuring PostgreSQL}{_ChapterStart10}
127 chapter of this document for the details. For more information on PostgreSQL,
129 \elink{www.postgresql.org}{http://www.postgresql.org}.
131 Configuring and building SQLite is even easier. For the details of
132 configuring SQLite, please see the
133 \ilink{ Installing and Configuring SQLite}{_ChapterStart33} chapter
137 {\bf Bacula Monitor} services is the program that allows the administrator or
138 user to watch current status of {\bf Bacula Directors}, {\bf Bacula File
139 Daemons} and {\bf Bacula Storage Daemons} (see above). Currently, only a GTK+
140 version is available, which works with Gnome and KDE (or any window manager
141 that supports the FreeDesktop.org system tray standard).
144 To perform a successful save or restore, the following four daemons must be
145 configured and running: the Director daemon, the File daemon, the Storage
146 daemon, and MySQL, PostgreSQL or SQLite.
148 \subsection*{Bacula Configuration}
149 \index[general]{Configuration!Bacula }
150 \index[general]{Bacula Configuration }
151 \addcontentsline{toc}{subsection}{Bacula Configuration}
153 In order for Bacula to understand your system, what clients you want backed
154 up, and how, you must create a number of configuration files containing
155 resources (or objects). The following presents an overall picture of this:
157 \addcontentsline{lof}{figure}{Bacula Objects}
158 \includegraphics{./bacula-objects.eps}
160 \subsection*{Conventions Used in this Document}
161 \index[general]{Conventions Used in this Document }
162 \index[general]{Document!Conventions Used in this }
163 \addcontentsline{toc}{subsection}{Conventions Used in this Document}
165 {\bf Bacula} is in a state of evolution, and as a consequence, this manual
166 will not always agree with the code. If an item in this manual is preceded by
167 an asterisk (*), it indicates that the particular feature is not implemented.
168 If it is preceded by a plus sign (+), it indicates that the feature may be
169 partially implemented.
171 If you are reading this manual as supplied in a released version of the
172 software, the above paragraph holds true. If you are reading the online
173 version of the manual,
174 \elink{ www.bacula.org/manual}{http://www.bacula.org/manual}, please bear in
175 mind that this version describes the current version in development (in the
176 CVS) that may contain features not in the released version. Just the same, it
177 generally lags behind the code a bit.
179 \subsection*{Quick Start}
180 \index[general]{Quick Start }
181 \index[general]{Start!Quick }
182 \addcontentsline{toc}{subsection}{Quick Start}
184 To get Bacula up and running quickly, we recommend that you first scan the
185 Terminology section below, then quickly review the next chapter entitled
186 \ilink{The Current State of Bacula}{_ChapterStart2}, then the
187 \ilink{Getting Started with Bacula}{_ChapterStart37}, which will
188 give you a quick overview of getting Bacula running. After which, you should
189 proceed to the chapter on
190 \ilink{Installing Bacula}{_ChapterStart17}, then
191 \ilink{How to Configure Bacula}{_ChapterStart16}, and finally the
193 \ilink{ Running Bacula}{_ChapterStart1}.
195 \subsection*{Terminology}
196 \index[general]{Terminology }
197 \addcontentsline{toc}{subsection}{Terminology}
199 To facilitate communication about this project, we provide here the
200 definitions of the terminology that we use.
204 \item [Administrator]
205 \index[fd]{Administrator }
206 The person or persons responsible for administrating the Bacula system.
210 We use the term {\bf Backup} to refer to a Bacula Job that saves files.
212 \item [Bootstrap File]
213 \index[fd]{Bootstrap File }
214 The bootstrap file is an ASCII file containing a compact form of commands
215 that allow Bacula or the stand-alone file extraction utility ({\bf bextract})
216 to restore the contents of one or more Volumes, for example, the current
217 state of a system just backed up. With a bootstrap file, Bacula can restore
218 your system without a Catalog. You can create a bootstrap file from a Catalog
219 to extract any file or files you wish.
223 The Catalog is used to store summary information about the Jobs, Clients, and
224 Files that were backed up and on what Volume or Volumes. The information
225 saved in the Catalog permits the administrator or user to determine what jobs
226 were run, their status as well as the important characteristics of each file
227 that was backed up. The Catalog is an online resource, but does not contain
228 the data for the files backed up. Most of the information stored in the
229 catalog is also stored on the backup volumes (i.e. tapes). Of course, the
230 tapes will also have a copy of the file in addition to the File Attributes
233 The catalog feature is one part of Bacula that distinguishes it from simple
234 backup and archive programs such as {\bf dump} and {\bf tar}.
238 In Bacula's terminology, the word Client refers to the machine being backed
239 up, and it is synonymous with the File services or File daemon, and quite
240 often, we refer to it as the FD. A Client is defined in a configuration file
245 The program that interfaces to the Director allowing the user or system
246 administrator to control Bacula.
250 Unix terminology for a program that is always present in the background to
251 carry out a designated task. On Windows systems, as well as some Linux
252 systems, daemons are called {\bf Services}.
255 \index[fd]{Directive }
256 The term directive is used to refer to a statement or a record within a
257 Resource in a configuration file that defines one specific thing. For
258 example, the {\bf Name} directive defines the name of the Resource.
261 \index[fd]{Director }
262 The main Bacula server daemon that schedules and directs all Bacula
263 operations. Occasionally, we refer to the Director as DIR.
266 \index[fd]{Differential }
267 A backup that includes all files changed since the last Full save started.
268 Note, other backup programs may define this differently.
270 \item [File Attributes]
271 \index[fd]{File Attributes }
272 The File Attributes are all the information necessary about a file to
273 identify it and all its properties such as size, creation date, modification
274 date, permissions, etc. Normally, the attributes are handled entirely by
275 Bacula so that the user never needs to be concerned about them. The
276 attributes do not include the file's data.
279 \index[fd]{File Daemon }
280 The daemon running on the client computer to be backed up. This is also
281 referred to as the File services, and sometimes as the Client services or the
288 A FileSet is a Resource contained in a configuration file that defines the
289 files to be backed up. It consists of a list of included files or
290 directories, a list of excluded files, and how the file is to be stored
291 (compression, encryption, signatures). For more details, see the
292 \ilink{FileSet Resource definition}{FileSetResource} in the
293 Director chapter of this document.
296 \index[fd]{Incremental }
297 A backup that includes all files changed since the last Full, Differential,
298 or Incremental backup started. It is normally specified on the {\bf Level}
299 directive within the Job resource definition, or in a Schedule resource.
305 A Bacula Job is a configuration resource that defines the work that Bacula
306 must perform to backup or restore a particular Client. It consists of the
307 {\bf Type} (backup, restore, verify, etc), the {\bf Level} (full,
308 incremental,...), the {\bf FileSet}, and {\bf Storage} the files are to be
309 backed up (Storage device, Media Pool). For more details, see the
310 \ilink{Job Resource definition}{JobResource} in the Director
311 chapter of this document.
315 The program that interfaces to the all the daemons allowing the user or
316 system administrator to monitor Bacula status.
319 \index[fd]{Resource }
320 A resource is a part of a configuration file that defines a specific unit of
321 information that is available to Bacula. For example, the {\bf Job} resource
322 defines all the properties of a specific Job: name, schedule, Volume pool,
323 backup type, backup level, ...
327 A restore is a configuration resource that describes the operation of
328 recovering a file (lost or damaged) from backup media. It is the inverse of a
329 save, except that in most cases, a restore will normally have a small set of
330 files to restore, while normally a Save backs up all the files on the system.
331 Of course, after a disk crash, Bacula can be called upon to do a full
332 Restore of all files that were on the system.
335 \index[fd]{Schedule }
336 A Schedule is a configuration resource that defines when the Bacula Job will
337 be scheduled for execution. To use the Schedule, the Job resource will refer
338 to the name of the Schedule. For more details, see the
339 \ilink{Schedule Resource definition}{ScheduleResource} in the
340 Director chapter of this document.
344 This is Windows terminology for a {\bf daemon} -- see above. It is now
345 frequently used in Unix environments as well.
347 \item [Storage Coordinates]
348 \index[fd]{Storage Coordinates }
349 The information returned from the Storage Services that uniquely locates a
350 file on a backup medium. It consists of two parts: one part pertains to each
351 file saved, and the other part pertains to the whole Job. Normally, this
352 information is saved in the Catalog so that the user doesn't need specific
353 knowledge of the Storage Coordinates. The Storage Coordinates include the
354 File Attributes (see above) plus the unique location of the information on
357 \item [Storage Daemon]
358 \index[fd]{Storage Daemon }
359 The Storage daemon, sometimes referred to as the SD, is the code that writes
360 the attributes and data to a storage Volume (usually a tape or disk).
364 Normally refers to the internal conversation between the File daemon and the
365 Storage daemon. The File daemon opens a {\bf session} with the Storage daemon
366 to save a FileSet, or to restore it. A session has a one to one
367 correspondence to a Bacula Job (see above).
371 A verify is a job that compares the current file attributes to the attributes
372 that have previously been stored in the Bacula Catalog. This feature can be
373 used for detecting changes to critical system files similar to what {\bf
374 Tripwire} does. One of the major advantages of using Bacula to do this is
375 that on the machine you want protected such as a server, you can run just
376 the File daemon, and the Director, Storage daemon, and Catalog reside on a
377 different machine. As a consequence, if your server is ever compromised, it
378 is unlikely that your verification database will be tampered with.
380 Verify can also be used to check that the most recent Job data written to a
381 Volume agrees with what is stored in the Catalog (i.e. it compares the file
382 attributes), *or it can check the Volume contents against the original files
386 \index[fd]{*Archive }
387 An Archive operation is done after a Save, and it consists of removing the
388 Volumes on which data is saved from active use. These Volumes are marked as
389 Archived, and may no longer be used to save files. All the files contained
390 on an Archived Volume are removed from the Catalog. NOT YET IMPLEMENTED.
394 An Update operation causes the files on the remote system to be updated to be
395 the same as the host system. This is equivalent to an {\bf rdist} capability.
398 \item [Retention Period]
399 \index[fd]{Retention Period }
400 There are various kinds of retention periods that Bacula recognizes. The most
401 important are the {\bf File} Retention Period, {\bf Job} Retention Period,
402 and the {\bf Volume} Retention Period. Each of these retention periods
403 applies to the time that specific records will be kept in the Catalog
404 database. This should not be confused with the time that the data saved to a
407 The File Retention Period determines the time that File records are kept in
408 the catalog database. This period is important because the volume of the
409 database File records by far use the most storage space in the database. As a
410 consequence, you must ensure that regular ``pruning'' of the database file
411 records is done. (See the Console {\bf retention} command for more details on
414 The Job Retention Period is the length of time that Job records will be kept
415 in the database. Note, all the File records are tied to the Job that saved
416 those files. The File records can be purged leaving the Job records. In this
417 case, information will be available about the jobs that ran, but not the
418 details of the files that were backed up. Normally, when a Job record is
419 purged, all its File records will also be purged.
421 The Volume Retention Period is the minimum of time that a Volume will be
422 kept before it is reused. Bacula will normally never overwrite a Volume that
423 contains the only backup copy of a file. Under ideal conditions, the Catalog
424 would retain entries for all files backed up for all current Volumes. Once a
425 Volume is overwritten, the files that were backed up on that Volume are
426 automatically removed from the Catalog. However, if there is a very large
427 pool of Volumes or a Volume is never overwritten, the Catalog database may
428 become enormous. To keep the Catalog to a manageable size, the backup
429 information should be removed from the Catalog after the defined File Retention
430 Period. Bacula provides the mechanisms for the catalog to be automatically
431 pruned according to the retention periods defined.
435 A Scan operation causes the contents of a Volume or a series of Volumes to be
436 scanned. These Volumes with the information on which files they contain are
437 restored to the Bacula Catalog. Once the information is restored to the
438 Catalog, the files contained on those Volumes may be easily restored. This
439 function is particularly useful if certain Volumes or Jobs have exceeded
440 their retention period and have been pruned or purged from the Catalog.
441 Scanning data from Volumes into the Catalog is done by using the {\bf bscan}
443 \ilink{ bscan section}{bscan} of the Bacula Utilities Chapter of
444 this manual for more details.
448 A Volume is an archive unit, normally a tape or a named disk file where
449 Bacula stores the data from one or more backup jobs. All Bacula Volumes have
450 a software label written to the Volume by Bacula so that it identifies what
451 Volume it is really reading. (Normally there should be no confusion with disk
452 files, but with tapes, it is easy to mount the wrong one).
455 \subsection*{What Bacula is Not}
456 \index[general]{Not!What Bacula is }
457 \index[general]{What Bacula is Not }
458 \addcontentsline{toc}{subsection}{What Bacula is Not}
460 {\bf Bacula} is a backup, restore and verification program and is not a
461 complete disaster recovery system in itself, but it can be a key part of one
462 if you plan carefully and follow the instructions included in the
463 \ilink{ Disaster Recovery}{_ChapterStart38} Chapter of this manual.
465 With proper planning, as mentioned in the Disaster Recovery chapter {\bf
466 Bacula} can be a central component of your disaster recovery system. For
467 example, if you have created an emergency boot disk, a Bacula Rescue disk to
468 save the current partitioning information of your hard disk, and maintain a
469 complete Bacula backup, it is possible to completely recover your system from
472 If you have used the {\bf WriteBootstrap} record in your job or some other
473 means to save a valid bootstrap file, you will be able to use it to extract
474 the necessary files (without using the catalog or manually searching for the
477 \subsection*{Interactions Between the Bacula Services}
478 \index[general]{Interactions Between the Bacula Services }
479 \index[general]{Services!Interactions Between the Bacula }
480 \addcontentsline{toc}{subsection}{Interactions Between the Bacula Services}
482 The following block diagram shows the typical interactions between the Bacula
483 Services for a backup job. Each block represents in general a separate process
484 (normally a daemon). In general, the Director oversees the flow of
485 information. It also maintains the Catalog.
487 \addcontentsline{lof}{figure}{Interactions between Bacula Services}
488 \includegraphics{./flow.eps}
projects / bacula / docs / blob