Six Considerations for More Effective Disaster Recovery

May 30, 2016 (919 Views)

Disasters happen. They could be natural catastrophes. They could be human-driven. But they happen. And by definition, they’re always sudden and unexpected.

That’s why IT pros have to be prepared. Having a defined,tested and comprehensive disaster recovery plan is an essential part of running any business. The more effort put into planning for different disaster recovery (DR) scenarios,the better prepared your business will be.

6 Things to Consider When Designing Your Disaster Recovery Plan:

1. RPO

RPO(recovery point objective) refers to the specific point in time to which you require your data restored. If disaster strikes, will data restored up to the end of last week be sufficient? Or do you need it to include the last few minutes right before failure? Your RPO is directly related to your backup schedule.If your backups are taken nightly, then your RPO will be data restored to the end of the previous day.

RPO may be different for the various parts of your business.The reporting data warehouse, for example, might only need a RPO of one week. Your sales department, however, will likely need to be as near to real time as possible. Having different RPOs presents its own challenges. It’s important to make sure that systems with varying RPOs do not have dependencies between them that can break when data becomes out of sync. Try to settle on a realistic RPO that will not impact operations significantly.

2. RTO

RTO (recovery time objective) is the target time you require systems to be backup and running following a disaster. By deciding firstly what your RTO needs to be, you can then determine what recovery methods will be required. A process with a one week RTO can be recovered with much simpler solutions compared to a system with a one hour RTO. Often, business activities that have a very small RTO require a hot or warm stand by ready to go. The clock starts ticking as soon as your applications become unusable. Try to balance impact on your users against cost and practicality of time to restore.1_Body

3. Automatic or manual failover

Which parts of your DR process will be automatic, and which will require manual intervention? Although it is possible to fully automate your entire DR process, it is a good idea to include a human component in at least a decision-making capacity. Some of your systems with short RTOs may require more automation, where as a higher RTO allows more time for manual configuration.

4. Documentation

Best in class DR plans usually begin with an outline of clear action steps and key contacts. When disaster strikes, it is crucial to have accurate documentation and procedures in place. This way it is just a matter of switching into DR mode and following through the plan.

Documentation should be:

  • Readily available
  • Easy to read
  • Up to date
  • Stored offsite

5. Security

Although a large amount of attention is normally given to security in general, it is also important to ensure that your DR plan and processes are secure. One important consideration is around the security of your backups. Is access limited to them? Are they encrypted? Where are the encryption keys stored? Another thing to plan for is security after the fact. When your DR plan is invoked and alternative systems are brought online, it is important to make sure that your usual security policies are still adhered to. Just because there is a disaster is no reason to ignore security.

6. Disaster recovery team

A DR team should be set up to take charge and organize the work that needs to be done in event of disaster. It’s important that there are clear responsibilities and roles. In a time of crisis, the last thing you need is doubt about who is doing what.

A DR Team should contain:

  • A project manager
  • A deputy manager
  • DR coordinator

Creating the DR plan is a great achievement, but it is only one part of the entire DR solution. Studies show that between 23 and 46 percent of companies don’t test their DR plans at all. Practice drills should be carried out on a regular basis, and change management should include a DR component to ensure that documentation and configurations are kept up to date.

A rock solid, tested and consistently updated DR plan will go along way toward ensuring that when disaster strikes, it is merely an inconvenience for your business.


flickr photo by Jennifer Kelly shared under a Creative Commons (BY) license
flickr photo by Jennifer Kelly shared under a Creative Commons (BY) license

(No Comments)

Top Related Posts

Written By

  • Dan O'Shea

    Dan O'Shea has covered the telecom and IT sectors as a journalist and technology analyst for more than 20 years. His reporting and analysis have appeared in Entrepreneur magazine, Light Reading, FierceTelecom, Telephony and elsewhere. He is based in Chicago.

Nerdio Blog