Slashdot Mirror
Best Home Backup Strategy Now?
jollyreaper writes "Technology moves quickly and what was conventional wisdom last year can be folly this year. But the one thing that's remained constant is hard drives are far too large to backup via conventional means. Tape is expensive and can be unreliable, though it certainly has its proponents. DVDs are just too small. There are prosumer devices like the Drobo, but it's still just a giant box of hard drives, basically RAID. And as we've all had drilled into our heads, 'RAID is not backup.' When last this topic came up on Slashdot, the consensus was that hard drives were the best way to backup hard drives. Backup your internal HDD to an external one, and if your data is really important, have two externals and swap one off-site once a week. Is there any better advice these days?"
I've re-purposed a computer as a backup server, which lives at my parents house. It runs Ubuntu, with ZFS running over FUSE. Each night, a scripted CRON event will run zpool scrub on my storage pool, and if there is a problem, it will send me a text.
My MacBook Pro will use Time Machine over NFS over SSH to make the actual backups from my dorm/wherever I happen to be.
Commence CDDL/GPL/BSD Flamewar.
-jX
Don't you just love politics? It's like a comedy of errors.
http://backuppc.sourceforge.net/
Get an old P3 for free somewhere and load this up on it with a big disk or two for storage, put it on your network, and run it. That's what I do and it works like a charm. I went through all the options over the years, tape, DVDs, manual copying to a server.
Backuppc backs up all my windows and linux PCs. It backs up only what I tell it to, and it does both full and incremental. Sort of a pain in the ass to set up (I use cygwin rsyncd on the windows boxes, and regular rsyncd on the linux boxes), and it works well.
Only drawback is it is still on site.
We must lay out the kinds of failures and goals of a backup to determine how best to back up.
1. We would like to protect against mechanical drive failure. This can be done with a RAID.
1.5. We may also want to protect against the failure of other components of the computer. I recently had a computer die because its motherboard died, and it took about two weeks to get a new computer, and the new computer was a significant upgrade so it had SATA instead of IDE. In the mean time, I needed my data on other systems, and when the new computer came, I needed to borrow a USB-IDE bridge to recover some stuff that I wasn't backing up.
2. We would like to protect against accidental deletion of files, file corruption, or edits to a file that we have now reconsidered. This can be done with snapshotting. In source code, to reconsider and edit to a file is fairly common, and is the reason why most programming projects use revision control systems. Other options like nilfs or ZFS snapshots can also fill this goal. This goal is accomplished more easily if the backups area automatic and the backup device is live on the system.
Depending on your needs, this goal may be counterbalanced by a need to not retain the history of files for legal or other reasons, and this should inform your choice of backup strategy.
3. We would like to protect against filesystem corruption, whether by an OS bug, or by accidentally doing cat /dev/random > /dev/hda. This can be done by having an extra drive of some sort that isn't normally hooked up to the computer. Tape drives, CDs, and DVDs have traditionally fulfilled this purpose, and this is where the use of additional hard drives is being suggested. Remote backups, via rsync can also accomplish this. For this I use git.
4. We would like to protect against natural disasters. For someone living in New Orleans, it would be nice to have a backup somewhere outside the path of Hurricane Katrina. Remote backups may be pretty much the only way to accomplish this, unless you're a frequent traveler and can hand-deliver backup media to remote locations.
5. In addition to any of the above, the code you use create said backup may be buggy, or may become buggy or misconfigured over time. Checking the integrity and restorability of your backups after creating them, and keeping several (independent) previous versions of a backup may help here.
You may not be concerned with the various modes of failure described here occuring simultaneously. For example, it may be unlikely that you need to deal with file system corruption at the same time that you regret one of the edits you made on your file. In that case, your offline backup device doesn't need to hold all of your snapshots.