Extra Copy using Recoverpoint with VPLEX

Roy,

I assume you are talking about the CDP copy, this is entirely necessary and provides you with a lot of flexibility.  The Recoverpoint copy and the VPLEX mirror are providing different things.  VPLEX is providing ultra high availability, RP is providing any point in time recovery.

In a lot of use case you might not want to halt your production to do certain recovery options or you may only want to access a copy at a particular point in time. The CDP copy can be rolled forward and back to various points in time and accessed independently maintaining replication and protection for the production copy without impact to production processing or compromising your RPO.  The CDP copy can also be used to restore your production to any point in time (within your RPO defined when creating your journal).

EDIT:: Tidied up my english. 

Hi Paul,

Thanks for answering my question. Not sure if we are dealing with CDP. The document is not telling. Anyway It's the journal which provides and hold the 'copy'. I know every IO is split and saved to the journal. All functionalities you mentioned like rolling back and forward is possible too etc.

Why the extra copy? I am still confused. Or am I missing something?

ps. In my original post opinium=opinion ;-)

Ok, I assumed you need a copy LUN for each production LUN. But you use it the same as the journal, as per consistency group right?

But in the end a copy LUN should be the same size as the original. Even if they make part of the consistency group. Your copy LUN should be the same size as all LUNs in the consistency group. Thats your penalty correct?

Roy,

I don't know whether you'd call it a penalty or not but yes your copy luns need to be the same size or bigger than your source lun so you need to have at least 200% capacity + the journal capacity, so there is an overhead but you're buying into that with the recoverability you now have and it's planned for with this type of technology.  

Hello Roy,

Just like Paul said, "The Journal doesn't hold a full copy of the data, it's normally something like 20% for example, and sized to be able to cope with some server side processing, i.e. you can do work on the copy without compromising your RPO.  You have a single Journal for your consistency group, not for every volume being copied.  Changes are accumulated on the Journal and then applied to the copy."

The copy here, is the CDP copy that the RP Appliance is replicating it's writes from the production source, to. The journal alone will not suffice, if you lose your production volumes due to a corruption or a failure. Also, if you need to make some tests on the data and cannot afford to do that on the production volumes, you can select a recent image (because the writes on the production volume are replicated to the CDP copy volumes and the history is stored in the journal) from the journal and "enable image access" on the CDP copy. That way, you will be able to make modifications on the CDP copy and later discard the changes once done with your testing [the journal will undo the changes you made on the CDP copy]

You're most likely dealing with a CDP replication here. The writes at site2 are getting split and are sent to the production volumes and to the RPA. The RPA is then sending them to the CDP copy after making a note of the writes in the CDP journal. [the small multicolored cylinder that you see in between the prod and the CDP copy at site2 is your CDP journal]

Hope this helps.

Thanks.