SureBackup Job on Offsite Backup

[lobo519]

I have a colocation that has a VMware cluster for DR and it's also a repo of our main site backup that is run on a nightly basis. I would like to run a SureBackup job on this backup but I want to make sure this will work and not go over the WAN.

1. Setup a virtual lab at the colocation though my Veeam server at the main site.

2. Setup a Surebackup job at the main site using the virtual lab at the colocation and link the backup job that's at the colocation repo.



Is that correct?

[Vitaliy S.]

Yes, looks good to me.

[lobo519]

Case # 00206260

This seems to be working except for the Ping test. It fails with 'Request time out". When I login to the vlab appliance I am able to ping by the original IP. On the Veeam server I am NOT able to ping by the masquerade IP.

The static route that is added to the Veeam server by the job on our main site is 10.10.10.0 255.255.255.0 192.168.5.5.

192.168.5.5 = vlab appliance at our colocation which is on a site to site VPN with our main site..
10.10.10.0 = Masquerade IP


What am I missing?? I am thinking its a routing issue but not sure where the break down is..

I

[lobo519]

Booo - Support says this is not supported

"That is an unsupported configuration for Surebackup. The virtual lab needs to be on the same network/subnet as the Veeam Server. The ping test will always fail in situations such as that because of NATing and timeouts...If this is being done for just backup verification, I would suggest disabling the 'Ping Test' in the application group to verify integrity"

It would be nice if the appliance could do the ping test and report back.

I nobody running a SureBackup job on their remote backups?

[tsightler]

The static route that is added to the Veeam server by the job on our main site is 10.10.10.0 255.255.255.0 192.168.5.5.

192.168.5.5 = vlab appliance at our colocation which is on a site to site VPN with our main site..
10.10.10.0 = Masquerade IP

What am I missing?? I am thinking its a routing issue but not sure where the break down is..

You're right, it's a routing issue. Veeam can only add a static route to the proxy appliance NAT to your Veeam server, it can't add it to your routers or even to the correct gateway. Notice about that we added a route to 192.168.5.5 because we expect 192.168.5.5 to be on the same network with the Veeam server. In your setup, it is not, it's remote, so you would need a static route to your local gateway, and then your gateway (and any other gateways in between) would also need this route added.

It's completely possible to actually do this, but it's a complex setup. There's already some threads where I have outlined the required steps, but effectively it involved making sure that your entire network will properly route the NAT network to the proxy at the remote site.

Other options include configuring a layer-2 bridge between the two sites, from the Veeam server to perhaps another server at the remote site or I've known one customer that used a VPN configuration, I think using OpenVPN.

Another, sometimes simpler option is to just install a copy of Veeam at the remote site and use this instance to run the SureBackup job.

[foggy]

Similar discussions, just FYI:
SureBackup Design Question
Virtual Lab Routing Engine issue

[StefanSpecht]

Has this situation improved in v8 or v9 ?

We followed the distributed deployment scenario with only one central Veeam Backup Server per continent.
As we use forever incremental in most of our sites, we have to find out how to perform SureBackup jobs in these remote sites.
Is there any chance to accomplish this now without adding routes to our routers?

[foggy]

Stefan, v8/v9 do not change anything in this regard, routing is still need to be configured.

[StefanSpecht]

Thanks.
I understand that we will not be able to perform sucessfull ping test verfication until we created custom routes on our routers for the masquerade IP.
As this seems not be possible at the moment for us, I'd like to start with remote SureBackup but without a ping test (either using just VM heartbeat only, or even do a manuall check of the isolated VM).

But now I am a little bit on a loss when trying to create a Virtual Lab for these remote jobs. Both the remote proxy and the remote (Windows) repository are located on another network then the Veeam Proxy Server, and in the same network as the vmkernel ports of the remote VMWare hosts (behind a firewall). When creating a virtual lab for that site, I have no options to choose the remote repository to be the vPower NFS server (feature is enabled).
Veeam tries to mount the vPower NFS datstore from the Veeam B&R Server which is not possible and not what we want.

Any advice how we can configure our environment to perform remote SureBackup without ping verification?

[StefanSpecht]

I tested the creation of the virtual lab for another remote site, now. The difference to the other remote site (that is not working) is, that the ESXi vmkernel ports are not behind a firewall.

I used the following settings for the Virtual Lab:
S1) Host: ESXi Host in Moskow
S2) Datastore: NFS Datastore connected to the ESXi host
S3) Proxy: Disabled (as I don't want to use ping test)
S4) Networking: Advanced single-host
S5) Isolated Network: Mapped the production network in Moskow to a isolated network
S6) Network appliance connectivity: Configured vNIC1 to connect to the isolated network and assigned the GW IP address for the production network

During lab creation, I then saw the following behavior:
B1) Isolated network was configured on the specified ESXi host
B2) Proxy appliance was copied over, registered and configured
B3) vPower NFS datastore from the central Veeam Backup Server (not remote repository) was mounted to the host (for this site this is possible, because vmkernel is not behind firewall)

When then running a SureBack job for this remote site
B4) The vPower NFS Datastore from the local repository in this site gets mounted
B5) SureBackup runs sucessfully

This brings me to the following questions:
- Why must the vPower NFS datastore from the central Veeam Server get mounted to the remote ESXi host, even if this datastore is not used after that?
- Is there any workaround to avoid this? Most of our remote ESXi hosts are behind a firewall, and we don't want to open unnecessary ports
- If there is no workaround: Can we remove this datastore after initial Virtual Lab creation and close ports again?
- Why do I have to configure the Virtual Lab Appliance networking, and why is this virtual lab appliance then registered in the vCenter, even I have choosen "Disable virtual lab appliance" before in step S3?
(This appliance will never be powered on anyway?!)
- Can we unregister / delete the virtual appliance after initial creation of the virtual lab?

Support case 01391779 has been opened