Bacula Lab

In this lab, you will backup and restore files using a Bacula. For this practical we need 2 Machines, Bacula Server and a Bacula Client. Download BackupServer_VM and ClientHost_VM from below links.

BackUp Server=>​https://docs.learn.ac.lk/index.php/s/3dN0PPWbJOqCR0k
Client Host =>​https://docs.learn.ac.lk/index.php/s/ze90jc3LzYa15A9

Install Bacula Server in Bacula_VM

A Bacula server, which we will also refer to as the “backup server”, has these components:

Bacula Director (DIR): Software that controls the backup and restore operations that are performed by the File and Storage daemons

Storage Daemon (SD): Software that performs reads and writes on the storage devices used for backups

Catalog: Services that maintain a database of files that are backed up. The database is stored in an SQL database such as MySQL or PostgreSQL

Bacula Console: A command-line interface that allows the backup administrator to interact with, and control, Bacula Director

Set the time zone

sudo timedatectl set-timezone Asia/Colombo

Set the IP addresses

In case if bridging adapter setting is not working with your Virtual box,make the Adapter 1 as NAT and please add a 2nd adapter as Host-Only adapter for both Backup Server and Client-Host. Then set the IP addresses as below.

For the Backup Server

sudo vim /etc/netplan/00-installer-config.yaml

network:
  ethernets:
    enp0s3:
      dhcp4: true
    enp0s8:
      dhcp4: false
      addresses:
         - 192.168.56.105/24
  version: 2

sudo netplan apply

For the Client-Host

sudo vim /etc/netplan/00-installer-config.yaml

network:
  ethernets:
    enp0s3:
      dhcp4: true
    enp0s8:
      dhcp4: false
      addresses:
         - 192.168.56.106/24
  version: 2

sudo netplan apply

Now check the connectivity between Server and client and it should success.

ping 192.168.56.106

Install postgresql Database in Backup Server

sudo apt-get update -y
sudo apt install postgresql
sudo systemctl start postgresql
sudo systemctl enable postgresql

Install Bacula in Backup Server

sudo apt-get install bacula -y

While installing Bacula, you will be asked to configure Postfix.Pick "No configuration" under General Type of Mail Configuration.

If prompted for 'Configure database for bacula-director-postgresql with dbconfig-common?' Enter "Yes." For 'Password of the database's administrative user,set the password as 1234.

Screen shots

Configure Bacula Director

Bacula has several components that must be configured independently in order to function correctly. The configuration files can all be found in the /etc/bacula directory.

We’ll start with the Bacula Director.

Open the Bacula Director configuration file in your favorite text editor. We’ll use vi:

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

This is the main configuration file of Bacula and we will modify this file later according our Lab setup.

Create Backup and Restore Directories and assign permission

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

Now we start configuring Client Side

Install Bacula Client in Client Machine

A Bacula client, i.e. a server that will be backed up, runs the File Daemon (FD) component. The File Daemon is software that provides the Bacula server (the Director, specifically) access to the data that will be backed up. We will also refer to these servers as “backup clients” or “clients”.

Install and Configure Bacula Client

sudo apt-get update
sudo apt-get install bacula-client

you can verify your installation by executing

sudo systemctl status bacula-fd

if the service is not running

sudo systemctl start bacula-fd
sudo systemctl enable bacula-fd

Configure Client

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

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 or private IP address

Bacula Server hostname: Our example will use “BackupServer”

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

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.

change the “Name” parameter to the hostname of your backup server followed by “-dir”.

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

You also need to copy the Password, which is the automatically generated password used for connections to File Daemon, and save it for future reference. This 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
  FDport = 9102                       # where we listen for the director
  WorkingDirectory = /var/lib/bacula
  Pid Directory = /var/run/bacula
  Maximum Concurrent Jobs = 20
  FDAddress = client_private_FQDN / Private IP
}

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 BackupServer-dir 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 service bacula-fd restart

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

Add FileSets (Bacula Server)

A Bacula FileSet defines a set of files or directories to include or exclude files from a backup selection, and are used by backup jobs on the Bacula Server. With the default Bacula Server components, you already have a FileSet called “Full Set”. If you want to run Backup jobs that include almost every file on your Backup Clients, you can use that FileSet in your jobs. You may find, however, that you often don’t want or need to have backups of everything on a server, and that a subset of data will suffice.

Being more selective in which files are included in a FileSet will decrease the amount of disk space and time, required by your Backup Server, to run a backup job. It can also make restoration simpler, as you won’t need to sift through the “Full Set” to find which files you want to restore.

We will create new FileSet resources, so that you can be more selective in what you back up.

On your Bacula Server, open bacula-dir.conf,

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

Create a FileSet resource for each particular set of files that you want to use in your backup jobs. In this example, we’ll create a FileSet that only includes the home and etc directories:

FileSet {
  Name = "Home and Etc"
  Include {
    Options {
      signature = MD5
      compression = GZIP
    }
    File = /home
    File = /etc
  }
  Exclude {
    File = /home/bacula/not_important
  }
}

There are a lot of things going on in this file, but here are a few details to keep in mind:

The FileSet Name must be unique

Include any files or partitions that you want to have backups of

Exclude any files that you don’t want to back up, but were selected as a result of existing within an included file

You can create multiple FileSets if you wish. Save and exit, when you are finished.

Configure Storage Daemon

Our Bacula server is almost set up, but we still need to configure the Storage Daemon, so Bacula knows where to store backups.

Open the SD configuration in your favorite text editor. We’ll use vi:

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

Configure Storage Resource

Find the Storage resource. This defines where the SD process will listen for connections. Add the SDAddress parameter, and assign it to the private FQDN (or private IP address) of your backup server:

Storage {                             # definition of myself
  Name = BackupServer-sd
  SDPort = 9103                  # Director's port
  WorkingDirectory = "/var/lib/bacula"
  Pid Directory = "/var/run/bacula"
  Maximum Concurrent Jobs = 20
  SDAddress = backup_server_private_FQDN / Private IP
}

Configure Storage Device

Next, find the Device resource section of the file and add following “FileStorage” to the config file.

Device {
  Name = FileStorage
  Media Type = File
  Archive Device = /bacula/backup 
  LabelMedia = yes;                   # lets Bacula label unlabeled media
  Random Access = Yes;
  AutomaticMount = yes;               # when device opened, read it
  RemovableMedia = no;
  AlwaysOpen = no;
}

Save and Exit.

Configure Storage Daemon Connection

open bacula-dir.conf again.

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

In the Bacula Director configuration file, the Storage resource defines the Storage Daemon that the Director should connect to. We have configured the actual Storage Daemon in previous step.

Now we need to add Storage resource to director, add following lines to bacula-dir.conf and replace the value of Address, localhost, with the private FQDN (or private IP address) of your backup server (add these lines after the auto charger section). It should look like this (substitute the password--you can copy it from auto charger section):

Storage {
  Name = File
# Do not use "localhost" here
  Address = backup_server_private_FQDN / private IP     # N.B. Use a fully qualified name here
  SDPort = 9103
  Password = "ITXAsuVLi1LZaSfihQ6Q6yUCYMUssdmu_"
  Device = FileStorage
  Media Type = File
}

This is necessary because we are going to configure the Storage Daemon to listen on the private network interface, so remote clients can connect to it.

Verify Storage Daemon Configuration

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

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

If there are no error messages, your bacula-sd.conf file has no syntax errors.

Restart Bacula Director and Storage Daemon

To put the configuration changes that you made into effect, restart Bacula Director and Storage Daemon with these commands:

sudo service bacula-director restart
sudo service bacula-sd restart

Add RemoteFile Pool

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

sudo vi /etc/bacula/bacula-dir.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

Now we’re ready to create backup job that will use our new FileSet.

Add Client and Backup Job to Bacula Server

Now we’re ready to add our Client to the Bacula Server. To do this, we must configure the Bacula Director with new Client and Job resources.

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

Add Client Resource

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).

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

Create a backup job:

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,

Job {
  Name = "BackupClientHost"
  JobDefs = "DefaultJob"
  Client = ClientHost-fd
  Pool = RemoteFile
  Storage = File
  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.

Create a Restore job:

Job {
  Name = "RestoreClientHost"
  Type = Restore
  Client=ClientHost-fd
  Storage = File
# The FileSet and Pool directives are not used by Restore Jobs
# but must not be removed
  FileSet="Home and Etc"
  Pool = RemoteFile
  Messages = Standard
  Where = /bacula/restore
}

Verify Director Configuration

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

sudo bacula-dir -tc /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.

Restart Bacula Director

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

sudo service bacula-director restart

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

Test Client Connection

We should verify that the Bacula Director can connect to the Bacula Client.

On your Bacula Server, enter the Bacula Console:

sudo bconsole
*status client

Select Client resource: ClientHost-fd
The defined Client resources are:
     1: BackupServer-fd
     2: ClientHost-fd
Select Client (File daemon) resource (1-2): 2

The Client’s File Daemon status should return immediately. If it doesn’t, and there is a connection error, there is something wrong with the configuration of the Bacula Server or of the Client’s File Daemon.

Test Backup Job

Let’s run the backup job to make sure it works. On the Bacula Server, while still in the Console, use this command:

*run

You will be prompted to select which Job to run. Select the one we created earlier,

e.g. “4. BackupClientHost”:

Select Job resource: BackupClientHost
The defined Job resources are:
     1: BackupLocalFiles
     2: BackupCatalog
     3: RestoreLocalFiles
     4: BackupClientHost
Select Job resource (1-4): 4

At the confirmation prompt, enter “yes”:

Confirmation prompt:
OK to run? (yes/mod/no): yes

Check Messages and Status 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.