Connection Requirements

[vertices]

We have been using Veeam for a while now. I am looking at shaking up how we do some things. I have a couple of questions that I haven't quite been able to find the answer to.

1. If our Veeam Server is not being used as a repo or proxy, but simply a command and control server, does it use much bandwidth? Can we easily drop this up on Azure tunneled back to our colocation facility and it shouldn't consume a ton of bandwidth? Looking at ours now, it would seem that most network usage is between hosts, proxies, and repos. Just want to verify.

2. If the Veeam Server is across a tunnel, and is controlling hosts, repos, and proxies, as in #1, on the other side of the tunnel, will it function properly if it doesn't have network access to the VMs themselves? If it had access to the hosts, repos, and proxies, but no route to the the actual VMs, and the repos and proxies DID have access to the VMs, would that work? I am concerned about the hot injected veeam service into the VM and if that comes from the Veeam Server, or from a proxy.

Thanks!

[PetrM]

Hi Rob,

1. Veeam server just orchestrates jobs and tasks and does not consume a lot of bandwidth, only management traffic goes through it unless it has a role of proxy or repository. Nevertheless, I'd suggest to review this page of our best practices guide and security considerations on our help center.

2. I don't see a problem with that as long as you deploy guest interaction proxy and specify it in job settings.

Thanks!

[vertices]

Thanks! I checked the guest interaction proxy page and noticed this:

IMPORTANT!
The guest interaction proxy deploys the non-persistent runtime components or persistent agent components only in Microsoft Windows VMs. In VMs with another guest OS, the non-persistent runtime components or persistent agent components are deployed by the backup server.

So I guess I can only do this if the VMs are running Windows and not something like Ubuntu. Is that correct?

Also, I don't seem to be able to specify Guest Interaction Proxy in the jobs under Guest Processing. I'm assuming that's due to us running Veeam Standard? We are about to upgrade to Ent Plus in a week though.

Thank you.

[foggy]

Right, guest interaction proxies are not available in the Standard Edition.

[vertices]

Thanks Foggy. What about non-windows VMs like I posted above? We are upgrading to Ent. Plus June 1.

I checked the guest interaction proxy page and noticed this:

IMPORTANT!
The guest interaction proxy deploys the non-persistent runtime components or persistent agent components only in Microsoft Windows VMs. In VMs with another guest OS, the non-persistent runtime components or persistent agent components are deployed by the backup server.

So I guess I can only do this if the VMs are running Windows and not something like Ubuntu. Is that correct?

What happens if the remote site has Ubuntu VMs that need to be backed up and the Veeam Server does not have direct access to the VMs?

[foggy]

Correct. For other OS's, the Veeam backup server should have access for components deployment.

[vertices]

That's unfortunate, and pretty much nullifies the effectiveness of the guest interaction proxy. Surely most environments have at least one non-Windows system/appliance that needs to be backed up. Not sure what the point of the guest interaction proxy is if it only works with Windows. Seems silly to build this functionality in, which seems like great functionality, then hamstring it by only supporting Windows VMs. Back to the drawing board.

[PetrM]

Hi Rob,

Your feedback is highly appreciated! The idea is noted, we keep tracking similar requests to decide on feasibility to implement it in our future releases.

Thanks!

[soncscy]

What happens if the remote site has Ubuntu VMs that need to be backed up and the Veeam Server does not have direct access to the VMs?

Wouldn't going through the host work here? The VMware Web Services (formerly VIX) should allow "connectionless" options for Linux VMs.

[vertices]

We utilize both Hyper-V and VMware environments at our colocation facility. So the solution will need to support Linux VMs hosted on either platform. Since we can't do it, I plan on building access to the VMs, which I didn't want to do, but I guess we have to.