Veeam B&R 10 with EMC Data Domain - Replication

[DukeR]

Hi guys

In the old days I was able to setup an EMC Data Domain and replicate its data to another one with the native EMC DD replication feature. I added the 2nd device into Veeam so I was able to restore files from both sides. In version 9 Veeam changed the approach and when adding the 2nd EMC DD and its replicated data the first backup data was removed within Veaem B&R with the restore points of the 2nd one which leads to the situation that I was only able to have one EMC DD within Veeam and when I needed to have the 2nd one I just added it on demand.

Now I am not up to date anymore and I got a customer request:

We want to backup the VMware environment with Veeam and save it onto a EMC DD within the same room. We want to have a copy/replication of this data on another EMC DD in another room.

At the moment we have backup jobs which store data on a physical veeam proxy with 20 TB.

In the old days I would just have created additional copy jobs and save this data to the first EMC and replicate the data with the built in EMC DD replication.

But as I mention I think this does not work anymore.

HOW DO WE SOLVE THIS WITH THE CURRENT SITUATION?

- Additional Copy Jobs?
- Native Replication?
- Veeam Integration or not?

DO I NEED ANY ADDITIONAL LICENSES?

Thanks

[Gostev]

Can you clarify what "does not work anymore" specifically when you use backup copy jobs?

[DukeR]

Having only one backup copy job which saves to the first EMC DD and replicate this data with the native EMC DD replication AND having both repositories and data within veeam

[Gostev]

Ah, so you're NOT talking about using backup copy jobs? Your first post specifically referred to using them. If you use backup copy jobs, then everything should certainly work fine, just as before.

Please be aware that replicating backups using technologies outside Veeam is not recommended in principle, because such replication is not content-aware, and will replicate corrupted backups without raising a flag. If you still choose to do this, you can consider having a scheduled PowerShell one-liner that automatically imports backups from the secondary Data Domain periodically. This should solve the issue you're facing due to duplicate backup IDs associated with backup files created by Data Domain replication.

Thanks!

[DukeR]

Thanks for this feedback! Son in theory i can create two copy jobs which copy the files on one data domain and to the other as well.
Is this the way how to do this nowadays?

Cheers

[Gostev]

Yes, this has always been the recommended approach.

[DukeR]

Thank you

[reza]

It's a normal behaviour because Vbr creates an Identificateur for the backup file and when you replicate with native DD replication , it puts the same ID on the secondary DD. From Vbr side when it discovers the same ID , two times , it's a corruption so it deletes both. there is one workaround, on the secondary DD , you create a new Vbr and with this solution each Identificateur is managed but different Vbr.

[werner.vergauwen]

Sorry to hijack this thread, but I wanted to dig a bit deeper into DD Replication.

I do second your remark about preferring BCJ over DD replication. But the "native" replication could be particularly useful over higher latency WAN. The deduplication will optimize traffic even beyond what WAN Accelerator is able to do, especially on global implementations with lots of ROBO sites. (This is also the reasoning behind integrating StorOnce, I guess) The problem however lies in accessing the remote repository. Especially the "oneliner" you were talking about triggered my curiosity. Would you mind sharing that one?

That said, what I understand from a lot of customers is that they are not confident as to how to deal with importing the remote repository. Would it be possible to issue some KB containing best practices on how to do this? And on when to do this?

thanks

[GonzaloMurillo]

This is Gonzalo, I can add information from the Data Domain perspective.

If you use native Data Domain replication ensure that you have the information from VEEAM in several mtrees.

Is not a good practice that you try to replicate just one mtree (typically named /data/col1/Veeam) to a remote Data Domain, because then the number of replication streams will be limited.

The approach to follow is rather to have multiple mtrees.

For example:

/data/col1/VeeamSQLServers
/data/col1/VeeamFileServers
/data/col1/VeeamExchangeServers
/data/col1/VeeamOracle

And then create further replication mtrees

BCJ have a lot of issues. Being the first one that the data at source needs to be read, which is slow.

I have said this several times, but I will say it once again, the main problem here is that VEEAM does not implement Managed File Replication, which leverages on the Data Domain native replication and makes the software application to be aware of that second copy.

All the rest, are just "patches" trying to solve something that should feel much more simpler and natural to the customer.

Thanks for listening.

Best regards,

[werner.vergauwen]

Hi Gonzalo

thanks for the update. You are correct indeed, but watch out if you are replicating from 90-odd sites to a central DD as you might run out of mtrees.

The MFR is definitely something that would be useful. The main reason for me asking for the KB is that this would validated the solution from a Veeam standpoint. The customer would have some assurance the Veeam+DD combo is actually endorsed by Veeam.

cheers
Werner

[foggy]

Hi Werner, please look at this PS command for the repository rescan.