RPO Validation of No Data Loss

[x166366]

I coordinate the technology BC and DR recovery testing at my organization.

Our Corporate Office and Auditors are requesting that we should in the test execution plans steps that demonstrate the RPO objectives and steps that verify that there was No Data Loss experienced in the application and system recoveries.

I have responsibilities for 50+ Critical Applications requiring an RTO of less than 24 hours.

I understand the concepts of RTO thoroughly. My problem is that these applications all use various database products and I do not know what to identify or how to identify a step or steps in a test exercise that demonstrates No Data Loss (RPO).

I am looking for techniques that I could use to focus on to articulate RPO objectives are meet.

What tasks can I add to BC Test plan that would provide evidence that there was No Data Loss or that that data loss is within the RPO Objectives for each application?

The database products I use are ORACLE, Progress, SQL, and DB2.

Keep in mind that I know that log shipping, journaling, mirroring, and tape loads are techniques to load databases and keep them synchronized, I am looking for something that explicitly says that the Production Database is equal to the Contingency database.

I would appreciate any help anyone has to offer.

[rtoledo]

Reading your question, made me remember a presentation that I saw of "Veritas Disaster Recover Adivisor:http://www.symantec.com/disaster-recovery-advisor" that is offered by Symantec. Check it an see if it helps you.
Regards,
Roberto Toledo

[grewjac]

A zero RPO is a matter of putting a data protection solution in place that has data captured on the production storage in parallel with another storage system located in a secure facility suitable distance away, usually within 25 miles or so. These are commonplace in banks, where transactions simply can NOT be lost, because a second or two can mean millions of dollars lost. In banking, RTO's tens toward zero RTO as well, and those solutions have been around for years.

So, to test, I would imagine it's possible to simulate a disruption at a specified time by stopping the production feed for a few minutes, check the data at the failover site to see if the data captured equals the stop point, then fail back to the production environment. Yes, this would have to be done during a "slow period, like a weekend night preceded by a DO NOT LOG ON message to all users. But this is the only way to know if the chosen architecture actually does what it's supposed to do. If it doesn't, the test is a success because you found a vulnerability still exists that needs fixing.

You mention your Corporate Office and auditors are looking at "test execution steps that demonstrate the RPO objectives..." The solution design does that, NOT the test plan. In testing, you execute THE PLAN, which, in this case, is an automated failover of data capture and either an automated (if zero RTO) or manual (if RTO is greater than a few minutes) failover of processing. In a zero/zero solution, no one does anything, the infrastructure and programming do it. And that's how you test it.

[x166366]

Rtoledo and Grewjac,

Thanks for your replies. Some of the clarification you provided and the links were very helpful.

Every reply helps me to better articulate the subject of RPO to my management.

Keep them coming..