Disaster recovery is one of the most pressing issues facing IT departments. Time is money, after all, and the longer your key business systems take to recover from unexpected outages or outright catastrophes, the more money your business stands to lose.
But no system is perfect, and even if you could create a DR program that could instantaneously bring your failed systems back online, the costs might actually be greater than the impact of the downtime. So, like everything else in business, disaster recovery often boils down to prioritization.
Our partners at the Dummies line of how-to books take a detailed look at prioritizing DR response levels in their guide to IT Disaster Recovery, an excerpt of which is available free to IT Business Edge members here in the IT Downloads library. The 22-page PDF covers a wide range of disaster recovery planning and maintenance issues.
In its discussion of response plan prioritization, the book considers a hypothetical business that has categorized its business processes in three tiers:
Tier 1: Absolutely critical
Tier: 2: High impact
Tier 3: Important, but a few days of downtime won't be crippling
You can see a portion of the table that lays out the three layers of DR response in the figure below.
The first two metrics in the table are, as you might expect, the most fundamental in determining what tier of DR service a business process warrants. The recovery time objective (RTO) is how long the service of application can be down before business continuity is seriously damaged. The Recovery Point Objective (RPO) is a measure of how much data loss (by time) is considered acceptable before the business is seriously harmed. In the hypothetical presented here, losing just one minute's worth of data from a Tier 1 process would likely do long-term harm to the business. For most shops, we are not talking about email here - think credit card payments or health insurance claims.
Every business manager thinks their process is vital, so objectively reviewing the impact of a business process failure is the first step in meaningful DR prioritization. The book also notes that it's critical to have essentially the same disaster recovery plan in place for all applications in a tier - case-by-case customization is not an option if you are serious here. You'll note that hardware, OS and database software are also included in the tier criteria; network standardization is a lynchpin of disaster recovery planning.
The book excerpt has a wealth of other great tips for any shop looking to shore up its disaster recovery planning and documentation, such as:
Treat high-value documents such as Business Impact Analyses (BIAs) and DR procedures as reverently as software source code. The book suggests keeping these documents locked away in a "vault" of your document management system where only authorized personnel can view them.
Have new staff members read through the BIA to help them see the big picture about the business's critical processes. This should happen within a week or so of the hire.
Be highly mindful of changes in the nearby environment. This included keeping an eye on road and utility crews in your office campus.