EMC RecoverPoint – Repository and Journal Volumes

Last week I have created a post describing EMC RecoverPoint Architecture – mostly from hardware point of view.  This time I would like to go a little bit into software. As you already known, an RPA (RecovePoint Appliance) manages all aspects of data protection for a storage group, such as maintining the images in the Journal Volumes. But what are Journal Volumes? What is the Repository Volume? Let me answer those in this short post

Repository Volume

The Repository Volume is a special type of volume which is dedicated on the SAN-attached storage for each RPA Cluster. Important to remember – one Repository Volume for each RPA Cluster. This volume stores configuration information about the RPAs and Consistency Groups. It is used, for example, during one of the RPA failure in a cluster, when rest of RPAs (within same cluster) are taking over its job. Beside the function, Repository Volume, is a normal volume, that can be provisioned from example from VNX. Although it should not be a thin LUN (rather thick, or traditional RAID LUN). In addition – the volume cannot be located on a VPLEX distributed device

Journal Volumes

Journal Volumes are very much connected with Consistency Group term, that I will describe a little bit better later. For now you can think of Consistency Group as a group of volumes, the CG ensures that updates to the production volumes are also written to the copies in consistent and correct write-order. Consequence: Copies are always consistent. Now – back to the Journal Volumes. Each copy of data in a Consistency Group must contain at least one volume that is dedicated to hold poin-in-time history of the data. Journal volumes hold snapshots of data to be replicated – holding as many poin-in-time images as the capacity allows. There are two types of journal volumes:

• Replica (Copy) Journal(s)
• Production Journal(s) – this one is more-or-less not used during normal operation, however it is necessery and being used when the relationship is promoted to secondary side.

Journal Volume cannot be masked to host(s) – only RPAs in the cluster should have access to it.

In synchronous replication, every write is retained in the replica journal, so you can recover to any point in time. In asynchronous replication, several writes are grouped in a single snapshot. The granularity for async replication can be set to seconds or MBs.

Above  you see the example of both CPD and CRR replication. As you can see we have three Journal Volumes:

• two Replica (Copy) Journals
• one Production Volume

As I mentioned above, normal operation doesn’t include Production Journal Volume, both CDP Replica Volume and CRR Replica Volume are used for communication between RPA (in this case vRPA) and Storage.