Replication to achieve site migration

[glennsantacruz]

(Still evaluating the product -- still happy with what I'm seeing...)

Situation: we want to gracefully migrate a VM from a "staging/test" site to a "production site" ; the VM is in active use by developers and consists of at least 40GB vmdk's. The production site is across a WAN (with a thin pipe), so we decide to allow the developers to have continued access to the VM while systems folks prepare it for migration. Hence - replication (instead of VM copy), to allow for "slow" seeding to the secondary facility (via offline / removable storage), followed by periodic replication (to get changes from the developers). This appears to work well, as it allows for the major data movement to not interfere with developer access to the VM, and we are able to capture remaining changes on a periodic basis until we're ready to go live at the secondary site.

Now comes the day for actual machine migration, to be "live" in the second site. We decide to :

1) Shutdown the VM
2) Perform final replication
3) Use Veeam to initiate failover
4) Log in to the replicant VM in the secondary site, then shut it down
5) Manipulate the replicant settings ( change network labels, RAM size, etc. )
6) Power-on the VM & ensure network connectivity is ok

So far, so good - we have a "live" VM in the secondary site. All is well. Now we need to "break" the replication job, as this VM will not be "failed back" or "undone" to the original site. So we:

1) Delete replication job in Veeam
2) Delete replication files (but do not delete from disk) in Veeam

And then we noticed something interesting -- the replicant VM is running under a snapshot ; this appears to be "proper" behavior in the event that someone would decide to "fail back" the replicant VM to the original datacenter. No problem - we delete the snapshot. But this raises the questions:

1) is this the "correct" method of breaking a replicant into a stand-alone VM?
2) what about all the "extra" files that are now in the secondary site? ( many *.vrb, running.rbk, replica.vbk ) ; can we safely remove these by hand?
3) are there other files to "clean up" by hand?
4) Does Veeam offer a native way to break-off the replicant VM to be stand-alone, or must all of the above be done manually?
5) Would this scenario be better addressed with a traditional backup/restore? If so, would that not involve moving the *entire* block of data (.vbk) file at one time, thereby introducing an unwanted downtime while the giant backup file is transferred to the other facility?

[Vitaliy S.]

Hello Glenn,

1. Yes, you may manually remove Veeam snapshot if you want to use replicated VM in production.
2. As soon as you've deleted the snapshot and started using VM in production, yes, you may manually delete those files. It shouldn't cause you any issues
3. No, only vbk/vrb files should be removed.
4. We are working on that.
5. Alternatively, you may backup your developer's VM, then move this vbk file offline to a production site, import this file to Veeam console and perform a restore, however I assume replica seeding option looks more optimal for your scenario

[glennsantacruz]

Hate to be nit-picky, but I want to be certain of your point number 3 -- you point out that only "vbk/vrb" files should be removed. To test and ensure we don't remove anything that VMware really needs, we decided to storage vmotion the replicant VM, and anything "left behind" must belong to Veeam. Here's what we found left behind:

Code: Select all

-rw-r--r-- 1 root root 393M Mar  4 09:09 2010-03-04T084755.vrb
-rw-r--r-- 1 root root  46M Mar  4 10:14 2010-03-04T085302.vrb
-rw-r--r-- 1 root root 245M Mar  5 10:33 2010-03-04T100617.vrb
-rw-r--r-- 1 root root 657M Mar  5 16:13 2010-03-05T102000.vrb
-rw-r--r-- 1 root root 8.1M Mar  5 16:41 2010-03-05T154758.vrb
-rw-r--r-- 1 root root 8.1M Mar  5 16:42 running.rbk
-rw-r--r-- 1 root root 8.1M Mar  5 16:42 replica.vbk

From this observation, it looks like we should remove all "vrb/vbk/rbk" files, correct?

[Gostev]

That is correct.