Skip to main content
Question

DR Scenario Query

  • April 20, 2026
  • 12 comments
  • 62 views

  • Not a newbie anymore

Hi,

I am going over DR scenarios and have a query on improving our procedure.

We have two sites

  • Primary site
    Hosts all production servers (5x physical & 30ish virtual)
    Hosts the VSA virtual server
    Primary & immutable storage repositories
  • Secondary DR Site
    Off-site storage repository
    2x spare physical servers for use in DR scenario

Both sites connected via VPN. Everything on Hyper-V

 

Now my query - lets say the primary site is destroyed. We want to restore everything to the secondary site.

First step I can’t login to Veeam console because it was hosted in the primary site. Therefore current procedure is to setup a new instance of VSA and import a backup of the config. Not a difficult task but it takes time which I’d rather not have to spend during an emergency scenario.

Is there a better way? Does it make sense to replicate our VSA virtual machine to the secondary site? Maybe high availability? Or should we be hosting the VSA virtual machine at the secondary DR site with a proxy server at the primary site?

 

Thanks in advance for any suggestions.

 

12 comments

CMF
Forum|alt.badge.img+8
  • Veeam Legend
  • April 20, 2026

Hi ​@MTGWA ,

HA is only available in premium edition so it brings a financial aspect with it. 

Replication should be working but I haven´t tried it out yet.

What you could do is having a second, empty appliance on the other side so that you could just restore the config backup when needed without going through the process of deploying a new appliance. This would speed up everything a little bit. In this case it might make sense to have the config backup on a target in the DR Site as well to make sure you can access it when the primary site is lost.

Regards

Chalid


  • Author
  • Not a newbie anymore
  • April 20, 2026

Thanks. Not sure why I hadn’t considered having a empty appliance ready but that significantly cuts down time. 

 

Follow up question on this. We also want to begin running test DR scenarios on a regular basis. As an example I kill the VPN simulating the primary site going down. I then import config backup to the empty appliance and run some test restores confirming everything is good. Once happy I shutdown the appliance and delete any restored VM’s.

What happens when I bring the VPN back online and the original appliance in primary site is reconnected? Would you expect this to create any issues because another appliance has now touched those off-site repositories and servers? 


CMF
Forum|alt.badge.img+8
  • Veeam Legend
  • April 20, 2026

Hi good question. I believe as long as you haven´t done any changes to backup chains, or creating new backup files, things should be fine. 

But think about it that you should try to make the config backup after the last Backup job the day so that you have, more or less, up to date database with all the restore points. If you only run Backup Jobs once a night. 


coolsport00
Forum|alt.badge.img+22
  • Veeam Legend
  • April 20, 2026

@MTGWA - Welcome to the Community!

Is there a reason you haven’t considered using Replication? You have to use the Veeam Console for this, as you do have to do for most tasks at this point, but no “downtime” really at all because your VMs are already on your DR site. For example...this is my current setup:

  • I use VBR v12 currently, but this really doesn’t matter
  • have a “Backup” VBR at my CO site and a “Replication” VBR at my DR site
    • I replicate VMs throughout the day outside of my Backup windows. RPO is a bit less than my Backups but I’m ok with that
    • I “pin” my VBR server to a Host at my DR site so I know how to reach it, though in this instance (Primary site down) all Hosts should be online as only the CO site would be down
    • With this setup there is no downtime for my VBR server. I’m pretty much ready to go in the event I lose my CO site. Full VMs are there as well. You just have to make sure networking is all set at your DR site (mirroring your Primary site)
  • You can test DR easily by using Planned Failover process. All data is retained and, when you get your Primary site back up (or reconnected via VPN), all data changes replicate back to the Prod for no data loss

The only thing you have to have configured on your DR side is have identical networking as in your Primary site.

Hope that helps.

 


  • Author
  • Not a newbie anymore
  • April 20, 2026

Hi good question. I believe as long as you haven´t done any changes to backup chains, or creating new backup files, things should be fine. 

But think about it that you should try to make the config backup after the last Backup job the day so that you have, more or less, up to date database with all the restore points. If you only run Backup Jobs once a night. 

 

Great, thanks.

From the DR appliance I would only be running restores so no changes to any chains, jobs or configuration.

Backups run at 06:00 12:00 and 18:00 but I could postpone or disable temporarily during the DR test.


Tommy O'Shea
Forum|alt.badge.img+5
  • Veeam Legend
  • April 20, 2026

You could consider running the appliance in the DR site, that way if something happens to production, your Veeam server is unaffected. 

You'll just want to make sure you set up a local proxy, Mount server, etc in the primary site to ensure all local maps stay local. 


Chris.Childerhose
Forum|alt.badge.img+21

You could consider running the appliance in the DR site, that way if something happens to production, your Veeam server is unaffected. 

You'll just want to make sure you set up a local proxy, Mount server, etc in the primary site to ensure all local maps stay local. 

This is a best practice to run the VBR in the DR site, not PROD for this type of scenario. The other option is the HA feature but comes at a cost with Premium license required.


Stabz
Forum|alt.badge.img+9
  • Veeam Legend
  • April 20, 2026

I agree with the guys,

Regarding the infrastructure, you should consider deploying Veeam on the disaster recovery (DR) site. Be careful: if the site-to-site VPN link goes down, backups will fail.

Alternatively, a good practice would be to have a standby Veeam server ready on the DR site along with a backup of the configuration. In the event of a loss, you would simply need to re-import the configuration and rescan the repositories.

Please note that the rescan task can be time-consuming depending on the volume of data.


  • Author
  • Not a newbie anymore
  • April 20, 2026

Thanks for the replies everyone. Some good ideas for me to go away and research further.

I think at first glance we will favour moving the Veeam server into our DR site, with proxies and mount servers in Prod. The VPN is very stable with fibre both ends I can’t recall it ever dropping (of course it will now I have said this).

 

 

 

@MTGWA - Welcome to the Community!

Is there a reason you haven’t considered using Replication?

 

 

In response to this - yes! We already replicate a handful of larger VM’s and a domain controller to give us a head-start on restores. It’s the Veeam server itself I’m unsure on replicating and how that behaves in a failover/failback scenario, especially as the networking at our DR site doesn’t match the primary site.


Chris.Childerhose
Forum|alt.badge.img+21

Please let us know how it goes with the VBR in the DR site.  It should work fine if you have a stable connection.

 
 
 

coolsport00
Forum|alt.badge.img+22
  • Veeam Legend
  • April 20, 2026

Glad to help ​@MTGWA . 

So my suggestion of Replication was solely from a production server (VM) standpoint, not necessarily from a VBR standpoint. If your VBR “konks out” and you want to run it from your DR side, then yeah..I agree with the others who suggested to just keep a bare-bones VBR VSA installed at your DR side and just restore the config DB to get it up & going if/when needed.

Keep us posted how things go for you.


eblack
Forum|alt.badge.img+2
  • Influencer
  • April 20, 2026

We always position the VBR at the DR sites, unless you have easy access to shared storage with the DB configs and bare metals already baked in. It’s the way to go if RTO is the biggest concern.