Separate network backup traffic and backup traffic for backup repository server

You need to use network rules within Veeam.  As long as each subnet can talk to each other you are good.

https://helpcenter.veeam.com/docs/backup/vsphere/network_rules.html?ver=120

https://bp.veeam.com/vbr/3_Build_structures/B_Other/network_rules.html

Hi ​@Kan Lin This is the goal:

Use IP 1.0.0.1 primary NIC to receive primary backup data from production VMs.

Use IP 2.0.0.1 secondary NIC to send backup copy data to another secondary backup repository.

let's check how we can achieve this target:

Configure the network interfaces and make sure firewall ports are open between 2500-3300 for data movers.

IP 1.0.0.1 to the NIC used for regular backup traffic.

IP 2.0.0.1 to the NIC used for backup copy.

Configure Hostname:

repo-backup. domain.local → 1.0.0.1

repo-copy.domain.local → 2.0.0.1

in the end create a new traffic rule in VBR.

Source IP: your VBR IP
Target IP: 2.0.0.1 for backup copy
Ports: default or customized ports
Purpose: Backup Copy traffic only

Please check hows going.

Hi Kan Lin, 

i have almost this design as well

as mentioned here, it replication to secondary repository server will run, it will run over 2.0.0.1, but if you will see traffic needed as well backwards from secondary to primary on ports 2500-3300. So in some cases you will have connection back and this will be from 2.0.0.1 to 1.0.0.1. So completely to isolate is not possible.

in my design i have two different admin lan so 1.0.0.0 and like 11.0.0.0  and both components have same backup vlan like 2.0.0.0. Then traffic is on 100% only via 2.0.0.0.

So if on secondary repository server you will remove interface, or change, you will always have traffic over 2.0.0.0, as there is no other opton.

If you cannot, you an edit hosts file and put into hosts ip 2.0.0.0 of primary repository server (if you are using fqdn in console), then traffic will try to reach over fqdn and traffic over 2.0.0.0 will be managed via this vlan only. In my tests host file is used first and then dns, so traffic should always run over 2.0.0.0. So is not problem to resolve fqdn of primary on secondary repository as well.