Backup Copy Jobs with DataDomain Replication

[Psylak]

Hi all,

Just a quick overview of what I am trying to achieve:

We currently have a backup job running nightly with all our VMs with a DDBoost Repository as the target.
This DDBoost repository gets replicated to another DataDomain at the DR Location with a 30MBit link. The replication works as intended and I can see the contents at DR after doing a rescan of the Repository once replication is complete.

Now what I am trying to achieve is to setup a backup copy job for GFS purposes. What I have tried is to create the job as a secondary target for the main daily backup job but then selecting the replicated repository at DR as the source. All my DR repositories are configured correctly afaik using a VM at the DR as the gateway server and mount server.
The backup copy job runs but it is extremely slow as it is still pulling lots of data over the link from the main VEEAM B+R server located in production.

My idea is to get the backup copy job running independently from the DR link and using the data that it has available locally at the DR to avoid network bottlenecks. The DR link should only be used for the builtin datadomain replication.

Is my way of thinking correct? Is there a better way to achieve this or is something perhaps misconfigured?

Let me know if any further detailed info is required.

Thanks

[ferrus]

The official Veeam line on DD replication - is it's not recommended/unsupported, and to utilize Backup Copy Jobs instead.
Unfortunately in our case - that's just not physically possible within the constraints of the Backup Windows, Bandwidth etc.

As you're already planning to do Backup Copy Jobs for the GFS, maybe it's more suitable in your environment?
Could you do the BCJ only, using DDboost, as a secondary target, and match the number of restore points as the original job + GFS?

I think using anything on the DD as a data source, could decrease performance considerably - perhaps more than the network bottleneck, because the data has to be rehydrated before it's presented to Veeam.

[Psylak]

Thanks Ferrus, I'm not sure I understand completely as my current BCJ is configured with a DDBoost as the secondary target located at DR and then I changed the source setting to pull from the replicated DDBoost available at DR.
I can change this back to the default setting but then the job would be pulling data over the DR link anyway and I doubt the job would complete within our backup time windows.
I am using the DD replication as it manages to replicate over the DR link before the next scheduled backup runs.

All my repositories are currently DDBoost repositories so it seems my data would always need to be rehydrated as I have no other sources?

I will try to create a simple diagram of the layout as to hopefully make it clearer.

[ferrus]

Then it sounds like you're in the same catch-22 situation as us.
Can't possibly use full GFS Copy Jobs of our estate, within the backup window - but DD replication just about manages it.

Basically, Veeam are concerned that there's a small risk of data corruption in the first backup, which would then transfer to the second and third (as all the backups come from that first backup as their source).
If they were two or three separate jobs - this wouldn't be a concern.

Running SureBackups may mitigate that risk, regular Active Fulls on the primary jobs instead of Forever Incremental may also reduce the risk.

[foggy]

Does the target repository have a gateway server assigned that is located in the same location?

[Psylak]

Hi foggy,
yes, the target repository has a gateway server which is located in the DR.

[foggy]

If you're doing everything correctly (rescanning the repository, mapping the backups to a dummy backup job, limiting the scope of the backup copy job), there shouldn't be a significant traffic between the sites. I suggest asking support at least to review the setup.

[Psylak]

Thanks foggy! It seems it was just the dummy job I was missing. BCJ is now running correctly.
I am having trouble with my pre job script though for scanning the repository. Is it better to have a pre job script or just to run the script on a windows schedule?

I am getting an exit code 1 when running the following:

Code: Select all

$Repository = Get-VBRBackupRepository -Name "DDBoost"
Rescan-VBREntity -Entity $Repository -Wait

The script runs fine within powershell but not when attached to the job, is there something I may be missing?

[foggy]

Could be permissions issue, being run from the job, the script is executed under service account, if I'm not mistaken.

[BrandonM]

Do you have the path to powershell specified when calling the script and the snap-in imported into the script for access to the module?