Failing back to production

[smcauley]

Hi folks,

Had a question about Failing back to Production for offsite replicas. We had an issue where we lost our file server while waiting for it to "Fail back to Production" (Case # 01103192) which was kindly resolved by support. Now, our company is planning on performing an actual DR test in the near future where we run off the replicas in our DR site and work for a couple of days. With the core VMs running in DR we are talking around 2TB worth of data. We don't foresee much increase in data while we are in DR, mostly changes to existing files. Our concerns with the process are:-

1. How long will it take to fail back to production (link between sites is 100mb)?
2. Does Veeam have to read every block and therefore take a long time to analyse the differences between the disks?
3. Does it use CBT to do this?
4. If this process takes say 12 hours are the replicas still available to use during this time?
5. If they are is there a cut off where data added to them would not be available when the failback was complete?

Thanks in advance!

[foggy]

During replica failback to the original VM Veeam B&R needs to calculate and synchronize the differences between the original VM and the replica VM. The time required to scan the VM image depends on its size and is comparable to the full backup time of this VM. Replica VM is available during failback until it is powered off for the second digests calculation, required to avoid last-minute changes loss.

[smcauley]

Thanks Foggy. Can't say I love that answer as I was hoping it would be faster than that. Anyway doesn't sound like there is much we can do about that. Perhaps some kind of CBT functionality for this process would be useful in future releases.

[alanbolte]

Our current 'quick rollback' feature for full VM restore is only effective if CBT data is reliable, which it won't be in most disaster recovery scenarios. We only recommend quick rollback in situations where the reason for restore occurred entirely within the VM guest OS (such a user deleting application files in such a way that file level restore is impractical).
Outside of DR tests (which you would want to be realistic and not use a different process from normal failback), would you anticipate failing over and back when CBT is reliable, such as for purely in-guest issues?

[smcauley]

I guess I'm just interested in a faster outcome. Obviously if CBT was reliable that would be the best thing to use.

If I fail over to replicas during a DR scenario I can have our systems up and running in 10-15 mins which is impressive and a credit to the Veeam technology. If I'm changing data however and looking at 24 hours to failback changes then this is hard to explain to my company. I'm surprised that this hasn't really come up before. What does everyone do? Just wait or am I perhaps going about this the wrong way?

[veremin]

If that is the last synchronization step (during which VMs are powered off) that is taking 24 hours, then, you might try to create additional replication job from DR to production and perform planned failover; the last step might be faster in this case. Thanks.