News Stay informed about the latest enterprise technology news and product updates.

Testing IT disaster recovery plans

Don't overlook the importance of how applications depend on each other for data when testing your DR 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 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.

Dig Deeper on Disaster recovery planning - management

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.