Help me failback my VM to Prod!

[matt_778]

Hi there,

Site Info
Prod: 3 x ESXi 5.5, Virtual vCenter, Physical Veeam/Proxy Server (V8)
DR: 3 x ESXi, Virtual Center, Physical Veeam/Proxy Server (V8)
Connectivity: Layer 2 stretched WAN - 50Mb (same subnet either end)

Due to a Prod SAN failure, we had to spin up our Exchange Server in our DR site, this worked fine.
Its a single Exchange 2010 with 3 VMware vdisks attached, totaling 565GB. Its now been running in DR for 2.5 days.

Last night I planned to failback, (the original VM was available and turned off in Prod site) hoping that overnight was long enough to get it done (it wasn't)
On the failback job, I was careful to select the correct Proxies for the two sites.
After 9hrs, I don't think it was halfway through - I would have left it going, but for Veeam had turned the Replica off, so Exchange was down for staff, so I had to cancel the failback.

http://1drv.ms/1gOSxA1

I wasn't expecting the Replica Server to be off during the long copy back - this seemed different to the Veeam user guide pg150

http://1drv.ms/1gOSOmu

Questions:
1. Is there a way to failback with minimal Server downtime (I would expect/accept a small outage when doing final delta)
2. Is it a good idea to make the failover permanent, then setup a new, reverse replication job so the server can trickle back up to Prod (then do a new failover)

[foggy]

Matt, basically, for such a highly-transactional application as Exchange, it is quite expected that during the first synchronization stage (which takes considerable time in your case, several hours) it generated significant amount of changes. So the second synchronization cycle that should copy "a portion of last-minute changes made on the VM replica while the failback process was being performed" takes longer than expected. I suggest to do the following:

- set up a couple of hotadd proxies, one per side, so that data retrieval and population perform better (currently you're using direct SAN on source and NBD on target, since direct SAN cannot be used for writing data on incremental runs);
- enable WAN acceleration for the replication job.

Regarding your second question, yes, you can also go this way, additionally consider using planned failover to avoid any data loss during failover.

[foggy]

Correction: WAN acceleration is not used during failback, so probably the approach using replication from DR site back to production would be faster.

[matt_778]

Thanks for the response.

I did end up setting up a fresh replica job from DR to Prod and failed back (I didn't use "Planned failover" though did pretty much the same steps manually)
I do think the documentation is ambiguous about when the VM actually gets powered off.
I also wonder how one might failback large environments, would be tricky.

Anyways, it worked well.
Cheers

[foggy]

Glad you were able to finally get it done. Failback to the original VM indeed requires significant time as calculating and synchronizing the differences between the original VM and its replica is performed. With hotadd proxies on both sides, however, the process would be faster.