Question about Veeam Replication - Failback

[wa15]

When failing back to the production VM, you are presented with three options, the first one being "Fail back to a VM in the original location on the source host". The actual synchronizing of the data doesn't start until you initiate a failback process. This can make it difficult to schedule downtime since you can't schedule a time (afterhours) for the actual power up of the original VM and the power down of the replica.

For example, you have been running on the replica of the VM for a week and there is about 100GB of changes to sync back to the production VM over a 20 Megabit VPN pipe. You start the failback process, and the 100GB of data takes a few days to sync over to the replica for example. When the sync finishes, the replica VM is powered off without any prompt of "do you want to power off the replica VM?"

So my question is, is there any way around this?

Thanks!

[Gostev]

Not currently, but this is certainly a good idea for a future improvement... we should allow specifying the time when switch over should take place, or at least hold its execution with the interactive prompt. Thanks for your feedback!

[wa15]

Thank you Gostev. That would be really helpful! This is one of the features that I really miss from testing VMware SRM. An option to sync back data from replica to production WHILE running on the replica would be awesome. That way you don't have a bunch of "piled up" changes to replicate over.

[Gostev]

That should be doable too.

[wa15]

Thanks Gostev.

One thing I realized is that during calculation of original and replica hard disks, the replica VM remains powered on, but during the ACTUAL replication of the data, the replica VM is shut off (presumably to avoid any changes to it). If this is correct, this was a somewhat disturbing find because again, in case of a large amount of changed data, the replication will take days to complete. Can you please confirm that during the "replicating changes hard disk 1" data is in fact transferred over the WAN?

[wa15]

Actually I see the transfer rate during the "replicating changes Hard Disk 1 stage, I see transfer rate about 18 MB/s so that can't be over the WAN. It must be local? And the proxies were selected manually and correctly. They are local to each site.

[veremin]

Hi, Farshid,

Yes, this is the way the failback works.

Firstly, the restored VM is updated to the replica failover state. Then, the protective snapshot is taken on replica VM. All activities on replica VM are put on hold, until the failback is either committed or undone. In case of big amount of changes made to replica VM after failover operation, the failback commit process might, indeed, take some time to complete.

The detailed description of this process can be found here.

Thanks.

[wa15]

Thank you Vladimir. Appreciate the information.

As soon as I started replication of a 4TB Exchange VM, I realized another problem! It would take a few weeks to replicate the VM over the 30Mb WAN to our DR site, and Veeam doesn't remove the snapshot until replication finishes. So imagine having a 600-user Exchange box having a snapshot for over a week! Looks like we may have to seed a copy of the local Veeam backups to our DR site first, via the Veeam backup copy jobs. But then again even on the incremental changes, the Veeam snapshot will be pending for a little more than I would like I think; for a couple hours on a 4-hour RPO probably.

[veremin]

Yes, you can backup the Exchange VM in remote site. Take the resulting backup file, transfer it to production site, restore the Exchange VM, and failback to it. This action should allow you to decrease the time of initial synchronization, as well as, service downtime during commit stage.

Thanks.

[wa15]

Thank you Vladimir.

Now, are there any methods we can use to perhaps have Veeam take a snapshot, remove it, and then replicate the data over? Instead of taking snapshot, replicating, and then removing the snapshot? Also, are there any mechanism that Veeam uses to avoid the snapshot from getting too large in cases where the replication or backup on a server with a high rate of change takes hours?

[veremin]

Now, are there any methods we can use to perhaps have Veeam take a snapshot, remove it, and then replicate the data over? Instead of taking snapshot, replicating, and then removing the snapshot?

No, I don't think there are any. The least harmful scenario seems to be the one described above (seeding backup job, failbacking to the restored VM).

Also, are there any mechanism that Veeam uses to avoid the snapshot from getting too large in cases where the replication or backup on a server with a high rate of change takes hours?

The only thing you can do is to set up a backup window for the job during which the job can run, and select the "Terminate job if it exceeds allowed backup window" option. This way, the job that exceeds allowed backup window will be immediately terminated.

However, there is no mechanism preventing snapshot from growing large, because changes made to VM are constantly written to the snapshot file.

Thanks.

[Vitaliy S.]

Also, are there any mechanism that Veeam uses to avoid the snapshot from getting too large in cases where the replication or backup on a server with a high rate of change takes hours?

You can monitor snapshot size via Veeam ONE and be notified when the snapshot grows large.