Which DD did you set as "default replication storage"?
Seems need to set the target DD to be default, then do the replication, from what Pawan mentioned.
And where did you put the checkservers option? Isn't it suppose to have a "--" in front of it?
I still don't have chance to test it on mine yet, but just some thoughts.
Maybe try it again with command line:
avrepl --operation=replicate -[replscript]dpnname=myavamar --[avtar]id=myid@avamar -ap=mypassword --[replscript]dstaddr=myavamar -[replscript]dstid=myid --dstpassword=mypassword ...
I apologize for not catching this thread before it went completely off the rails.
2. can we manually copy old backups writtne to a DD, to another new DD storage?
Yes, you can do this. It can be done by using DD replication. Depending on your requirement, you can use Directory/ Mtree/Collective replication. Once replication is completed, you need to delete the replication pair, and you can start using your destination DD/Directory/Mtree as normal.
This is incorrect. Data Domain replication is unsupported for Avamar / DD integrated backups except in a very specific configuration for Dell EMC's Cyber Recovery offering. MTree replication can be used to replace a Data Domain system with another Data Domain system but this must be done before integrating the Avamar with the replacement DD.
It is not currently possible to move a backup between DD systems attached to the same Avamar. For customers trying to migrate SOME data, we currently recommend attaching an AVE system to the target DD, replicating the data to the AVE, then deleting the backups from the source system and replicating them back from the AVE. There is an RFE open for Avamar to support migration of backups directly from one DD to another.
you need to use advance option --checkservers=false in replication set
Never do this. This option disables some really important safety checks. If you run replication with checkservers=false, you're more likely than not to spend the next week on the phone with support fixing your domain structure. Setting this flag permits the replicator to replicate a system to itself. Since the default is to replicate from / to /REPLICATE/sourcename, all your client accounts would be moved into the /REPLICATE domain, the MCS would no longer be able to find them, and backups for the affected clients would fail until the domain structure were fixed.
I found something in Avamar document about it, seems a new feature introduced from Avamar 7.2, called "Replicas at source", in page 249 on Avamar 7.5 admin guide.
Enable Replicas at source option, then Avamar can replicate backup jobs from one DD to another, which will do DD replication and then create meta data for new backup replica.
The replicas at source feature just displays backups from a replication target in the GUI on the replication source. It will not migrate backups between two DD systems attached to the same Avamar.
So to get rid of my old DD but keep the data, I'll have to create another Avamar VE to connect to my new DD, and then replicate everything from existing Avamar VE to this new Avamar VE systems, right?
How about licensing, do I need to procure a new license or is it possible to transfer the license to new Avamar VE?
From my understanding, you can't copy DD backup to Avamar itself, as the format is different?
Also I can't do it anyway, cause I have 2.3 PB data on existing DD, too hard to find storage space for Avamar VE to copy it.
I assumed you were using a physical Avamar server but if the existing system is an AVE, that makes things easier.
If you stand up a new AVE and integrate it only with the new DD, data will be migrated from the old DD to the new one during replication. However, if you wanted to keep your existing settings (datasets, policies, etc.), the replication would have to be a "root-to-root migration" which is normally done by professional services.
Alternatively, you could replicate the backups to the new AVE, then delete the backups from the existing system, set the default replication storage target on the existing Avamar to point to the new DD, then replicate them back. This is more complicated (and the professional services route would certainly be easier) but somebody with enough command line replicator experience could do it.
I'd recommend working with your account team on this. In particular, you would likely need their help to transfer the license.
If you find yourself in a similar situation in future, it's best to take care of this type of migration before anything has been written to the new DD. For DD system replacement, we normally use MTree replication to replicate the Avamar MTree from the old DD to the new DD (before attaching it to Avamar), then just update the Avamar DD configuration to point to the new DD. This provides a seamless migration. Unfortunately if the existing Avamar system has already been integrated with the new DD and backup data has been written to it, this is no longer possible.
It's not possible to migrate backups from DD storage to Avamar storage (and I would advise against it even if it were possible).
Thanks a lot, now it's much more clear to me.
My Avamar is an AVE, I'm now thinking of setup a new AVE and do this repilcation, but not sure if it's easy to setup, and how to deal with licensing.
If we just import the AVE into VMware and boot it up, it'll use 30 days grace period without any license needed?
About the alternative option, replicate things to new AVE, then replicate it back... but when you replicate it back, it'll be on different AVE, replicate from one MTree to another MTree, but both MTrees are on same DD, right? Would it be a problem or performance impact on the new DD and daily backup jobs still running on the AVE?
We have 2.3PB data on the existing DD, so not sure how long this replication would be.
Of course I'd like to take the easiest path... our new DD is not setup for Avamar yet.
So is there any document of detailed steps to do that?
To do this DD MTree replication, I need to manually create a MTree on new DD with name "avamar-<system id>", right?
When MTree replication completed, when we point Avamar to the MTree on new DD, would Avamar scan the content and generate metadata from it, for the restore?
Or any other operation is needed to "import" what is in the MTree, to Avamar aware?
I noticed, when you setup MTree in Avamar, it'll actually automatically create the MTree, so if the MTree is already there with name "avamar-<system id>", Avamar would not overwrite it but will take over the content?
Sorry for too many questions,
Which version of AVE support these solutions you provided above?