DR Planning - Method Validation

[philfreund]

Could someone please tell me if I'm approaching my DR planning for moving over to running on a DR site correctly?

Environment Info:
Primary and DR site both have B&R 9.5 servers installed.
Primary site runs all Backup jobs and then runs Backup Copy jobs that store their output in Repositories located on the DR site B&R server.
Replicas are created on the DR site using the Backup Copy images stored on the DR site. (Replication jobs are run by the Primary site B&R server using the DR site B&R server as the proxy.)
Primary site B&R Configuration DB backups are copied to a directory on the DR B&R server.

Scenario: My primary data center is a smoking crater and I need to get the replicas failed over ASAP and the other backups available to use for recovery.

Recovery goes as follows:
1. Restore the Primary site B&R Configuration DB onto the DR site B&R server.
2. Rescan the contents of the repositories located locally on the DR site B&R server.
3. Failover the Replicas and commit them permanently. (Based on the time of the Configuration backups, there may be Replica restore points stored that aren't in the restored Configuration DB. Only the latest replica stored in the Configuration DB would be available to start.)
4. Restore any VMs that don't have replicas from the Backup Copies stored in the DR site repositories.

Have I missed or misunderstood something? Have I overly complicated something?

Also, is it possible to setup a job/script to create Configuration backups after every Replication job runs so I don't lose access to the most current Replica restore points? Right now, I create Replicas at varying points in the day but only backup the Configuration DB once a day.

[DGrinev]

Hi Phil,

Your approach for the DR plan looks correct and can be used without any changes.
You utilize Remote replica from a backups that provides you the possibility to use a single snapshot on the production VMs during processing which can reduce additional workloads on your production storage.
But in disaster situation you will need some additional time before you can start the failover process at the DR site, as you have to restore config, rescan repositories and etc.
There is a script for post job activities, so you can perform configuration backup right after the replication jobs.

Alternatively, you can configure all Replica jobs on the backup server at DR site, so this will allow you to start the failover process instantly.
You can use replica seeding to reduce traffic over WAN during the first replica jobs run.
The only disadvantage of such scenario is the workload on production VMs will be increased, as an additional snapshot for replication processing is needed.
Thanks!