Backups Across Segregated Networks

[kalbers]

I have three networks. Network A is the primary, network B is the user network in building BB, and network C is a segregated network in building BB. Network A and B can see each other with no restrictions. Network C can seen B, currently with no restrictions, but will eventually be locked down to where C can only see certain devices on B. Network C cannot see anything outside of Building BB, including network A. I do not have the option of making network A able to see into network C, or vise vera.

I have a Veeam B&R server in network A that does all of our backups currently to physically attached storage that is two physical repositories configured as a single Scale-out Repo. I have a handful of devices in network C that I somehow need to get backed up on our B&R server. I would just setup a second B&R in building BB, but need to get the backups stored outside of building BB due to controls that I must follow.

Network C has two VMs, two Red Hat hypervisors, and 5 physical Windows Server machines.

Can I setup some sort of proxy on network B to relay the backup data to the existing B&R server, or can I setup a second B&R server in building BB to use the repositories that reside on the first B&R server? If I go the second way, how does that affect the first B&R's ability to manage the space for its backups? Is there a better option I'm not thinking of?

Case # 04888058

[Andreas Neufert]

Can you please add a drawing so that we better can understand?

[skrause]

Can I setup some sort of proxy on network B to relay the backup data to the existing B&R server, or can I setup a second B&R server in building BB to use the repositories that reside on the first B&R server? If I go the second way, how does that affect the first B&R's ability to manage the space for its backups? Is there a better option I'm not thinking of?

You can always have multiple B&R servers connecting to the same infrastructure components (proxies, repositories, etc.) but you need to take into account that the two B&R servers are not aware of each other so their job/resource schedulers are unaware of what the other B&R server is having the system do. It also means that the backup files will not show up in the other B&R server unless a rescan/import is done on the repository.

If you schedule your jobs in such a way to not have the tasks run at the same time you should be ok.

[PetrM]

Hello,

@kalbers I'd like to clarify one detail:

Network C cannot see anything outside of Building BB, including network A.

In this case, I don't understand how will data flow go from the network C to the repository in the network A?

If there is a route from C to A, then the second VBR is not needed. If there is no route, I believe that the repository from A will be unavailable for backups coming from C.

Thanks!

[kalbers]

You can always have multiple B&R servers connecting to the same infrastructure components (proxies, repositories, etc.) but you need to take into account that the two B&R servers are not aware of each other so their job/resource schedulers are unaware of what the other B&R server is having the system do. It also means that the backup files will not show up in the other B&R server unless a rescan/import is done on the repository.

If you schedule your jobs in such a way to not have the tasks run at the same time you should be ok.

I'm not worried about the backup scheduling, but do appreciate you pointing that out. My main concern here is whether or not the second B&R or a Veeam Proxy can utilize the repository that is physically attached to the first B&R server.

In this case, I don't understand how will data flow go from the network C to the repository in the network A?

If there is a route from C to A, then the second VBR is not needed. If there is no route, I believe that the repository from A will be unavailable for backups coming from C.

Thanks!

You're correct in that C can't see to A, but both A and C can see into B. We're hoping there's a solution where we can put something in B to bridge the gap between A and C.

[Mildur]

My main concern here is whether or not the second B&R or a Veeam Proxy can utilize the repository that is physically attached to the first B&R server.

This will work with some requirements/limitations:
- Linux hardened Repo will not work
- windows local Disk Repo will work, but please use dedicated folders for each vbr server, don‘t use the same folder for multiple vbr servers
- both vbr servers targeted to the same windows local disk Repo needs to be on the same veeam version/build number
- for SMB Repos, nothing special, it will work, but create dedicated shares for each vbr server

[PetrM]

Hello,

If A and C are reachable from B, then why don't place a single VBR in B and keep the repository in A instead of deploying a new VBR and share the same repository between two different instances?

For VMware workloads: it will be enough to deploy a backup proxy on B.
For non-VMware workloads: you can create jobs in "Managed by backup server" mode and point these jobs to a shared folder SMB/NFS in A. Also, you can specify a gateway server from B, this server will play a role of the bridge. For example, it could be VBR itself. In this case, data transfer will be performed between Veeam Agent service that runs on the protected computer (C) and Veeam Data Mover that runs on the gateway server (B).

Thanks!