6.1. Bacula ArchitectureBacula 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 ComponentsFigure 6-1 shows the structure of Bacula and how its components are related. Figure 6-1. Bacula application interactions (Source: adapted from Bacula manual)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:
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 ComponentsFigure 6-2 shows the information flows between Bacula components in a typical backup job. Figure 6-2. Information flow in BaculaDuring 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. AuthenticationEach 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. ConfigurationEach 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. |