How to make backup data travel via different network?

[spgsit5upport]

2 x Hyper-V cluster. Each server connects to mails Lan (of course) as well as to dedicated separate iSCSI network (via 10G connections)

Veeam is installed in VM, using offhost-proxy (one of the Hyper-V hosts), backup happens to Windows share (2012 R2 with lots of space, also connected to both networks - 1Gb Lan & 10G iSCSI data network)

How to make actual backup travel via 10G iSCSI network (and not main Lan)?

In Veeam console repository can only be chosen as main Lan address (as this VM has no idea/no connectivity to iSCSI network)

Would local host entry on the Hyper-V servers pointing Netbios name used in Veeam console to iSCSI network address do the trick?

Seb

[foggy]

Basically, to enable data transfer over the 10GB network, you should add proxy and repository servers via corresponding addresses into Veeam B&R console. Is there any reason why you use CIFS type of repository while you could add the 2012 R2 box as a Windows server? If this is not an option, you could probably specify the proxying server from the 10GB network for the CIFS repository to accept traffic from proxy (configurable in the repository server settings).

[spgsit5upport]

OK, I do not use CIFS, I have added the 2012 R2 as Windows server to Veeam B&R console.

But it is added with Netbios name (which Veeam B&R console VM resolves as main Lan IP, as it does NOT have any access to iSCSI network)

Hence the question about changing hosts entry in the Hyper-V hosts

If I try to add offhost proxy it still only gives me access to same Windows machines that are predefined with Netbios name

Seb

[spgsit5upport]

Surely that is not an unusual setup?

Nobody does it this way?

Seb

[nefes]

Resolving of repository IPs happens on backup console. Is there a possibility to connect console VM to 10G network and add repository by IP in that network?

[spgsit5upport]

No, as backup console runs in VM that does not have any connection to dedicated data iSCSI network

Design flaw if you ask me then

Seb

[foggy]

But you could plug it into the corresponding virtual switch so that it get address in this network.

[spgsit5upport]

Not really, as I have NO virtual connection of any kind from my Hyper-V cluster

The ONLY connection that exists is physical one from Hyper-V hosts via dedicated cards/switches

VM running in the cluster does not know anything about this storage network at ALL

Seb

[foggy]

Then you could switch to CIFS and specify some server with access to both networks as a proxying one for the repository (as I've mentioned in my first post).

[spgsit5upport]

Lets try again. Hosts have access to BOTH networks. Veeam VM has ONLY access to internal 1Gb network (it knows NOTHING about existence of iSCSI data network)
The backup is done on-host. Shall I add this host to be also a proxy?

No need to use CIFS as all involved are Server 2012 R2

Seb

[foggy]

Seb, please review this thread discussing similar setups, probably will give you some hints.

[spgsit5upport]

Resolving of repository IPs happens on backup console.

"The other way is to register both proxies in Veeam using their DNS names (which should resolve to their production IP's) and use hosts file on each of them to point the counterpart's DNS name to its IP address on replication network."

Why would I need proxy when the backup is done onhost (Hyper-V host directly to Storage server)

Would that proxy need to be the very same host?

I already have local hosts file entries that point to iSCSI network addresses, but as per quote above that makes no difference

Seb

I do not want to mess with routes on the Hyper-V host itself (that is asking for troubles!)

[foggy]

In case of on-host backup, the role of the proxy is performed by the host itself.

Do you have those entries both on the host and repository server?

[spgsit5upport]

On both hosts I have Netbios entry & DNS entry for the repository pointing to 172.x.x.x iSCSI network

On the repo I have Netbios entry & DNS entry for each Hyper-V host pointing also to 172.x.x.x iSCSI network

So as far as hosts & repo are concerned there is NO other network

The "bottleneck" is only how Veeam console sends the data

Seb

[foggy]

Veeam console does not send the data, backup traffic is transferred between the proxy (which is the host itself, in case of an on-host backup) and repository servers directly. Veeam console performs the managements function, connecting to both host and repository via their addresses on the main LAN. Backup traffic should be routed according to the hosts file entries. Not sure what is wrong in your case, feel free to contact support and ask for remote WebEx session. I know you're not a big support fan, but a look at your setup will be more effective than forum correspondence.

[spgsit5upport]

Well, according to support that is not possible, unless Veeam B&R server can also be connected to same network (of course, that is obvious!)

Which is rather more then difficult to get done in case B&R is a VM

Seb

[foggy]

Seb, what is your support case ID?

[spgsit5upport]

Support came back stating that original advice was no correct (huh?)

But it should work with specifying the preferred network in Network Traffic as per: http://helpcenter.veeam.com/backup/80/h ... twork.html

Sadly that does apply for BOTH (backup & replication AND copy)

As copy from Repo 1 to Repo 2 can not happen over dedicated network (at least in my setup, where Repo 2 is in different building 300m away from Repo 1), it simply fails

So half job done, half is worse then before...

edit:
It seems that ALL network must be added & I suppose they are being used in preference order .. if one can not be used, then the next one is tried, seems to be the case, as my copy job now runs OK

Seb

[spgsit5upport]

Well, that does not work after all. It only works if I have a single preferred network (does work for backup), but backup copy job can not utilize this network, so if both networks are specified it does NOT use the order, but seems to ONLY use LAN for all the jobs (backup & backup copy)

So back to starting point...