Announcement Banner

dwilk1973

updated

15 years ago

D

dwilk1973

1 Rookie

•

63 Posts

0

2409

June 13th, 2011 07:00

Help! Root-to-Root replication

I have to go from a 2TB gen 3 v5.x grid to a new 3 tb gen 3 grid v 5.x.  Retain all backups and start backing up once the 3tb gen 3 node is up.  Would I use ROOT-TO-ROOT replication for this to retain the old backup data?  If so what is the procedure for it?  I couildn't find on on the procedure generator.

Is this the best practice way to go from one grid to a new grid and retain backups for clients?

Thanks in advance!

  • arif_ahmad

    20 Posts

    884

    0

    Posted June 13th, 2011 08:00

    Hi,

    After you install the new Avamar Gen 3 3.3TB grid, you need to perform a standard root-to-root replication. After completion of the replication, you need to perform a restore of MCS on the target 3.3TB nodes grid with a parameter "new-system" as:

    mcserver.sh --restore --restoretype=new-system

    Please see the EMC Avamar 5.0 System Administrator Guide (300-008-814) for the topic Migrating Avamar Servers on page 439.

    Thanks,

    Anser A Arif

    1 Attachment

  • rpervan

    266 Posts

    884

    1

    Posted June 13th, 2011 07:00

    dwilk,

    > Is this the best practice way to go from one grid to a new grid and retain backups for clients?

    root to root "FULL" replication is the only way how to migrate existing avatar server to the new one for expanding purpose (your case)

    That mean, the Root-to-root replication is used for migrating and rebuilding systems.
    Server migrations are planned operations that move all content of one Avamar server to another Avamar server using root-to-root replication.

    1) Perform the root-to-root replication from Server ?A? to Server ?B?.

    2) After root-to-root replication completes, start up the MCS on Server ?B? by doing the following:

    mcserver.sh --restore --restoretype=new-system

    This step is essential because this is the only way to get the CIDs in both the MCS database and the GSAN synchronized. The CIDs on the GSAN in Server ?B? are different than the CIDs in Server ?A? because Server ?B? is running a different GSAN. That?s why you have to specify --restoretype=new-system; to ensure that the MCS database reflects the same CIDs in Server ?B? rather than the CIDs that it used when the MCS was ?hooked? to Server ?A?.

    3) Then, after you get Server ?B? up and running, then change the IP, hostname, usersettings.cfg, probe.out, etc., so that Server ?B? has the same IP as Server ?A?. At this point, then you can restore the MCS with the following:

    mcserver.sh --restore --restoretype=rename-system


    https://solutions.emc.com/emcsolutionview.asp?id=esg95094

  • dwilk1973

    1 Rookie

    •

    63 Posts

    884

    0

    Posted June 13th, 2011 11:00

    Thanks guys for the answers.  I could not see the solutions link that was in the first post but did read the admin guide section.  Looks easy enough.  Thanks again guys!  I wish I could put both of you as correct so one will have to live with helpful answer.