Replica Failover when you have lost your backup server

[tommyv]

So I'm exploring the possibilities of using Veeam replication as part of our offsite DR procedure. I've been reading the v8 user guide and it suggests using a Veeam Backup server & proxy at the source site and a proxy at the destination site.

I seem to be missing something, what happens when you have a full site failure and your backup server becomes inaccessible? How can I failover the replica? Should I have a Veeam backup server on standby at the destination site and import the metadata? Will this work and how can I do it in such a way that the RTO is kept to a minimum?

Advice appreciated

[foggy]

Tom, it is typically recommended to have Veeam B&R server responsible for replication jobs at the replication target site. This allows for automatic failover/failback using Veeam B&R UI in case of DR. This could be just a separate Veeam B&R instance handling replication jobs only. Among other approaches are replicating Veeam B&R console VM to be able to start the replica manually and perform further failover or using Veeam B&R built-in configuration backup functionality.

[tommyv]

Thanks Foggy, this makes perfect sense its just the that v8 user guide seems to contradict this? Specifically on page 112 it shows the backup server on the source side and also states that the backup repository for metadata MUST be located at the source site which doesn't seem right?

As I see it the B&R server and metadata repository should exist at the target site and the only thing at the source site should be a proxy?

[foggy]

Repository for replica metadata should indeed be located at the source site (close to the source) for optimal replication performance. So the user guide just outlines the basic architecture, where you manage all your jobs using console located at the source (typically, production) site. If we go beyond basics, then the best practice is to have a second dedicated remote console for managing replicas.

[tommyv]

Hi Foggy,

If we have a dedicated remote console at destination for managing replicas, where is the recommended location for the metadata? Is there a way of synchronizing the metadata between the source and destination sites?

[veremin]

As Foggy's mentioned, the recommended location for replica metadata is repository that resides at source site. Thanks.

[tommyv]

Hi Vladimir, this would be no good in a disaster scenario since the metadata would be lost. Is there a way of syncing the metadata to the destination or do I need to store the metadata at the destination repository and sacrifice performance?

As Foggy's mentioned, the recommended location for replica metadata is repository that resides at source site. Thanks.

[veremin]

Replica metadata isn't involved in failover (DR scenario), so I don't think syncing it will be very helpful.

[tommyv]

Aah ok thats the missing link, I assumed the metadata was required. Will configure as recommended

[veremin]

You're welcome. Feel free to ask, should any additional help be needed. Thanks.

[foggy]

Moreover, if the metadata is lost, it will be automatically re-created during the next job run (though taking a bit longer to complete).

[tommyv]

Guys, I have another conundrum! So assuming I perform my backups on a B&R server &repository located in the source site and my replication jobs from a B&R server in the destination site, is it possible to perform replication based on the backups from the first B&R server? If I map to the same repository is it intelligent enough to work out when the backup file is complete and ready for replication? Thanks

[veremin]

Dummy job mapped to the backup files created by first backup console, and repository rescan setup as a pre replication job script should be your way to go. Thanks.

[SGalbincea]

Dummy job mapped to the backup files created by first backup console, and repository rescan setup as a pre replication job script should be your way to go. Thanks.

Would love to see a more elegant solution to this in an upcoming version.

[veremin]

Separate consoles are unaware of each other, so the usage of custom script and dummy job seems like the only workaround at the moment. Anyway, thank for the feedback; appreciated.

[dellock6]

Also, complete separation between the two sites from a security perspective is a great solution: if anything happens to the first site, there is no authorization from a compromised user in site1 to access site2. Otherwise, if the two are connected, an unauthorized user can connect to remote site from primary and delete/damage also those backups, thus denying the benefits of having a secondary site.