Avamar R2R replication - Using replication port

Hello Ian,

Many thanks for your reply.

1.  May I confirm that if I want to touch up on the last replication by running the replicate command again below:

Edit by moderator: Command removed

2. The target node is Single Node S2400.  So what is the best recommendation to do this r2r replication and if possible, with a dedicated replication ethernet port.

Hi Ian again,

1. Meaning to say, if I do not configure the port as a dedicated replication port, the same backup port will be used for backup and replication at the same time when r2r replication is running?

2. Please enlighten me, if nothing configured for the replication ethernet port, based on the migration guide, what is the purpose of the replication port for then?  Or rather I should define my question when is this port needed to be used?

Thank you in advance.

Re-running the same replicate command used during the migration will run the "catch up" replication, yes.

The procedure is well documented in the migration guide. Follow the guide. What benefit do you hope to gain by configuring dedicated replication? Configuring dedicated replication and then removing it when the replication is complete would increase the likelihood of human error and would almost certainly be more time consuming than just letting the replication run with the systems cabled to the external switch.

By default, the external bond will be used for all external traffic (backup, replication, management). Think of replication as a restore from the source and a backup to the target. The network is very rarely the bottleneck in Avamar. The Gigabit Ethernet network on the Avamar can handle about 350GB/hr per node raw. Since we compress at about 2:1, the maximum effective throughput is around 700GB/hr per node. The I/O subsystem of an S2400 node can ingest about 75GB/hr so the network is unlikely to be the bottleneck. There would be no performance benefit to segregating the network traffic unless the switch is the bottleneck.

There isn't really a dedicated replication port as such. It's possible to configure a port for dedicated replication (and there are recommendations on which port should be used for this to try to maintain standard field configurations) but that's not quite the same thing. Normally customers use a dedicated replication network when they need to separate replication traffic from backup traffic because it's using a different route (e.g. a dedicated replication link between data centers or to an external backup provider), because they have a mandate to separate traffic by type for management reasons (e.g. different QoS configurations for replication traffic vs. backup traffic), etc..

Hi Ian,

Sorry been busy to thank you for your last few posts.  Your posts have given me the full confidence to carry out the r2r replication today which ran successfully.

1. There is a new updated r2r documentation.  Ran the proactive health on both destination and source.  Destination health was showing 2 FAILED lines.  One was SLES repository and another was MCS patch upgrade (or update). Are they significant?

2. I ran the replrpt.sh and have to point it with --log to the output of the replication command --fullcopy and seems like the script is a bit outdated with the first column "DATE" not showing:

DATE             CLIENT               Replicated    Throughput   Time        Backups Replicated

================ ==================== ============= ============ =========== ==================

           avamarproxy10-proxy-          0 MB       0 Kbps       0 Min 0 Done

           avamarproxy11-proxy-          0 MB       0 Kbps       0 Min 0 Done

           avamarproxy7-proxy-1          0 MB       0 Kbps       0 Min 0 Done

           avamarproxy8-proxy-1          0 MB       0 Kbps       0 Min 0 Done

           avamarproxy9-proxy-1          0 MB       0 Kbps       0 Min 0 Done

           AVI_BACKUPS                 634 MB    4949 Kbps      17 Min 21351 Done

           aa3.exampleabcdef.co       5281 MB  235666 Kbps       3 Min 6 Done

           aa4.exampleabcdef.co      88248 MB  282240 Kbps      42 Min 13 Done

           aa5.exampleabcdef.co       5599 MB  134355 Kbps       5 Min 6 Done

           abcde4.exampleabcdef      23439 MB  263612 Kbps      12 Min 6 Done

I thought I read somewhere that the script can show me the % replication progress.  Is there a way if the protected bytes is 8TB and actual deduped data is about 4TB, that I can roughly estimate when this replication will complete?

3. Lastly, after replication is done next few days later, I will have to run to restore the database on the destination, is there a formula to calculate the TIME that it will take to run the whole restoration on the new system?

Many thanks again.

Have a wonderful weekend.

AJosh

1. The SLES repository issue causes nuisance pop-ups in the GUI. It's a two minute fix. I always recommend using the most recent MCS roll-up. I'd recommend correcting both.

2. It's possible you have an outdated version of replrpt.sh. The most recent versions of the various support scripts can be downloaded from the FTP site. Directory listing is disabled but if you know the name of the script, you can copy and paste the following URL and add the script name:
ftp://avamar_ftp:anonymous@ftp.emc.com/software/scripts/anonymous@ftp.emc.com/software/scripts/

I don't have much experience with the replrtp script so I can't really comment on specifics.

Assuming 7.8 TB nodes on both sides, if you're replicating the entire 4TB, the replication will likely take two to three days. Typical replication performance for single node servers across a LAN link is about 75GB per hour since it's limited by the ingest rate of the target.

3. I find answering all the questions in the "new system" restore usually takes longer than the restore itself. In total, the whole restore process should be less than 30 minutes end-to-end.

Hi Ian,

Thanks again.  You know what?  The customer just email me a while ago, the replication of 4TB was completed in less than 24 hours after we kickstart it on Saturday. So happy that you provided a rough estimate that restoration does not take up too much time, great confidence .

Now some questions:

1. I asked before and you have answered me, since the baseline migration has completed.  And that there are new fresh backups completed recently, we should rerun the same command line "nohup replicate ... --fullcopy" in order to synchronise the latest.  Was looking through the technical addendum, there are many other options such as | --reportonly | --restore, is there an option such as "--synchronise" (searched through the whole 494 pages of EMC Avamar 7.0 Technical Addendum) to complete this last synchronisation or we have to use this "--fullcopy" option?

2. As an example of hostname and IP address to be updated accordining, with Source named as A, Destination as B.  Now customer wants the new Avamar to be named as B.  But according to the hostname/ip address change documentation and the original replicated database tagged to A, do i need to:

a) use documentation and perform executed needed hostname change to B as it is? or

b) use documentation and perform executed needed hostname change to A first, and then use same documentation to change to B again?  And is there a best practice that per Avamar grid, not to allow hostname/ip address change too often as this might clog up the historical database tables of tracking changes.

Many thanks in advance.  AJ

Just to make sure this is clear, when I say "complete the migration", I mean finish with the migration procedure completely (including the MCS restore, etc.) before making further changes.

Using DNS alias for the client failover instead of renaming the Avamar server is fairly common.

Hi Ian,

I like your sanity check even more with the checkpoint not mentioned in the documentation.

Will be doing the restoration and hostname/IP address change tomorrow.

Customer looks like want to retain the B hostname (new hostname), and after shutting down the source server, he suggests using DNS alias on the DNS server (so that we do not have to re-register all the 100++ backup clients to the new server) to redirect to the new server.  Lets hope this work.

Will keep you updated.  Thanks again.

1. Use the exact parameters you used for the initial replication to run the "catch up" replication. Replication is always incremental. The replicator will not re-replicate any data that is already on the target system.

2. I would complete the migration first, perform a quick sanity check (e.g. run a test backup and a test restore) then take a checkpoint, shut the system down and perform the hostname / IP change. It's always easier to troubleshoot if you change one thing at a time.

Systems can be renamed or their IP addresses changed as many times as needed.

I am new to this community.  Your replies given to me so far has been satisfactory, how to mark them as best answers?

thanks for the clarification on migration procedure.

So actually DNS alias actually equates to Failover, never thought of that

Was searching for Avamar Failover document, seems like no such document. 

so if sticking to new hostname, involving DNS Alias update on the DNS Manager, what I will do, following the migration documentation, as steps in order below:

- Restoration of database (as per migration documentation)

- Shutdown of source server (not mentioned needed in any documentation)

- Change of destination hostname/IP adddress (as per last step in migration documentation)

- Using hostname/IP address change documentation to update any needed new hostname/IP address parameters during CLI

- Add new DNS Alias in DNS Manager.

Any shorter steps?  I saw somewhere in migration documentation some options, not sure if this is the shortcut:

Select the Avamar server IP address or fully-qualified hostname to

be used by backup clients:

1) DESTINATION_SERVER.avamar.com

2) SOURCE_SERVER.avamar.com

3) Enter another address

Thank you.

Your replies given to me so far has been satisfactory, how to mark them as best answers?

I'm very happy to help! I've changed your post into a question so you should now see buttons for "Correct Answer" and "Helpful Answer" which you can use to mark correct or helpful replies.

If you'll be updating DNS, there's no need to change the hostname or IP address of the Avamar. You only need to do one or the other. As long as the clients can reach the new server at the hostname they're activated to, they'll back up just fine.