Datadomain and Gateway architecture

[matteu]

Hello,

I have 8 VBR server on 8 differents site.
In 1 site I have a Data domain.

On all the VBR I have 1 backup copy job to target the Data domain.
Do I need to create 7 different gateway on the same site I have the data domain or can I create only 1 and share it ?

ddboost is used.

Thanks for your answer.

[Andreas Neufert]

You have two options.
Veeam optimization vs. DataDomain optimization.

You need to create 8 storages on the datadomain for each site.
I would create one gateway server (can be as well the backup server itself) and use it to write with DDboost to the central DataDomain. Basically everything that is done over the long distance is optimized by DDboost then.

Other option would be to create one central gateway server next to the datadomain and potentially use this server with Veeam WAN acceleration. This server can be used shared as long as you write from each site into another datadomain store, every VBR uses the same version/patch level and you have enough CPU RAM in the server to handle the load from all 8 sites.

I think the first one is the most effective and stable one to maintain and operate.

[matteu]

The actual infrastructure is :

Site 1 :
Datadomain + VBR1

Site 2 :
VBR2

There is WAN link between both.

Backup copy job from VBR2 (proxy + GW) -> WAN -> Datadomain.

My idea is to create a GW on Site 1 to do :
VBR2 (proxy) -> WAN -> GW -> Datadomain.

Is it what you mean with idea 1 ?

And if my understand is good, I could share this gateway to other Veeam infrastructure as soon as they use the exact same build ?

[Andreas Neufert]

"Backup copy job from VBR2 (proxy + GW) -> WAN -> Datadomain" this is my first mentioned scenario and it is the best you can do.
The only thing that it is important is that you do not write the backups in the same directory of the datadomain. The different VBR servers should not see backups from each other when they actively write into it. Best to create one datadomain storage per VBR.

VBR2 (proxy) -> WAN -> GW (shared) -> Datadomain (different DD stor per VBR)
is the second approach that I have shared. It might not be that efficient as DDBoost over WAN.

[matteu]

I'm not sure to understand, sorry

Now, the architecture is the drawing below



I would think use GW on the same site as the datadomain is better because traffic between datamoover is compressed and then uncompressed to put it into the datadomain.
On the actual setup, source data mover and target data mover = VBR and then traffic is uncompressed to reach the data domain right ?

I'm thinking about improving the architecture because WAN link is slow and sometime backup copy is performed during 10+ hours for 8/9 GB.

There is one folder per site on the datadomain.

[Andreas Neufert]

Your "actual setup" uses DDboost source side deduplication and very likely the traffic is smaller than your "improved setup" illustration.
In you drawing of the "improved setup" the ddboost is wrongly placed. It should be between GW and Datadomain.

For you the questions is:
Is Veeam compressed traffic smaller than DDBoost traffic and the answer is that DDBoost traffic is smaller.

If you want to give the "Improved Setup" a try and you have very small WAN links involved, you could test it with our WAN Accelerators so that the traffic goes:
Source => Proxy => Source WAN Accelerator => WAN => Target WAN Accelerator => GW => (DDBoost)=> Datadomain
Veeam WAN Accelerators are roles that you can install on Windows systems together with the other roles. They need some resources and disk space. It needs Enterprise Plus or Veeam Universal Licensing (which is Enterprise Plus).

I think even then the DDBoost source side deduplication is more optimized.

[matteu]

It's really strange....

The "actual setup" draw did : 1h30 for 2GB.

I tested with the improved setup yesterday and it's 23 min for 2GB (without wan accelerator, I just setup the new gateway server and select it on the DD repository as gw)

Do you know why ?

[Andreas Neufert]

I can not really say. Maybe the Datadomain does a lot of optimizations but transfer less data then.

Anyway if the Veeam setup is better, then of cause you can use it.

Veeam Job Settings:
Compression enabled.

Veeam Repository Setting:
Uncompression enabled

You can use the Gateway Server shared. As long as you consider the following:
- Use different folders (you have implement it that way as shared above).
- The gateway server has enough CPU and RAM for the processing. As the Backup & Replication Server do not know the load created from the other VBR, they just consum resources as they would own the shared Gateway Server themself only.
- Veeam VBR version need to be the same on all sites. Updates need to be carefully planned and executed at the same time on all sites.

[matteu]

Thanks for your answer.

I just see on the advanced option of the backup copy job inline deduplication was enabled. I just disabled it now and need to test again !

[Andreas Neufert]

https://helpcenter.veeam.com/docs/backu ... ml?ver=110

You can let the inline data deduplication setting be enabled. It will reduce the data that you need to transport over the WAN slightly. Of cause DD will then show less data reduction ratio but this is the case because you made the data smaller before it hit the datadomain. Anyway compression level should be "Optimal" or maybe "high" selected. By default it is "Auto" and therefore depend on the primary backup setting.

[matteu]

I just follow what is written here : https://www.veeam.com/kb1745

Inline Deduplication
Disable inline deduplication setting when writing into deduplication storages.


Is this KB outdated ? Because there is a difference between what you say me and what there is in it

[matteu]

Mmmm.... Maybe the best practice here are for backup job only or backup copy but not over WAN right ?

[Andreas Neufert]

Inline data deduplication will lower the effective deduplication ratio of the storage as part of the reduction is done outside of the storage itself. So it is best practices to disable inline deduplication for on-premises workloads. If you are short on the WAN link throughput you want to reduce the data upfront as much as you can. So it makes sense to let it stay enabled.

[Andreas Neufert]

Anyway you can check the html report on what the deduplication effect of Veeam was and in this scenario it has little effect on the whole throughput demand. It does not matter much if it is enabled or not.

[gnalley]

There’s a lot of talk about back ups, but there has been a little discussions of restore. Make sure you design for the restore.

[WernerV]

All,
we have tried to set up something similar, and it blew up in our face. The "actual setup" with the GW on the source side is a good idea for reducing the network load. Unfortunately, there is a some "think-time" involved, where the proxy is validating with the remote DD which blocks are already in cache. This is especially hurtful when doing synthetic fulls. In some cases backup jobs initially running at 1h took an additional 2h of this think time.

If you really want to make use of ddboost over the WAN, then take your wallet and install DD on the source side and use DD based replication. The drawback of this is you will not see the replication in your Veeam console. And you will probably need to rescan the central repository when you need to perform a restore, as this is a copy Veeam is actually unaware of. This could be remedied by installing another VBR server alongside this DD, and regularly import.

This will always be a matter of financials

[Andreas Neufert]

The functionality you speak about here is MFA replication. If you want to use this technology, reach out to your Dell service org as they have to deactivate 2 things and schedule the replication outside of Veeam backup window (no permanent replication) to optimize for Veeam. Anyway this is not the recommended method.

Using Veeam Gateways on the side of the Datadomain is a good solution. If the bandwith is not enough, then think about Veeam WAN accelerator usage and enable it on both sides.

In any way, make sure that different B&R servers or different Repository definition (or SOBR extents) do not point to the same storage place.