Yet Another Reminder That Replication Is Not Backup

It seems like every six months we hear another sad tale of a huge amount of data lost by an online service. The story usually revolves around the fact that IT management forgets that replication is not backup. Last week the story hit the web about Microsoft / Danger’s disaster with their online service for Sidekick. For anyone who didn’t read about the issues, the Sidekick is a mobile phone from T-Mobile that doesn’t store data locally, but pulls is from (what is now known as) a cloud service. The device and service are offered by Danger which is now owned by Microsoft. The service went offline about a week and a half ago and last week T-Mobile, Microsoft, and Danger let customers know that their data is most likely gone for good.

The announcement told customers that the data loss was due to a “server failure”, though some have speculated that it was due to some sort of botched SAN maintenance. The story is truly sad since loads of people lost data including contacts, calendars, to-do lists, and photos; however it’s not nearly as sad until you factor in that the whole thing was easily preventable. In this case, Microsoft apparently didn’t have any sort of backups.

Interestingly enough, a lot of sysadmins seem to forget some basic rules of keeping valuable data around. After disasters like this, it’s important to examine our own operations with this cardinal rule in mind: replication is by no means of the imagination a backup. This is especially true when one tries to depend upon RAID to protect from data loss. RAID is effective against hard drive failures, but if you delete a file on one drive, it deletes it on the other. This is important to keep in mind as well when replicating data across a network either through a straight file copy or a clustered file system. No matter the method, keep in mind that you still need old copies for those accidental deletes.