Disaster recovery is in the details

Disaster recovery is in the details

October 18

When you sit down to make a recovery plan, you’ll often hear two pieces of advice: figure out what pieces of your operation are business critical and make sure you have a plan for everything. On the surface, these seem like contradictory statements, but they really aren’t. Prioritizing your critical elements doesn’t mean you recover them exclusively. It means you recover them differently. Just because your recovery time objective for your Exchange server is one second and the recovery time objective for the server that holds seven-year-old tax data is two weeks doesn’t mean you don’t need a plan for the tax server. You just need a different plan.

When it comes to simple data, it’d be nice to simply treat it all the same, to assume an instantaneous recovery regardless if it’s a crucial contract or template for internal emails. Of course, the reality is that it’s not always possible to treat all data the same and so you need to really consider how to organize your data and then make appropriate plans for each set.

But there’s more to it than that. And there’s more to your business than just the data, so your disaster recovery plan needs to be flexible there too. Recently, I came across two examples of recovery that doesn’t fit within the standard disaster recovery box.

The first is one we probably all have to deal with sooner or later. Our phones. In this case, it was my wife’s phone. I guess a couple of years of using the Internet filled its memory with random bits and basically mucked everything up. After consulting with the techs at our local store, we concluded the only option was to restore the phone to its factory preset, thus deleting all the information on it. We were able to copy most of her pictures and stuff to the SD card, but we had to do some manual dragging and dropping as it was. And we forgot her favorite ring tone, so we had to buy that again.

In my wife’s case, it was a pretty simple, painless fix. All of her app info was stored in the cloud, but she’s not the most aggressive phone user. But have you considered what would happen if your phone—or any of your employee’s phones—died? What information is on there? What protocols do you have in place for backing up and protecting that information? In this day and age, as our businesses get more and more complex, elements like our phones can become serious liabilities if we haven’t planned for them.

Shortly after the phone incident, I read this article from the great folks at WPMU.org. I’m a huge WordPress user (the Recovery Zone is built on it, in fact), but to be honest, there are a lot of questions in this article that I’d never really thought of.  In this case, the recovery plan is more about the WordPress installation itself (keeping database passwords, etc.) than the content contained therein. But again, it’s an example of something of a fringe aspect of your business (assuming you’re using WordPress, and if you’re not, the same idea probably applies to whatever you are using), but just because it isn’t “critical,” doesn’t mean you don’t need to recover it.

These are small, localized examples, but the point is that we need to really be looking at our businesses and trying to find those elements that we’ve missed. And then plan for them.