Just wait a little bit for the next release with Replicator incremental attach

Is there any information on that?  I dont want to have to "redo" anything if it could have been avoided knowing something upfront.

Should be in the 6.0 Replicator manual since it's already available there

I just can't check right now

Hi,

I am just looking for the same procedure.

Could you finally do it?

Best regards,

Raul

Please download the latest Replicator manual and search for „common base checkpoints” there

I did that.  Without sounding like I'm asking to be spoon fed, it leaves a lot of open questions on how to accomplish this.

What Rainer is referring to in the document is "Common Base Checkpoints".  Refreshing a replication with common base checkpoints between multiple Celerras allows you maintain the "state" of filesystem and VDM replications, using a user-created checkpoint that you create as the "base".  In your example, when you're ready to replace Cel-A -> Cel-X replication with Cel-B, you would create common checkpoints with the "fs_ckpt" command on Cel-B and Cel-X, then use "nas_replicate -refresh" against those checkpoints on each Celerra.  This makes a common "starting point" for the new replication you're creating between Cel-B -> Cel-X.  This way, you avoid having to re-replicate the VDMs and filesystems from scratch.

This is pretty easy to test out on the VNX simulator for Proof-of-Concept or creating documentation. 

Let us know if that helps!

yep - thats what I meant

Its pretty simple

you create a user checkpoint on each of the systems and then use nas_replicate refresh to get them all to the same state

when you later a replication between them and create a new replication the system will automatically determine that these checkpoints are suitable as a common base and will just do in incremental update instead of a full copy.

for example if you have

A -> WAN -> B (to be replaced)

you create a RevpV2 session to the new system

A -> WAN -> B (to be replaced) -> C (new system)

then create user checkpoints and A,B,C and refresh them

Now you can remove both replications and setup a new one like this:

A -> WAN -> C (new system)

without incurring a full copy

hope that helps

Rainer

P.S.: another use case for refreshing checkpoints over a replication session would be create application constistant state on a src system, refresh the local cpkt, refresh local to remote cpkt and now you have the exact same content there for backup purposes

how does VNX know that snapshot on A and C contain the same data. At what point do you remove replication session between B and C ?

VNX compares the versioning numbers of the checkpoints. Same numbers mean same data.

What does it look for , same version ?  If yes, why would the version be the same if i manually create a checkpoint on both VNX ?

manualy creating a checkpoint is not enough

Rainers:

> then create user checkpoints and A,B,C and refresh them

should read:

create user checkpoints and refresh replications with these user checkpoints from A to B and A to C

example for A to B:

$ nas_replicate –refresh –source

-destination

where:

= name of the replication session between A and B

= name of the user checkpoint for source VNX A

= name of the user checkpoint for destination VNX B

do the same for A to C

this is the trigger for the VNX systems to treat checkpoints identical.

Please check the manual for more details.

Rainer:

correction: you do need to specify the user checkpoints in the refresh

so for clarity,

I have A -->B and B-->C

I want to have A replicate to C (removing B)

I create user checkpoints on A, B and C and REFRESH

I delete replications between A,B and B,C

I create replication from A to C using the User checkpoints as the common base.

Please check the manual replication, chapter "Configure a cascading replication with common base checkpoints"

There is a step by step procedure with the commands and command outputs for changing replications from A -> B and B ->C to A -> C (eliminating the B partner in replication, without full sync)

From the manual:

-refresh{ |id= }

Updates the destination side of the specified replication session based

on changes to the source side. Execute this command from the

Control Station on the source side only. A refresh operation handles

updates on demand; as an alternative, the -max_time_out_of_sync

option performs an update automatically after a specified number of

minutes.

[-source{ |id= }

-destination{ |id= }]

Instructs the replication -refresh option to use a specific checkpoint

on the source side and a specific checkpoint on the destination side.

Specifying source and destination checkpoints for the -refresh option

is optional. However, if you specify a source checkpoint, you must

also specify a destination checkpoint. Replication transfers the

contents of the user-specified source checkpoint to the destination file

system. This transfer can be either a full copy or a differential copy

depending on the existing replication semantics. After the transfer,

the replication internally refreshes the user-specified destination

checkpoint and marks the two checkpoints as common bases.

After the replication refresh operation completes successfully, both

the source and destination checkpoints have the same view of their

file systems. The replication continues to use these checkpoints as

common bases until the next transfer is completed. After a user

checkpoint is marked with a common base property, the property is

retained until the checkpoint is refreshed or deleted. A checkpoint

that is already paired as a common base with another checkpoint

propagates its common base property when it is specified as the

source in a replication refresh operation. This propagation makes it

possible for file systems without a direct replication relationship to

have common base checkpoints.