Best practice for VBR server placement when replicating from PROD to DR?

[cerberus]

Hi all,

We have a physical VBR machine in our production site for B2D2T (reverse incremental, full tapes daily). This single server is beefy and has local storage for B2D repository.

We are evaluating VBR VM replication to sync our production and D/R site. I am looking for best practice in terms of VBR server placement when planning for true D/R scenarios where production goes down (including the VBR server).

Currently the single server in production is responsible for everything, we are replicating from backup repository (and not from live production VMs) and use built-in many-to-one WAN accelerators at source and destination.

I read that the general recommendation is to have 2 VBR servers, 1 in PROD for B2D2T and 1 in D/R for replication (referred to as "pull" replication, vs. what we currently have in place which is "push" replication).

Lots of the threads are a few years old; what is the latest recommendations for VBR placement to be able to perform fail-over in case PROD site is down in latest VBR release?

If we need to switch from "push" replication to "pull" using a 2nd VBR instance in D/R to be able to perform fail-over automatically, can this be done in a way to preserve existing replication progress?

If we don't do a 2nd VBR instance in D/R; the only option then is to script this?

[Mildur]

You don‘t need a second VBR Server.
It‘s recommended to put your vbr server in the dr site.

If your first datacenter is failing, you have a working VBR in the DR Side to start all your replicas.
There is no automated built-in way to start a replica with Veeam.
Veeam is not a redundancy solution But you have the possibility to script that with Powershell, if you need some automation.

If you have lost your vbr server in first side, you can boot up your replicas without veeam. Only you have lost your vbr server. If you start the replica vms manually, then there shouldn‘t be a new run of the replica job, or your changes will be lost.

[foggy]

It's actually a matter of preference - you can have a single instance or have two separate ones, one local responsible for backups and remote exclusively for replicas to allow for a failover from the console. Should you decide to switch to the pull scenario, you can map the newly created replication jobs to existing replica VMs to continue incremental runs or just import the first instance configuration backup to the second one and disable/delete unneeded jobs/stuff.

[Zew]

I've been down this road... not a fun time....

veeam-backup-replication-f2/replica-bac ... 69281.html

[cerberus]

Yeah I kind of wish I knew about this best practice before I replicated 90% of our VMs. The VBR install at source is doing everything (B2D2T and Replication Jobs from backup source). I do like the idea of D/R Veeam instance to manage replication jobs, but AFAIK that would mean two different VBR servers with different jobs. I am going to keep everything as is and just script D/R with PowerCLI.

[Zew]

Oh I know it bugs me that you can't have 2 BR servers for this (to pull it off yourself *Correct myself* YOU CAN but you will face caveats as in the thread I shared), but you can pay more and get VAO (Veeam Availability Orchestrator) which pretty does exactly that.

As you can see by this design architecture: https://helpcenter.veeam.com/docs/vao/u ... tml?ver=40

Which you can see says has Veeam BR at primary site, and VAO at DR site, which VAO has an imbedded BR server to do exactly the failover and failbacks you'd otherwise have to do manually via a "replica back sync" which is exactly my thread I shared with you.

Been one of those thorns in my side.