I recently ran across a new feature in EMC Replication Manager 5.3.1. Users now have the ability to create SnapView replicas of RecoverPoint CDP, CRR or CLR target volumes. This improves recoverability and resiliency significantly by reducing the time the target volume has to be in physical access mode for backups or remote side testing activities.

The impact of mounting a RecoverPoint replica has always been a challenge. You have these nice consistent copies of your data in a remote location, so wouldn’t it make sense to mount them to a backup server and back them up? Additionally, wouldn’t it be convenient to test that application patch prior to going live?

The downside regarding these functions is that within logged access or physical access mode, users have a limited amount of journal space for incoming replication, and by default an even smaller amount for target side writes. If either of these fill up, you lose journaling and have to re-sync, and/or lose access to the target side volume.

Previous to RM 5.3.1, the only option was to halt the replication, roll to physical access and perform your activities. This left users without replication for the duration of the testing/backup. If you were to take a snapshot or mirror using SnapView, you could resume the replication much sooner, but now we have all kinds of moving pieces to keep track of. That kind of complexity is sure to breed mistakes…

RM 5.3.1 addresses this issue head on with linked jobs.

Under the covers, all of the previously described complexities are still going on. It is orchestrated, though, so that nothing gets fat-fingered and the application’s consistent bookmark gets mounted, rolled to physical access, SnapView creates its replica, and that replica is mounted to a mount host.

There are two ways to configure SnapView replicas of RecoverPoint targets: two-phase jobs and copy jobs. With a two phase-job, RecoverPoint CDP or CRR is selected as the source and the SnapView snap or clone is selected as the replication technology. This method leverages the link job mechanism. The copy job references an existing RecoverPoint CDP or CRR job as the source of the SnapView replica. I realize this seems redundant, but there are many situations where you may want to separate jobs that are called by separate schedules.

If you want more details on any of these technologies or have any comments, please drop me a line below.

Photo Credit: Jeff Howard