One of the challenges I faced in configuring my new backup system on my Ubuntu Linux-based server was setting up my two external drives to mount at the same place in the filesystem.

Why? Because the program I use to manage my backups, BackupPC, expects the storage “pool” to always be in the same place. My options were to write a script to change the BackupPC configuration each time a different drive was plugged in, or make the pool mount in the same location regardless of which drive I’m using. Because I was working with LUKS-encrypted volumes I faced additional complexities which made it  difficult to use other methods (like volume labeling) because of how Gnome handles and mounts such encrypted volumes.

While it took a while to make it work, once I figured it out it did exactly what I needed. Now, I’m sharing my results with you to save you the trouble of doing all the research yourself!

I found the easiest solution both for this problem and my next one (making eSATA drives auto mount) was to use HAL configuration files. HAL stands for “Hardware Abstraction Layer” and is one of the ways Linux interfaces with various hardware elements, including hard drives. Using XML it is easy to create custom policies to define how HAL handles particular devices.

(*Note: I have read that Ubuntu will soon be moving away from using HAL, possibly as soon as 9.10, Karmic Koala. I’ve tested this on Ubuntu 8.04, 8.10, and 9.04, but it should work with any distro that (still) uses HAL.)

(** Note 2: Having recently begun the process of rebuilding my server on Ubuntu 9.10/Karmic, I can verify that this method DOES NOT WORK. I am currently in the process of figuring out a solution, likely using udev and scripting, and will post my results as a post here …)

These configuration files are located in /etc/hal/fdi/policy. My installation included one existing file – preferences.fdi – which defines whether non-removable drives are auto-mounted. (We’ll get to eSATA auto mounting soon enough …)

Some quick notes on how .fdi files work: first devices are matched with pre-determined keys, defined through XML. Then, actions are taken by changing (or “merging”) other keys. A very basic .fdi file might consist of the following:

<?xml version="1.0" encoding="ISO-8859-1"?> <!-- -*- SGML -*- -->
<deviceinfo version="0.2">

 <device>
   <match key="some.key" string="some_string">
     <merge key="another.key" type="bool">true</merge>
   </match>
 </device>

So what’s the easiest way to find these keys to match and merge? In my experience, Gnome Device Manager (aka gnome-device-manager).

To see if you have Device Manager installed, check under “Applications -> System Tools” or try to launch gnome-device-manager from the terminal. If it doesn’t work, install it using Synaptic or run:

sudo apt-get install gnome-device-manager

With your drive plugged in and turned on, open up the device manager and begin to look for your drive. You may have to expand some of the trees for “SCSI Host Adapters” and “SCSI Devices”, or possibly USB-related trees,  before you see the drive entries, usually titled “Mass Storage Drive” or something about removable storage.  There may be several of these entries. You will need to look at attributes like the model numbers and capacities to determine which drive it is you’re wanting.

Once you’ve identified the drive you want the information for, type ctrl+p or click on “View -> Device Properties” which should make an additional “Properties” tab appear beside the previous “Summary” tab. Now you will be able to see the various keys, types, and values you can use when creating .fdi files. For our purposes here we will need to look at the properties not for the drive itself, but for the volume we want to create a mount point for.

Note: this is with drive attached via eSATA

Our first order of business is to find a key that will provide a definitive match for each drive / volume. In my situation I was using two identical external enclosures with two identical drives. I could have simply created one rule that would specify the mount point based on any drive that matched some shared property, such as the model number (storage.model) but I wanted to make sure that these two volumes and only these volumes would share this mount point. In addition, I wanted to be able to tell at a glance which one was mounted, so I needed HAL to distinguish between them somehow.

Every volume has a distinctive UUID – kind of like a fingerprint that identifies it to the rest of the system. In the device manager, under the properties tab for the volume you’re working on, look for the volume.UUID key. Once you’ve found it you can begin to write your HAL policy file.

Create a new, blank text file in /etc/hal/fdi/policy. (You will probably need to do all this as root / sudo) Name it something like 30-sharedmounts.fdi. (The “30″ in the file name makes sure this policy is evaluated prior to the general preferences file.) Once you have created your file, open it in your favorite text editor and start with the following:

<?xml version="1.0" encoding="ISO-8859-1"?> <!-- -*- SGML -*- -->
<deviceinfo version="0.2">

Now we need to specify the device and they keys we want to match and merge:

<device>
 <match key="block.is_volume" bool="true">
 <match key="volume.uuid" string="7feeefbf-416b-4383-9bb3-7fd51cb3e702">
   <merge key="volume.policy.desired_mount_point" type="string">ext_backup</merge>
   <merge key="volume.label" type="string">Ext Backup 1</merge>
 </match>
 </match>
</device>

Here’s a quick explanation of what you see above, and what each does:

• <match key=”block.is_volume” bool=”true”> – A little bit of insurance, to make sure we’re working with a volume and not a drive.
• <match key=”volume.uuid” string=”7feeefbf-416b-4383-9bb3-7fd51cb3e702″> – As described above, identifies the particular volume you want to specify the mount point for.
• <merge key=”volume.policy.desired_mount_point” type=”string”>ext_backup – This is the new mount point, which will appear beneath /media/ , so this example would mount as /media/ext_backup .
• <merge key=”volume.label” type=”string”>Ext Backup 1 – A little extra nicety. This is how we can identify between different volumes, even when they’re mounted at the same point in the filesystem.

Now that you’ve got the mount point specified for your first volume, you’ll want to do the same for your second (and any other subsequent) volumes. For each volume, just find the UUID and create a new <device> section in the .fdi file. Be sure to specify the same mount point and unique volume labels (if you so desire.) Once you’re done, save your file and restart HAL (or just reboot.)

sudo /etc/init.d/hal restart

Now, whenever you plug in your drives and Gnome auto-mounts your volumes, they will mount in the same place every time.

What’s that, you say? You’re using eSATA drives and they don’t auto-mount? My next blog post will take care of that for you, and it shouldn’t take more than about 5 minutes of your time. As an added bonus, this method will mount the volumes in the same place regardless of whether they’re connected by USB or eSATA.

Before I get to what my new backup hardware consists of, it might be helpful to know a bit about my existing (old) setup. My home network consists of a workstation, a laptop, a netbook, a seldom-used garage PC, and a multipurpose server. Among it’s many duties, the server is a centralized backup server, allowing the various computers to back up files each night. It runs on an old AMD Athlon motherboard with 512MB RAM, using a 30 GB drive for the OS and programs and a pair of 200 GB drives for storage and backup.

Prior to this upgrade, the backup drive was regularly at 95% capacity. Even with the intelligent pooling technology used by the BackupPC software it had become necessary to limit the number of nightly backups I was keeping in order to make space for the unique data from the various PCs.  So I decided it was time to upgrade my storage situation.

I had been debating for a while how to best increase my storage space while also ensuring the integrity and protection of my data. Having recently witnessed my parents’ misfortune and recognizing that if a similar tragedy would have happened to me that many priceless digital memories and large amounts of work-related data would have been lost, I knew it was time for a system that incorporated some kind of off-site backup.

One option I contemplated was an online backup service, where your data is stored in the “cloud” and available whenever and wherever you need to access it. The particular provider I considered was SpiderOak. I had one of their free 2 GB accounts already and I was very impressed with their security and privacy policies as well as their interoperability with Linux. However, the problem with such online backup options is their monthly fees. For the price of 100 GB per year at SpiderOak I could buy a hard drive ten times that size!

So that’s what I did – I bought two 1TB hard drives. This will allow for one hard drive to be in service and the other stored at a secure, off-site location in case of disaster. I’ll have tons of storage space and no monthly fees. A win-win situation.

Of course, juggling two different drives means additional complications with set-up and management, but those are later blog posts.

My original plan was to buy two bare drives and two USB enclosures. My server does not support serial ATA (SATA) drives, so USB seemed easiest for both compatibility and swap-ability. I’ll elaborate later, but to make a long story short USB simply was not adequate for my particular needs, so I ended up purchasing a PCI SATA controller as well. Thankfully the enclosures supported both USB and eSATA, so everything else was simply a matter of configuration (also another post.)

So finally, here’s the hardware I ended up using to make my backup plans a reality. All links are to Newegg, my personal favorite purveyor of computer parts. (The prices listed were as of July 2009, and I’m sure will probably become laughable as time passes.)

• 2 Western Digital Caviar Green WD10EADS  1TB SATA drives – $79.99 ea.
• 2 Vantec NST-300SU external USB / eSATA enclosures – $27.98 ea.
• Rosewill RC-210 PCI internal & external SATA controller – $19.99

Total cost – $235.93 (All the items qualified for free shipping at the time I ordered them.) Less than the cost of 100GB for two years through an online backup provider.

Thus far I’ve had no hardware-related problems, and everything has been superbly compatible with Linux (Ubuntu 8.04 LTS / Hardy Heron.) The drives are extraordinarily quiet. Since the server still has 3 internal hard drives and several fans, the new external drives are basically inaudible.

The only nitpick I’ve got is with the Vantec enclosures. There is a bright blue power / activity LED on the front the enclosure, and when you install the drive into the internal tray you have to plug the LED in as you put the enclosure back together. Two small, recessed screws hold the drive tray in place. I found (with both my enclosures) that if I tightened the screws all the way down, completely closing the gap between the tray and the rest of the enclosure, the lights would not work. If I backed the screws out just a few threads everything worked fine. I don’t think the gap is large enough to pose a concern, so it’s basically just a small aesthetic annoyance. Not a deal-breaker, but something worth noting.

That’s it for the hardware specs! Next up, formatting the removable drives and setting them up with LUKS encryption.

Over the next couple days (weeks?) you can expect more on the following topics:

• New backup hardware: drives, enclosures, and controller card
• Setting things up: LUKS encryption on external drives
• Specifying a shared mount point in Ubuntu Linux
• Switching from USB to eSATA, making eSATA automount
• Making external encrypted drives work with BackupPC

As you can tell from this list I faced a lot of hoops to jump through in order to get this up and running. I’ll add links to the individual posts as I write them. Feel free to ask questions if you’ve got any!