feature request - backup and failback collided and messed up

[mcz]

Hi everybody,

I was running a planned failover for doing latency tests and finally I started the failback process. Unfortunately, this failback has been started quite close to the next backup job of the original vm but I thought that this wouldn't be a problem since veeam normally detects if there is another job running for the same vm and therefor puts the backup job on hold.

Yeah I thought that it would be like this but I was wrong. Somehow, replica failback and backup job for this one vm were running at the same time (and I saw two snapshots for the vm, both created by veeam) and there I know that it was far too late to stop the action... Both jobs failed and now I'm not able to start failback again because it aborts with a message about a different disk size.

I'm currently working on this issue with the support team (case 02392538) and I'm sure that they will do a good job but the question to me is: Why did it happen and how can we prevent it in the future? Should source and target VMs always be locked during failback or is there a reason why such a functionality is missing? Or is ist just a bug? Could it be that this behaviour was triggered by the different failback mechanism which has been introduced in update 2? If I remember correctly, prior to update 2, failback always triggered replication job for the affected vm but now the process is not directly handled by replication jobs...

[foggy]

Hi Michael, indeed, there's no check that prevents other jobs processing the same VM during failback. We filed this as an issue to address in one of the following releases. Thanks! As a workaround, you can failback to an alternate location, this, however, will result in a changed VM ID (new VM will be created).

[mcz]

Hi foggy, thanks for this clarification and your quick reply!