Automated incremental backups to an external drive

Question

Background

A client needs an automated backup solution to an external drive (to be taken offsite weekly). I'd typically suggest rsnapshot (or perhaps rolling out a custom rsync script), but this question is slightly more involved.

The Arch Linux based system is headless and therefore the solution must be fully automated, requiring no user intervention.

An ideal scenario would be as follows:

1. The user plugs in a USB hard drive
2. A complete incremental backup is made
3. The hard drive is unmounted
4. The user is notified that the hard drive can be unplugged

Proposal

My proposed solution consists of:

1. A udev rule automatically mounts the drive

2. The backup is started with:

   1. The same udev rule also triggers a rsnapshot script
   2. An inotify create event detects the new mount point and triggers rsnapshot

3. After rsnapshot exits, umount is ran on the drive

4. Possible ways to notify the hard drive can be removed:

   1. The CD drive opens
   2. A sound is played through the PC speaker

If an error occurred at any point, email the user and unmount the drive.

Questions

1. My proposal seems feasible but are there obvious flaws? How can I make it robust?
2. For security purposes, how can I make sure the hard drive plugged in is the user's? ssh keys? Drive label?
3. Are there existing (Linux) solutions that encompass this?

Answer 1

Your solution seems relatively suitable, however:

• Make sure that the rsnapshot script does not presume to know the block device. Ideally address the filesystem by its UUID or label to avoid carnage.
• Add timeouts. This way, if something goes wrong that we don't know about, or something causes the script to never finish, it can be dealt with as an error instead of continuing indefinitely.
• You state that at the end that "[i]f an error occurred at any point, email the user and unmount the drive" -- what happens if it cannot unmount the drive, or the unmount is where it fails? What happens if the email fails? Make sure to build failsafes into your system.
• For basic security, the UUID should be fine (unless an attacker might have knowledge of your UUID), however, if security is more of a concern, consider writing some data to the code area of the MBR (bytes 0-440), and having the script check for it before beginning the backup. You should be warned that this is more security through obscurity than anything else, however in this situation I don't see any easily available methods which are superior. If you want to go the full way, however, you could determine if the drive is authorised by analyzing an encrypted certificate stored on the disk. When udev detects the drive, the script decrypts the certificate using its key. The certificate contains parameters relating to the drive, such as the drive's serial number, model number, capacity, etc, then compares the parameters extracted from the encrypted certificate with the parameters seen when analysing the drive. If the parameters match, the drive is determined to be authentic, otherwise the drive is rejected, and the script terminates.

There are existing Linux solutions that fall into this remit, however, for your specific needs I think that you'd be better off making a bespoke solution instead of fiddling with the source of other programs to get them to do what you want.

To write random data to the code area of the MBR, which you can then check for, do something like dd if=/dev/urandom of=/dev/sdX bs=440 count=1.