For a set up like this you just need to have one additional VBR installed and ready in one of the other three DCs.  As long as you are doing Configuration Backups from the main VBR that you have access to from the other DCs you can restore your server very easily.  You will not require an additional licenses if the spare VBR sits idle as you will use the same license file for the restored VBR.

This is the best way for HA in a Veeam environment is the Configuration Backup as that will restore the database and everything job related back to a new database server.

Hi ​@Nikks deploy standalone VBR servers in each DC with local proxies & repositories for independence kindly note that extra licenses will be needed but for HA, consider Veeam Enterprise Manager or a standby server with config backups as job migration must be done manually.  

Thank you for your response. From your suggestion, it seems you're recommending setting up a secondary, passive Veeam B&R server in one of the three data centers—correct?

In this setup, if the primary Veeam B&R server goes down, the standby server would need to be restored and take over as the new primary. Can you confirm whether this failover process is manual or automatic? Based on what I understand, it appears to be a manual process.

A few follow-up questions:

1. Can the configuration backups from the primary Veeam server be stored on all repositories? This is important since the repository containing the configuration backup must be accessible even during a network outage.

2. During the time it takes to restore the standby Veeam server, any in-progress or scheduled backup jobs would begin to fail—this is exactly what we’re trying to avoid.

3. What is the typical turnaround time for restoring the full job configuration and database to a standby VBR instance? In my case, the environment includes 10 hosts in the backup schedule.

Could you provide more insights into these points, particularly around high availability best practices and minimizing downtime during failover?

It sounds like you are set on breaking out each site to have it’s own Veeam server. Since each site has it’s own repository, there isn’t too much data to move around. 

Regarding the license, I would install a Veeam Enterprise Manager server in one of the sites, then add each Veeam server to the Enterprise Manager. It will push the licenses to each of the Veeam server, as well as provide a single pane of glass for all the jobs.

Once you’ve removed the remote sites (and remote repositories) from your current Veeam server, install a new Veeam server at each site, and configure the same repository you were using before, choosing the option to import any backups found. 

The backups should show up in under “Backups - Imported”, and then you’ll be able to recreate the jobs and map them.

By the way, this configuration, with an Enterprise Manager and multiple Veeam B&R servers connected is referred to as a “Distributed Deployment”

Thanks for response. A few follow-up questions:

1. During the time it takes to restore the standby Veeam server, any in-progress or scheduled backup jobs would begin to fail—this is exactly what we’re trying to avoid.

2. What is the typical turnaround time for restoring the full job configuration and database to a standby VBR instance? In my case, the environment includes 10 hosts in the backup schedule.

The duration to restore the configuration database varies depending on the size of the Veeam installation and whether or not you choose to restore previous session history or not. The only advice I could give would be to test this restore and time it, so that you can account for it when planning your DR strategy.

Veeam doesn’t currently have any HA functionality that can automatically kick in. (Though I’m hoping that changes in v13).

I you can’t have you Veeam server going down even briefly, then I’d recommend moving your current Veeam server to a service provider or hyperscaler with the SLAs you require, and set up network connectivity to each of the remote sites from there. It may be more expensive, but more resilient.

​@Chris.Childerhose  Please advise

The failover process is manual there is no automatic failover for Veeam.

1. Yes it can as you can back up to one repo and then do a backup copy job to the other repositories.  The Configuration Backup options only allow one repository to be selected so you will need to create the File Copy job to move the file to the other repos.
2. Yes this will happen and is unavoidable unfortunately.
3. It will take less than 30 minutes to restore things for you.  You just need to ensure the database server is accessible to all sites where the DB is stored.  If it is local on the PROD VBR then you can have the restore create a local copy on the standby VBR server.

if you platform allows, use stretched datastore like vSAN and provide replication on another location on vSAN level. As second save is that this central VBR is backed up by another VBR. So if vSAN replication will fail, you can restore VBR and you can be quickly back - that’s my solution. 

I know, officially we cannot backup VBR, but i have been restored VBR several times already.

Do I need to purchase additional 3 VBR license or only one enterprise manager is needed which can distribute existing parent VBR license to 3 VBR?

VEM can distribute the license to each VBR server when installed there.

If I’m correct VBR version 13 will be High Available, so in this situation you can easily have the primary allocated in the fourth DC and the secondary in DC 1,2 or 3? 
 

Yes v13 will change the landscape with the HA stuff coming.

After reading V13 notes it looks like HA servers have to be on the same subnet… At least for the beta. This may or may not change things depending on your network connectivity and if you have a flat network spanning sites.  

I am not 100% on this yet, but something I will be looking into before creating muti-site Veeam servers.