RecoverPoint Vs MirrorView/SANCopy?

Hello Ravi,

RecoverPoint is designed to produce high frequency snapshots of production data. By default, RP can create a crash-consistent local replica once per second, but this can be changed from its default setting to 'once per write I/O'. So, by default, every second we have a crash-consistent PIT image that we can recover from, if the need should arise. These high frequency snapshots are preserved in a private LUN pool called the Journal. The journal needs to be sized accordingly for both capacity and performance.

Let's imagine that our database administrator discovers a d/b corruption at 10 am. If the Journal has been sized accordingly, we can recover from any previous crash-consistent PIT image that is present in the Journal (hence the Journal needs to be sized accordingly - read circular buffer here). Since, in my example, we have a detected corruption at 10am we could do the following:

• 
  
  • access the image from 9:30 am
    
    • IF 9:30 am image is corrupt
      
    • THEN
      
      • access the image from 9:15 am
        
      • ... repeat so as to continue to 'home-in' on that last good image
        
    • ELSE (9:30 image is good)
      
      • access the image from 9:45am
        
      • ... repeat so as to continue to 'home-in' on that last good image
        

So, we can use a 'binary-chop' method to identify (and recover from) that last good image. (As a storage admin, the RTO may depend on our good working relationship with the d/b administrator).

This small post cannot do justice to all the other benefits of RecoverPoint. Some of which are:

• Heterogeneous support - RP supports both local and remote replication between heterogeneous arrays, including arrays from different vendors (but follow the support matrix, of course)
  
• Intelligent GUI work flows for 'restores, from a local or remote replica, to production' and 'failover, from production, to a local or remote replica'
  
• Optimized remote replication (compression, hot-spot detection, data de-duplication).
  
• RP guarantees that all PIT images are 'crash-consistent' by preserving write-ordering across all volumes with a RP Consisteny Group.
  

So, RecoverPoint micro-snapshots. If the Journal is sized accordingly, RP can preserve a crash-consistent PIT snapshot once-per-second for several days (or longer). However, important to remember here that RP is designed to mitigate against 'short-term' data loss and 'short-term' data corruption. Definition of short-term here will vary from customer to customer and data-set to data-set.

One last point. In addition to the system generated micro-snapshots, you can also configure your own manual snapshots representing PITs of transactional consistency (eg. put database into hot backup mode, and then take a RP manual snapshot, or, unmount filesystem (sync buffer cache) take a RP manual snapshot). Both the system generated and manual snapshots are held in the Journal.

Does this make sense?

Thanks, Richard.