In this article by Timothy Boronczyk,the author of the book CentOS 7 Server Management Cookbook,we'll discuss how to set up a network backup server with Bacula.

The fact of the matter is that we are living in a world that is becoming increasingly dependent on data. Also, from accidental deletion to a catastrophic hard drive failure, there are many threats to the safety of your data. The more important your data is and the more difficult it is to recreate if it were lost, the more important it is to have backups. So, this article shows you how you can set up a backup server using Bacula and how to configure other systems on your network to back up their data to it.

(For more resources related to this topic, see here.)

Getting ready

This article requires at least two CentOS systems with working network connections. The first system is the local system which we'll assume has the hostname benito and the IP address 192.168.56.41. The second system is the backup server. You'll need administrative access on both systems, either by logging in with the root account or through the use of sudo.

How to do it…

Perform the following steps on your local system to install and configure the Bacula file daemon:

Install the bacula-client package.
```
yum install bacula-client
```
Open the file daemon's configuration file with your text editor.
```
vi /etc/bacula/bacula-fd.conf
```
In the FileDaemon resource, update the value of the Name directive to reflect the system's hostname with the suffix -fd.
```
FileDaemon {

  Name = benito-fd

...

}
```
Save the changes and close the file.

Start the file daemon and enable it to start when the system reboots.

systemctl start bacula-fd.service

systemctl enable bacula-fd.service

Open the firewall to allow TCP traffic through to port 9102.

firewall-cmd --zone=public --permanent --add-port=9102/tcp

firewall-cmd --reload

Repeat steps 1-6 on each system that will be backed up.
- Install the bacula-console, bacula-director, bacula-storage, and bacula-client packages.
yum install bacula-console bacula-director bacula-storage bacula-client
Re-link the catalog library to use SQLite database storage.
alternatives --config libbaccats.so
Type 2 when asked to provide the selection number.

Create the SQLite database file and import the table schema.

/usr/libexec/bacula/create_sqlite3_database

/usr/libexec/bacula/make_sqlite3_tables

Open the director's configuration file with your text editor. vi /etc/bacula/bacula-dir.conf
In the Job resource where Name has the value BackupClient1, change the value of the Name directive to reflect one of the local systems. Then add a Client directive with a value that matches that system's FileDaemonName. Job { Name = "BackupBenito" Client = benito-fd JobDefs = "DefaultJob" }
Duplicate the Job resource and update its directive values as necessary so that there is a Job resource defined for each system to be backed up. For each system that will be backed up, duplicate the Client resource where the Name directive is set to bacula-fd. In the copied resource, update the Name and Address directives to identify that system. Client { Name = bacula-fd Address = localhost ... } Client { Name = benito-fd Address = 192.168.56.41 ... } Client { Name = javier-fd Address = 192.168.56.42 ... }
Save your changes and close the file.
Open the storage daemon's configuration file.
```
vi /etc/bacula/bacula-sd.conf
```
In the Device resource where Name has the value FileStorage, change the value of the Archive Device directive to /bacula.
```
Device {

  Name = FileStorage

  Media Type = File

  Archive Device = /bacula

...
```
Save the update and close the file.
Create the /bacula directory and assign it the proper ownership.
```
mkdir /bacula

chown bacula:bacula /bacula
```
If you have SELinux enabled, reset the security context on the new directory.
```
restorecon -Rv /bacula
```

Start the director and storage daemons and enable them to start when the system reboots.

systemctl start bacula-dir.service bacula-sd.service bacula-fd.service

systemctl enable bacula-dir.service bacula-sd.service bacula-fd.service

Open the firewall to allow TCP traffic through to ports 9101-9103.

firewall-cmd --zone=public --permanent --add-port=9101-9103/tcp

firewall-cmd –reload

Launch Bacula's console interface.
```
bconsole
```
Enter label to create a destination for the backup. When prompted for the volume name, use Volume0001 or a similar value. When prompted for the pool, select the File pool.
```
label
```
Enter quit to leave the console interface.

How it works…

The suite's distributed architecture and the amount of flexibility it offers us can make configuring Bacula a daunting task.However, once you have everything up and running, you'll be able to rest easy knowing that your data is safe from disasters and accidents.

Bacula is broken up into several components. In this article, our efforts centered on the following three daemons: the director, the file daemon, and the storage daemon. The file daemon is installed on each local system to be backed up and listens for connections from the director. The director connects to each file daemon as scheduled and tells it whichfiles to back up and where to copy them to (the storage daemon). This allows us to perform all scheduling at a central location. The storage daemon then receives the data and writes it to the backup medium, for example, disk or tape drive.

On the local system, we installed the file daemon with the bacula-client package andedited the file daemon's configuration file at /etc/bacula/bacula-fd.conf to specify the name of the process. The convention is to add the suffix -fd to the system's hostname.

FileDaemon {

  Name = benito-fd

  FDPort = 9102

  WorkingDirectory = /var/spool/bacula

  Pid Directory = /var/run

  Maximum Concurrent Jobs = 20

}

On the backup server, we installed thebacula-console, bacula-director, bacula-storage, and bacula-client packages. This gives us the director and storage daemon and another file daemon. This file daemon's purpose is to back up Bacula's catalog.

Bacula maintains a database of metadata about previous backup jobs called the catalog, which can be managed by MySQL, PostgreSQL, or SQLite. To support multiple databases, Bacula is written so that all of its database access routines are contained in shared libraries with a different library for each database. When Bacula wants to interact with a database, it does so through libbaccats.so, a fake library that is nothing more than a symbolic link pointing to one of the specific database libraries. This let's Bacula support different databases without requiring us to recompile its source code.

To create the symbolic link, we usedalternatives and selected the real library that we want to use. I chose SQLite since it's an embedded database library and doesn't require additional services.

setting-upa-network-backup-server-bacula-img-0

Next, we needed to initialize the database schema using scripts that come with Bacula. If you want to use MySQL, you'll need to create a dedicated MySQL user for Bacula to use and then initialize the schema with the following scripts instead. You'll also need to review Bacula's configuration files to provide Bacula with the required MySQL credentials.

/usr/libexec/bacula/grant_mysql_privileges

/usr/libexec/bacula/create_mysql_database

/usr/libexec/bacula/make_mysql_tables

Different resources are defined in the director's configuration file at /etc/bacula/bacula-dir.conf, many of which consist not only of their own values but also reference other resources. For example, the FileSet resource specifies which files are included or excluded in backups and restores, while a Schedule resource specifies when backups should be made. A JobDef resource can contain various configuration directives that are common to multiple backup jobs and also reference particular FileSet and Schedule resources. Client resources identify the names and addresses of systems running file daemons, and a Job resource will pull together a JobDef and Client resource to define the backup or restore task for a particular system. Some resources define things at a more granular level and are used as building blocks to define other resources. Thisallows us to create complex definitions in a flexible manner.

The default resource definitions outline basic backup and restore jobs that are sufficient for this article (you'll want to study the configuration and see how the different resources fit together so that you can tweak them to better suit your needs). We customized the existing backup Jobresource by changing its name and client. Then, we customized the Client resource by changing its name and address to point to a specific system running a file daemon. A pair of Job and Client resources can be duplicated for each additional system youwant to back up. However, notice that I left the default Client resource that defines bacula-fd for the localhost. This is for the file daemon that's local to the backup server and will be the target for things such as restore jobs and catalog backups.

Job {

  Name = "BackupBenito"

  Client = benito-fd

  JobDefs = "DefaultJob"

}

 

Job {

  Name = "BackupJavier"

  Client = javier-fd

  JobDefs = "DefaultJob"

}

 

Client {

  Name = bacula-fd

  Address = localhost

  ...

}

 

Client {

  Name = benito-fd

  Address = 192.168.56.41

  ...

}

 

Client {

  Name = javier-fd

  Address = 192.168.56.42

  ...

}

To complete the setup, we labeled a backup volume. This task, as with most others, is performed through bconsole, a console interface to the Bacula director. We used thelabel command to specify a label for the backup volume and when prompted for the pool, we assigned the labeled volume to the File pool. In a way very similar to how LVM works, an individual device or storage unit is allocated as a volume and the volumes are grouped into storage pools. If a pool contains two volumes backed by tape drives for example and one of the drives is full, the storage daemon will write the data to the tape that has space available. Even though in our configuration we're storing the backup to disk, we still need to create a volume as the destination for data to be written to.

There's more...

At this point, you should consider which backup strategy works best for you. A full backup is a complete copy of your data, a differential backup captures only the files that have changed since the last full backup, and an incremental backup copies the files that have changed since the last backup (regardless of the type of backup). Commonly, administrators employ a previous combination, perhaps making a full backup at the start of the week and then differential or incremental backups each day thereafter. This saves storage space because the differential and incremental backups are not only smaller but also convenient when the need to restore a file arises because a limited number of backups need to be searched for the file.

Another consideration is the expected size of each backup and how long it will take for the backup to run to completion. Full backups obviously take longer to run, and in an office with 9-5 working hours, Monday through Friday and it may not be possible to run a full backup during the evenings. Performing a full backup on Fridays gives the backup time over the weekend to run. Smaller, incremental backups can be performed on the other days when time is lesser.

Yet another point that is important in your backup strategy is, how long the backups will be kept and where they will be kept. A year's worth of backups is of no use if your office burns down and they were sitting in the office's IT closet. At one employer, we kept the last full back up and last day's incremental on site;they were then duplicated to tape and stored off site.

Regardless of the strategy you choose to implement, your backups are only as good as your ability to restore data from them. You should periodically test your backups to make sure you can restore your files.

To run a backup job on demand, enter run in bconsole. You'll be prompted with a menu to select one of the current configured jobs. You'll then be presented with the job's options, such as what level of backup will be performed (full, incremental, or differential), it's priority, and when it will run. You can type yes or no to accept or cancel it or mod to modify a parameter. Once accepted, the job will be queued and assigned a job ID.

To restore files from a backup, use the restore command. You'll be presented with a list of options allowing you to specify which backup the desired files will be retrieved from. Depending on your selection, the prompts will be different. Bacula's prompts are rather clear, so read them carefully and they will guide you through the process.

Apart from the run and restore commands, another useful command is status. It allows you to see the current status of the Bacula components, if there are any jobs currently running, and which jobs have completed. A full list of commands can be retrieved by typing help in bconsole.

setting-upa-network-backup-server-bacula-img-1

Summary

In this article, we discussed how we can set up a backup server using Bacula and how to configure other systems on our network to back up our data to it.