Feature Request - Add option for Veeam Agent to backup ONLY if it's on same subnet as repository

[Novox]

In my scenario, we have a hub/spoke network, where our headquarters is the hub and branch offices are the spokes. Backups are performed at headquarters and branch offices are connected to headquarters via VPN.

In the case where a laptop user is at headquarters, Veeam Agent backups backup to the local repository without a hitch.

When staff travels to branch offices however, the agent will still attempt to backup per the agent schedule. The repository is still reachable due to our topography. Therefore, these remote machines attempt to perform their backups over the WAN/VPN links. This can, at times, saturate our WAN links, and frequently the backups fail during the copy or merge operations because they take so much extra time and are sensitive to any network hiccups.

I'm requesting an option to allow or suppress backups if agents are on the same subnet as the backup repository. I would personally suppress these backups. I know this would increase my RPO for the client computers, but it would greatly decrease network traffic, often wasted due to subsequent failures.

Thank you!
~Bill

[Dima P.]

Hello Bill,

Thank you for your request. May I ask how these devices are connected (via WiFi or regular network cable)? Have you tried to specify the global throttling options via Veeam B&R console to achieve your goal? Cheers!

[Novox]

The devices are connected both wired and over Wireless.

The throttling options look like I can throttle the speed between different ranges of IP addresses, but I cannot set that speed to zero or otherwise suppress the backup.

The issue is less about the bandwidth saturation, and more about the jobs that frequently eventually fail because of the speed/network... (either the data copies or the merging)... since remote jobs take longer anyway, they are more susceptible to network hiccups, or the employee simply not letting the job complete (and not knowing it's happening when they reboot or shutdown).

For example, I very frequently see this error when remote agents try to perform backups to our headquarters.

Full backup file merge failed Error: Agent: Failed to process method {Transform.Patch}: An unexpected network error occurred.
Error: Agent: Failed to process method {Transform.Patch}: An unexpected network error occurred. Failed to read data from the file [...].

[Dima P.]

I cannot set that speed to zero or otherwise suppress the backup.

You can set Preferred Networks for Data Transfer rules.

The issue is less about the bandwidth saturation, and more about the jobs that frequently eventually fail because of the speed/network... (either the data copies or the merging)... since remote jobs take longer anyway, they are more susceptible to network hiccups, or the employee simply not letting the job complete (and not knowing it's happening when they reboot or shutdown).

Understood, thanks for the clarification. Will it work if backup is stored locally in backup cache while user is away from backup network? Backup cache functionality is now available in standalone agents only but we plan to provide it for the managed agents as well.

[Novox]

I don't think "Preferred Networks" is going to help me because we have only one route from remote sites to our headquarters, and if I understand "Preferred Networks" correctly, it will choose the preferred one if there are more than one, otherwise, it will continue to allow backups to happen on "other" networks.

Will it work if backup is stored locally in backup cache while user is away from backup network?

I don't know, does this functionality work if the agent is operating in Free mode, but still backing up to Veeam Infrastructure? (is that considered a standalone agent?) Do the standalone agents realize they're not on the same network as the backup infrastructure and store backups locally? If so, then it might work?

I reviewed the "Backup Cache" feature.

• It looks like it's a licensed feature as I can't find it anywhere in the Free version

• Regardless, the agent checks connectivity by attempting to connect to the Veeam Backup Service. Backup Cache is used when there is no connectivity, defined as follows:

  [For Veeam backup repository] Veeam Agent for Microsoft Windows Service cannot connect to the Veeam Backup Service that runs on the backup server to which the backup repository specified as a target location for Veeam Agent backups is connected.

  In my scenario, there is always a route, and therefore "connectivity" to the Veeam Backup Service such that I don't think the Backup Cache would ever get triggered.

[deebee]

Sorry if there's some intricacy I can't work out here - but could you not simply drop traffic to the B&R server from remote subnets used by the users?

That would prevent connectivity and therefore the backups happening from that remote site, even if the B&R IP is routable.

If you've got devices on the remote networks you do need to back up, you can still allow those specific IP's to connect while blocking 'others' from the remote subnet.. result should be what you're after I think?

[voyager529]

Sorry if there's some intricacy I can't work out here - but could you not simply drop traffic to the B&R server from remote subnets used by the users?

That would prevent connectivity and therefore the backups happening from that remote site, even if the B&R IP is routable.

This.

Assuming you have VBR installed on a server or VM such that the only reason traffic would be going there is to do the backups, you can use your firewall to deny traffic from the VPN subnet to the VBR server. You can also do this in the Windows Firewall on that server, if nothing else.

Joey