Bacula is an open source network backup solution that allows you create backups and perform data recovery of your computer systems. It is very flexible and robust, which makes it, while slightly cumbersome to configure, suitable for backups in many situations. A backup system is an important component in most server infrastructures, as recovering from data loss is often a critical part of disaster recovery plans.
In
this tutorial, we will show you how to install and configure the server
components of Bacula on a CentOS 7 server. We will configure Bacula to perform
a weekly job that creates a local backup (i.e. a backup of its own host). This,
by itself, is not a particularly compelling use of Bacula, but it will provide
you with a good starting point for creating backups of your other servers, i.e.
the backup clients. The next tutorial in this series will cover creating
backups of your other, remote, servers by installing and configuring the Bacula
client, and configuring the Bacula server.
Prerequisites:
You
must have superuser (sudo) access on a CentOS 7 server. Also, the server will
require adequate disk space for all of the backups that you plan on retaining
at any given time.
If
you are using DigitalOcean, you should enable Private Networking on
your Bacula server, and all of your client servers that are in the same
datacenter region. This will allow your servers to use private networking when
performing backups, reducing network overhead.
We
will configure Bacula to use the private FQDN of our servers, e.g. bacula.example.com. If
you don't have a DNS setup, use the appropriate IP addresses instead. If you
don't have private networking enabled, replace all network connection
information in this tutorial with network addresses that are reachable by servers
in question (e.g. public IP addresses or VPN tunnels).
The
last assumption is that SELinux is disabled or you are able to troubleshoot
SELinux-related issues on your own.
Let's
get started by looking at an overview of Bacula's components.
Bacula Component
Overview:
Although
Bacula is composed of several software components, it follows the server-client
backup model; to simplify the discussion, we will focus more on the backup
server and the backup clients than the individual
Bacula components. Still, it is important to have cursory knowledge of the
various Bacula components, so we will go over them now.
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
Note: The Bacula server components don't need to run on the same server, but they all work together to provide the backup server functionality.
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".
As
we noted in the introduction, we will configure the backup server to create a
backup of its own filesystem. This means that the backup server will also be a
backup client, and will run the File Daemon component.
Let's
get started with the installation.
Install Bacula and
MySQL
Bacula
uses an SQL database, such as MySQL or PostreSQL, to manage its backups
catalog. We will use MariaDB, a drop-in replacement for MySQL, in this
tutorial.
Install
the Bacula and MariaDB Server packages with yum:
sudo
yum install -y bacula-director bacula-storage bacula-console bacula-client
mariadb-server
When
the installation is complete, we need to start MySQL with the following
command:
sudo
systemctl start mariadb
Now
that MySQL (MariaDB) is installed and running, let's create the Bacula database
user and tables, with these scripts:
/usr/libexec/bacula/grant_mysql_privileges
/usr/libexec/bacula/create_mysql_database
-u root
/usr/libexec/bacula/make_mysql_tables
-u bacula
Next,
we want to run a simple security script that will remove some dangerous
defaults and lock down access to our database system a little bit. Start the
interactive script by running:
sudo
mysql_secure_installation
The
prompt will ask you for your current root password. Since you just installed
MySQL, you most likely won’t have one, so leave it blank by pressing enter.
Then the prompt will ask you if you want to set a root password. Go ahead and
hit Enter, and set the password. For the rest of the questions, you should simply
hit the Enter key through each prompt to accept the default values.
This will remove some sample users and databases, disable remote root logins,
and load these new rules so that MySQL immediately respects the changes we have
made.
Now
we need to set the password for the Bacula database user.
Enter
the MySQL console, as the root MySQL user:
mysql
-u root -p
Enter
the MySQL root password, that you just set, at the prompt.
Now
set the password for the Bacula database user. Use this command, but replace
the highlighted "baculadbpassword" with strong password:
UPDATE
mysql.user SET Password=PASSWORD('bacula_db_password') WHERE User='bacula';
FLUSH
PRIVILEGES;
Once
you're done here, exit the MySQL prompt:
exit
Enable
MariaDB to start on boot. Use the following command to do so:
sudo
systemctl enable mariadb
Set Bacula to Use MySQL Library
By
default, Bacula is set to use the PostgreSQL library. Because we are using MySQL,
we need to set it to use the MySQL library instead.
Run
this command:
sudo
alternatives --config libbaccats.so
You
will see the following prompt. Enter 1 (MySQL):
Output
There
are 3 programs which provide 'libbaccats.so'.
Selection
Command
-----------------------------------------------
1
/usr/lib64/libbaccats-mysql.so
2
/usr/lib64/libbaccats-sqlite3.so
*+
3
/usr/lib64/libbaccats-postgresql.so
Enter
to keep the current selection[+], or type selection number: 1
The
Bacula server (and client) components are now installed. Let's create the
backup and restore directories.
Create Backup and
Restore Directories
Bacula
needs a backup directory—for storing backup archives—and restore directory—where
restored files will be placed. If your system has multiple partitions, make
sure to create the directories on one that has sufficient space.
Let's
create new directories for both of these purposes:
sudo
mkdir -p /bacula/backup /bacula/restore
We
need to change the file permissions so that only the bacula process (and a
superuser) can access these locations:
sudo
chown -R bacula:bacula /bacula
sudo
chmod -R 700 /bacula
Now
we're ready to configure the Bacula Director.
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
Configure Director Resource
Find
the Director resource, and configure it to listen on 127.0.0.1 (localhost),
by adding the DirAddressline shown here:
bacula-dir.conf
— Add Director DirAddress
Director
{ # define
myself
Name = bacula-dir
DIRport = 9101 # where we listen for UA
connections
QueryFile = "/etc/bacula/query.sql"
WorkingDirectory =
"/var/spool/bacula"
PidDirectory = "/var/run"
Maximum Concurrent Jobs = 1
Password = "@@DIR_PASSWORD@@" # Console password
Messages = Daemon
DirAddress
= 127.0.0.1
}
Now
move on to the rest of the file.
Configure Local Jobs
A
Bacula job is used to perform backup and restore actions. Job resources define
the details of what a particular job will do, including the name of the Client,
the FileSet to back up or restore, among other things.
Here,
we will configure the jobs that will be used to perform backups of the local
filesystem.
In
the Director configuration, find the Job resource with a name
of "BackupClient1" (search for "BackupClient1"). Change the
value of Name to "BackupLocalFiles", so it looks like
this:
bacula-dir.conf
— Rename BackupClient1 job
Job
{
Name = "BackupLocalFiles"
JobDefs = "DefaultJob"
}
Next,
find the Job resource that is named "RestoreFiles"
(search for "RestoreFiles"). In this job, you want to change two
things: update the value of Name to "RestoreLocalFiles", and the value
of Where to
"/bacula/restore". It should look like this:
bacula-dir.conf
— Rename RestoreFiles job
Job
{
Name = "RestoreLocalFiles"
Type = Restore
Client=BackupServer-fd
FileSet="Full Set"
Storage = File
Pool = Default
Messages = Standard
Where = /bacula/restore
}
This
configures the RestoreLocalFiles job to restore files to /bacula/restore, the
directory we created earlier.
Configure File Set
A
Bacula FileSet defines a set of files or directories to include or exclude files
from a backup selection, and are used by jobs.
Find
the FileSet resource named "Full Set" (it's under a comment that
says, "# List of files to be backed up"). Here we will make three
changes: (1) Add the option to use gzip to compress our backups, (2) change the
include File from /usr/sbin to /, and (3) add File
= /bacula under the Exclude section. With
the comments removed, it should look like this:
bacula-dir.conf
— Update "Full Set" FileSet
FileSet
{
Name = "Full Set"
Include {
Options {
signature = MD5
compression
= GZIP
}
File
= /
}
Exclude
{
File = /var/lib/bacula
File = /proc
File = /tmp
File = /.journal
File = /.fsck
File =
/bacula
}
}
Let's
go over the changes that we made to the "Full Set" FileSet. First, we
enabled gzip compression when creating a backup archive. Second, we are
including /, i.e. the root partition, to be backed up. Third, we are
excluding /bacula because we don't want to redundantly back up our
Bacula backups and restored files.
Note:
If you have partitions that are mounted within /, and you want to include those
in the FileSet, you will need to include additional File records for each of
them.
Keep
in mind that if you always use broad FileSets, like "Full Set", in
your backup jobs, your backups will require more disk space than if your backup
selections are more specific. For example, a FileSet that only includes your
customized configuration files and databases might be sufficient for your
needs, if you have a clear recovery plan that details installing required
software packages and placing the restored files in the proper locations, while
only using a fraction of the disk space for backup archives.
Configure Storage Daemon Connection
In
the Bacula Director configuration file, the Storage resource defines the
Storage Daemon that the Director should connect to. We'll configure the actual
Storage Daemon in just a moment.
Find
the Storage resource, and replace the value of Address, localhost, with the
private FQDN (or private IP address) of your backup server. It should look like
this (substitute the highlighted word):
bacula-dir.conf
— Update Storage Address
Storage
{
Name = File
#
Do not use "localhost" here
Address = backup_server_private_FQDN #
N.B. Use a fully qualified name here
SDPort = 9103
Password = "@@SD_PASSWORD@@"
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.
Configure Catalog Connection
In
the Bacula Director configuration file, the Catalog resource defines where the
Database that the Director should use and connect to.
Find
the Catalog resource named "MyCatalog" (it's under a comment that
says "Generic catalog service"), and update the value of dbpassword so it
matches the password you set for the bacula MySQL user:
bacula-dir.conf
— Update Catalog dbpassword
#
Generic catalog service
Catalog
{
Name = MyCatalog
#
Uncomment the following line if you want the dbi driver
#
dbdriver = "dbi:postgresql"; dbaddress = 127.0.0.1; dbport =
dbname = "bacula"; dbuser =
"bacula"; dbpassword = "bacula_db_password"
}
This
will allow the Bacula Director to connect to the MySQL database.
Configure Pool
A
Pool resource defines the set of storage used by Bacula to write backups. We
will use files as our storage volumes, and we will simply update the label so
our local backups get labeled properly.
Find
the Pool resource named "File" (it's under a comment that says
"# File Pool definition"), and add a line that specifies a Label
Format. It should look like this when you're done:
bacula-dir.conf
— Update Pool:
#
File Pool definition
Pool
{
Name = File
Pool Type = Backup
Label
Format = Local-
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. You're finally done configuring the Bacula Director.
Check 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
there are no error messages, your bacula-dir.conf file has no syntax errors.
Next,
we'll configure the Storage Daemon.
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 theSDAddress parameter, and assign it to the private FQDN (or
private IP address) of your backup server:
bacula-sd.conf
— update SDAddress
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
}
Configure Storage Device
Next,
find the Device resource named "FileStorage" (search for "FileStorage"),
and update the value ofArchive Device to match your backups directory:
bacula-sd.conf
— update Archive Device
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.
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.
We've
completed the Bacula configuration. We're ready to restart the Bacula server components.
Set Bacula Component Passwords
Each
Bacula component, such as the Director, SD, and FD, have passwords that are
used for inter-component authentication—you probably noticed placeholders while
going through the configuration files. It is possible to set these passwords
manually but, because you don't actually need to know these passwords, we'll
run commands to generate random passwords and insert them into the various
Bacula configuration files.
These
commands generate and set the Director password. The bconsole connects
to the Director, so it needs the password too:
DIR_PASSWORD=`date
+%s | sha256sum | base64 | head -c 33`
sudo
sed -i "s/@@DIR_PASSWORD@@/${DIR_PASSWORD}/"
/etc/bacula/bacula-dir.conf
sudo
sed -i "s/@@DIR_PASSWORD@@/${DIR_PASSWORD}/"
/etc/bacula/bconsole.conf
These
commands generate and set the Storage Daemon password. The Director connects to
the SD, so it needs the password too:
SD_PASSWORD=`date
+%s | sha256sum | base64 | head -c 33`
sudo
sed -i "s/@@SD_PASSWORD@@/${SD_PASSWORD}/" /etc/bacula/bacula-sd.conf
sudo
sed -i "s/@@SD_PASSWORD@@/${SD_PASSWORD}/"
/etc/bacula/bacula-dir.conf
These
commands generate and set the local File Daemon (the Bacula client software)
password. The Director connects to this FD, so it needs the password too:
FD_PASSWORD=`date
+%s | sha256sum | base64 | head -c 33`
sudo
sed -i "s/@@FD_PASSWORD@@/${FD_PASSWORD}/"
/etc/bacula/bacula-dir.conf
sudo
sed -i "s/@@FD_PASSWORD@@/${FD_PASSWORD}/" /etc/bacula/bacula-fd.conf
Now
we're ready to start our Bacula components!
Start Bacula Components
Start
the Bacula Director, Storage Daemon, and local File Daemon with these commands:
sudo
systemctl start bacula-dir
sudo
systemctl start bacula-sd
sudo
systemctl start bacula-fd
If
they all started correctly, run these commands so they start automatically on
boot:
sudo
systemctl enable bacula-dir
sudo
systemctl enable bacula-sd
sudo
systemctl enable bacula-fd
Let's
test that Bacula works by running a backup job.
Test Backup Job
We
will use the Bacula Console to run our first backup job. If it runs without any
issues, we will know that Bacula is configured properly.
Now
enter the Console with this command:
sudo
bconsole
This
will take you to the Bacula Console prompt, denoted by a * prompt.
Create a Label
Begin by issuing a label command:
label
You
will be prompted to enter a volume name. Enter any name that you want:
Enter
new Volume name:
MyVolume
Then
select the pool that the backup should use. We'll use the "File" pool
that we configured earlier, by entering "2":
Select
the Pool (1-3):
2
Manually Run Backup Job
Bacula
now knows how we want to write the data for our backup. We can now run our
backup to test that it works correctly:
run
You
will be prompted to select which job to run. We want to run the
"BackupLocalFiles" job, so enter "1" at the prompt:
Select
Job resource (1-3):
1
At
the "Run Backup job" confirmation prompt, review the details, then
enter "yes" to run the job:
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.
Something like this:
Output
— status director (Running Jobs)
Running
Jobs:
Console
connected at 09-Apr-15 12:16
JobId Level
Name Status
=============================================================
3 Full
BackupLocalFiles.2015-04-09_12.31.41_06 is running
When
your job completes, it will move to the "Terminated Jobs" section of
the status report, like this:
Output
— status director (Terminated Jobs)
Terminated
Jobs:
JobId Level
Files Bytes Status
Finished Name
===============================================================
3
Full 161,124 877.5 M
OK 09-Apr-15 12:34 BackupLocalFiles
The
"OK" status indicates that the backup job ran without any problems.
Congratulations! You have a backup of the "Full Set" of your Bacula
server.
The
next step is to test the restore job.
Test Restore Job
Now
that a backup has been created, it is important to check that it can be
restored properly. Therestore command will allow us restore files that were backed
up.
Run Restore All Job
To
demonstrate, we'll restore all of the files in our last backup:
restore
all
A
selection menu will appear with many different options, which are used to
identify which backup set to restore from. Since we only have a single backup,
let's "Select the most recent backup"—select option 5:
Select
item (1-13):
5
Because
there is only one client, the Bacula server, it will automatically be selected.
The
next prompt will ask which FileSet you want to use. Select "Full
Set", which should be 2:
Select
FileSet resource (1-2):
2
This
will drop you into a virtual file tree with the entire directory structure that
you backed up. This shell-like interface allows for simple commands to mark and
unmark files to be restored.
Because
we specified that we wanted to "restore all", every backed up file is
already marked for restoration. Marked files are denoted by a leading * character.
If
you would like to fine-tune your selection, you can navigate and list files
with the "ls" and "cd" commands, mark files for restoration
with "mark", and unmark files with "unmark". A full list of
commands is available by typing "help" into the console.
When
you are finished making your restore selection, proceed by typing:
done
Confirm
that you would like to run the restore job:
OK
to run? (yes/mod/no):
Yes
Check Messages and 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
Verify Restore
To
verify that the restore job actually restored the selected files, you can look
in the /bacula/restoredirectory (which was defined in the
"RestoreLocalFiles" job in the Director configuration):
sudo
ls -la /bacula/restore
You
should see restored copies of the files in your root file system, excluding the
files and directories that were listed in the "Exclude" section of
the "RestoreLocalFiles" job. If you were trying to recover from data
loss, you could copy the restored files to their appropriate locations.
Delete Restored Files
You
may want to delete the restored files to free up disk space. To do so, use this
command:
sudo
-u root bash -c "rm -rf /bacula/restore/*"
Note
that you have to run this rm command as root, as many of the restored files are
owned by root.
Conclusion
You
now have a basic Bacula setup that can backup and restore your local file
system. The next step is to add your other servers as backup clients so you can
recover them, in case of data loss.
Bacula
has been successfully installed and configured. You can now add clients, jobs
and volumes by updating the bacula config files. Alternatively you can
use webmin to make the work more simple. It is quite easier
then updating the config files manually.
Manage Bacula with
Webmin
Webmin
is a web-based interface for system administration for Unix. Using any modern
web browser, you can setup user accounts, Apache, DNS, file sharing and much
more.
Download
and install the latest version of webmin from here.
wget http://sourceforge.net/projects/webadmin/files/webmin/1.770/webmin-1.770.tar.gz/download
tar zxvf webmin-1.7.tar.gz
cd webmin-1.770/
./setup.sh
Access
Webmin
Now
you can login through webmin by “//http://server-ip-address:10000” or “http://domain-name:10000/”.
Next
step will show you how to add your other, remote servers as Bacula
clients:
Organize Bacula Director Configuration (Server)
On
your Bacula Server, perform this section once.
When
setting up your Bacula Server, you may have noticed that the configuration
files are excessively long. We'll try and organize the Bacula Director
configuration a bit, so it uses separate files to add new configuration such as
jobs, file sets, and pools.
Let's
create a directory to help organize the Bacula configuration files:
sudo
mkdir /etc/bacula/conf.d
Then
open the Bacula Director configuration file:
sudo
vi /etc/bacula/bacula-dir.conf
At
the end of the file add, this line:
bacula-dir.conf
— Add to end of file
@|"find
/etc/bacula/conf.d -name '*.conf' -type f -exec echo @{} \;"
Save
and exit. This line makes the Director look in the /etc/bacula/conf.d directory
for additional configuration files to append. That is, any .conf file added in
there will be loaded as part of the configuration.
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.
Open
the conf.d/pools.conf file:
sudo
vi /etc/bacula/conf.d/pools.conf
Add
the following Pool resource:
conf.d/pools.conf
— Add 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.
Install and Configure Bacula Client
Perform
this section on any Client Host that you are adding to your
Bacula setup.
Then
install the bacula-client package:
sudo
yum install bacula-client
This
installs the Bacula File Daemon (FD), which is often referred to as the
"Bacula client".
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 tutorial:
Client
hostname:: Our example will use
"ClientHost"
Client
Private FQDN: We'll refer to this as
"client_private_FQDN", which may look likeclienthost.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:
bacula-fd.conf
— Update Director Name and Password
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 FDAddressparameter 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):
bacula-fd.conf
— Update Name and Add FDAddress
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:
bacula-fd.conf
— Update director
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.
Add FileSets (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.
If
you followed the prerequisite tutorial, which sets up the 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 show you how to create new FileSet resources, so that you can be more
selective in what you back up.
On
your Bacula Server, open a file called filesets.conf, in the
Bacula Director configuration directory we created earlier:
sudo
vi /etc/bacula/conf.d/filesets.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:
filesets.conf
— Add Home and Etc FileSet
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.
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.
Open
the conf.d/clients.conf file:
sudo
vi /etc/bacula/conf.d/clients.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), where
highlighted:
conf.d/clients.conf
— Add Client resource
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.
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, substituting the Client hostname for the
highlighted text:
conf.d/clients.conf
— Add Backup job resource
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.
Verify Director Configuration
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.
Restart Bacula Director
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.
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.
Perform Restore
The
first time you set up a new Bacula Client, you should test that the restore
works properly.
If
you want to perform a restore, use the restore command at the Bacula Console:
restore
all
A
selection menu will appear with many different options, which are used to
identify which backup set to restore from. Since we only have a single backup,
let's "Select the most recent backup"—
select
option 5:
Select
item (1-13):
5
Then
you must specify which Client to restore. We want to restore the remote host
that we just set up, e.g. "ClientHost-fd":
Select
the Client: ClientHost-fd
Defined
Clients:
1: BackupServer-fd
2: ClientHost-fd
Select
the Client (1-2): 2
This
will drop you into a virtual file tree with the entire directory structure that
you backed up. This shell-like interface allows for simple commands to mark and
unmark files to be restored.
Because
we specified that we wanted to "restore all", every backed up file is
already marked for restoration. Marked files are denoted by a leading * character.
If
you would like to fine-tune your selection, you can navigate and list files
with the "ls" and "cd" commands, mark files for restoration
with "mark", and unmark files with "unmark". A full list of
commands is available by typing "help" into the console.
When
you are finished making your restore selection, proceed by typing:
done
Confirm
that you would like to run the restore job:
OK
to run? (yes/mod/no):
Yes
Check Messages and 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/restoredirectory. If you were simply testing the restore process,
you should delete the contents of that directory.
Conclusion
You
now have a Bacula Server that is backing up files from a remote Bacula Client.
Be sure to review and revise your configuration until you are certain that you
are backing up the correct FileSets, on a schedule that meets your needs.
The
next thing you should do is repeat the relevant sections of this tutorial for
any additional CentOS 7 servers that you want to back up.
