How to Set Up Backup with Bacula

Bacula is a cross-platform client-server open source backup software that enables you to back up files, directories, databases, mail server data (Postfix, Exim, Sendmail, Dovecot), system images, and entire operating systems.

In this guide, we’ll walk you through the process of installing and configuring Bacula on Linux, as well as creating backups and restoring user data.

To get started with Bacula, you’ll need a server or virtual machine running any Linux distribution. In this tutorial, we’ll be using a cloud server from Hostman with Debian 12. Or you can choose your own private Linux server.

Bacula Architecture

Copy link

Bacula’s architecture consists of the following components:

Director (Bacula Director)

The core component responsible for managing all backup, restore, and verification operations. The Director schedules jobs, sends commands to other components, and writes information to the database.

Storage Daemon (Bacula Storage)

Handles communication with storage devices such as disks, cloud storage, etc. The Storage Daemon receives data from the File Daemon and writes it to the configured storage medium.

File Daemon (Bacula File)

The agent installed on client machines to perform the actual backup operations.

Catalog

A database (MySQL, PostgreSQL, or SQLite) used by Bacula to store information about completed jobs, such as backup metadata, file lists, and restore history.

Console (Bacula Console, bconsole)

A command-line utility for interacting with Bacula. The Console allows administrators to control the Director via a CLI. GUI tools such as Bacula Web and Baculum are also available.

Monitor (Optional)

A component for monitoring the Bacula system status. It tracks job statuses, daemon states, and storage device conditions.

Creating Test Data for Backup

Copy link

Let’s create some test files to use in our backup.

Create a test directory and navigate into it:

mkdir /root/test_backups && cd /root/test_backups

Now create six sequential files:

touch file{1..6}.txt

Also, create a directory in advance for storing restored files:

mkdir /root/restored-files

Installing Bacula

Copy link

In this tutorial, we will install all Bacula components on a single server. However, Bacula also supports a distributed setup where components such as the Director, Storage Daemon, Client, and database can be installed on separate servers. This decentralized setup is suitable for backing up multiple systems without overloading a single server.

We'll be using Debian 12 and installing PostgreSQL (version 15) as the backend database.

Update the package index and install Bacula (server and client components):

apt update && apt -y install bacula-server bacula-client

PostgreSQL 15 will also be installed during this process.

During installation:

• When prompted with: “Configure database for bacula-director-pgsql with dbconfig-common?”, press ENTER.

• When asked to choose the database host, select localhost, since we are installing everything on one server.

• When prompted with: “PostgreSQL application password for bacula-director-pgsql”, set a password for the Bacula database. 

• Re-enter the password when asked to confirm.

The installation will then continue normally.

After the installation is complete, verify the status of Bacula components and PostgreSQL.

Check the status of the Bacula Director:

systemctl status bacula-director

Check the Storage Daemon:

systemctl status bacula-sd

Check the File Daemon:

systemctl status bacula-fd

Check PostgreSQL:

systemctl status postgresql

If all components display a status of active, then Bacula has been successfully installed and is running.

Bacula Configuration

Copy link

Bacula is configured by editing the configuration files of the program components. By default, all Bacula configuration files are located in the /etc/bacula directory.

Next, we will configure each Bacula component individually.

Configuring Bacula Director

Copy link

Using any text editor, open the bacula-dir.conf configuration file for editing:

nano /etc/bacula/bacula-dir.conf

Let’s start with the Director block, which sets the main configuration parameters for the Director component:

Director {
  Name = 4142939-bi08079-dir
  DIRport = 9101
  QueryFile = "/etc/bacula/scripts/query.sql"
  WorkingDirectory = "/var/lib/bacula"
  PidDirectory = "/run/bacula"
  Maximum Concurrent Jobs = 20
  Password = "ohzb29XNWSFISd6qN6fG2urERzxOl9w68"
  Messages = Daemon
  DirAddress = 127.0.0.1
}

Explanation of parameters:

• Name: The name of the Director component. This is a unique identifier used to connect with other components like the File Daemon and Storage Daemon. By default, it includes the server's hostname and the -dir suffix. Example: 4142939-bi08079-dir.

• DIRport: The port that Bacula Director listens to for incoming connections from the management console (bconsole). Default is 9101.

• QueryFile: Path to the SQL script file used to run queries on the database. It contains predefined SQL queries for job management, verification, data restoration, etc. Default: /etc/bacula/scripts/query.sql.

• WorkingDirectory: The working directory where Bacula Director temporarily saves files during job execution.

• PidDirectory: The directory where the Director saves its PID file (process identifier). This is used to track if the process is running.

• Maximum Concurrent Jobs: The maximum number of jobs that can run simultaneously. The default is 20.

• Password: Password used for authenticating the management console (bconsole) with the Director. Must match the one specified in the console’s configuration.

• Messages: Specifies the name of the message resource that determines how messages (errors, warnings, events) are handled. Common values: Daemon, Standard, Custom.

• DirAddress: The IP address the Director listens on. This can be 127.0.0.1 for local connections or an external IP.

Catalog Configuration

By default, Bacula comes with its own PostgreSQL instance on the same host, and in that case, database connection settings don’t need changes. But if you're deploying the database separately (recommended for production), the address, username, and password must be specified in the Catalog block:

Catalog {
  Name = MyCatalog
  dbname = "bacula"; DB Address = "localhost"; dbuser = "bacula"; dbpassword = "StrongPassword4747563"
}

Explanation of parameters:

• dbname: The name of the database used by Bacula (default is bacula). The database must already exist (when deployed separately).

• DB Address: Host address where the DBMS is deployed. Use IP or a domain name. For local setup: localhost or 127.0.0.1.

• dbuser: The user Bacula will use to connect to the database.

• dbpassword: Password for the specified database user. Must be preconfigured.

Restore Job Configuration

Locate the Job block named RestoreFiles, responsible for file restoration. Set the Where parameter to specify the directory where restored files will be saved. Earlier, we created /root/restored-files, which we’ll use here:

Job {
  Name = "RestoreFiles"
  Type = Restore
  Client=4244027-bi08079-fd
  Storage = File1
  # The FileSet and Pool directives are not used by Restore Jobs
  # but must not be removed
  FileSet="Full Set"
  Pool = File
  Messages = Standard
  Where = /root/restored-files
}

Backup Schedule Configuration

Next, we set up the Schedule block that defines when backups are created.

We create:

• A full backup every Monday at 00:01.
• A differential backup every Sunday (2nd to 5th week) at 23:05.
• An incremental backup daily at 23:00:

Schedule {
  Name = "WeeklyCycle"
  Run = Full 1st mon at 00:01
  Run = Differential 2nd-5th sun at 23:05
  Run = Incremental mon-sun at 23:00
}

FileSet Configuration

Now, we specify which files and directories will be backed up. This is defined in the FileSet block. Earlier we created /root/test_backups with six files. We’ll specify that path:

FileSet {
  Name = "Full Set"
  Include {
    Options {
      signature = MD5
    }
    File = /root/test_backups
  }
}

Explanation of parameters:

• Name: The name of the FileSet block, used for identification in configuration.
• Options: Settings that apply to all files listed under Include.
• signature = MD5: Specifies the checksum algorithm used to verify file integrity. MD5 generates a 128-bit hash to track file changes.

Exclude Configuration (Optional)

The Exclude block is used to specify files or directories that should not be backed up. This block is placed inside the FileSet definition and acts on files included via Include.

Exclude {
    File = /var/lib/bacula
    ...
}

Pool Configuration

The Pool block defines a group of volumes (storage units) used for backup. Pools help manage how data is stored, rotated, and deleted.

Pool {
  Name = Default
  Pool Type = Backup
  Recycle = yes
  AutoPrune = yes
  Volume Retention = 7 days
  Maximum Volume Bytes = 10G
  Maximum Volumes = 2
}

Explanation of parameters:

• Name: The pool's name, here it's Default.
• Pool Type: Defines the pool's function:
  
  • Backup: Regular backups.
  • Archive: Long-term storage.
  • Cloning: Data duplication.
• Recycle: Indicates whether volumes can be reused once they're no longer needed (yes or no).
• AutoPrune: Enables automatic cleanup of expired volumes.
• Volume Retention: How long (in days) to retain data on a volume. After 7 days, the volume becomes eligible for reuse.
• Maximum Volume Bytes: The max size for a volume. If it exceeds 10 GB, a new volume is created (if allowed).
• Maximum Volumes: Limits the number of volumes in the pool. Here, it's 2. Older volumes are recycled when the limit is hit (if Recycle = yes).

Validating Configuration and Restarting Bacula

After making all changes, check the bacula-dir.conf file for syntax errors:

/usr/sbin/bacula-dir -t -c /etc/bacula/bacula-dir.conf

If the command output is empty, there are no syntax errors. If there are errors, the output will specify the line number and error description.

Restart the Bacula Director service:

systemctl restart bacula-director

Configuring Bacula Storage

Copy link

The next step is configuring Bacula Storage, where the backup files will be stored.

Using any text editor, open the configuration file bacula-sd.conf for editing:

nano /etc/bacula/bacula-sd.conf

We'll start with the Storage block, which defines the storage daemon responsible for physically saving backup files:

Storage {                             
 Name = 4149195-bi08079-sd
 SDPort = 9103                  
 WorkingDirectory = "/var/lib/bacula"
 Pid Directory = "/run/bacula"
 Plugin Directory = "/usr/lib/bacula"
 Maximum Concurrent Jobs = 20
 SDAddress = 127.0.0.1
}

Here’s what each parameter means:

• Name: Name of the storage daemon instance, used to identify it uniquely.
• SDPort: Port number the Storage Daemon listens on. The default is 9103.
• WorkingDirectory: Working directory for temporary files. Default: /var/lib/bacula.
• Pid Directory: Directory to store the PID file (process ID) for the storage daemon. Default: /run/bacula.
• Plugin Directory: Path where Bacula’s plugins for the storage daemon are located. These plugins can provide extra features such as encryption or cloud integration.
• Maximum Concurrent Jobs: Maximum number of jobs the storage daemon can handle simultaneously.
• SDAddress: IP address the Storage Daemon is available at. This can be an IP or a domain name. Since in our case the Storage Daemon runs on the same server as the Director, we use localhost.

The next block to configure is Device, which defines the storage device where backups will be written.

The device can be physical (e.g., a tape drive) or logical (e.g., a directory on disk). For testing, one Device block will suffice. By default, bacula-sd.conf may contain more than one Device block, including a Virtual Autochanger — a mechanism that emulates a physical autochanger (used for managing tapes or other media). It lets you manage multiple virtual volumes (typically as disk files) just like real tapes in a tape library.

Locate the Autochanger block and remove the FileChgr1-Dev2 value from the Device parameter:

Autochanger {
  Name = FileChgr1
  Device = FileChgr1-Dev1
  Changer Command = ""
  Changer Device = /dev/null
}

Next, in the Device block below, specify the full path to the directory we previously created for storing backup files (/srv/backup) in the Archive Device parameter:

Device {
  Name = FileChgr1-Dev1
  Media Type = File1
  Archive Device = /srv/backup
  LabelMedia = yes;                   
  Random Access = Yes;
  AutomaticMount = yes;               
  RemovableMedia = no;
  AlwaysOpen = no;
  Maximum Concurrent Jobs = 5
}

Any blocks referencing FileChgr2 and FileChgr1-dev2 should be deleted:

Explanation of the parameters:

• Autochanger Block:
  
  • Name: Identifier for the autochanger (you can have multiple).
  • Device: Name of the device linked to this autochanger—must match the Device block name.
  • Changer Command: Script or command used to manage the changer. An empty value ("") means none is used—suitable for virtual changers or simple setups.
  • Changer Device: Refers to the device tied to the autochanger, typically for physical devices.
• Device Block:
  
  • Name: Identifier for the device.
  • Media Type: Media type associated with the device. Must match the Pool block media type.
  • Archive Device: Full path to the device or directory for storing backups; /srv/backup in this case.
  • LabelMedia: Whether Bacula should auto-label new media.
  • Random Access: Whether random access is supported.
  • AutomaticMount: Whether to auto-mount the device when used.
  • RemovableMedia: Specifies if the media is removable.
  • AlwaysOpen: Whether the device should always stay open.
  • Maximum Concurrent Jobs: Maximum number of simultaneous jobs using this device.

Since we previously specified the directory for backup storage, create it:

mkdir -p /srv/backup

Set the ownership to the bacula user:

chown bacula:bacula /srv/backup

Next, check the config file for syntax errors:

/usr/sbin/bacula-sd -t -c /etc/bacula/bacula-sd.conf

If there are no syntax errors, the output will be empty. Otherwise, it will indicate the line number and description of any error.

Restart the storage daemon:

systemctl restart bacula-sd

Creating a Backup

Copy link

Backups in Bacula are created using the bconsole command-line tool. Launch the utility:

bconsole

If it connects to the Director component successfully, it will display 1000 OK.

Before running a backup, you can check the status of all components by entering the command:

status

This will display a list of the five Bacula system components. To check them all, enter 6.

To initiate a backup, enter the command:

run

From the list, choose the BackupClient1 option (your client name might differ based on previous config), by typing 1.

After selecting the option, you’ll see detailed info about the backup operation.

You’ll then be prompted with three choices:

• yes — start the backup process;
• mod — modify parameters before starting;
• no — cancel the backup.

If you enter mod, you’ll be able to edit up to 9 parameters.

To proceed with the backup, type yes.

To view all backup and restore jobs and their statuses:

list jobs

In our case, a backup with Job ID 1 was created:

list jobid=1

If the status is T, the backup was successful.

Possible statuses in the "Terminated Jobs" column:

• T (Success) — Job completed successfully.
• E (Error) — Job ended with an error.
• A (Canceled) — Job was canceled by the user.
• F (Fatal) — Job ended due to a critical error.
• R (Running) → Terminated — Job completed (may be successful or not).

You can also monitor backup activity and errors via the log file:

cat /var/log/bacula/bacula.log

Once the backup finishes, the file will be saved in the specified directory.

file Vol-0001

Restoring Files from Backup

Copy link

Earlier, we backed up the /root/test_backups directory, which contained six .txt files. Suppose these files were lost or deleted. Let’s restore them:

Launch the Bacula console:

bconsole

Start the restore process:

restore

You’ll see 12 available restore options.

We’ll use option 3. Type 3.

Earlier we used Job ID 1 for our backup. Enter 1. 

You’ll enter a file selection mode. Since our files were in the root/test_backups directory, navigate there.

All previously saved files should be visible.

To restore the whole directory, go up one level:

cd ..

Then mark the whole test_backups folder:

mark test_backups/

Finish selection:

done

The system will display a final summary showing which data will be restored and the target directory (in our case: /root/restored-files).

To start the restore, enter yes.

Finally, verify that the files have been successfully restored.

Conclusion

Copy link

We’ve now reviewed the installation and configuration of Bacula, a client-server backup solution. Bacula isn’t limited to backing up regular files—thanks to its plugin support, it can also handle backups of virtual machines, OS images, and more.