Testing IT disaster recovery plans

Robert L. Scheier
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

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.

There are Comments. Add yours.

TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to: