DNS resolution
Domain Name System (DNS) resolution to IPv4 addresses is critical for Veeam Backup & Replication deployment, configuration and daily operations. All infrastructure components should be resolvable through a fully qualified domain name (FQDN). This is especially important for vSphere/Hyper-V hosts and clusters. Resolvable means that components are accessible through both forward (A) and reverse (PTR) lookups. While reverse resolution is not mandatory, forward resolution totally is.
For this reason, you need to ensure that the Veeam Backup & Replication server is installed on a machine that has a resolvable FQDN, and also all the other components are resolvable in the same way. To check that the FQDN is resolvable, type
nslookup vbr-server-name.domain.local
at a command line prompt. If the FQDN is resolvable, the nslookup command returns the IPv4 address and name of the Veeam Backup & Replication server.
Proper DNS resolution should always be the preferred method to find machines in the network. With it, a network administrator should only have to take care of the DNS server(s) and their zone files, and every time a zone is updated with a new record, the entire network will immediately see the changes in a consistent way. There are however situations where DNS resolution is not available; in these cases, you may add the infrastructure components (like e.g. VMware vCenter, ESXi and managed Veeam servers) to the local hosts file on all managed Veeam servers. When using this workaround, it is recommended to add both short name and fully qualified domain name in the hosts file.
When using the hosts file, you should keep track of which servers had their file modified, and ensure that the content of these files is consistent across all the copies.
When ESXi hosts are added to vCenter it is recommended to use FQDN. When backing up through the network with the Network Block Device (NBD) transport mode, the FQDN is returned via VMware API for Data Protection (VADP) so the backup proxy server must be able to resolve the FQDN via DNS.
Using the hosts file the data transport path can be altered for NBD transfers. Let’s use the example below.
Example hosts file
10.0.4.10 vcenter vcenter.example.com
# 10.0.4.21 esx1 esx1.example.com # commented out 1GbE management interface
# 10.0.4.22 esx2 esx2.example.com # commented out 1GbE management interface
10.255.4.21 esx1 esx1.example.com # dedicated 10 GbE backup network
10.255.4.22 esx2 esx2.example.com # dedicated 10 GbE backup network
The management interface of the two ESXi servers is located on the 10.0.4.0 subnet, that is the same network where the vCenter server is, and has a speed of 1GbE. By relying on the DNS server, this would be the IP addresses that our backup proxies would receive and use to connect to the ESXi servers. But our infrastructure has also a secondary network, dedicated to backups, that has a speed of 10GbE. We want to use this network for our backups, so by editing the hosts file, we let our proxies know that the two ESXi servers are reachable via the 10.255.4.0 subnet. The final result is that the backup traffic will flow via this dedicated network.
To explicitly alter the data transport path, the hosts file must be deployed on all backup proxy servers.