Disaster Recovery – when to declare one?
Has anyone performed a business anlaysis regarding when to activate a DR plan? If a problem appears to be a memory that can be fixed within 4-5 hours...would you declare a disaster and move to your hot site...or would you attempt to fix the system problem and if issues still exist, then declare it a disaster. What criteria would you use in trying to evaluate when to declare a disaster and when to stay put and fix existing system..
Software/Hardware used:
Software/Hardware used:
ASKED:
January 18, 2010 7:42 PM
UPDATED:
January 18, 2012 5:00 PM
Answer Wiki:
When creating your DR plan, you should be looking at every aspect of your business and determining how long you can be without a specific function.
Then you try to determine the impact on business, customer relations, etc for every N period over that amount.
For instance some business may be able to have an FTP server be down for one day without a great impact and anouther business it might be one or two hours.
The same for internet access, and other processes.
Once that is done, you deterime the ROI on setting up your redundacy systems and you should have all the specs ready so that you are not making the tought decision at the time of the disaster. Rather you are following the plan.
A disaster exists when critical business processes are sufficiently impacted such that down-time procedures cannot prevent unsustainable harm to the organization. For example, down time procedures can typically keep critical processes going but at some point, recovering from the use of those downtime procedures (re-entering all the data accumulated during the downtime) is impossible.
kgb
To see all answers submitted to the Answer Wiki: View Answer History.
The procedures for our D/R plan state that if the recovery time at our local site will exceed 24 hours a disaster is declared and we go offsite.
We do not have a “hot” site for d/r. We have access to other computer systems, but we have to build them from the ground up. It takes about 24 hours to do this.
Hence, if it will take longer than 24 hours to recovey at local site, we go to d/r site. We have not done this for real. But we do go offsite and rebuild critical apps twice per year.
CharlieBrowne and Meandyou,
Great, informative answers here. Thank you!
Jenny
Community Manager
Bottom line – How’s it going to impact your business?
This is why performing a business impact analysis and documenting your plans before such issues arise is so important. Here’s a good resource.
Absolutely let the requirements dictate the solution as well as the activation plan. It’s business processes that need the technology. If a business process is mission critical it needs to be expressed in a tolerable amount of downtime, or response time objective (RTO). When does the disruption of the business process hurt the long term marketshare or financial viability of the organization?. If it is a really short period of time, then it is the requirement that dictates having a multi-site active cluster of services (“hot site”) that fail over without human intervention. Your question suggests you have built a “warm site” that requires a manual decision to transfer processing. This may be acceptable from a requirements (RTO) and cost-benefit standpoint (hot sites are inherently more expensive), but your business processes should dictate the number of minutes or hours you have to resume the business process that is dependent on the technology. Then you have your answer, if fixing the problem locally is estimated to be within your RTO guidelines, then fit it…If the estimated fix time exceeds the RTO, you declare and fire up the warm site.