Pointer-Based Virtual Replication: Need Clarification

Hi Tim,

The health of the pointer-based replica is dependent on the physical health of the source (production) volume; if the source volume becomes physically corrupt, then (as you say), the pointer-based replica is of no use (just one of many possible examples of this would be two failed drives in a RAID 5 source volume). Some vendors refer to a pointer-based replica as a 'compact-dependent' replica, i.e. the replica's size is less than that of the production source, and it's health is dependent on the physical health of the production source.

Having said this, the pointer-based replica can certainly be of use if there is a logical corruption of the source volume. Imagine that we receive some new database binaries/patches from our software house, and we fail to test those binaries thoroughly. The binaries go 'live', and those binaries corrupt the source volume. Because of pointer-based technology (e.g. 'copy on write' and 'copy on first write'), the original PIT source blocks will be copied to the pointer-based replica before they can be written to by those new and inadequately tested binaries. Once the logical corruption has been detected, we can restore the source, from the pointer-based replica, to the PIT at which the pointer-based replica was created.

Just to build on this. Imagine that (just examples only):

• We have a 500 GB database
  
• We need to address the needs for protecting against logical corruption
  
• Our desired RPO is 30 minutes
  
• We recognize that there may be unusual (according to our business dynamics) situations where 4 hours may pass before we realize that a logical corruption has occurred (meaning that we fail to meet our desired RPO).
  

So, over a period of 4 hours, and at 30 minute intervals, we could create a total of 8 pointer-based replicas (actually, it would be 9). Although it would depend on how busy the production source actually is, we would hope that the total space required would be less that 9 x 500 GB (the space taken up by 9 full volume copies). Let's imagine that the level of activity is such that the average change rate of the production source in 30 minutes is 5%, this would mean the space taken by the pointer-based replicas is 8 x 25 GB = 200 GB. (My use of 8 versus 9 is because if you build a fence with 'N' fencing panels, then there are 'N+1' fencing posts - any way, it probably deviates from the point of the answer).

There are also other good use cases for pointer-based snapshots. Here is another example:

Let's imagine that the customer wishes to backup a 500 GB database, and the backup needs to represent a database that has transactional consistency. So, a traditional approach would be to quiesce the database, and then perform the backup. However, with the technology that this imaginary customer has, the backup will take several hours, and so, that is several hours during which the database must remain quiesced. An alternative approach would be to quiesce the database for several seconds only, create the pointer-based replica, un-quiesce the database, and then use the pointer-based replica as a source for the backup - for the sake of a few seconds of down-time, the customer has a backup window into 500 GB of consistent data. Another use case would be to use the pointer-based replica to test new binaries on a replica of the production database (or filesystem or whatever).

I hope that makes sense.

Best regards, Richard.

Richard,

This is a fantastic explanation. Your illustration is crystal clear. Really appreciate your taking the time to answer so fully!!

Tim

I was also wondrring the need of the virtual rerplica...

many thanks to Richard