Bacula is an open source backup solution. It’s known to be robust enough but yet relatively easy-to-configure. As it is open source, software license costs are nullified. Also a proof to its stability, it’s RPMs and DEBs are to be found in software repositories of the most popular Linux server distributions, Red Hat (CentOS) and Debian, so installation and deployment of upgrades can be done in a common way by anyone. Bottom line, Bacula has its flaws, but it’s still likely better than fooling around with rsync based scripts and catalogues.
Bacula infrastructure
Bacula is a set of services and management utilities to manage backup, recovery, and verification of computer data across a network of computers with different operating systems.
Bacula Director
The Bacula Director service is the program that supervises all the backup, restore, verify and archive operations. The system administrator uses the Bacula Director to schedule backups and to recover files. The Director runs as a daemon in the background.
Bacula Console
The Bacula Console utility is the program that allows the administrator or user to communicate with the Bacula Director. Currently, the Bacula Console is available in three versions: text-based console interface, QT-based interface, and a wxWidgets graphical interface. The first and simplest is to run the Console program in a shell window (i.e. TTY interface). Most system administrators will find this completely adequate. The second version is a GNOME GUI interface that is far from complete, but quite functional as it has most the capabilities of the shell Console. The third version is a wxWidgets GUI, which has most of the capabilities of the shell console and also an interactive file restore function.
Bacula File Daemon
The Bacula File Daemon service (also known as the Client program) is the software program that is installed on the machine to be backed up. It is specific to the operating system on which it runs and is responsible for providing the file attributes and data when requested by the Director. The File services are also responsible for the file system dependent part of restoring the file attributes and data during a recovery operation. This program runs as a daemon on the machine to be backed up. In addition to Unix/Linux File daemons, there is also a Windows File daemon.
Bacula Storage
The Bacula Storage services consist of the software programs that perform the storage and recovery of the file attributes and data to the physical backup media or volumes. In other words, the Storage daemon is responsible for reading and writing the storage media (e.g. files or tape). The Storage service runs as a daemon on the machine that has the backup device.
Catalog
The Catalog services are comprised of the software programs responsible for maintaining the file indexes and volume databases for all files backed up. The Catalog services permit the system administrator or user to quickly locate and restore any desired file. The Catalog services sets Bacula apart from simple backup programs like tar, because the catalog maintains a record of all Volumes used, all Jobs run, and all Files saved, permitting efficient restoration and Volume management. Bacula currently supports three different databases, MySQL, PostgreSQL, and SQLite, one of which must be chosen when building Bacula.
Service interactions
In general, Director serves as an orchestrator of the Bacula infrastructure. As it executes scheduled backup jobs, it’s the actuator of most communication scenarios. Below table contains all relevant communication paths, including the default Bacula service ports.
| Source | Destination | Dest. port |
| Director | Storage Daemon | 9003 |
| Director | File Daemon | 9002 |
| File daemon | Storage Daemon | 9003 |
| Console | Director | 9001 |
| Director | Catalogue (MySQL) | 3306 |
Resources
Configuration of Bacula is realized through a flat structure of objects, called resources. This structure is defined on the Director with the Job resources as their central elements. A Job is the logical identity of a backup task. It is associated with several other resources to describe every aspect of that task:
- What? – FileSet. A collection of files and directories to back up.
- From where? – Client. A host where the above FileSet
- To where? – Storage, Pool. A storage server and a data file where we put a copy of FileSet.
- When? – Schedule. A set of dates and times for the Job to start.
There are also some service-specific backend resources (e.g. Catalogue on the Director and Device on the Storage Daemon) and service-definition resources, like Client, Storage and Director.
In fact, all services share a Director resource, which contains access details of the common Director instance. There’s also a Messages resource available on every node that holds configuration options to tell the service at hand where to send its output (e.g. to local log facility or to the Director).
Critical file system paths are organized into so-called file sets (FileSet resource). Every job runs on a single file set, but multiple jobs can be defined for a single client. Bacula is by default configured not to cross file system boundaries, so all mount points should included in the list, even when their paths are overlapping in VFS. If you configure Bacula to diverge from this behaviour, make sure virtual file systems and temp (/proc, /dev, /tmp, /sys) are explicitly excluded to ensure safe execution of backups.
Data restoration
File restoration can only be initiated manually via Bacula Console. The command line console’s “restore” command lets the administrator choose which files to restore from the storage. The selected files will then be copied to their original location or another predefined file system directory.
In order to restore any number of files from backup, one can do the following. Note, that there are numerous other ways to fulfil this task, but describing all of them is out of the scope of this document.
- Log in to the Bacula Director host.
- Start the Bacula Console by issuing the “bconsole” command in shell.
- Enter the following console command.restore where=<path> client=<client>Where path is the directory where the files should be copied to and client is the host for which the restoration is performed. If root (/) is given as path, then the files will be restored to their original location.
- Bacula presents several ways to select the files to be restored. Enter “8” after the prompt for “Enter a list of files to restore before a specified time”.To select the JobIds, you have the following choices:
1: List last 20 Jobs run 2: List Jobs where a given File is saved 3: Enter list of comma separated JobIds to select 4: Enter SQL list command 5: Select the most recent backup for a client 6: Select backup for a client before a specified time 7: Enter a list of files to restore 8: Enter a list of files to restore before a specified time 9: Find the JobIds of the most recent backup for a client 10: Find the JobIds for a backup for a client before a specified time 11: Enter a list of directories to restore for found JobIds 12: Select full restore to a specified Job date 13: Cancel Select item: (1-13): 8
- Enter the date and time in ISO standard format (YYYY-MM-DD HH:MM:SS) when the desired state of the files was supposedly backed up.
- Now enter one file name per line with full path. Press Enter again after the last one.
- Restore job details are displayed. This job will be scheduled to copy the files to the given location. Review this information – the “Restore Client” and “Where” parts in particular. Type yes to schedule the job.
- You can view the status messages via the console command “messages”. The job should terminate with a “Restore OK” status.
Let IT know 