Backup Proxy from Different Subnet

[CoffeeCup]

Hello,

We have a VMWare cluster that includes 3 hosts (let’s say 10.0.0.1, 10.0.0.2, 10.0.0.2) connected to SAN via iSCSI. Cluster's IP is 10.0.0.10 and it’s how it added to Veeam. All the VMs on the hosts have IP addresses from different subnet. Veeam server is the VM on one of the hosts (192.168.1.1) and I would like to use it as a proxy for Cluster's VMs backup. In the current moment backup repository is separate physical server.
When I start the backup job with the proxy selection set to “automatic” Veeam says that proxy from the vCluster network is not found (because Veeam is using the IP from different network I guess) so I think I have to manually specify the Veeam server as proxy for this backup job.
Could you please clarify:
-does it matter for backup performance on which Cluster hosts the proxy is located or it’s doesn’t matter as soon as it’s sitting on the same datastore (SAN) as backed up VMs?
-If I manually specify which proxy to use do I also need to include the Backup server as proxy? It doesnt look for me that I should but maybe I missed something...

Thank you very much

[PTide]

does it matter for backup performance on which Cluster hosts the proxy is located or it’s doesn’t matter as soon as it’s sitting on the same datastore (SAN) as backed up VMs?

No, it does not matter if all hosts have the same level of access to LUNs where your VMs reside at. Have you considered using direct-SAN transport mode by the way?

because Veeam is using the IP from different network I guess

Could you clarify that please? Does your Veeam server have two network adapters (10.0.0.x and 192.168.1.X )or just one (10.0.0.10)?

Also, what transport mode are you going to use?

Thank you.

[CoffeeCup]

No, it does not matter if all hosts have the same level of access to LUNs where your VMs reside at. Have you considered using direct-SAN transport mode by the way?

It's a good question. I set the transport mode to "Automatic Selection" and I'm wondering now which transport mode is actually in use. We are allocate separate volumes on the SAN for each VMs. Does it mean to use the Direct SAN access mode the backup proxy should have all the volumes mounted?

Could you clarify that please? Does your Veeam server have two network adapters (10.0.0.x and 192.168.1.X )or just one (10.0.0.10)?

No, Veeam server has just one IP address 192.168.1.1 but routing table is setup so it can access 10.0.0.x subnet and it's located on the cluster's host so technicaly I should be able to use it at least in Virtual Appliance mode.

Also, what transport mode are you going to use?

The transport mode is set to "Automatic selection". Is it possible to figure out from logs which transport mode is actually in use - I dont see anything fin Job action...

Thank you very much,

[PTide]

It's a good question. I set the transport mode to "Automatic Selection" and I'm wondering now which transport mode is actually in use.

You can see that from logs, please check the screenshot. nbd stands for Network Block Device here, which is LAN transport mode:

We are allocate separate volumes on the SAN for each VMs. Does it mean to use the Direct SAN access mode the backup proxy should have all the volumes mounted?

For direct SAN you need to have a physical proxy that has a direct access to your production storage, please see this article for details. Veeam server can serve as proxy too, however if you cannot make proxy server to be physical then it'd better to stay with hotadd mode because there is not much sense to have direct SAN via VM since direct SAN approach was meant to let you avoid ESXi stack and retrieve VM's data directly from storage. Also proxies must be able to communicate with the ESXi hosts and the vCenter server (if any).

With all said, if you cannot provide a dedicated physical server for direct-SAN proxy then consider to have a three separate hot-add-proxy VMs at each of your hosts so you can use proxy_1 for VMs that reside on host_1, proxy_2 for host_2 etc.

I dont see anything fin Job action...

Answered.