Spell out IT’s Disaster Recovery Capability
August 4, 2010Can
your IT department articulate its ability to withstand and recover from a disaster? Knowing IT’s existing ability to withstand and recover from disaster provides a baseline from which all future disaster recovery (DR) enhancements and/or downgrades can be made.
However, without understanding where the business’ needs begin and end, IT will be blindly assembling disaster recovery objectives. The organization will either waste money on unneeded DR or, won’t be fully prepared for disasters.
Buy-in is not as elusive as you might imagine, but here are some tips just in case:
- Many organizations have found that simply explaining DR’s relevance to the business and the company’s survivability goes a long way in generating buy-in.
- If you have trouble getting buy-in from the business group, try focusing on one key individual. If you can win over a business leader and have them champion DR to the rest of the departments, then the process should be much smoother.
One of our clients, a consulting company, went so far as to place an executive from the business side of the organization in charge of the DR initiative in order to get buy-in for the project from both IT and the business. Due to his connections with other business stakeholders and the relevance of the project to IT, the executive was able to collect input from both sides and build the organization’s DR capabilities to the satisfaction of all involved.
Milestones on the Path to Understanding
You can’t know which direction your organization should head in until you know where it stands. Ask yourself:
- What is IT currently doing? Are there multiple data centers? How often is data backed up? What are the general practices around storing data and fixing technology problems? Whether IT realizes it or not, aspects of DR might already be incorporated into their standard operating procedures.
- How do these practices translate into measurable statistics? Once IT recognizes what’s being done, it becomes a matter of recording how effective those practices are.
Recovery objectives are a useful metric for determining effectiveness. They are the metrics that set the level of your organization’s DR capability. The Recovery Time Objective (RTO) is the amount of time and organization can afford to have its systems down (e.g. the organization’s systems can be down no longer than one hour). The Recovery Point Objective (RPO) is the point in time beyond which an organization cannot afford to lose information (e.g. the organization can afford to lose 24 hours data/processing).
RTOs and RPOs vary depending on the needs of the organization and the criticality of the system/data they are relevant to; they can range from less than an hour to more than a week. Off-site back up does not result in RTOs and RPOs of zero hour. Unless data is streamed to redundant facilities and simultaneously processed, outages can still occur.
Knowing what recovery infrastructure and systems are in place is the first step in understanding how your organization can improve recovery times. If you know what you currently have, then it’s much easier to identify what you still need. A review of your organizations’ resources may also identify what can be cut, and thereby save your organization from some unnecessary expenses.
You can save time and money by properly scoping your disaster recovery capabilities prior to creating the actual DR plan. Properly scoping DR will prevent over spending and ensure a good return on investment.
This entry was posted in Infrastructure, What's New in Research and tagged disaster-recovery, disaster-recovery-planning, drp, recovery-point, recovery-time, rpo, rto. Bookmark the permalink.
Comments are closed.