General security

Data Backups with Bacula: Mobile Devices

Introduction

Bacula was specifically designed for backup jobs in a server environment, where servers have IP addresses that don't change regularly and are always up and running. Mobile devices usually connect to the network by using a cable (when an employee comes to the office) or through a VPN (when an employee connects to the corporate environment from home). Bacula works by a director initiating the connection with a file daemon on a regular basis, instructing it to send the data to a storage daemon. The communication between the mobile device and storage daemon is usually not problematic, since we only need to open TCP port 9103 to allow the mobile device to connect to the storage daemon.

The problems occur when the mobile device is not present in the network and director wants to connect to it to instruct it to backup certain files. The problem is that the mobile device is not present at that time, which results in connection timeout on director's endpoint. To solve the problem, the mobile device file daemon must initiate the connection with the director by notifying it about its presence. The best way to do that is by allowing the client to connect to the director by using bconsole and issuing the relevant commands to initiate the backup.

FREE role-guided training plans

Get 12 cybersecurity training plans — one for each of the most common roles requested by employers.

Download Now

We have to configure Bacula to use an empty schedule on the mobile device job in order to avoid failed backup attempts. We can do that by creating the Schedule definition block, which only has Name element defined without the Run element. Next we have to reference that schedule element in Job definition as presented below. This will ensure that backup will never be initiated from Bacula director, thus preventing errors when mobile device is not accessible.

[plain]

Job {

Name = "MyClient"

JobDefs = "DefaultJobClients"

Client = myclient-fd

FileSet = "FilesMyClient"

Pool = PoolMyClient

Schedule = "EmptyCycle"

}

Schedule {

Name = "EmptyCycle"

}

[/plain]

We disabled the backup being initiated by the Bacula director, which is normally responsible for running the backup. Therefore, its the client's responsibility to run the backup whenever it's plugged into the network. In order to do that, we have to allow the client to access the director via bconsole. In order to do that, we have to add the Console element to the bacula-dir.conf configuration file as presented below.

[plain]

Console {

Name = myclient

Password = "b.n2?,.)FU]$/,i`|lD8NZ79k.8xykOeqNjy8z"

CatalogACL = MyCatalog

CommandACL = run, status

ClientACL = MyClient

JobACL = MyClient

PoolACL = PoolMyClient

StorageACL = File

FileSetACL = FilesMyClient

}

Console {

Name = myclient

Password = "b.n2?,.)FU]$/,i`|lD8NZ79k.8xykOeqNjy8z"

CatalogACL = MyCatalog

CommandACL = status, .status, list

JobACL = *all*

}

[/plain]

The Name and Password configuration options must match the ones specified in the bconsole.conf configuration file on the client, which is presented below. Note that the password specified by the Director block is not an actual password and it shouldn't be – it's dangerous to use it on the client side, since the client then has complete control over the Bacula director. Only the password to Console block must be correct in order for client to be able to do certain actions according to the configuration ACL lines.

[plain]

Director {

Name = baculaserver-dir

DIRport = 9101

address = baculaserverbox

Password = "NotMyPassword"

}

Console {

Name = myclient

Password = "b.n2?,.)FU]$/,i`|lD8NZ79k.8xykOeqNjy8z"

}

[/plain]

The following ACL configuration options are supported in the Console element block:

JobACL: specify a list of job resource names that can be accessed by the console.
ClientACL: specify a list of client resource names that can be accessed by the console.
StorageACL: specify a list of storage resource names that can be accessed by the console.
ScheduleACL: specify a list of schedule resource names that can be accessed by the console.
PoolACL: specify a list of pool resource names that can be accessed by the console.
FileSetACL: specify a list of fileset resource names that can be accessed by the console.
CatalogACL: specify a list of catalog resource names that can be accessed by the console.
CommandACL: specify a list of console commands that can be executed by the console.
WhereACL: specify where the restricted console can restore files.

To allow the client to initiate the job run for a specific client, we need to use CommandACL to specify the commands the client is allowed to execute. If we try to execute an unauthorized command, a message about the invalid command will be displayed on the screen. To allow the client to initialize the backup, the CommandACL must include the run command, but it's also good to include the status command so we can check whether the job has been run successfully. The other ACL configuration options must also be specified, so the commands have access to the requested resources like Catalog, Client, Job, Pool, Storage and FileSet block elements. Without those configuration options, the client won't be able to initiate the job by himself.

There's one more command that we need to give the client access to, and that's the setip command. Since the mobile device can receive a different IP every time it connects to the networks, we must let the director know about its new IP, which we can do by using the setip command. Otherwise, the director will try to connect to the file daemon at a different IP address, which is not present on the network and the job won't be executed. Whenever executing the setip command I received the "Unauthorized command from this console" error message; this is because the console name should be the same as client name, after which the setip will work flawlessly.

Let's now test the setip option. First set the DNS we use in the bacula-dir.conf for our client machine to an address that doesn't exist; we can do that in our internal NS server. After that we can issue the following status command in bconsole to instruct bacula director to connect to the client's file daemon. Below we can see that:

[plain]

*status client=myclient-fd yes

Connecting to Client myclient-fd at myclient:9102

Failed to connect to Client myclient-fd.

baculaserver-dir JobId 0: Fatal error: bsock.c:133 Unable to connect to Client: myclient-fd on myclient:9102. ERR=Connection timed out

[/plain]

Next, on the client we have to issue the setip comand to set the client IP address to its current address 192.168.1.5.

[plain]

# bconsole

*setip 192.168.1.5

Client "myclient-fd" address set to 192.168.1.5

[/plain]

Next, we have to reissue the status command at the server side. This time the Bacula director will be able to connect to the client machine, which is seen below.

[plain]

*status client=myclient-fd yes

Connecting to Client myclient-fd at 192.168.1.5:9102

myclient-fd Version: 5.2.13 (19 February 2013)

Daemon started 17-Aug-14 12:46. Jobs: run=2 running=0.

Heap: heap=269,024 smbytes=112,838 max_bytes=424,393 bufs=94 max_bufs=176

Sizeof: boffset_t=8 size_t=8 debug=0 trace=0

Running Jobs:

Director connected at: 18-Aug-14 00:50

No Jobs running.

====

[/plain]

This verifies that the connection to the client is initiated and we can now run the backup from the client bconsole. Therefore, to enable the client to initiate the backup, we have to follow the following steps:

setip: execute the setip command to set the current client's IP address.
run: run the backup job.
status: check the status of the backup job.

A simple script that does that can be seen below. It first checks whether the baculaserverbox DNS is accessible, which is always the case in the internal network; this is also true when we've connected to the network via VPN. If the server is not accessible it immediately terminates the connection, otherwise it continues. Next, the script gets the current address of the tun0 interface, which corresponds to the VPN interface. If you're using different interface on your mobile device, choose it appropriate to your needs. At last the bconsole is run, feeding it the setip, then run and at last the status commands, which set the client IP address and run the backup job.

[bash]
#!/bin/sh

# Check if bacula server accessible.

if [ ! $(dig +short baculaserverbox) ]; then

echo "Backup server is not accessible."

exit 1

# Get the current IP address.
ip=$(ifconfig tun0 | grep -Eo 'inet (addr:)?([0-9]*.){3}[0-9]*' | grep -Eo '([0-9]*.){3}[0-9]*')

# Set the IP address and run the backup

/usr/sbin/bconsole -c /etc/bacula/bconsole.conf <<EOF

setip "$ip"

run job="MyClient" yes

status client=myclient-fd yes

EOF

[/bash]

The only thing left is to actually run the script periodically every day – the schedule depends upon the client. In any case, a crontab entry is needed, which can be added by using the crontab entry in Linux. We can use the following crontab entry to backup files to the server every 12 hours by running the /home/user/bacula script.

[plain]

0 */12 * * * bash -c '/home/user/bacula' 2>&1 > /var/log/bacula/backup-$(date +"%Y%m%d").log

[/plain]

The crontab entry also saves the log information into the /var/log/bacula/ folder, which needs to be created and permissions changed in order for backup process to be able to save the log file. The following commands need to be run as root on the client to create the appropriate /var/log/bacula folder.

[plain]

# mkdir /var/log/bacula

# chown user:bacula /var/log/bacula -R

[/plain]

After that we're all set and backup will be run every 12 hours and log written to the log file in /var/log/bacula/. A new log file will be created each day a backup is run in order to prevent infestation of the log file; saving information to separate files will keep things organized and maintainable.

Conclusion

In this article we've presented how Bacula can be used as a backup solution for mobile devices, which requires a little bit of skill, but can be a powerful backing up solution. I've been using Bacula as a backup solution for my laptop and a few other mobile devices without a problem for weeks and everything is working without a problem.

The process of integrating Bacula as an everyday backup solution takes a bit of time, since the configuration of Bacula director, file and storage daemons are quite daunting jobs, but at the end it's worth the effort. Once you've got a hang of the configuration files and how everything fits together, it will be a breeze to reconfigure Bacula to fit your needs. At the end of the day, you have to invest the time and energy in understanding the Bacula backup process and configuration files, but you get so much out of this great open-source backup solution, that's it's worth every minute of your time.

Think about what Bacula provides for free: backup agent that works on almost any platform, scheduling mechanisms, data compression, data encryption, etc. There are other aspects of Bacula that are not as great though like lack of GUI tools: we have bat and webacula, but they are not as complete and feature-ready as they could be. Nevertheless, if you're a Linux guru, you shouldn't have a problem dealing with Bacula configuration files, otherwise you can contact a great many people for help, like Bacula IRC channel, Bacula mailing lists, etc.