FEATURE REQUEST: VBR manageable Agent Networks

[iwdinw]

Hello,

In Case # 01999304 I was confronted with a problem having a configuration of Veeam Backup & Recovery (VBR) and Veeam Endpoint Backup (VEB).

Here is some of my VBR/VEB-configuration:

• Networks
  - Production Network
  - Backup Network
  -- Jumbo Packets
  
  Physical VBR server with
  - 4 Network-Ports, configured as 2 Teams:
  -- 1 Team in Production Network
  -- 1 Team in Backup Network
  - Windows Network Priority set to
  -- 1. Production Network
  -- 2. Backup Network
  - VBR 9.5.0.711
  -- no Global network Traffic Rules
  -- Preferred Networks set to Backup Network (Fallback to Production Network occurs automatically)
  -- Endpoint Repository on NAS with CIFS in Production Network
  --- Agent Permissions: single Agent-User
  --- (Other Repositories on Backup Network)
  
  NAS
  - with 4 Network-Ports, configured as 2 Teams
  -- 1 Team is in Production Network
  -- 1 Team is in Backup Network
  - configured as
  -- CIFS Repository for connections from production Backup Network
  -- (Linux Repository for connections from Backup Network)
  
  Workstations with
  - 1 Network-Port in Production Network
  - VEB 1.5.0.306, with the following configuration
  -- Volume Level Backup
  -- VBR-Repository
  -- Agent User
  -- 1 Day retention
  -- ...

So basically I have a rather simple VBR configuration with two networks. The traffic from the VBR initiated backups goes over the Backup Network.
And on the client side I have workstations with one network port, which should be backed up using VEB using the Production Network.

Here is the problem:

• Incremental VEB Backups take a really long time in this setup as compared to using the same VBR-Repository but as a shared folder configuration in VEB (practically circumventing VBR).

Together with a veeam support contact we figured out the following:

1. 1. VEB initiates the connection to the VBR server.

• 2. The VBR server tells the VEB client the IP addresses the Windows server is set up with. Because of the “primary networks” configuration in VBR the VBR server, tells the VEB Client its IP address on the Backup Network first.

• 3. The client tries to connect to the IP address of the VBR server in the Backup Network from its IP address in the Production Network.

• 4. There is no route on the client to the VBR server in the Backup Network. So after several retries it falls back to the next IP address it got from the VBR server.
  In the VEB logfile you will find the following:
  Failed to connect to agent's endpoint 'VBR-IP-ADDRESS-IN-BACKUP-NETWORK:2503'. Host: 'DNS-NAME-OF-VBR-SERVER'.

• 5. Then It falls back to the other IP (in the Production Network) the server gave it, connects, gets the NAS repository and transfers its shadow copy data. etc. (I guess the Veeam Support is better at describing what exactly happens here.)

• 6. In the finalizing step of a VEB backup you will find the same errors and retries again.

All the retries sum up to about 5 Minutes per VEB Backup that are not necessary.

My support contact told me, he

consulted with [...] T2 engineers and they've said that setting Preferred networks settings in VBR should be enough with VBR jobs and agents, but it's not known how does it work with Endpoint agents.

So here comes my suggestion of improvement:

• Usually in a VBR-Setup all backups are initiated on the VBR-Server side.
  In a setup that involves VBR and VEB some Backups are initiated from the Client-side.
  
  BUT: VBR recognizes the VEB Client as an agent, knows where it comes from network wise and gives it the appropriate data for its Backup.
  The VBR server should give the VEB client only the data it can work with.
  This could be made manageable by adding a new menu “Agent Networks” to the “Global Network Traffic Rules”

expected result:

• smaller VEB backup time
• fewer errors (at least in the logs)
• less support time

cheers,
Chris

[Dima P.]

Hi Chris,

Thank you for your post. Checking with QA team, stay tuned.