Offsite Copy Backup Repository based on WS2016

[geordi]

Hi together

I have a design question and would like to know what you think would be the best solution.

We have a VBR infrastructure with 2 repositories. Both are installed with actual Windows Server 2016 providing 44TB disk space. The volume is configured wit Dedup feature from MS.
The jobs are running multiple times a day with active full over the weekend.
Works like a charm.

Now we would like to copy the backups offsite from our primary site to another data centre. WAN performance is not the issue as we are having a dark fibre connection which is running with 10G
At the target data centre we are having also a Windows Server 2016 box providing enough disk space.
The goal is not that we have an exact copy as on the primary site, on the secondary site we would like to achieve that we have at least one restore point per day for the last 30 days.

At the moment I am struggling how to realize the copy as there are multiple options.

1. Usage of DFSR and activating Dedup on the target box, resulting in copy of all restore points (as my current information is that the synced data over DFSR is not deduped and needs to be activated on the target box)
2. Usage of 3rd party sync tools (e.g. robocopy) and activating Dedup on the target box, resulting in copy of all restore points
3. Using the secondary target option of VBR, which would provide more control over the restore points synced to the target so that we can achieve our goal.

What is your opinion here?
Despite the fact that we need enough disk space and the disk system should be as fast as possible ... which system would be the one handling the cpu power regarding the 3rd option? My understanding is that the WS2016 placed in the secondary site is doing all the jobs and needs sufficient CPU and RAM resources as this system is getting the backup data from the primary site and is creating the restore points. Correct?

---edit---
Should we plan to use REFS on the secondary target as this would bring more performance? Or stuck on NTFS and Deduplication like we do at the moment on the primary site?

Regards,
geordi

[nmdange]

Veeam backup copy job would be the most appropriate option. I would not use anything like DFSR or robocopy. You *could* look at using Storage Replica which can do a high performance volume-level replication, but Backup Copy Job gives you more options. The only plus with Storage Replica is that it should in theory maintain the NTFS dedup so you wouldn't have to dedup again on the target. However I don't know if Storage Replica officially supports Dedupped volumes.

As far as ReFS, if there weren't any bugs, I'd say you should use it on both your primary and secondary locations, but for now I would stick with NTFS. There are supposed to be fixes imminent for Windows Server 2016 that backported from RS4 (which will I assume become Windows Server 1803 when released) but no guarantee when it will be available.

[foggy]

which system would be the one handling the cpu power regarding the 3rd option? My understanding is that the WS2016 placed in the secondary site is doing all the jobs and needs sufficient CPU and RAM resources as this system is getting the backup data from the primary site and is creating the restore points. Correct?

All processing will be performed by the Veeam data movers installed on source and target repository servers.