DD Replication over WAN - How to make initial synchronization/alignment?

Hi Moab,

thank you for the answer!

I thought to use the DD transporter in a CASCADING REPLICATION (DD A--->DD B--->DD C), and when the three DD are synchronized, I would remove the DD B...

Do you think it's possible that the replication continuous between DD A and DD C, without need to restart the replication process?
PS: I opened a new debate on this topic (https://community.emc.com/thread/206939)

thanks again

L.

Hi Lionhands,

As far as I know. No there is no alternative methode.

Use replication over WAN. You can manage the bandwidth with throttling. Upgrade the Data Domain software to version 5.5, because replication got better with this release.

Hi.

Depending what type of replication you are using and what to use.

Have you been replicating to the remote DD at all?

I would see the setup as follow:

1. Configure replication from local DD to transported DD

2. Move transporter DD to remote DD site

3. Setup replication from transported DD to remote DD

Step 3 could involve resyncing if the remote DD previously had replication setup from local DD (this would save time)

4. Setup replication from local DD to remote DD using the resync option and not initialize.

Cheers.

Hi Lionhands,

Ignes is correct.  I've used this method for multiple customers.  It does not matter what method is used to write data to the remote DD for seeding, provided that the data/segments are not altered (ex. compressed, encrypted before writing to remote DD).  You can use a 'transporter DD' as a mobile seeding device via the method you described.  For smaller amounts of data you could even use a portable USB drive for the transport.  Also, It does not matter whether the local DD thinks that it is replicating to a second destination. You do not have to use the exact same contexts/folders for the seeding data.  The DD unit will dedupe across the folders.   If you use a separate folder for seeding you just need to remember to remove it an run cleaning after the local and remote folders are in sync.

The important step is to to ensure only DELTA data goes across the WAN is to use replication resync, instead of replication initialize, when setting up the final replication context(s) from local DD to remote DD (after seeding).

The steps Ignes provided a correct;

1. Configure replication from local DD to transported DD

     1b.  Once local seeding in sync, Break replication context(s) from local to transport DD

2. Move transporter DD to remote DD site

3. Setup replication from transported DD to remote DD

Step 3 could involve resyncing if the remote DD previously had replication setup from local DD (this would save time)

    3b.  Once remote seeding in sync, Break replication context(s) between transporter DD and remote DD 

4. Setup replication from local DD to remote DD using the replication resync option and not initialize.

Cheers,

Steve

Hello everyone, thank you for your answers, I understand how the mechanism works, so I hope to have resolved this question, in the coming weeks I should have a chance to test it!

thank you again!

Lion

Hi!

I want to tell you that this morning I had the opportunity to test this thing and I can tell you that it is less complicated than it seems. I followed all procedures as you told me, but I have a problem in the final part, when I setup replication from local DD to remote DD using the replication resync, the system reports an error: "No common snapshot, resync not possible".

So we decided to create a new replication between local DD and remote DD, and I realized that the source has sent only a small part of the data, because the target had already the data that the source was sending to him, is this possible? or I'm wrong?

and why the system reports this error? ---> "No common snapshot, resync not possible"


Lion

Mtree replication uses snapshots to track what data needs to be replicated to get the destination at a specific point in time replica.

This might then be the only limitation when using mtree replication in a cascaded scenario.

Will see that when issuing the command - snapshot list mtree xxxxx - there will be a snapshot called REPL_AUTO or similar. Whenever you break the replication context an additional snapshot is created called RESYNC_RESERVE on both the source and destination.

Whenever it is required to perform a resync of a context this snapshot is used as the base to continue replication where it was broken hence no need to resend all the data.

One way around this is to recreate the destination mtree as the mtree on the destination cannot exist during the configuration of mtree replication.

So my steps will be on destination:

1. Break replication context on both source and destination.

2. Create temp mtree - mtree create xxx_old

3. Fastcopy data - filesys fastcopy source xxxxx destination xxxx_old

4. Delete original mtree - mtree delete xxxx (take take if this was VTL - then you will have to delete the tapes and pool first)

5. Create replication context.

At this stage the comparison will be done and only new data will be sent to the destination.

Hopefully this helps and is an option.

Cheers.

Ignes

hi all, 

Can anyone tell me if it is possible to  prepare an initial synchronization by using a transportable external hard disk instead of a transportable DD ?

I would like to activate the replication of 5TB data into a remote datadomain. But my goal is to use a transportable HDD (I cannot manage a transportable DD) to copy the files on the remote DD before activating the Mtree replication.   

Thanks a lot in advance !

While initial synchronization identifies time alignment of the spreading code.