• Press Center
• Press Releases
• Media Resources
• Media Contacts
• In the News
• Podcasts
• Awards
• Careers
• Submit Feedback

Newsletter

Processor

October 24, 2008

by Curt Harler

Full text of original article at PROCESSOR web site

Disaster Recovery Testing

Make It A Benefit, Not A Burden

Many managers fear that disaster recovery, aka DR, testing is expensive and disrupts daily operations. The onus is on IT staff to convince management that DR testing is more a benefit than a burden.

"While it's useful to have a written plan, it's more important to test that plan," states Stephen Lawton, senior director of strategic marketing for Acronis (www.acronis.com) in Burlington, Mass. "All one need do is look at the devastation in Texas or Louisiana to see what can happen when a natural disaster strikes. Companies without a plan in place, with data stored locally and offsite, can disappear as quickly as a twig hut on Galveston Island."

Testing helps with little problems, too. "Not all disasters are smoke and rubble. Most are just recovering lost files," says Jon Toigo, managing principal with Data Management Institute (www.datainstitute.org) in Tampa, Fla. He says that testing is generally seen as "complicated, time-consuming, and a pain."

"Testing should not be looked at as a chore but rather as part of the regular security maintenance operation," Lawton says. "Just as you make sure your firewalls are working, antivirus and antispyware software is updated, and that applications and the OS have the appropriate security patches, your DR testing is a maintenance issue."

He continues, "Every company needs a DR strategy. But just as important, every company needs to know that the plan will work. The only way to ensure a plan is adequate and that all of the employees know how to implement the plan is to test it."

Not All About You

When presenting a DR plan to management for testing, IT should focus on what's important to its audience — in this case, the bottom line. "Ask how long the company could survive if it didn't have its mission-critical applications. Without email or financial applications, a company comes to a grinding halt," Lawton says.

Management is not the only group that will benefit from testing DR. IT, like any corporate department, has staff changes. "It's critical that new staff members be trained on the company's DR plan," Lawton says.

An SME with 20 servers might have only four that are mission-critical. "Does everyone know which servers they are and which applications must be up and running all the time?" Lawton asks.

In a regional catastrophe, does everyone on the IT team know how to move key servers to a remote location? What kinds of preparations have been made? Do they know how to take the backup image of the Windows Server running Exchange and bring it up on a remote Linux server running VMware or Microsoft Virtual Server?

According to Lawton, "The ideal situation is to have your most experienced engineers solving the most serious IT issues and to have less-technical staff restore servers to working condition. This is possible with the right disk-imaging software, but, as in all aspects of life, practice makes perfect."

Many department heads will raise valid objections to DR test schedules. Given that end-of-month is a bad time at most SMEs, there is no one-size-fits-all answer to the question of when to test. The IT manager should chat with other department heads to determine the best time to test.

"This assumes that the backup would impact the company's existing servers. That's not always the case," Lawton says. He notes that, with the appropriate software, SMEs can test plans any time—including end-of-month or end-of-year periods for finance. "The key is to make sure you don't interrupt those servers," he continues. "Do this by using image-based backup software." In such a test, restore the image to different hardware — perhaps locally or even at a different location by using FTP to move the image from the local site to a remote one where the backup servers are located.

"This way, finance's servers are not interrupted, but you still can do your tests. Plus, it makes the tests more authentic, since if there's an emergency, you likely would not be restoring the exact same hardware," Lawton points out.

Testing Frequency

Assuming that there are no major changes in infrastructure or staffing, the consensus is that SMEs should test about once a quarter. "If there is a significant change in infrastructure or staffing, test the plan immediately, regardless of the last time it was tested. If there is staff turnover, test more frequently," Lawton advises.

Toigo says an SME can keep a plan current by eliminating technical factors and focusing on logistics. "If you do that, you can do a recovery rehearsal two or three times a year and eliminate a large share of the hassles."

"Part of the issue of testing is removing the FUD (fear, uncertainly, and doubt) about why it's being done and then making the testing as transparent to the users as possible," Lawton says. "Remember, if you interrupt user operations, it won't be an easy process. If you use software that can run all of the backup and recovery tests in the background, your users and customers will never notice — and isn't that the goal?"

One way to make DR testing less painful is to make sure that you are testing accurately. For example, Lawton asks whether you are testing the mission-critical servers that must be restored first or testing every server in the company, including file and print servers. Perhaps those servers don't need to be tested the same way as the Exchange server, he suggests.

"If you have software that monitors specific data or specific servers, perhaps you can adjust your test so that you're not duplicating efforts. Create the right kinds of tests for your environment — one size never fits all," he says.

Other Tips

"Build in recovery — don't bolt it on," Toigo says, adding that elimination of things involved in recovering applications or platforms simplifies the process. Data copying should be routine.

"Test restoring systems to different hardware," Lawton advises. He says that restoring to the same system is unlikely. With a serious problem, such as a natural disaster or a major hardware failure (such as a motherboard), Windows will not be restored to the exact same system with identical hardware.

"Also, try restoring to and from virtual machines," Lawton suggests. "Creating a VM and loading your backup image there will likely get you up and running very fast. However, many virtualization vendors don't offer tools to migrate from a virtual environment back to a physical one, so be sure your DR software has that ability."

Toigo is not so sold on VM, calling it "a tower ready to fall over." He prefers wrappers — products that put an SME's infrastructure into a recovery envelope and fail it over as a complete package.