Veeam Data centre migration success story

[chattingh]

We recently had quite a big win with Veeam which I thought I'd share.

We have a customer, a high profile retailer, who wished to relocate their Data center from New Zealand to Melbourne, Australia in a very short time-frame. Approximately 25 VM's on VMware, consuming around 4Tb of storage. As our client already used Veeam in their New Zealand Data center, we decided to use Veeam Replication to perform the migration. However, there wasn't enough bandwidth between the two Data centers to replicate the entire environment in the time-frames we were given. The maths simply didn't work out. There was a very short time between the client's new hardware being deployed in the new Data center in Melbourne, to their desired go live date.

We are also a Veeam Cloud Connect provider, providing an offsite Veeam Cloud Connect Backup service to this same customer, so decided to leverage those backups as a seed to achieve what would otherwise be impossible. This is how we did it:

• We copied the clients encrypted Cloud Connect backups to a NAS device and in turn copied that to their new VMware environment whilst we were building it and had physical access to the hardware. We deployed a Linux VM to hold this encrypted "seed data".

• The hardware was shipped to the Melbourne Data centre, installed, and connectivity to the New Zealand Data center was established.

• Our next goal was to set up Veeam Replication jobs for all the VM's that needed to migrate from New Zealand to Melbourne, Australia.

• To do this, we added the Linux VM in Melbourne as a Backup Repository to the Veeam BR server in New Zealand, and deployed a Server 2012 R2 Core VM as a Veeam Proxy in Melbourne.

• Once the customer entered their Cloud Connect encryption key, we could import the Cloud Connect backups into Veeam.

• We set up the replication jobs, specifying the Linux Repository in Melbourne as the replica seed.

• At this stage, the seed backups were about one week old, we had less than a week to perform the catch-up replication, and to cutover to the new Data center.

The replication jobs worked perfectly, obtaining their seed data from the imported (and encrypted) Cloud Connect backup. We were able to obtain up to date VM replicas in a matter of a couple days. Last night, we performed the Data center migration, with very little, to no, business impacting downtime. Source VM's were shut down in groups, a final replication performed, and the VM's failed over to the new Data center. They were brought up in the new Data center, re-IP'ed, new Port Groups mapped, no dramas. The entire process took around 8 hours, and at the end when all business checks had passed, the failover's were made permanent.

So, what went wrong? Pretty much nothing. On one VM only, the new IP Address was not set correctly. We didn't bother troubleshooting it; just set it correctly and carried on.

Veeam, It just works. Sounds like a marketing cliché, but we have proven it to be true.

[dellock6]

Really nice!
Thanks for sharing.