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...