Backup of remote physical host

[Domino5]

Hi All,

I'm testing Veeam, so a newbie to it. I've been a long-time ShadowProtect customer and I have seen the (Veeam Green!) light.

I have the Backup Server (version 10.a, trial licence) installed in my datacenter. I have remote sites with site-to-site VPNs between them. At some of those sites, I have physical servers that I need to backup. I have a Repository at my datacenter and a Repository(s) at my remote sites.

I'd like to be able to backup the remote physical servers to their local Repository. When I create the job using Managed by Backup Server the job does not complete the error says "Error: Timeout to start agent". I get the same thing when I select Managed by Agent.

I suspect I am doing something incorrectly. What is the best way to get a backup of a physical server at a remote location, keeping the data at its local Repository? Do I need to install a backup server at each location or something? Would that mean I need several .lic files?

Thanks in advance!

[Dima P.]

Hello Domino5,

For remote sites it's recommended to use managed by agent job mode as it keeps the job settings locally on the agent side. Based on the error it looks like there is no connectivity with the agent, can you confirm that agent was successfully installed and, say, you can connect to the remote admin share on the agent host from the Veeam B&R server? Thanks!

[Gostev]

Yes, this looks like a network connectivity issue, please troubleshoot it with support.

If you have many remote sites to protect, you can dramatically simplify your backup infrastructure by deploying the Veeam Cloud Connect (VCC) in your main data center. This removes the need for VPNs and opening many ports in the firewall (as all traffic goes through the single port).

There are different packages available for both MSPs and enterprise customers, depending on who you are. Licensing also depends on whether you're an MSP or an end-user. But in both cases, you will need to work with the Veeam pre-sales engineer to validate the applicability of VCC to your environment (your Veeam sales rep will be able to arrange the call).

Thanks!

[Domino5]

Hi Dima,

Fab. Yes, I have switched to "managed by agent". There is a site-to-site VPN between the two offices. Which is up. I'd class my connectivity as pretty decent! When you say "remote admin share" I assume you mean C$? If so, I can, without issue, from either server.

Kind regards,

[Domino5]

Yes, this looks like a network connectivity issue, please troubleshoot it with support.

If you have many remote sites to protect, you can dramatically simplify your backup infrastructure by deploying the Veeam Cloud Connect (VCC) in your main data center. This removes the need for VPNs and opening many ports in the firewall (as all traffic goes through the single port).

There are different packages available for both MSPs and enterprise customers, depending on who you are. Licensing also depends on whether you're an MSP or an end-user. But in both cases, you will need to work with the Veeam pre-sales engineer to validate the applicability of VCC to your environment (your Veeam sales rep will be able to arrange the call).

Thanks!

Hi Gostev,
I believe Veeam Cloud Connect is when I send my backup data into someone else's cloud (Azure, AWS) etc rather than an on-prem Repo, is that correct? In my environment, I need to keep the data local due to the size of the backup data.
Kind regards,

[Egor Yakovlev]

Hi Domino5,

You can install Veeam Cloud Connect(with proper license) within your own datacenter to provide more flexible backup services for your own organization branches - cases like "remote workforce backup" or "multiple branches to HQ" will benefit from it. It can be done with your local resources and it does not have to be public cloud or 3rd party service provider datacenter.
You will become a kind of service provider for yourself.

[Gostev]

Sure, I even said that myself in what you quoted:
"deploying the Veeam Cloud Connect (VCC) in your main data center"

The specific name for the offering is Veeam Cloud Connect for the Enterprise.

It's quite a popular tech indeed among our distributed enterprise customers, because it completely removes the networking aspect of ROBO backups and enables remote backup server management. But it does not make sense to deploy if you only have a handful of remote offices, as in this case the overhead of maintaining VCC infrastructure does not provide sufficient benefits comparing to just setting up a few site to site VPNs.

[Domino5]

Hi All,

Thanks for your input!

I found the logs in the host C:\ProgramData\Veeam\EndPoint. I could see an entry for "Failed to connect to agent 'VBR.domain.com', EP 'IP-ADDRESS-A:2500;IP-ADDRESS-B' (System.Exception)"IP-ADDRESS-A is for a NIC on my VBR Server which is not the LAN at my data center but a direct connection into the NAS for ImageManager (ShadowProtect). That NIC is not registered in DNS and when I ping the VBR Server FQDN the correct (IP-ADDRESS-B) is resolved. So I figured maybe Veeam is trying to use the wrong IP address as it is listed first in the log file. Because Veeam is sensible I thought there must be a way of telling Veeam what NIC to use. I found the Global Network Traffic Rules --> Prefered Networks. I whacked in my datacenter's local subnet, started the job again and it is currently backing up to the NAS at the remote site.

My last question (!) is rather than putting the backup data in the Repository in a nicely named folder like "HOSTNAME-OF-SERVER" is has created a folder "VeeamAgentUserRANDOMLETTERSANDNUMBERS" any idea why?

Kind regards,

[Gostev]

Normally, this approach is used by developers to prevent conflicts where they are possible in theory. By conflicts I mean things like multiple jobs continuing each other's incremental chain, thus corrupting the backups. Thanks!