The host names of the machines involved in the backup must be resolvable to IPv4 address. In basic terms, host names of all client nodes involved in backup need to be resolvable from the Command Server, otherwise backups will not work properly. This requirement did not exist in earlier versions of the DataCenter product, it started in version 8. This would apply to any client node which you have added to the Nodes Management area of the Command Server GUI, whereby the Default Address property of the node is assigned by IP address. From the Command Server machine you would need to be able to ping the host name of all clients and have it to resolve to the IP address which is specified as the "Default Address" property of the node. This differs from versions of DataCenter prior to version 8, where it did not require host name resolution for nodes involved in backup. You will need a DNS "Host A" record entry on your DNS server(s) for each client node, which contains the host name and the IP address that the Default Address property is set to when viewing the node's properties. This would apply to any client node where the Default Address property for the node is using an IP address. This would include WORKGROUP joined Windows machines and any Linux machines. Alternatively, the Windows hosts file on the Command Server can be used for host name mapping and that also works equally as well. The need to do this appears to be less of an issue if the Windows OS is more modern (at that point the client node host name is being read and resolved via NetBIOS from the Command Server properly). If you have an issue with Connectivity Test, or a backup log that shows "Failure: failure" for the contents, where it appears the data mover process is working to backup selected files, an .SV file (backup file) is created in the target disk pool, but in the end no Restore entry exists for that failed backup, take a look on the Command Server to see if you can resolve the host name (DNS name), via 'ping hostname'. If the host name cannot resolve to the IP address that was specified in the Default Address property of the client node, then that is likely why this failure is occurring. On the Command Server machine you can try to perform a "ipconfig /flushdns" and then "ipconfig /registerdns" via an Admin Command Prompt, and then try that same ping command again. The host name will need to resolve to the IP address that was utilized as the Default Address if using an IP address (and not a DNS address) there.
There should be nothing necessary to change on the client node machines, but to confirm, you should attempt to resolve the host name of the Command Server from each of your client nodes, to make sure that each client node can communicate to the Command Server by way of the Command Server's DNS address. This would be more important if the Windows machine was in a WORKGROUP or it were a Linux machine that does not utilize NetBIOS for host name translation (a hosts entry in /etc/hosts file in Linux could be created in that case to map the Command Server's IP to DNS address, the format of the hosts file entry is the same regardless of Windows or Linux). So example 'ping commandserver', where commandserver is the host name of the Command Server. That needs to resolve and show you a valid IP address and ping response that correlates to the Command Server.
Example node properties for our Linux node, as seen when initially adding the node via Nodes Management, showing the Linux node being searched for by IP address at the top, after clicking "Fetch" button, in this case we change nothing about the Node Info after it is fetched when we add the node:
Example node properties for our Linux node, as seen when editing the node only to view the address properties in "Configure Address" via Nodes Management, showing the "Default Address" property at the top which contains the IP address of the Linux client node:
Example ping command from the example Linux node:
PING commandserver.sv.novastor.local (192.168.0.123) 56(84) bytes of data.
64 bytes from commandserver.sv.novastor.local (192.168.0.123): icmp_seq=1 ttl=128 time=0.318 ms
64 bytes from commandserver.sv.novastor.local (192.168.0.123): icmp_seq=2 ttl=128 time=0.303 ms
The client nodes should all be able to resolve the host name of the Command Server machine. If they cannot then something is either incorrect in DNS or other methods of name resolution, and either the DNS entry needs to be corrected on the DNS server, or a hosts file entry will need to be added to the respective hosts file on each client node machine. Both Windows and Linux can utilize a local hosts file, and details on how to do that follow.
How-to Instructions / Steps:
You will need to create a DNS "Host A" record on the primary DNS server which your Command Server and client nodes utilize as a DNS server. Alternatively you can create a Windows hosts file on the Command Server itself, and add an entry for each client node, to map the host name to the IP address (the IP address there would be what is specified in the Default Address property for the node) of the node, and that will work as well. How to do this is detailed below.
On your Windows Command Server machine, backup the C:\WINDOWS\System32\Drivers\etc\hosts file as hosts_backup. Then edit C:\WINDOWS\System32\Drivers\etc\hosts in notepad or in NotePad++ (better), and then add a static hosts entry per client node. For a Linux Command Server machine, the hosts file is /etc/hosts. The format is the same for both Windows and Linux for the hosts file. Note: Make sure that after making your changes, that the file actually saves, so edit it twice, the second time to verify the contents, and if it is saved you can test it by pinging the host name now from the Command Server to see that take affect instantly. Some good third party tutorials on understanding and using the hosts file are here, and here. An example hosts file that contains some host entries discussed in this article is here:
# localhost name resolution is handled within DNS itself.
# 127.0.0.1 localhost
# ::1 localhost
The first portion of the Windows hosts entry is the IPv4 address of the client node, which is the preferred IP to communicate with the node, as configured in the Default Address portion of the node in Nodes Management:Edit Node. The second portion is the computer name, which is what is displayed as the "Host Name" value in Nodes Management:Edit Node. The host name is the computer's name, without the DNS suffix added. Add every client node that you are using that technique with (where the Default Address = an IP address and not DNS address) as a static Windows hosts file entry on the Command Server in question.
After saving the hosts file entry to the Windows hosts file, go back into the Admin Command Prompt session on the Command Server and perform an "ipconfig /flushdns" and then "ipconfig /registerdns" via an Admin Command Prompt. Now to attempt to resolve the client node host names again via 'ping hostname' command, so 'ping vm1-srv2019' and 'ping vm2-srv2019'. If not, go back and verify the contents of that host record either in the DNS entry on the DNS server that it exists at, or the Windows hosts file on the Command Server. You should be ready now to test perform a connectivity test and run the backup job. Here is an example step-by-step operation performed on the Command Server machine via an Admin Command Prompt. In this case we do not have a DNS entry on any of our local DNS servers for the example Linux client node to be able to ping it by host name from the Command Server, so it fails the first time:
In the example we perform the 'ipconfig /flush' and 'ipconfig /registerdns' commands, then we ping the host name of the Linux client node, which fails to resolve, then we add the Windows hosts file entry on the Command Server, then we ping one more time and the host name resolves for the Linux client node now. If the Command Server cannot properly communicate to the client node it won't be able to perform backups properly, even though you may see data mover functions process files during backup and the backup .SV file may store ultimately, the log may show failure and this backup may not have an entry to be able to restore it.