Disaster Recovery – when to declare one?

Disaster Preparedness/Recovery
Disaster Recovery
Disaster recovery planning
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..


Answer Wiki

Thanks. We'll let you know when a new response is added.

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.


Discuss This Question: 4  Replies

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.
  • Meandyou
    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.
    5,220 pointsBadges:
  • JennyMack
    CharlieBrowne and Meandyou, Great, informative answers here. Thank you! Jenny Community Manager
    4,280 pointsBadges:
  • Kevin Beaver
    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.
    27,550 pointsBadges:
  • Lightmike
    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.
    245 pointsBadges:

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

Thanks! We'll email you when relevant content is added and updated.


Share this item with your network: