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