RAID != Backup

Published: 2009-01-03. Last Updated: 2009-01-04 16:09:54 UTC
by Rick Wanner (Version: 1)
2 comment(s)

Reader Tomasz sent in a message discussing the demise of JournalSpace.  JournalSpace was a relatively small player in the whole blogging boom, but the interesting bit is what caused their demise.  Their main database was RAID-1, in other words mirrored to another drive, For reasons that are not entirely clear, both the primary disk and the mirror were overwritten. Speculation is a malicious insider is responsible.  Software error is also a possibility.

While this is sad, the important lesson from this is that RAID is not a substitute for a good backup strategy. Your data is your business...If your business is important to you, you should have a comprehensive backup strategy that involves daily backups and most importantly offsite storage of backups.

 

-- Rick Wanner rwanner at isc dot sans dot org

2 comment(s)

Comments

As was noted in the diary item, there are plenty of other reasons to roll back time besides media failure. Not only can good data be lost, but bad data can appear.

One scenario I imagine is that a business that develops intellectual property finds that a competitor's IP has contaminated their product, say, two weeks prior. While the lawyers duke it out, wouldn't it be nice to roll back to before the contamination, instead of throwing away months or years of development? Fault-tolerant media won't do that.
mexaly, while your point is good, in the particular situation you're talking about, that's what source code version control is for. I'd posit a scenario where you were compromised, knew when it was, and so you roll back to before that date so you know you're not using bad data.

Diary Archives