How VBR handles name lookup for agents

[DanielJ]

I found a confusing inconsistency that I thought could be worth mentioning here:

Imagine that you are tasked with backing up a number of servers with VAW. You get a list of ip addresses and hostnames. The names are generic ones like "web01" so you invent a domain name and add it to each name, to know which customer/company they belong to. You add the "web01.company.com" names along with their ip's to the hosts file on the VBR server. The VBR server uses the hosts file for all its lookups to avoid being dependent on dns, but it does have dns servers in its network connection as a fallback. After adding all servers to a protection group, you deploy the agents. You add the protection group to a backup job and run it, and it works fine. The next day you want to do a restore test, so you open "Restore guest files" for a random server, right click a random file, and select Restore. The restore process times out and fails. Then you try the same file again, but select "Restore to" instead, and select the same server. This works.

The problem has to do with name lookups. This is how VBR acts to get the ip address in different situations (at least how it looks to me) :

"Test now" while adding to a protection group: VBR gets the ip from the hosts file (I guess it just asks the OS, which finds it in the hosts file).
Deploying agent: Gets the ip from the hosts file.
Rescan agent: Gets the ip from the hosts file.
Running a backup: Gets the ip from the hosts file.
Restore a file using "Restore to": Gets the ip from the hosts file.
Restore a file using "Restore": Here something weird happens. It looks like VBR first gets the ip normally, then uses it to ask the agent what the hostname is of the server it is installed on, then tries to resolve the ip of this hostname, which most likely is something else than the name used to add it to VBR. If that fails, the ip it already got is used and the restore works. But if the dns for some reason can resolve this name, it might very well resolve to something completely different than the ip that should be used for backups, and the connection fails.

Why does this particular use case, and only that, use such a different method? Support suggested that it is because the agent server might use dhcp, which I don't really understand since it looks like VBR first must contact the agent server to get its "internal" hostname, and if the server had changed ip since last time it wouldn't have worked anyway, and the backup wouldn't have worked either. Yes, this happened for real (ticket 07475403 which is closed now).

Using each server's real hostname instead of inventing names would also have failed, since those names were resolvable by the dns, and VBR bypasses the hosts file in the described situation. All I could do was to clear out the dns addresses from the connection, so the VBR server must rely fully on the hosts file. After that, everything works as expected.

[Andreas Neufert]

I will ask someone from the Agent team to comment here.
But maybe a question upfront.
The system that runs the (UI) console and the system that is selected as "mount server" for the repository, do they have the same hosts file present?

Usually what happens is that we fallback to all kinds of processing and this is why it looks like that we are checking DNS from the agent, but before that we likely test other connections and use this only as fallback.

Our support can maybe help as well with analysing the logs and give you a better insight. Please open a ticket and upload logs. Please share here the ticket number for reference.

As a fast workaround you can always restore the files to the backup server and then copy it manually.

[Dima P.]

But if the dns for some reason can resolve this name, it might very well resolve to something completely different than the ip that should be used for backups, and the connection fails.

I suspect this one to be related to DNS cache on the B&R, seen similar behavior in the past.

(ticket 07475403 which is closed now)

Will review it with QA folks, thank you!

[DanielJ]

The system that runs the (UI) console and the system that is selected as "mount server" for the repository, do they have the same hosts file present?

Yes, they are the same server.

I suspect this one to be related to DNS cache on the B&R, seen similar behavior in the past.

I see that it's easy to misread my post as "if the dns for some reason CAN'T resolve..." rather than "can resolve". In my case I was surprised when the names VBR tried to use (which it got from the agents) were resolvable, and resolved to public addresses which VBR obviously couldn't use. My suggestion for all this is to let VBR always rely on what the OS looks up for it, since it will then be clear for everyone that all lookups will be through the hosts file first and through the configured dns servers second, rather than trying to do some smart stuff with names it pilfers from the agents' OS.

[Dima P.]

Daniel,

Got it. QA is investigating the resolutions while performing the "Restore" option. Thank you!