logo

Why Disaster Recovery Plans Fail

Let’s pause for a sec and see what we’ve covered so far.  We know that there are 4 pieces to Disaster Recovery and they are Mitigation, Disaster Planning, Response, and Disaster Recovery itself.  We’ve also defined Mitigation as those steps you can take to eliminate or lessen the impact an incident will have.  We even looked at a couple of pieces of mitigation you might do on a daily basis.

We could belabor the point of mitigation all day long, and look at each threat and how we could lessen the impact, but that would merely prolong this series.  Instead, let’s start talking about planning.  Planning is simply taking it and putting it on paper.  But the process involved in getting it on paper is anything but simple, and we’ll be looking at those steps in later articles.

For now, let’s talk about why plans fail.

The list could be endless, but at the end of the day, there are four basic reasons plans fail.

Reason number 1:  That can’t happen to us.  I like to call this the Ostrich approach to Disaster Planning; you stick your head in the sand and pretend it can’t happen to you.  This unfortunately is wired into us.  It’s the other guy that gets mugged or in the wreck.  It’s the other guys’ house that burns down.  Bad things don’t happen to us!  But as someone who has had something bad happen to them can tell you, it does.  One of the things that will probably impact you as an individual and as someone owning or employed by a business is fire.

Fire has been part of the human existence probably ever since the model came out.  Along the way we’ve realized it is a great and wondrous tool.  It warms our homes, cooks our foods, and powers our world.  It’s also a tool that looks to revolt against us and will take advantage of the slightest slip of our guard, and it will burn down the same homes it was supposed to warm, burn up the foods we were supposed to eat, and burn out the hearts of communities it was supposed to power.

The story is told of small business that tool this seriously.  We’re not talking anything that made millions of dollars a year, it was just a small mom and pop shop, but it was big enough to provide for its owners and a few employees.  Anyway, they got invited to a bit of meet and greet put on by the local fire department.  Some of you might have been to some of these, they give you coffee, give you doughnut or two, and then you sit through some presentation.  In this case it was about Disaster Planning for small businesses.  The owner of the business listened, thought it had merit, and began doing some planning.  He made sure he had the information he needed backed up and that it could be retrieved.  He had contacts for people who could rent him office space if he needed it.  He knew how to move his phone lines and data links over.  So the day when the building his business was in burnt to the ground, it proved easier to open somewhere else.  His business is still open while others in the same building failed to ever reopen.

The problem with this approach is that we start business for one simple reason and that’s because we want to make money.  We want to put a roof over our heads, food in our bellies, go on vacation once or twice a year, and send our kids to college.  If we’re really lucky, we make enough money we can help other people do the same thing by hiring them to make more money for us.  Nowhere on this planet has a business ever opened its doors with the business planning of going under at the first hint of trouble.

Reason number 2:  We stole the plan.  Well, maybe stole is too strong a word.  What they did is they took someone else’s plan and altered it to fit them (changed names and etc.), but at the end of the day, that plan has very little to do with our company.  While there might be only so many ways to recover a Windows Domain Controller or an Exchange server, what if there are special needs for your company.  Where people get stuck here is they fail to understand the dependencies their system may have.  Like for instance, say you have to restore a domain controller, but your data recovery method assumes that the domain controller is up and going.  What do you do.  Too often stolen plans fail to take that into account because you didn’t put any thought into it.

Reason number 3:   You went through a lot of trouble to get a good plan, you’ve let everyone know you got a great plan, and then you rested.  In short, you let a great plan go out of date.  Plans should be reviewed at a minimum, every 6 months.  And anytime you make a change such as adding servers or services, retiring others, or changing some aspect of your operation, that needs to be reflected in the plan.

It might be argued that an out of date plan is worse than no plan at all because now you have a feel of security that may or may not still work for you.  We’re faced with having to update plans constantly in our lives.  Children are born or leave home, we find ourselves looking for new work or a new city, or simply trying to figure out how to rearrange the living room.

We need to connect that our businesses because business changes at a frightening speed.

Reason number 4:  The plan is just too complicated.  It happens more than you’d think.  I’ve seen disaster recovery plans that were beautiful, with flow charts of if this works, do this, and if not do that.  What you end up with is a plan no one can follow and unfortunately becomes too complicated and might not allow for natural human creativity.  The biggest problem here is that we think we’ve thought of every possibility and then some, but what happens in the real world rarely matches our expectations.

TOP-7-522X90 (1)

Richard is a freelance IT consultant, a blogger, and a teacher for Saisoft where he teaches VMware Administration, Citrix XenApp, Disaster Planning and Recovery for IT, and Comptia Server+