The fear that business services – or indeed the business itself – might not be recoverable after a disaster-level event results in many sleepless nights for CIOs across the world. But it doesn’t need to be that way.
Disaster recovery planning, a subset of business continuity, comprises the process, policies and procedures required for the recovery or continuation of technology infrastructure after a disaster-level event.
Disasters come in multiple forms and may be highly unpredictable in nature, but the effect they have on your business can be calculated and mitigated against through robust preparation and testing.
So how do you avoid those sleepless nights? In short, you prepare for the worst case scenario. Imagine you lost everything in and around your primary datacentre facility.
There are four key questions that need to be answered to have confidence in your disaster recovery (DR) solution:
- Can my DR infrastructure be affected by the same disaster that destroyed my primary datacentre?
- Has my DR solution been designed and built to ensure adherence to application recovery objectives – ie, recovery point objective (RPO) and recovery time objective (RTO)?
- Are my DR processes documented, accessible and understood by everyone who might have to follow them?
- Can users connect to applications that are running from DR? (Remember the primary datacentre and associated networks may not be there any more.)
While an audit that answers the above four questions will help, the only way to be sure that an organisation is DR ready is by testing, testing and more testing.
DR tests are scary and expensive, but are invaluable exercises which assess both the disaster recovery solution and the people who execute it. Regular DR tests alleviate the stresses associated with the unknown and regular practice will reduce time to recovery in disaster scenarios.
Hywel Matthews is principal consultant at GlassHouse Technologies (UK).
This was first published in August 2013