"A Wizard is never late, nor is he early. He arrives precisely when he means to." is what I thought in panic when the Veeam Failback wizard was crawling through the change blocks. Who knew that cheaping out on proxies with Linux proxies means you don't get to Failback quickly (at least in v10) and it has to count chose blocks again...

The short of moral of here is: test your DR and DR software! Not just the failover, but failback as well! Just because you think you wrote a solid DR plan and guide doesn't mean it works or that you will know how to work it when the time comes (and it will).

​

The bit longer version is: I took the ambitious plan of designing, deploying and testing the DR plan for the client without any prior experience in DR (just lots of RTFMing and lurking here).

The DR server was deployed. The Veeam replica's pre-seeded before the DR server sent off to a remote colo. Replicas ran great for a month. I wrote the requirements for and the DR plan. Now it all came down to testing the procedures...

Only to find out that something like this can go wrong after simply TESTING the DR and running a failback. The issue I think is that I shutdown the replicated VM when I was done testing it to prepare for failback. The funny part that after implementing the fix, Veeam suddenly shows in logs that failback was successful! Ehm, yea nah - that failed - had to do that manually.

Everything else went smooth though. Thank you for making a great product!

Hopefully this experience will save the companies butt when the time comes despite how "Nasty disturbing uncomfortable things" disasters are.