Greetings friends, I found myself the other day with an issue I had not seen before, I will explain below the symptoms of the issue, but first let’s remember what the Veeam Gateway Server is and what it does in a simple Veeam topology.
Veeam Gateway Server
When configuring an SMB type repository in Veeam, the following options are available:
- Automatic selection of the server as the SMB gateway proxy (i.e. the server that will host the transport component on the destination side and thus play the role of a data writer to the SMB shared resource itself).
- Select an specific server (among the managed Windows servers available in Veeam Backup & Replication) as an SMB gateway proxy.
The second option is very useful in situations where the SMB share is in a remote location, as it prevents auto-selection from using a non-local server for the SMB share, so all synthetic operations or backup jobs are performed over the WAN link (which is usually slower than the local link). It is always recommended to use an SMB gateway server as close as possible to the SMB storage. By specifying the SMB gateway we are more likely to keep data flow under control and prevent data from unnecessarily crossing WAN links.
Because single stream performance for SMB repositories can be less than optimal, we can potentially increase SMB storage performance by configuring multiple repositories pointing to the same folder using different gateway servers. With multiple proxies, the automatic SMB gateway can be a good option and can be configured by selecting Automatic from the drop-down list.
Tip: Gateway servers should be the right size as normal Windows repositories. If we are using the automatic mode, let’s remember that the same machine can be chosen as a backup proxy server and a gateway server simultaneously. We’ll have to dimension it correctly.
Therefore, a simple Veeam topology will look like this, in which the proxy is in charge as always of communicating with the Hypervisor and sending the information to the gateway server (which could be the same) before sending the information to the SMB resource:
Veeam Gateway Server in a Multi-Cloud environment
In a multi-cloud environment (connected via VPN of course), things get much more complicated, and in what we might think Veeam acts in the following way in automatic mode:The truth is that it can act in the following way if we have in automatic mode the gateway, and also selected the per-VM option in the Backup Repository, slowing down the backups, generating errors, and of course an unnecessary bandwidth consumption:
Show me the way, Doc!
As we have already seen, we will have to configure our configuration in the multi-cloud environment in a more cautious way, and restrict the traffic to the components that are closest to us, for this we have to follow the following steps:
1.- Configure that all the jobs of a Backup Repository go for only one Veeam Gateway Server
It is a more restrictive, but more secure way, with this we will ensure that all traffic generated by the proxy, or proxies, is transferred to this gateway server located on the same network and the data is stored in the SMB that we have in the same place. To do this, in the Backup Repository, make sure you have selected the corresponding gateway server on your network:
Finally, I recommend that in the Mount Server, you also use a server that is located in the datacenter where you are configuring all this, in my case in the secondary, so that when we do restores we don’t have to load the WAN mounting the backup, etc, a computer that has the closest access makes it:
Veeam Proxy Affinity is not restrictive, so it is only recommended to configure it, but it will not help us as much as the first option. When we configure it, Veeam will try to use the Veeam Proxies that have more Repository affinity than we have defined.
That’s all folks, if you are experiencing backups that take a long time to launch to an SMB, and you are in a Multi-Datacenter environment, with the gateway-server in automatic, surely the best thing to do is to look in the logs to verify that you are not making intensive use of the WAN because you do not have this perfectly configured. I hope it’ll help you.