Failed to resolve IP's for repository ?

[ftcnet]

Any ideas what this error refers to or how to troubleshoot it? I presume 'repository' refers to the NAS backup target? It's assigned a static IP address. I see this error on several PC's at several sites. NAS backup is a Drobo 5N at each site. Didn't see this error until ver. 3.0.2.

[DGrinev]

Hi Bernard,

Are you seeing this error on a standalone agent or in the Veeam B&R console?
Did you use a DNS name for the backup target or an IP address?
Please elaborate a bit on settings for the agents.

Thanks!

[ftcnet]

It's a typical Windows peer-to-peer environment. Shared folder is \\DROBO5N\WinUser-PC
Clicking the [Populate] button shows expected free space, so I presume it's communicating with the NAS.
I could go back to the site and try it using the IP addresses instead of NetBios name and see if that makes a difference.
I've created Case# 03964351 for this one.

[Dima P.]

ftcnet,

Make sure that you can open the mentioned file share via regular windows explorer (for both host name and ip address set in the path). Additionally, please make sure that you've set the correct credentials in case anonymous access to this shared folder is disabled. Cheers!

[asdffdsa6131]

Are you seeing this error on a standalone agent or in the Veeam B&R console?

you mentioned that you have this problem on several sites, is the backup server accessed over a vpn?

you can modify the hosts files to hard-code the dns entry like so.
192.168.1.66 DROBO5N

[ftcnet]

I've only encountered this error since VAW 3.0.2. All VAW installs are standalone on peer-to-peer (workgroup) environment. The NAS (Drobo 5N) is on the local LAN (no VPN involved).

The NAS shares are accessible from Windows Explorer by host name and IP address. I'm confident the entered network credentials are correct. [Populate] wouldn't work if they were wrong. The sequence is:
* Initializing
* Preparing for backup
* Creating VSS snapshot
* Finalizing
X Error: Failed to resolve IP's for repository ..
X Processing finished with errors ..

[DGrinev]

Bernard,

Please work with the support team since it's hard to guess without the logs review.

Thank you!

[agrob]

Was there any solution on this case? I'm facing the same issue at the moment, thanks

[Dima P.]

Andre,

This problem is usually related to connectivity issues, make sure that the set account has access to the share (read/write permissions) and that the file share in the question is accessible via regular windows explorer from the same machine. Cheers!

[agrob]

Hello Dim

Thanks for your Feedback. I'm aware of that. i already checked SMB Access with windows explorer with the same account and it wa successful. This problem happens only if i'm connected via direct access to your company (where the backup target is). it worked serveral months but suddenly stopped. when i do a classic vpn connection to your company (ipv4 transparent) backup works again... So just with DA connection the problem ocur.

[Dima P.]

What backup target are you using? If that's a Veeam repository most likely you cannot access the repository over internet (non-vpn connection) thus you get the resolution error.

[agrob]

It is a NAS Folder and i can access the folder via windows explorer. It worked normaly several months before it suddenly stopped working. if i edit the job in VAW and and in the destination tab click "Populate" it can access the shared folder, i can also browse the folder and see other backup files... but as soon as the job starts, it throws the error... strange

[Egor Yakovlev]

Hi Andre,

Please open support case(can be done directly from agent UI) and share it's number here.

/Thanks!

[ds307]

I performed an upgrade from Version 2.2.0589 to 3.0.2.1170

The 2.2 backup job ran without issue, the job on 3.0 fails with the following error:
6/18/2020 10:16:24 AM :: Error: Failed to resolve IPs for repository [id=80b93950-d7b1-44e9-80a3-2b0fb697761e:name=Shared folder:host_id=6745a759-2205-4cd2-b172-8ec8f7e60ef8:mount_host_id=00000000-0000-0000-0000-000000000000:path=\\drobo5n\backup]

I have experienced this on three different Win10 systems backing up to the same NAS.
The share is reachable from Windows Explorer.

I opened support case 04229049 but it was archived due to high Support Team load.

I saw one thread in the forums for this issue but there was no resolution.
I have also tried to upgrade to 4.0 and received the same error.

[Egor Yakovlev]

Hi Dave.
I have checked your case's logs and here are my findings:
- initial backup attempts were done using Veeam Agent for Windows 2.1 which officially supported Win 10 up to "Creator's Fall Update" Version 1709 build 10.0.16299. On the other hand Win 10 you have is newer, Version 1909 (November 2019 Update) build 10.0.18363. So I just skipped those backup attempts troubleshooting as unsupported, however I can clearly see each session failed due to "Access denied" error for your account on said NAS box folder.
- Official support for Win 10 1909 came with Veeam Agent for Windows v4, and you have 1 backup attempt in the logs, dated 06/13. From that log I can see a connection break between Veeam agent and NAS box happened "[13.06.2020 11:26:56] <11> Error An existing connection was forcibly closed by the remote host (System.Net.Sockets.SocketException)" which usually indicates connection break(service down, connection drop, firewall lock, target refused connection etc).
So like posts above says, check networking stability, DNS name resolution for NAS box name and access permissions.
/Cheers!

[ds307]

I made sure the user account on the Win10 system match the Drobo NAS, Thinking there was an issue with connecting to the backup share with a different username than the logged in user. I don't think it made a difference.

The one thing that did is I turned off IPv6 on the network adapter settings in Windows. It looks like the backups are running now.
I tried this one two systems with the same results.
The Drobo does not seem to have IPv6 settings so I am not sure about that.
I did try to ping the drobo from powershell and every few tries I see an IPv6 reply rather than an IPv4

Any thoughts? I am going to perform some more tests.

[Egor Yakovlev]

Well, Veeam Agent does not operate on IPv6, so for sure that might be a good reason to disable it, especially taking a fact you don't use it in your infrastructure anyway.
/Cheers!