|
Back to DR planning basics
There haven't been many recent disasters, but that doesn't mean you can forget disaster recovery practices.
In the wake of Hurricanes Katrina, Wilma and company, there's been a sharp rise in the overall awareness of disaster recovery (DR) and the desire to improve DR capabilities. But the 2006 hurricane season represented something of a reversal from last year, and without the same high-profile disaster coverage, some companies may have been lulled into complacency. So it seems like a good time to reconsider some DR basics and discuss a lingering concern: the business-IT expectations gap.
I've written about business and IT alignment issues, a topic that has become standard fare in CIO-targeted publications. In the storage arena, we're seeing progress among forward-thinking companies toward better alignment of primary data and the beginnings of true business-driven, data-retention policies. However, DR is still one area where there's often a significant shortcoming.
In an ideal DR scenario, IT personnel would be prepared to handle multiple disaster categories with their actions dictated by clearly defined and documented policies and procedures. Application recovery would be prioritized on the basis of service levels driven by well thought-out recovery time objective (RTO) and recovery point objective (RPO) metrics. Much of the recovery would be automated through replication and other recovery tools.
Unfortunately, that scenario is more the exception than the rule for several reasons. First, like every other area within IT, DR is a balancing act; there's a trade-off between what we want to do and what we can afford. And by its very nature, DR is one of the biggest challenges IT faces. You must perform activities that are seldom done and accomplish them under the worst possible circumstances. Toss in the inherent limitations on planning and testing, and it's easy to understand why many IT professionals cringe at the mere mention of DR.
One of the fundamental prerequisites of successful DR planning is to understand the real requirements. What does the business need, and is it capable of addressing this need with regard to both capabilities and cost? As already noted, the key performance metrics to support this are RTO and RPO. Briefly, RTO is the maximum acceptable time to resume operations--not just to data recovery--and RPO is a measure of acceptable data loss.
The failure to understand and agree upon these metrics for critical applications, and the subsequent inability to invest in and develop capabilities to support them, is the basis for the DR gap between business and IT. Bridging this gap requires IT to meet with business and application owners to understand recovery needs so that the financial impact of outages can be quantified and then weighed against the cost of providing the necessary service level. This may require some negotiation, but the unavoidable truth is that without this conversation, DR success is impossible.
Building this capability goes well beyond a technology exercise. It consists of planning, identifying dependencies, developing processes and, above all, testing.
|
