Wednesday, January 20, 2016

How to install and configure Bacula Backup Server on Centos


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.


at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)