Auto-mounting usb hard drives

yaman666 · Posted: Mon Jun 30, 2008 7:49 pm Post subject: Auto-mounting usb hard drives

I am trying to set up a rotating hard drive backup system, where a single usb hard drive is plugged into the server. Server would synchronize backups to this hard drive and every day the hard drive would be swapped for another identical hard drive, that way there's always a complete copy that's a day old in case anything happens to both server and the hard drive.

My questions are:

1. What is the simplest way to auto-mount this hard drive, there seems to be so many solutions out there with autofs, ivman, etc
2. Is it possible to auto-unmount the drive, so that I could simply unplug one hard drive, plug the other one in and the server would not care
3. Would I need to set up udev rules to make sure the drives map to the same path all the time? Right now it doesn't look like any nodes are created for it under

coolsnowmen · Veteran Joined: 30 Jun 2004 Posts: 1479 Location: No.VA

I'm having a hard time understanding why automounting is even necessary. Assuming you backup at a particular time, why not have the backup.sh mount it, if this is already a scripted task?
_________________
emerge: there are no ebuilds to satisfy "moo"

yaman666 · Posted: Tue Jul 01, 2008 3:24 am Post subject:

The point is to be able to simply unplug the hard drive and replug another hard drive without touching the server. This is where question 2 comes in - does it get unmounted automatically?

coolsnowmen · Veteran Joined: 30 Jun 2004 Posts: 1479 Location: No.VA

they most certainly won't get unmounted in the traditional sense, I'm going to have to just mount something and pull it from the system to see what happens. This is nonstandard and so may have changed over the years. In the past the system took a while to realize that there was no connection to the device anymore, so the next usb connection *sometimes* had a different device node eg (/dev/sda the first time, but /dev/sdb the second) in the time it took for the system to realize the device was stale.

This might be a problem if you are thinking of having filesystems with the same label. Perhaps a different /dev/disk/by-* will be necessary.

More importantly, you have to be flushing or mounting synchronously if you don't want to lose anything (if i remember there is an option in the middle that could work). That still begs the question, if you are not unmounting it, how do you know it is done? You are writing to this disk, pulling before that process is finished ...

Then again, why can't your backup script unmount the drive when it is done? It could also signal you when it is done in someway, turn a light on, send you an email, play some music.
_________________
emerge: there are no ebuilds to satisfy "moo"

yaman666 · Posted: Wed Jul 02, 2008 8:56 pm Post subject:

Solved this using autofs. It allows you to auto-mount only when access is needed and then auto-unmount when idle for X seconds. So when I unplug/replug, it'll just remount the new hard drive since they both seem to map to /dev/sdc

coolsnowmen · Veteran Joined: 30 Jun 2004 Posts: 1479 Location: No.VA

I'm glad autofs does what you need. Its been years since I used it.

I used to use parallel ports to turn lights on and off. If you get a parallel port cable and chop it in half, and set up a simple circuit with an led+resistor in it, you can turn them on/off using standard linux libraries (paraport if memory serves)

I'm not even suggesting you do this, with a couple tests you should know the basic amount of time for a backup, but it would be cool if you had the time.

But for important headless systems in gerneral (if you are doing rotating-daily backups, I'm assuming it is important), developing a way (over the network?) of telling you if there is an error is worth the time. And if you are doing that then writing a "backup complete `date`" file would be good enough.

What are you spending on hard drives? if you were spending enough it might be worth getting a terastation and crossover cabling to it, and doing alternating rsyncs to it.
_________________
emerge: there are no ebuilds to satisfy "moo"

baeksu · l33t Joined: 26 Sep 2004 Posts: 609 Location: Seoul, Korea

coolsnowmen · Veteran Joined: 30 Jun 2004 Posts: 1479 Location: No.VA

it might not be necessary to actually mount it sync, especially If io performance hurts the overall performance needs of your system.

If you have a massive backup going, it won't just cache everything. Linux will actually write to the drive eventually. It is true that you can't trust a copy has actually occurred just by virtue of the face that the "cp" process ended. But unmounting or simply executing the "sync" command at the end of any backup would be sufficient.
_________________
emerge: there are no ebuilds to satisfy "moo"

yaman666 · Posted: Thu Jul 03, 2008 4:31 am Post subject:

I'd love to do something like an LED alert, but I'm afraid my electrical skills are somewhat lacking and I don't have enough time to research this. May be later as a pet project. :-)

Thanks for all the suggestions, guys! I actually didn't realize you could do an autofs with sync option. I'll give it a try and see how big of a performance hit it takes compared to simply syncing in the end of a cp.

As far as the drives, they're just cheap maxtor one touch minis 160Gb - around $70/piece. And I'm doing regular tarballs of everything, but I'm starting to look into bacula, amanda, etc - for a more flexible backup policy in the future, considering that the number of servers keeps increasing and doing complete daily dumps is starting to eat into the bandwidth cost.