veeam 13 backup server appliance disaster recovery

Does your network subnet span across your multiple sites? If it doesn't you'll need to configure your spare Veeam secret with a different IP. The configuration backup restore can handle going onto a server with a different IP address as long as all the backup infrastructure is resolvable and reachable from the new server. 

If it is on the same subnet, you might be able to consider setting up high availability with a node in each site. 

Thanks Tommy for your reply. The network subnets are stretched across both DC’s, unfortunately we have Veeam Advantage and not premium license for HA. The only concern with having a backup server with new IP was about opening firewall ports for all the communication with the new Backup server IP.

Rather than messing around with setting the same IP and potentially having duplicate IPs on your network while trying to keep the spare up to date, I'd rather just ensure that all firewall rules are created reference both Veeam IP server addresses. Perhaps in your firewall you can create a host group that contains both. 

I’m working on a simlar use case at present. 

Use Case: Managed BCDR with Veeam Using Active/Standby VBR, Cloud Connect, and Veeam Data Cloud Vault

Delivering Ransomware‑Resilient Business Continuity & Disaster Recovery as a Managed Service

Actors

• End Customer IT Environment
• Managed Service Provider (MSP)
• Primary (Active) Veeam Backup & Replication Server
• Secondary (Standby) Veeam Backup & Replication Server
• Veeam Cloud Connect Infrastructure
• Veeam Data Cloud Vault (Immutable Object Storage)
• Microsoft Azure (Disaster Recovery Target)

Business Problem

Mid‑market and enterprise customers require guaranteed recovery outcomes, not just backups.
They need:

• Predictable RPO and RTO
• Protection from ransomware and insider threats
• A recoverable Backup Control Plane
• A solution that works even if the primary backup server is destroyed

Traditional single‑VBR or direct‑attached Vault designs fail during control‑plane loss, especially due to the one‑VBR‑per‑Vault limitation. MSPs must deliver a repeatable, DR‑ready architecture that survives full site failure.

Preconditions

• Customer has production workloads (VMs, applications, or services) on‑premises or hybrid
• MSP operates Veeam Cloud Connect infrastructure
• Azure is pre‑configured as a DR target (networking, permissions, storage)
• Veeam Data Cloud Vault is enabled with immutability
• Active and Standby VBR servers are version‑matched

Architecture Summary

This use case implements:

• Local backups for fast restores
• Off‑site immutable copies via Cloud Connect → Vault
• Active/Standby VBR for control‑plane resiliency
• Separate Vault repositories for backup data and VBR configuration
• Azure as the recovery execution platform

Cloud Connect is used to abstract the Vault, eliminating the single‑VBR attachment constraint.

Main Flow (Normal Operations)

1. Active VBR performs local backups

   • Backups land on fast local storage to meet low RTO requirements

2. Backup Copy Jobs replicate data off‑site

   • Copies are sent to Cloud Connect repositories backed by Veeam Data Cloud Vault
   • Immutability and retention are enforced by the MSP

3. VBR Configuration Backups are isolated

   • Configuration backups are written to a separate Vault-backed repository
   • Encrypted and immutable to ensure control‑plane survivability

4. Standby VBR remains passive

   • Connected to the same Cloud Connect repositories
   • Performs no backups during normal operations

Exception Flow: Primary VBR Loss (Ransomware or Site Failure)

1. Primary VBR becomes unavailable

   • Caused by ransomware, corruption, or site‑wide outage

2. Standby VBR is activated

   • MSP validates Cloud Connect availability
   • Standby VBR performs a Rescan of off‑site repositories

3. Backup metadata is imported

   • All restore points become visible on the standby system without rehydration

4. Optional configuration restore

   • VBR configuration is restored from the dedicated configuration Vault

5. Recovery operations begin

   • Instant Recovery or Full Restore is initiated
   • Workloads are recovered into Azure or secondary infrastructure

Postconditions

• Customer workloads are running in Azure or DR infrastructure
• RPO reflects last successful backup copy
• Control plane is fully operational on the standby VBR
• Production site can be rebuilt without urgency
• Failback occurs when ready, restoring BAU operations

Benefits Delivered

For Customers

• Guaranteed recovery even when backup infrastructure is lost
• Strong ransomware protection via immutable Vault storage
• Clear RPO/RTO outcomes
• No dependency on customer-managed object storage

For MSPs

• Repeatable architecture across all tenants
• Centralized control of immutability and retention
• Supports multi‑VBR DR scenarios
• Aligns with Veeam best practices for Vault usage

Constraints & Limitations

• Vault buckets cannot be directly shared between VBR servers
• Cloud Connect WAN performance affects restore speed
• Replication jobs are not supported in Cloud Connect repositories
• Dual‑active VBR is not supported

Outcome

This use case demonstrates how MSPs can deliver enterprise‑grade, ransomware‑resilient Managed BCDR using Veeam — even under total infrastructure loss — by combining Active/Standby VBR, Cloud Connect abstraction, and Veeam Data Cloud Vault.

​@sudhir_h  check out my Blog: A Real‑World MSP Architecture Using Active/Standby VBR, Cloud Connect, and Veeam Data Cloud Vault | Veeam Community Resource Hub for some ideas