A few hard drives and rsync make a simple and effective onsite backup system. Scott Granneman shows you how to keep your desktop data safe.
Backup is vitally important, and you should do it as regularly as possible. There’s nothing worse than losing valuable data. However, individual backup needs vary, so different strategies and software packages are required.
This column describes the onsite backup strategy I use. This technique is supplemented (not replaced) with my offsite backup strategy, which uses a combination of rsync and Amazon’s S3, which was described here a short time ago.
I have four IDE hard drives, each 320 GB in size, and each dedicated to a particular kind of data (yes, a move to 500 GB SATA drives is imminent). The name of each drive corresponds to its mount point in
/media, as shown in the table.
|TABLE ONE: A map of the hard drives on the author’s desktop system
In addition to the four data drives, I have four backup drives, each with its own corresponding mount point, too: /media/data-copy, /media/movies-copy, /media/music-copy, and /media/music-rock-copy.
Each drive is in its own enclosure. After trying many different enclosures, I finally found what I consider to be the best of breed: the AMS VENUS DS-2316CBK Aluminum 3.5″ USB & 1394 Black External Enclosure. Priced at about $50 at NewEgg, this is a sturdy enclosure that supports both USB 2 and FireWire. Best of all, there’s a fan on the bottom to keep things cool.
But I was faced with one big problem: as I steadily increased the number of drives I owned, I had to increase the number of enclosures, which meant additional power, as well as an enormous rat’s nest of power and USB cables behind my desk. There had to be a better way. Finally, I purchased another two enclosures, also created by AMS. At about $115 at NewEgg, the AMS VENUS T4U DS-2340UBK 3.5″ USB 2.0 External Enclosure holds four internal hard drives, with one power cord and one USB 2 connection for all the drives.
In one T4U, I put data, movies, music, and music-rock; in the other, data-copy, movies-copy, music-copy, and music-rock-copy. When I buy a new hard drive, I use
fdisk to create a single partition on the drive. After that, I format the new partition as ext3 with the command
mkfs.ext3 /dev/sda1. By default, ext3 reserves 5 percent of the hard drive for emergency usage. On a 320 GB hard drive, that’s a ridiculous amount. 2 percent is more reasonable, which the following command puts in place:
tune2fs-m 2 /dev/sda1.
For ease of reference and mounting, I give the hard drive a label via
tune2fs-L music /dev/sda1. Even though I assign a label, I prefer to use the drive’s UUID (it’s unique ID) in /etc/fstab. Discovering the drive’s UUID isn’t that hard.
$ sudo vol_id /dev/sda1
In fstab, I add an entry for the drive (the entry is wrapped below to fit the column width):
/media/music ext3 rw,user,noauto 0 0
I must also create a mount point with the command
sudo mkdir /media/music. I can now mount the new drive with
mount /media/music. Of course, if I reboot (a very rare occurrence), KDE auto-mounts all the drives, making my life far easier.
The drives whose names end in “-copy” are backups of the original drives. To handle the backups, I use rsync. My script for the music drives, which copies /media/music to /media/music-copy, looks like this:
rsync --verbose --progress --stats \
--recursive --times --perms --links \
--delete /media/music/ /media/music-copy
mv /media/music-copy/111aaa_Music \
The latter line runs mv because a long time ago I was careless and stupidly deleted some files off of a “-copy” drive instead of its master drive. To prevent that, I created a file on data called 111aaa_Data and one on data-copy called 111aaa_Data_Copy, with similarly-named files on the other drives. When rsync runs, it copies 111aaa_Music from the master to the copy, so I use mv to rename the file.
That’s my onsite backup strategy. Future refinements include larger SATA drives, as well as the introduction of a T4U to hold hard drives dedicated to backups of my movies and connected to a Linux media center running Myth. Now, back your stuff up!
Fatal error: Call to undefined function aa_author_bios() in /opt/apache/dms/b2b/linux-mag.com/site/www/htdocs/wp-content/themes/linuxmag/single.php on line 62