Backup Proxy Selection Algo

[Zew]

Site A <-> Site B
Route changed from /24 to just /32 for just vCenter from Site B to Site A
All jobs work, one job picks wrong proxy.

"Failed to read VDDK" Checking log shows wrong proxy selected.

Quote from Tech "In reviewing the logs it appears that Veeam did what it always does when choosing between available backup proxies. That is, for each one, it determines if it is on the same subnet as the ESXi host"

1) Proxy does not sit on same subnet as ESXi host that is running the Guest VM being backed up
2) ESXi host that (incorrect proxy chosen) proxy sits on, recently got a new VMPG in which the Guest VM is a member of (but not running on this host)

*Workaround* I manually select the proxy that it should be using to complete the job and it works.

Is there a white paper for this algo as to better determine the root cause of the wrong proxy selection?

Case #01982435

[HannesK]

Hello,
can you describe a little bit more what you mean with /32 route? That's just a host-route...

The general order is described here https://helpcenter.veeam.com/docs/backu ... ml?ver=110 - it sounds like that you are only using NBD. That means if the proxy is not in the same subnet, the selection is more or less random, as we cannot know which one is the "nearest".

There are two ways to solve that
1) set the proxies in the backup jobs
2) set proxy affinity on the repository https://helpcenter.veeam.com/docs/backu ... ml?ver=110 (Note: see the "Proxy affinity rules are not restrictive." part)

Best regards,
Hannes

PS: the case number is many years old... can you please close the case on your own, as support is to help with technical issues and not with "how-to" questions

[Zew]

I do apologies, wrong case number. I see no way for me to edit my initial post, feel free to remove that, the actual case number is: #04762927

The general order is described here https://helpcenter.veeam.com/docs/backu ... ml?ver=110 - it sounds like that you are only using NBD. That means if the proxy is not in the same subnet, the selection is more or less random, as we cannot know which one is the "nearest".

Thanks, correct one couldn't not indicate that (nearest), but one would assume a ping test would help picking a suitable one? What really baffled me though was it not only picked one that had no network connectivity the the source VM, it picked the proxy that has no connection to the target backup repo. The selection over all is rather baffling.

There are two ways to solve that
1) set the proxies in the backup jobs

Yeah I already did that as a work around.

2) set proxy affinity on the repository https://helpcenter.veeam.com/docs/backu ... ml?ver=110 (Note: see the "Proxy affinity rules are not restrictive." part)

This probably what I'd need to avoid it, per my statement above that the proxy wouldn't even be able to reach the target, however. I went to my Backup Repo and I couldn't see anywhere to set this setting.

"Proxy affinity settings are specified at the level of a backup repository. By default, Veeam Backup & Replication lets all backup proxies in the backup infrastructure access the backup repository. Using proxy affinity settings, you can define a list of backup proxies that can access this backup repository." That's nice, but the linked KB has no snippet to show an example, or even how to navigate Veeam to find it...

Thanks for the additional information, and sorry again about posting a wrong case number.

[HannesK]

no worries about the case number

but one would assume a ping test would help picking a suitable one?

that could still lead to situations where a low bandwidth low latency connection is chosen over a high bandwidth temporarily higher latency connection. But sure, there is always room for improvement in software.

That's nice, but the linked KB has no snippet to show an example, or even how to navigate Veeam to find it...

do you mean the extra page where it has pictures? https://helpcenter.veeam.com/docs/backu ... ml?ver=110


If the button is not available, then I assume that you run standard edition?

Best regards,
Hannes

[Zew]

Thanks Hannes,

The support guy was amazing and helped analyze pretty what had happened. As I stated I made a site to site route change, and only allowed a route to the vCenter server, Un-beknown to me I guess since I had created that proxy (for a completely different purpose), it must have started using it. Since I only created a route to vCenter from that site (b), the proxy in that site was trying to reach the ESXi server in site A. Which... wait a second, this might have been DNS related on the proxy there.

so basically, the IP look up from (Site B Proxy) failed to get IP for (Site A ESXi Host). I just didn't think it would ever use this proxy for this job, but he provided a good reference on the FAQs.

Correct, I must be running standard. So appears that solution is out of my grasp. my workaround appears to be the only solution.