How To Back Up a CentOS 7 Server with Bacula

We want to add an additional Pool to our Bacula Director configuration, which we’ll use to configure our remote backup jobs.

Open the conf.d/pools.conf file:

sudo vi /etc/bacula/conf.d/pools.conf

Add the following Pool resource:

Pool {
  Name = RemoteFile
  Pool Type = Backup
  Label Format = Remote-
  Recycle = yes                       # Bacula can automatically recycle Volumes
  AutoPrune = yes                     # Prune expired volumes
  Volume Retention = 365 days         # one year
    Maximum Volume Bytes = 50G          # Limit Volume size to something reasonable
  Maximum Volumes = 100               # Limit number of Volumes in Pool
}

Save and exit. This defines a “RemoteFile” pool, which we will use by the backup job that we’ll create later. Feel free to change any of the parameters to meet your own needs.

We don’t need to restart Bacula Director just yet, but let’s verify that its configuration doesn’t have any errors in it:

sudo bacula-dir -tc /etc/bacula/bacula-dir.conf

If there are no errors, you’re ready to continue on to the Bacula Client setup.

Before configuring the client File Daemon, you will want to look up the following information, which will be used throughout the remainder of this tutorial:

• Client hostname:: Our example will use “ClientHost”
• Client Private FQDN: We’ll refer to this as “client_private_FQDN”, which may look like clienthost.private.example.com
• Bacula Server hostname: Our example will use “BackupServer”

Your actual setup will vary from the example, so be sure to make substitutions where appropriate.

We will need to set a password, that will allow the Bacula Director to connect, in the File Daemon configuration. Let’s generate a random password now (or you can skip this step and make up your own password):

date +%s | sha256sum | base64 | head -c 33 ; echo

You will want to copy the output, as you will use it in the next step.

Open the File Daemon configuration:

sudo vi /etc/bacula/bacula-fd.conf

We need to change a few items and save some information that we will need for our server configuration.

Begin by finding the Director resource that is named “ClientHost-dir”. As the Bacula Director that we want to control this Client is located on the Bacula Server, change the “Name” parameter to the hostname of your backup server followed by “-dir”. Also, replace the existing password with the one you generated in the previous step. It should look something like this after being updated:

Director {
  Name = BackupServer-dir
  Password = "Y2Q5ODUyMWM0YTFhYjA3NTcwYmU5OTA4Y"
}

Be sure to keep the password handy. It will be used in the Backup Server’s Director configuration, which we will set in an upcoming step, to connect to your Client’s File Daemon.

Next, we need to adjust one parameter in the FileDaemon resource. We will change the FDAddress parameter to match the private FQDN of our client machine. The Name parameter should already be populated correctly with the client file daemon name. The resource should looks something like this (substitute the actual FQDN or IP address):

FileDaemon {                          # this is me
  Name = ClientHost-fd
  FDAddress = client_private_ip
  FDport = 9102                  # where we listen for the director
  WorkingDirectory = /var/spool/bacula
  Pid Directory = /var/run
  Maximum Concurrent Jobs = 20
}

We also need to configure this daemon to pass its log messages to the Backup Server. Find the Messages resource and change the director parameter to match your backup server’s hostname with a “-dir” suffix. It should look something like this:

Messages {
  Name = Standard
  director =  BackupServer-dir = all, !skipped, !restored
}

Save the file and exit. Your File Daemon (Bacula Client) is now configured to listen for connections over the private network.

Check that your configuration file has the correct syntax with the following command:

sudo bacula-fd -tc /etc/bacula/bacula-fd.conf

If the command returns no output, the configuration file has valid syntax. Restart the file daemon to use the new settings:

sudo systemctl restart bacula-fd

Then run the following command to start the Bacula File Daemon automatically on boot:

sudo systemctl enable bacula-fd

Let’s set up a directory that the Bacula Server can restore files to. Create the file structure and lock down the permissions and ownership for security with the following commands:

sudo mkdir -p /bacula/restore
sudo chown -R bacula:bacula /bacula
sudo chmod -R 700 /bacula

The client machine is now configured correctly. Next, we will configure the Backup Server to be able to connect to the Bacula Client.

A Client resource configures the Director with the information it needs to connect to the Client Host. This includes the name, address, and password of the Client’s File Daemon.

Paste this Client resource definition into the file. Be sure to substitute in your Client hostname, private FQDN, and password (from the Client’s bacula-fd.conf), where highlighted:

Client {
  Name = ClientHost-fd
  Address = client_private_FQDN
  FDPort = 9102 
  Catalog = MyCatalog
  Password = "Y2Q5ODUyMWM0YTFhYjA3NTcwYmU5OTA4Y"          # password for Remote FileDaemon
  File Retention = 30 days            # 30 days
  Job Retention = 6 months            # six months
  AutoPrune = yes                     # Prune expired Jobs/Files
}

You only need to do this once for each Client.

A Backup job, which must have a unique name, defines the details of which Client and which data should be backed up.

Next, paste this backup job into the file, substituting the Client hostname for the highlighted text:

Job {
  Name = "BackupClientHost"
  JobDefs = "DefaultJob"
  Client = ClientHost-fd
  Pool = RemoteFile
  FileSet="Home and Etc"
}

This creates a backup job called “BackupClientHost”, which will back up the home and etc directories of the Client Host, as defined in the “Home and Etc” FileSet. It will use the settings specified in the “DefaultJob” JobDefs and “RemoteFile” Pool resources, which are both defined in the main bacula-dir.conf file. By default, jobs that specify JobDefs = "DefaultJob" will run weekly.

Save and exit when you are done.

Let’s verify that there are no syntax errors in your Director configuration file:

sudo bacula-dir /etc/bacula/bacula-dir.conf

If you are returned to the shell prompt, there are no syntax errors in your Bacula Director’s configuration files.

To put the configuration changes that you made into effect, restart Bacula Director:

sudo systemctl restart bacula-dir

Now your Client, or remote host, is configured to be backed up by your Bacula Server.

After running a job, Bacula will tell you that you have messages. The messages are output generated by running jobs.

Check the messages by typing:

messages

The messages should say “No prior Full backup Job record found”, and that the backup job started. If there are any errors, something is wrong, and they should give you a hint as to why the job did not run.

Another way to see the status of the job is to check the status of the Director. To do this, enter this command at the bconsole prompt:

status director

If everything is working properly, you should see that your job is running or terminated with an “OK” status.

As with backup jobs, you should check the messages and Director status after running a restore job.

Check the messages by typing:

messages

There should be a message that says the restore job has started or was terminated with an “Restore OK” status. If there are any errors, something is wrong, and they should give you a hint as to why the job did not run.

Again, checking the Director status is a great way to see the state of a restore job:

status director

When you are finished with the restore, type exit to leave the Bacula Console:

exit

If everything worked properly, your restored files will be on your Client host, in the /bacula/restore directory. If you were simply testing the restore process, you should delete the contents of that directory.