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.
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.