As part of revamping my backup scheme, I'm now adding rotating external hard drives, keeping one safely off-site at all times while the other is receiving backup data. Naturally, to ensure that my backups actually get done, the backups will be scripted and cron'd.

My plan is to manually plug in and mount the hard drive, and then leave it there until it's time to unmount it (again manually), take it away, bring in the next one, and (manually) mount that one. Both drives would be mounted to e.g. /mnt/backup.

Now, here comes the question: I don't want the backup script to run if I forget to plug in or mount the hard drive. So I need to be able to detect if there is a device mounted to /mnt/backup before the script is allowed to run. My first thought is to put a file named e.g. 'NO_DRIVE_MOUNTED' in the (unmounted) /mnt/backup directory, and then make sure that that does not exist before running the backup routine, but that just feels hackish. (Likewise, the inverse of putting a file named e.g. 'BACKUP_DEVICE_READY' in each external hard drive and checking that that file does exist feels just as hackish.)

Is there a better way to detect whether or not a device is mounted to a given directory? I'd rather avoid checking for the device itself, as my experience is that plugging in a drive in Linux just assigns it to the next available /dev/sdX, so while the backup drive might be /dev/sdf one day, if I have a different drive plugged in when connecting the backup drive the next time it would be /dev/sdg, which means testing for /dev/sdf would fail! I'd also prefer to avoid device-specific identification (e.g. by UUID) so that I can more easily and more transparently replace/upgrade the drives.

This will be on Ubuntu 10.10 (or possibly 11.04 if I drag my feet long enough, as I'm in the process of rebuilding the whole server anyway), and ideally I'd like a simple one-line test that I can prefix to my backup command directly in my crontab (but I'm not afraid of Bash scripts, either, if that's what's necessary).

Perfect, exactly what I was looking for! Thanks! And good point about logging the failed attempts in the script. Actually, I should set it up to e-mail me any errors, as I pretty much "set-and-forget" this server until I accidentally notice something's up (when the hard drive failed, I didn't notice for over a day, and as a result the most recent daily snapshot got corrupted all to hell!).
–
KromeyApr 7 '11 at 22:29

Here are two ways to check whether /mnt/backup is a mount point. The /proc/mounts method is specific to Linux, the df method is portable to all unix systems; other than that there's no major reason to prefer one or the other. Both may fail in corner cases when a mount point contains whitespace (just… don't do that!).

Note that you can assign a particular device name to a particular removable drive, based on criteria such a device serial number, a filesystem UUID or a filesystem label (the latter could be a reliable indicator). All it takes is one line in the udev configuration. But while that would be a good idea to facilitate mounting on the appropriate mount point, relying on the device's presence is no good: the device could be present but not mounted, so if your script depends on a mounted device, it should check the mount point.

There is another (better ?, safer ?) way to achieve what you want to do.
Instead of checking whether your backup drive is mounted, why not leave it plugged, but unmounted when it is not actually used.

This is probably better for the disk (some will just rest), and it
avoids accidental access to it. The cron job can mount it when it
starts and umount it when it finishes. This can be done as a normal
user with the commands mount /mnt/backup and umount /mnt/backup,
provided you described what you want in an entry of /etc/fstab. The entry has to include the option users if mounting is done as normal user. Now one has only
to detect whether the disk is actually plugged. The mount command
will tell you that by failing with error 32 for attempting to mount an unplugged disk (there are other causes
for that error too).

The last point is to tell /etc/fstab how to do the job. As you noticed, you cannot rely on the device name, since it changes all the time. But an actuall device can be recognized for itself. In the case of hard disk, partitons have a name that can be determined by appropriate tools, such as blkidor vol_id.
The command blkid will work for a normal user calling /sbin/blkid.
(BTW, this works also for DVDs).

For example, I have a disk with two partitions, currently on the device /dev/sdc. I will get the "UUID" of the first partition by calling as superuser:

and /etc/fstab will provide the right information to mount /mnt/backup to mount the right partition (if available) on /mnt/backup. The same goes for umount.

Unfortumately, this works only if you have a single backup DVD. The
reason is that the mount /mnt/backup command will use the first
entry in /etc/fstab that has /mnt/backup as a mount point. If it
happens not to match the disk you plugged in, it will fail without
looking for further entries that might do the job with a different
disk for the same mount point (I really wonder
why).

A solution is to associate all backup disks with /mnt/backup as mount point
in /etc/fstab. A script (even in normal user
mode) can try to mount each of the backup disk partition with mount -U 'xxxxxxx', when xxxxxxx is the UID of that disk (partition)
used to identify it in /etc/fstab. If one of the backup disks is plugged in, the script will eventually succeed.

Note that this will also prevent accidental destruction of a disk
mistaken for a back-up disk. If you plug in a disk that is not known
to your script, the script will be unable to mount it, even if the disk has an entry in /etc/fstab.

Another (even simpler) possibility to be checked (I never used that) is to use the command mount -a -O my_option that will mount all disks for which the /etc/fstab entry includes the option 'my_option'. And of course you have to add that option in each entry for a backup disks in /etc/fstab. The risk with this is that, if two backup disks are plugged in, they may be mounted on top of each other on /mnt/backup. This should not be a problem as only the second one, on top, will be visble. But I am not sure how careful one has to be to make sure both get
dismounted at the end. Some experimenting is probably in order.

However it seems that mount -a -O my_option is available only to the superuser, even for device the normal users could mount according to /etc/fstab. Again, I wonder why.