Encrypted offsite backups on auto-mounted media with Bacula & vchanger

Automating The Process:

Configuring autofs:

As mentioned in the previous section, udev is responsible for creating the appropriate symlinks in the /dev/disk/by-id, /dev/disk/by-label, /dev/disk/by-path, and /dev/disk/by-uuid which point to the kernel block device node (eg: /dev/sde, or /dev/mapper/sde, etc) when a new device or filesystem is detected.

This is important to know because we are planning on using Bacula with vchanger, and vchanger allows its removable magazines to be defined and referenced by their filesystem's UUID.

A filesystem's UUID may be determined by several methods. One way is by using the blkid program. First make sure that you have an encrypted container unlocked:

root@host: # cryptsetup -v luksOpen --key-file=/etc/bacula/include/Bacula_Key_File /dev/sde tempcontainer
key slot 1 unlocked.
Command successful.

Run the blkid program to identifty the TYPE and UUID of the device-mapper block device node "/dev/mapper/tempcontainer" created by the previous command:

root@host: # blkid /dev/mapper/tempcontainer
/dev/mapper/tempcontainer: UUID="6c5b725d-50c4-4605-b750-4f23575b9b5f" TYPE="reiserfs"

The blkid output above shows the UUID of the reiserfs filesystem in the encrypted container. As expected the UUID shown here matches the UUID displayed when the reiserfs filesystem was created in the "Creating The Filesystem In The Encrypted Container step previously. Save each UUID to a text file, as they will be needed later when vchanger is configured.

List the contents of /dev/disk/by-uuid to confirm the uuid symlink points to the tempcontainer block device node in the /dev/mapper directory:

root@host: # ls -la /dev/disk/by-uuid
drwxr-xr-x 2 root root 260 Jan 23 15:48 .
drwxr-xr-x 6 root root 120 Jan 21 19:29 ..
lrwxrwxrwx 1 root root  16 Jan 23 15:48 6c5b725d-50c4-4605-b750-4f23575b9b5f -> ../../mapper/tempcontainer

The /dev/mapper/tempcontainer block device node is exactly what the UUID symlink should be pointing to. Now close the encrypted container and remove the device-mapper block device node in /dev/mapper:

root@host: # cryptsetup -v luksClose tempcontainer
Command successful.

Editing the autofs map files:
Now we are going to configure autofs automatically mount filesystems based on their UUID.

autofs's main configuration file is /etc/autofs/auto.master. We are going to add one line to it:

/etc/autofs/auto.master

--[snip]--
/mnt/eSATA-1_Backups    /etc/autofs/auto.vchanger       --timeout=30
--[snip]--

This tells autofs to consult the /etc/auto/auto.vchanger map file whenever access to a file or directory below /mnt/eSATA-1_Backups is attempted.

Next, create the file /etc/autofs/auto.vchanger which will contain only the following one line:

/etc/autofs/auto.vchanger:

*       -fstype=auto,rw,sync    :/dev/disk/by-uuid/&

Restart autofs to activate the changes we just made. On Gentoo Linux run the following as root:

root@host: # /etc/init.d/autofs restart

Verify that autofs is now watching the /mnt/eSATA-1_Backups directory:

root@host: # mount -t autofs
automount(pid29068) on /mnt/eSATA-1_Backups type autofs (rw,fd=4,pgrp=29068,minproto=2,maxproto=4)

This confirms that automount is watching the /mnt/eSATA-1_Backups directory for access requests.

Now, whenever access to a file or directory below /mnt/eSATA-1_Backups is attempted, autofs runs*, or references the /etc/autofs/auto.vchanger map file to determine what steps to take.

In this case, /etc/autofs/auto.vchanger instructs autofs to to scan the /dev/disk/by-uuid directory to try to match the directory being accessed in /mnt/eSATA-1_Backups with a symlink having the same name. If a match is found, autofs creates a directory with the same name under /mnt/eSATA-1_Backups and mounts it on /dev/disk/by-uuid/<matching uuid symlink> - Which of course points to the device-mapper's block device node for the encrypted partition on the external disk.

For example, if a drive is inserted, and our udev rules have located and unlocked the encrypted partition (as above), and the following command is run:

root@host: # ls -la /mnt/eSATA-1_Backups/6c5b725d-50c4-4605-b750-4f23575b9b5f

autofs scans the /dev/disk/by-uuid directory and finds the 6c5b725d-50c4-4605-b750-4f23575b9b5f symlink and will create a directory /mnt/eSATA-1_Backups/6c5b725d-50c4-4605-b750-4f23575b9b5f, then mount /dev/disk/by-uuid/6c5b725d-50c4-4605-b750-4f23575b9b5f on it with read, write and sync options, and will unmount it after 30 seconds of inactivity.

The sync option will slow writes to the hard drive but is an added safety measure used on removable media to ensure that data is written immediately to help prevent data loss or curruption if the drive is removed before it is properly unmounted.

Verify that autofs has mounted the encrypted partition functionality by running:

root@host: # mount
/dev/sda3 on / type ext3 (rw,noatime)
/dev/sda1 on /boot type ext2 (rw,noatime)
--[snip]--
automount(pid29068) on /mnt/eSATA-1_Backups type autofs (rw,fd=4,pgrp=29068,minproto=2,maxproto=4)
/dev/mapper/6c5b725d-5....9b5f on /mnt/eSATA-1_Backups/6c5b725d-5....9b5f type reiserfs (rw,sync)

The bolded "/dev/mapper" line above confirms that autofs has created the directory in /mnt/eSATA-1_Backups, and has mounted the encrypted filesystem. This means that udev and autofs are working as expected and we can move on to configure vchanger.

If this mount command does not show that the encrypted partition has been automatically mounted, it is possible that more than 30 seconds have passed since the previous ls command was issued and autofs has automatically unmounted the partition. Run that command one more time, then run the mount command immediately after.

* NOTE: I found out the hard way that if the autofs map file (eg: /etc/autofs/auto.vchanger) is executable, then autofs will attempt to run it to generate its mapping rules, rather than reference it to read its mapping rules. Make sure your /etc/autofs/auto.vchanger file is chmod -x to save yourself future headaches.


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Few Modifications

A few things I ran into running this on current versions of cryptsetup.

1. You can create the encrypted drive WITH key in one command now;
cryptsetup -v luksFormat /dev/sdb --key-file /etc/bacula/include/Bacula_Key_File

2. There is a new format for the arguments? for key-file. For example;
cryptsetup -v luksOpen --key-file /etc/bacula/include/Bacula_Key_File /dev/sdb tempcontainer

3. I had to install some requirements in my ubuntu server 12.04 x64.
sudo apt-get install libblkid-dev
and
sudo apt-get install uuid-dev

4. I had a lot of trouble with the Client = None and Fileset = None. I thought they were built in keywords, wasn't until I read http://blog.serverfault.com/2011/01/10/some-notes-on-setting-up-backups-... that I realized they were just dummy ones created.

Very informative ,well written.

Thank you, this tutorial helped a huge amount.I've been struggling to automate the decryption and mounting/unmounting. This tutorial enabled me to accomplish exactly what we needed.

Great job!

Hi! Great job with this howto!

I'm using Bacula since 2.4 releases and it's the first time I found a solution to encrypt all the Bacula volumes and get the 'perfect' OUT-OF-OFFICE solution.

Thanks!

Thanks so much for this!
Incredibly thorough. As a recent Bacula convert I've found it really useful.

Post new comment

  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <b> <i> <u> <strong> <cite> <code> <pre> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.

More information about formatting options

CAPTCHA
This question is for testing whether you are a human visitor and to prevent automated spam submissions.
2
8
3
?
{
Y
Enter the code without spaces and pay attention to upper/lower case.