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.
Since when is tape unreliable? My DLT has a MTBF of 250,000 hours. I've used DLT, DDS, and Travan for years and I've seen far more HDD failures. I've seen plenty of tape drives fail, but not the tapes themselves. I trust my tapes far more than any spinning platter. Come to think of it, I trust my tapes more than any other backup I use (Optical disc, HDD, and Cloud). Once my station wagon full of tapes caught fire on the highway, but I blame that cheap-ass roach clip.
Really? I don't think you've looked at this very carefully...personally I use Mozy, it's a couple bucks a month, the initial upload took a week or so, but it was all backgrounded and I never even noticed (yes, you can turn your computer off, etc.). Daily incremental backups take just a few seconds. Retrieval is via downloading, if you just want a few files, or for some money ($50? I think?) they'll overnight you a couple of DVD's with your whole backup on it. So, it's cheap, requires absolutely no thinking on my part, is fire/meteor proof, and has unlimited storage. The choice was obvious, from my point of view.
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.
Interestingly, amazon web services now has a import/export service, where they will accept your USB drive via courier and import it into their "Simple Storage Service" aka S3.
http://aws.amazon.com/importexport/
--jeffk++
ipv6 is my vpn