recoverpoint

That's correct. This procedure can be used but this is rather risky as RP will not validate consistency of data b/w the two copies. Also, it requires that no new writes will be performed on the production so this means production downtime.

Another way to seed the target copy is to place the new array in the same DC as the production and add a link in RP (assuming RP 4.0 and onwards to support Multisite and RP/EX licensing), RP will perform a full sweep to that copy on the new VNX (to avoid production impact and limit RP read throughput, one can use the config_io_throttling CLI command). Afterwards the VNX can be physically moved to the DR site.

If the VNX array cannot be physically moved to the Production site, I would also recommend considering to use SAN copy or any other block level migration software to replication the data from the RP target to the new VNX. Once the copy is done, you can add a new RP copy in the same remote cluster. Again, assuming RP 4.0 and onward which supports multisite and the ability to configure another remote copy on the same remote cluster.

RP will perform a full sweep to that copy which will transfer only the changes across the WAN. This delta should be minimal because the production and the new remote copy are relatively similar.

Hope that helps,

Idan

Hi, You can look into an "intialize from backup" process, which is detailed in the Admin guide (linked below)

This is not without risks, and to be successful the instructions need to be followed strictly as all volume/copy markers are cleared and the source and target are treated as identical, without consistency being checked.

I am not aware of any other way to pre-stage/seed the target volumes.