“What’s the most important factor when it comes to Disaster Recovery?”
Management buy-in and acceptance, hands down. You can have the most rock-solid plan, with DR options for all the servers, and it all won’t matter if you didn’t align your plan with what management expects to see and get from an availability and recovery standpoint.
If you thought getting all the servers back up in eight hours was fine in the event of a fire, but management thought it was only going to be two, there will be a lot of friction when the plan is actually implemented.
However, you aren’t going to give management the detailed and pages-long table that we discussed in the previous article. In fact, you don’t want to make that other table until you hear management’s expectations. You would never get them to read it or pay attention to it anyway. What you have to do for management is give them something more simplistic and easy to digest.
The above would simply outline by overall business feature. “Email, ERP, Accounting” with a more generic disaster level. It would be up to the IT staff to translate this more generic table into the detailed one from the previous article and make sure everything required for ERP could fail over from one datacenter to another on campus, and then be recoverable at the DR site within 12 hours. And, ensure it will be recovered if both the main site and DR site failed in less than two days. Once management buys into a table such as this, when a disaster comes, two things happen:
- IT is protected as long as they can deliver on what they promised.
- When management asks how long until everything is back up, IT can point to the DR plan they signed off on and say “we are at a campus failure, based on the approved DR strategy x will be up in y hours”
Once you get management’s expectations and start to make IT’s table, keep in mind dependencies. If the ERP system is supposed to be up in <12 hours, remember you may need AD, SQL clusters, web servers, and various other systems up. If meeting that need isn’t possible with your current system, management must know that it can’t be done with existing systems but that it could with specified, upgraded technology, or their expectations should be modified.
Check out last week’s post on considering the end user when creating your disaster recovery plan, or skip around to read the rest of our series:
- What is a Disaster?
- How to Construct a Proper Disaster Recovery Plan
- Technical Documentation
- Care and Feeding