Testing IT disaster recovery plans

Article

Testing IT disaster recovery plans

In testing IT disaster recovery (DR) plans, IT staffs often overlook how applications depend on each other for data and don't understand which related sets of data need to be backed up and restored

    Requires Free Membership to View

    When you register for SearchDisasterRecovery.com, you’ll also receive targeted emails from my team of award-winning editorial writers. As you know, an interruption can threaten your organization at any time – and it’s our goal to ensure you’re armed with the right tips and information to help you ensure a swift recovery.

    Rich Castagna, Editorial Director

    By submitting your registration information to SearchDisasterRecovery.com you agree to receive email communications from TechTarget and TechTarget partners. We encourage you to read our Privacy Policy which contains important disclosures about how we collect and use your registration and other information. If you reside outside of the United States, by submitting this registration information you consent to having your personal data transferred to and processed in the United States. Your use of SearchDisasterRecovery.com is governed by our Terms of Use. You may contact us at webmaster@TechTarget.com.

to the same point in time, said Bill Peldzus, vice president of data centers, business continuity and disaster recovery at GlassHouse Technologies Inc., in Framingham, Mass.

More on disaster recovery planning
Change management in disaster recovery and business continuity planning

Using data classification tools to aid in disaster recovery planning

Disaster recovery team planning: Guidelines on DR roles and training


By failing to fully understand application dependencies and properly identify "consistency groups" -- related sets of data which should be updated to the same point in time -- organizations risk running disaster recovery tests that don't accurately reflect how well an application could be recovered after an actual disaster, he said.

For example, an order-entry system might have a recovery point objective (RPO) and a recovery time objective (RTO) of four hours. A customer database with which it shares data might have an RPO and RTO of 12 hours. When the data for both applications is restored in a test, "you have customers without orders and orders without customers because the data wasn't recovered in a consistent fashion," said Peldzus.

While many replication applications can identify consistency groups, they're much more difficult to use across different platforms, such as PC-based, minicomputer and mainframe servers, he said. Often, test designers lack the time to properly configure such tools to account for all of the platforms a company operates, said Peldzus.

Peldzus also recommends that companies test to see if they can recover all of their critical apps within the required time period, rather than (as is often the case) only testing the apps needed by one business unit or that serve one function, such as email.

Finally, he suggests testing critical apps most often. Apps with recovery point ojbectives or recovery time objectives of fewer than 24 hours are candidates for testing two to four times per year, rather than just annually, he said.

This article originally appeared in Storage magazine.

About this author: Robert L. Scheier is a frequent contributor to "Storage" magazine.