Data Domain MTree replication and Veeam repositories

[tomsmi]

Backup configuration is as follows: two Proxy servers and one Data Domain in site 1. Two Proxy servers and one Data Domain in site 2.
Between Data Domain configured MTree replication on backup folders.
Primary backup in site 1 is performed through DDBoost protocol to backup folder on Data Domain in site 1.
Replicated MTree is presented to Proxy servers in site 2.
Backup is performed in site 1 and replication occurs on Data Domain level. If on backup server I perform rescan on replica repository, then backups from primary repository is no more visible and only copy available to restore from Backup Console is reported present on replicated directory. This prevents from restoring backups from primary site directly in primary site.

How can I reach replicated backups without loosing access to primary ones?
Will it make any difference if secondary destination will be shared not by DDBoost but only by CIFS protocol?

[Gostev]

Probably, it happens because of the same file IDs or something like this. Sharing the secondary destination using a different protocol may help indeed. But please note that we do not support or recommend storage-based replication as means to copy backups in any case, you should be using Backup Copy jobs instead. Thanks!

[tomsmi]

Thank you for answer.
I suspect that ID is taken under consideration along with creation/replication date (or something like this) and newer file wins.
Sharing replicated repo with CIFS did not change situation at all - next backups were wisible only in replica repo.
In fact you do support storage replication (e.g. NetApp ), so why not support file-level replica on Data Domain triggered by Veeam?
Many other backup aps. takes advantage from this and offloads thair own servers from processing data that can be carried over in more afficient manner by storege itself.

[foggy]

This is a known issue currently under investigation. Please contact support to be notified about hotfix availability.

In fact you do support storage replication (e.g. NetApp ), so why not support file-level replica on Data Domain triggered by Veeam?

Production volume snapshot replication is a different story.

Many other backup aps. takes advantage from this and offloads thair own servers from processing data that can be carried over in more afficient manner by storege itself.

Storage-based replication simply copies the entire backup files without validating their content for consistency from application perspective. One day you can potentially end up with a completely identical, but unrecoverable offsite backup due to bad payload in the primary backup. That said, we're looking into leveraging storage-based replication engine as the underlying transport for backup copy jobs.

[DeadEyedJacks]

Hi Tom,
I'm assuming that you have a single Veeam Backup server managing all sites?

Either you need two Veeam Backup servers; one with primary backup repository attached and second with mirrored repository attached.

Or only present the mirrored repository to Veeam when the primary has been taken offline.

What's your rationale for wanting the mirrored repository presented to Veeam server at same time as primary?

NB wouldn't recommend sharing out DDBoost containers via CIFS...

[tomsmi]

Hi foggy.
Hi DeadEyedJack.

@foggy - thank you, I'll wait for enhancement like this.

@DeadEyedJacks - I got to know VB&R limitation after some tests, but that was quite suprising.
Imagine that for some reason you have manually created second copy of repository and VB&R doesn't allow you to have this second properly indexed in his own database. That also limits your ability to restore from this repository.
My reason would be a need to do a Backup Copy Job on secondary site from mirror done on DD level.
In fact presenting DDBoost container via CIFS looks safe as long as CIFS share is in read-only mode.