Planned failover for maint.

[blturner]

I want to upgrade ESXi on my production server from 5.1 to 5.5.
I think I can do a lossless transfer of the Exchange server by doing a "Planned Failover" to the backup ESXi server where it already gets replicated each night.
I then should be able to move it back using a "Failback" operation, also lossless. A table in the manual showing relative speed and lossiness of the various failover choices would be helpful.

I need to estimate the downtime for the mail server during this process and total time to complete. Looking at the logs, last nights replication took 42 minutes. However I think most of this time is quiescing via VSS and removing the oldest snapshot. Neither of which seems necessary in a planned failover. So it could be as little as 15 minutes and only 5 to 7 with the server actually down.

If it's going to be 42 minutes each way and another 30 to 45 for the upgrade then it's more than I want to do in an evening. I will have to plan a Saturday or at least two consecutive evenings.
I am running Veeam v8 and everything except the production server is already at vSphere 5.5. Its a 3 host setup. The Exchange 2010 server has 650 GB of mail and 2.7 TB of total storage.
The storage is all local disks in raid 10

[blturner]

My first post got delayed for moderation. So I decided to proceed rather than wait an indeterminate amount of time.
Well.... Not going well as of yet.
I ran another replica job to see if it always took the same amount of time. Only took 15 minutes. Cool. I'll be home in time for dinner.
So, I ran the planned failover job. It's been 1:37 minutes so far. With 1:20 sitting at 99% "Applying retention policy"
I know that means that it is removing a snapshot. I would prefer it would just get on with it and delete the snapshot when I was not waiting on it.
A proper progress indicator would also help. I found that the vSphere web client has one but it's been on 99% for the last 22 or so minutes.
This is taking so long I am going to run into my backup window and have to cancel tonight's backups.

I guess I should make a feature request that Veeam not delete snapshots during a planned failover.

If I had done this before I would just go home and trust it to complete on it's own. But now I am committed. I have to be here to make sure the mail server works when It's done.
Good news is the mail server is fine at the moment.

Brian

[foggy]

Most likely the specified retention setting (the number of restore points to keep) was reached right on that replication job run, so it started applying retention policy (while it didn't during the previous run(s)).

[blturner]

I gave up and went home. It completed without problems, but took 2:50. Could I have looked at the size of the oldest snapshot and predicted that?
In a true disaster situation where I'm burning $700+ per hour of downtime I need predictability. I probably would not do a planned failover but I might.
It seems that failback has a lot of variability and can be even slower than a planned failover.

I also can't failback to production because I removed a hard disk from the original VM about a week ago and the replica still has it. I opened a support ticket on that one. 00703418

Brian

[foggy]

It seems that failback has a lot of variability and can be even slower than a planned failover.

Failback to the original VM requires calculating and synchronizing the differences between the original VM and its replica, so definitely can take some time (usually comparable to the time required to make a full backup of the VM, as entire VM image is scanned during this process).