• Skip to main content
  • Skip to secondary menu
  • Skip to primary sidebar
The Blog of Jorge de la Cruz

The Blog of Jorge de la Cruz

Everything about VMware, Veeam, InfluxData, Grafana, Zimbra, etc.

  • Home
  • VMWARE
  • VEEAM
    • Veeam Content Recap 2021
    • Veeam v11a
      • Veeam Backup and Replication v11a
    • Veeam Backup for AWS
      • Veeam Backup for AWS v4
    • Veeam Backup for Azure
      • Veeam Backup for Azure v3
    • VeeamON 2021
      • Veeam Announces Support for Red Hat Enterprise Virtualization (RHEV/KVM)
      • Veeam announces enhancements for new versions of Veeam Backup for AWS v4/Azure v3/GVP v2
      • VBO v6 – Self-Service Portal and Native Integration with Azure Archive and AWS S3 Glacier
  • Grafana
    • Part I (Installing InfluxDB, Telegraf and Grafana on Ubuntu 20.04 LTS)
    • Part VIII (Monitoring Veeam using Veeam Enterprise Manager)
    • Part XII (Native Telegraf Plugin for vSphere)
    • Part XIII – Veeam Backup for Microsoft Office 365 v4
    • Part XIV – Veeam Availability Console
    • Part XV – IPMI Monitoring of our ESXi Hosts
    • Part XVI – Performance and Advanced Security of Veeam Backup for Microsoft Office 365
    • Part XVII – Showing Dashboards on Two Monitors Using Raspberry Pi 4
    • Part XIX (Monitoring Veeam with Enterprise Manager) Shell Script
    • Part XXII (Monitoring Cloudflare, include beautiful Maps)
    • Part XXIII (Monitoring WordPress with Jetpack RESTful API)
    • Part XXIV (Monitoring Veeam Backup for Microsoft Azure)
    • Part XXV (Monitoring Power Consumption)
    • Part XXVI (Monitoring Veeam Backup for Nutanix)
    • Part XXVII (Monitoring ReFS and XFS (block-cloning and reflink)
    • Part XXVIII (Monitoring HPE StoreOnce)
    • Part XXIX (Monitoring Pi-hole)
    • Part XXXI (Monitoring Unifi Protect)
    • Part XXXII (Monitoring Veeam ONE – experimental)
    • Part XXXIII (Monitoring NetApp ONTAP)
    • Part XXXIV (Monitoring Runecast)
  • Nutanix
  • ZIMBRA
  • PRTG
  • LINUX
  • MICROSOFT

Veeam: Best practices for Veeam Gateway Server and how to configure it correctly in multi-datacenter environments

23rd July 2018 - Written in: veeam

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:

In the next step of Repository, we’ll click on Advanced and uncheck the Use per-VM backup files option, it won’t give you more performance since we’re forcing you to use only one Gateway Server:

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:

2.- Configure Veeam Proxy Affinity properly

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.

And we’ll select the proxy we want to prioritize:

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.

Filed Under: veeam Tagged With: veeam cifs, veeam gateway, veeam gateway server, veeam proxy, veeam proxy affinity, veeam repo, veeam rule, veeam smb

Reader Interactions

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Primary Sidebar

  • E-mail
  • GitHub
  • LinkedIn
  • RSS
  • Twitter
  • YouTube

Posts Calendar

July 2018
M T W T F S S
 1
2345678
9101112131415
16171819202122
23242526272829
3031  
« Jun   Sep »

Disclaimer

All opinions expressed on this site are my own and do not represent the opinions of any company I have worked with, am working with, or will be working with.

Copyright © 2025 · The Blog of Jorge de la Cruz