instant recovery and backup

[StuartHurst]

Hi
We were trying to migrate a vmware (5) machine from it's current host to a new host as the host had failing disks. After a couple of attempts doing this, and manually copying the vmdk files, I realised we had got a full backup of the VM and used Instant recovery to put this onto a new host.
Now the backup's of this machine are failing and I'm nervous about the next steps. I can see in Instant recovery that the machine is mounted on the new host. Gut feeling if I click stop publishing, it will stop the VM.

Long and short of it, I need the VM to stay up and running, and have the server get backed up at night. We're running Veeam 6.0.0.153 32bit
Any idea's would be appreciated

Thanks

[Vitaliy S.]

Hi Stuart,

Now the backup's of this machine are failing and I'm nervous about the next steps. I can see in Instant recovery that the machine is mounted on the new host. Gut feeling if I click stop publishing, it will stop the VM.

Yes, you're correct. If you click stop publishing, this VM will be reverted back and you will lose all the changes occurred during "publishing" period.

Have you already scheduled a migration of this VM back to production? Btw, if you have any technical issues, please contact our support team directly. Thanks!

[StuartHurst]

I've called and they've given me two options - 1 to migrate the machine to another host using vMotion, or to Replicate the VM to another Host.

What would happen if I took a snapshot of the machine on the original host? Equally, It's great having Instant Recovery, which brings it back up, but it should be able to hand control of it back to VMWare, surely. Seems a bit daft that you have to go to this extra length to get something that's running in VMWare but handled by Veeam... What would happen if I shut the server down? The .vmdk files and vmx files are all on the new host so why can't Veeam Instant recovery let go and let VMWare take over and save this hassle of moving machines around instead to get Instant Recovery. Programming Request, Get Veeam to have an Instant Let Go button that you press after Instant Recovery that commits the recovered server to Vmware.

[tsightler]

Veeam can "hand back" control of the VM to VMware. Simply use storage vMotion to move the VM back to "real" storage. Remember that when a VM is running in "Instant Restore" mode, it's running from the compressed and deduplicated backup files. You must use some method to move these files back to "real" storage. You can use storage vMotion easily enough, which will migrate the VM with no downtime, or, if you don't have storage vMotion licensed, you can replicate the VM which will have minor downtime while the failover occurs.

[Gostev]

If you are running version 6.1, easiest way to finalize the recovery is right-click the published VM, and select Migrate to production. This option will work whether or not you have Storage VMotion licensed.

[tsightler]

If you are running version 6.1, easiest way to finalize the recovery is right-click the published VM, and select Migrate to production. This option will work whether or not you have Storage VMotion licensed.

But may entail some downtime without Storage vMotion.

[StuartHurst]

We've not upgraded to 6.1 yet - just have 6.0 installed. I've initiated vmotion to move the datastore to another datastore. From what you have said, this means that the datastore becomes committed and I can stop the publishing? or do I need to vmotion the machine to a new host too?

[dellock6]

Wait, you need _Storage_ vMotion to escape downtime, not vMotion. Do you have it in your vSphere edition?

[StuartHurst]

Hmm - not sure to be honest. When I right click and select migrate, I get the option to move host, or move datastore. The option to move both the host and datastore at the same time is greyed out. Where is vMotion_Storage?
The datastore has moved over to a new host now - no downtime so far. The Veeam Backup & Replication still has a status of mounted for this VM. Still nervous about stopping the publishing of this file. Oddly, when looking in the datastore, I see 2 sets of identical sized .vmdk with the names being different slightly, - one set have -000001.vmdk, and the other has -00002.vmdk.

Should I vmotion the VM to a new host too?

[StuartHurst]

We have Vmware Essentials so whatever is included with that, we have

[dellock6]

Ok, no, you do not have storage vmotion. you can check this by using Migrate command and then choosing datastore. If the VM is powered on you will receive an error that is not possible in the current VM power state.
Minimum licenses to have Storage vMotion is Enterprise:
http://www.vmware.com/products/vsphere/ ... rison.html

Luca.

[Vitaliy S.]

Should I vmotion the VM to a new host too?

Changing the host will not move VM virtual disks to the production datastore, you need to migrate this VM either by using Veeam backup console or vSphere Client.

I've initiated vmotion to move the datastore to another datastore. From what you have said, this means that the datastore becomes committed and I can stop the publishing? or do I need to vmotion the machine to a new host too?

I guess you've meant to say that you've initiated the move of VM virtual disks to another datastore, right? If this is the case, then feel free to stop publishing this VM once the migration is over, this will not affect the migrated VM.

[StuartHurst]

Sorted it - no downtime.
After migration of the datastore, I was able to stop publishing (after another reassurance call to Veeam Support. Thanks to Caleb for holding my hand - virtually...

[Vitaliy S.]

Thanks for coming back and updating this topic! Perfect real-life example demonstrating how Instant VM Recovery can help in a DR situation.

[Gostev]

But may entail some downtime without Storage vMotion.

...much shorter downtime than with your suggestion though as replication failover means cold restart.