Backup & Recovery: Inexpensive Backup Solutions for Open Systems

6.1. Bacula Architecture

Bacula is structured as a number of cooperating components, all of which use TCP sockets to communicate over a network connection. The use of TCP/IP as the intercomponent transport is essential to Bacula's design philosophy because it allows components to be deployed on multiple or separate machines (according to capability or access to specialized hardware) and provides a ubiquitous method for intercomponent commands. The TCP transport can be wrapped with a standard Transport Layer Security (TLS) encryption layer to protect data while in transmission. TLS is discussed in more detail in the section "Advanced Features" later in this chapter.

6.1.1. Bacula Components

Figure 6-1 shows the structure of Bacula and how its components are related.

The separate application components illustrated here each provide a basic function within the Bacula environment. The following list identifies each component and describes the function provided to the overall application:

Director

The Bacula director is the application at the heart of a Bacula deployment: it manages media pool definition, scheduling, dependency tracking, access control, and reporting. It is responsible for nearly all policy-based configuration. Most changes to Bacula configuration occur in the director's configuration file.

Database server

Another essential piece of the Bacula design philosophy is the catalogan index of backed-up file storage locationswhich is kept in a relational database and accessed by SQL queries and updates. Currently, Bacula supports three databases: SQLite, MySQL, and PostgreSQL.

Storage daemon

The Bacula storage daemon manages interaction with media used to store backup data and is the only part of Bacula that actually communicates with volumes (such as tape, disk, or DVD-ROM) used for backups. All other Bacula components use the storage daemon's TCP/IP interface to communicate with the storage daemon and are unaware of the actual methods used to store and retrieve data. The storage daemon manages mounting and unmounting of storage volumes, labeling tapes (using OCR barcodes if available), and management of automatic tape loaders/libraries (ATLs).

Administrative console

The administrative console provides the operator user interface for job management, message handling, and status information. Volume management operations (like manually labeling a new storage volume) are also handled from the console.

The console comes in multiple flavors. A line-mode console is available on all platforms, is the most well supported, and is the way most administrators choose to interact with Bacula. A GUI is available on systems with the wxWidgets libraries; the current GUI is a graphical wrapper over the line-mode interface, which makes interactive file restoration somewhat easier and provides tab-completion and instant interactive help for commands. The line-mode console is often preferred, largely because it is easy to operate over low-bandwidth connections, making remote administration easier. The Bacula console does not have to run on the same machine as the director.

File daemon

The file daemon actually transfers the client's data to the storage server. It must be installed on each machine that is to be backed up. This piece communicates with the director to determine what client data is to be backed up and which storage daemon is to be used, and then transmits the data directly to the selected storage daemon, including metadata about the files it is sending (such as file size, access control parameters, and ownership information) as well as file contents.

Bacula also provides small status-indicator application-tray monitors for Windows, GNOME, and KDE (with some support for other windowing environments that support the free-desktop system-tray standard). The tray monitor is simply an icon that resides in the system tray and indicates whether Bacula components on this machine are idle, currently running a job, or in an error state. These status monitor icons can be expanded to give complete status information.

6.1.2. Interaction Between Components

Figure 6-2 shows the information flows between Bacula components in a typical backup job.

During execution, the director instructs the file daemon to communicate directly with the appropriate storage daemon, thus removing the director from the high-traffic path of actual backup data. The director maintains its own scheduling service so that jobs may proceed (on a fixed schedule) without a console or any user commands. Output from scheduled jobs is sent via email to one or more administrators defined in the director configuration.

6.1.2.1. Authentication

Each communication path between Bacula components uses a component name and a password. These passwords are a shared secret, kept as clear text in the Bacula configuration files (although the package installation methods usually set them to random strings). They are used during authentication to hash the challenge and response tokens. The passwords are never directly sent over the network. It is also possible to configure Bacula with TLS. TLS is discussed in more detail in the section "Advanced Features" later in this chapter.

6.1.2.2. Configuration

Each Bacula component (except the database server, which is controlled by the database's configuration files) has its own configuration file consisting of one or more sets of resource definition statements describing Bacula objects and how the system should handle these objects. More complex configurations, such as those with automatically generated components, can be split into multiple files and included individually. These resource definitions can be edited with any standard text editor, although the default configuration supplied with the package represents a sane basic configuration.