Replacing a RP CX4 CRR target with a new VNX

You're only option if you want to avoid a re-installation is to remove RP/SE files and add temporary EX license files for each array, convert to RP/EX using DM, add the new VNX to the local RP cluster, add a second remote copy to include remote volumes on the new VNX for any CG's, perform the repository migration containing the CX4/new VNX cluster, remove the remote copy on the CX4 from any CG's, remove the CX4 from the local RP cluster, remove the RP/EX license files and add the permanent SE license files for the VNX arrays and then finally convert back to RP/SE using DM

I would recommend you are running the latest version of 4.0 or 4.1 code.

Regards,

Rich

Thank you for the response.  If I add another copy to the VNX at the target side, then are you certain that it will seed that copy from the local CX4?

That's not what I actually stated. I advocated adding a second remote copy to the CG contained volumes on the new VNX.

Perhaps I should restate something then.  My main goal is to avoid having to seed a new copy from the source across the WAN link.  I'm hoping I can migrate the copy on the CX over to the new VNX without having a big impact on the WAN link. 

Thanks for the responses.

That's what I'm afraid of.  Can you envision any method using something like SAN Copy that would reseed the volumes?  I don't know that RP has the ability to use that though.  I think it's going to still do a full sweep. 

You would have to failover all CG's to the CX4 copy, then add a local copy containing volumes on the new VNX, then failover to the copy on the new VNX and set it as production, then remove the remove the CX4 copy and fail back to the original copy on the original source VNX.

You can SAN Copy from an RP target/replica on the CX4 to the new VNX and then create the remote copy as part of the CG on the new VNX. This will hopefully reduce the amount of data replicated across the WAN to the additional remote copy and save time into the bargain as the differential data will be less.

I do appreciate the dialogue.  he "hopefully" part of your response is what I'm hoping to nail down.  I can't seem to find anyone who can answer that for me with any degree of certainty thus far.  Thank you!

The "hopefully" part of my response simply relates to the fact that if there is data change at Production during the time that you stop replication to the CX4 and start replication to the new VNX, then this has to be accounted for during the initial full sync and may add additional replication overhead. During the initial full sync process RecoverPoint performs a block by block comparison of data between the source and target volumes and identifies which are different and only sends the differential data blocks. However, we also have to take into account any blocks that are written to Production during the full sync process, although the impact of this will depend on whether the block has been written to before or after the read performed during the full sync process.