The focus on dealing with the problems of an ordinary day of business make it difficult to stop and think about how you’ll deal with the challenges of an extraordinary day of business. That’s why many companies don’t even have a disaster recovery (DR) plan.
It’s easy to think that using Disaster Recovery as a Service (DRaaS) is as good as having a DR plan. But using DRaaS doesn’t eliminate the need to have a written DR plan. DRaaS provides a mechanism for getting your systems back online; it doesn’t eliminate the need for your team to execute a sequence of recovery procedures.
Using DRaaS also doesn’t mean you don’t need to test your DR plan. While you should be able to rely on the DRaaS vendor’s services, the purpose of DR testing isn’t just to validate the documented recovery steps to bring applications back online. It’s about making sure the plan is complete and that the business, not just your applications, is able to recover.
Identify Missing Information to Complete the Plan
This means one of the most important goals of the DR test is to identify missing information that would be needed in a crisis. Even if every employee isn’t involved in a DR test, contact lists and call sheets need to be updated. Responsibilities should be reviewed and reassigned if needed.
The test preparation should also look for any applications or data sets that were omitted when the DRaaS process was designed. This can mean new applications that have been added, or end-of-quarter and end-of-year processes that no one remembered when the plan was originally written.
Test the Plan to Verify Business Recovery
A complete disaster recovery test requires simulating a day’s business and needs end users as well as the tech team to participate. Although a cloud-based DR service may let you bring up your DR systems in parallel with production, getting the necessary business participation may mean scheduling the test during off hours. If the business process requires connectivity to external vendors, you may need to coordinate with them to verify that DR servers can establish connections and to prevent test traffic from being treated as real.
You should simulate a full day’s processing during your DR test. This will let you confirm that your capacity can satisfy performance requirements. If the business has grown since the DR process was created, system restarts may take longer than expected and performance may not be enough to get a day’s business done.
Update Your Test Plan and DR Environment
After the test completes, there should be a post-mortem that reviews what went right and what went wrong. Test scripts need to be updated to correct steps that didn’t work as written or add procedures that were omitted. You may need to modify your DR service to include applications, data, or virtual machines that had been previously overlooked, or resize servers to provide more capacity or higher processing speeds.
Once you’ve gone through a test, done your post-mortem, and implemented any changes, don’t file the plan away and forget about it. Think about including updates to the DR plan as part of your change control or application deployment processes. Otherwise, those changes won’t be covered by your plan and you’ll have to scramble if disaster strikes before next year’s DR test uncovers the omission.
And put next year’s test on the calendar now; this isn’t a one-and-done event. Keeping your DR process current and making sure it’s effective is an ongoing process you need to repeat as long as your business is in business.
dcVAST helps organizations implement effective backup management and disaster recovery processes, including providing managed NetBackup and disaster recovery as a service. Contact us to learn how to test your DR process and how you can achieve a more robust, efficient recovery process.
