How can I backup and restore a production VM?

[bhartm62]

I'm looking to backup and restore VMs (VMware) using Nimble snapshots. If snapshots are done quiescing the vm while they are running, how can I restore them again?  Technically they would be in running state again when doing the rollback? What happens? All VM files (OS and data) are currently on the same volume.

[rugby0134]

When you mount the clone and copy/boot  the VMDK files, the VM will boot into a crash consistent state, and probably ask if you copied or moved the VM.  Pick the  moved option  and it will boot as if nothing happened.  Be aware - the new VM will have the same iSCSI initiator sand IP  as the original VM, so if any passthru LUN's are used it might try to steal them.

[chris24]

Hello,

In the instance of VMware snapshots, Nimble will call the VMware API which in turn will take a VMware snapshot to which writes are written during our snapshot operation, in addition VMware will invoke the VSS writers via VMware tools (VSS provider) thus quiescing the applications and filesystem to ensure all the writes are committed.

For details on what applications can be backed up in an application consistent snapshot see http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1031200

For details on how to recover and restore VM's there are a number of KB's available in infosight that detail the process.

[jzygmunt70 · Accepted solution]

What the others have said is correct.  Essentially you're not restoring a VM, but brining up another copy of the VM's volume from a prior time, at which point you can boot the copy of the VM from the volume snapshot based copy or you can just directly access the files located on the volume (perhaps to download the .vmdk and use another tool to browse for files inside the .vmdk).  If you choose to bring up a copy of the VM and your original VM is still running, I highly recommend first editing the VM settings to connect it to an isolated network (having to servers with the same name and IP on the same network is usually a bad idea).

However, you may already be aware of this, but to be more specific, the Nimble storage array is capable of snapshots, not backups.  This is an important distinction.  If you really mean you want to backup your VM, the Nimble array is the wrong tool for the job.  Snapshots, unlike backups, rely on the original data blocks being available.  In the event of a loss of the original data blocks (someone deletes the volume, you have multiple array drive failures, Bruce Willis fails to blow up meteor before it falls on your datacenter, etc.) you will not be able to recover your data.  Even making a full copy of a volume in the same array (rather than a snapshot) would qualify more as a backup than a snapshot (though not one would rely on).

[bhartm62]

I want to make a distinction. Nimble snapshots are not the same as a vmware snapshots, correct? Or does Nimble know about VMware and VMDKs when you make a Nimble volume snapshot?

Scenario VM:

1 OS disk + 1 Data disk (both on a Nimble volume)

I back up the OS disk with another solution. Now I take a Nimble volume snapshot of that volume while the VM is !running. Can I then revert to the storage snapshot and recover the Data drive?

The issue is that there are too many operations on the disk for the backup software to make a proper backup, but a storage snapshot would be more powerful and able to do the job?

[jzygmunt70]

You are correct when you say Nimble snapshots are not VMware snapshots.  IMHO, VMware snapshots are far less efficient and far more problematic, but they have their uses.  For example, if you have ten VMs on one nimble volume, the nimble snapshot will be a snapshot of all the VMs, whereas with VMware you could snapshot just one of the VMs on the volume.  I find the VMware snapshots to be far less efficient and way more troublesome than the Nimble snapshots (especially when someone takes a VMware snapshot of a VM that gets lots of changes and forgets to delete it).

I understand your desire to conduct the backup from a snapshot because of a high rate of data change on the source system.  Tell me about your backup solution and how you're using it.  Without knowing that information, here are some things I would consider:

1.     Is your backup solution currently backing up the VM through an agent running on the operating system.  In this case you're probably using VSS and perhaps you're having trouble getting quiescence.  Trying to use a tool that does backups this way with Nimble snapshots would be really difficult (but theoretically possible with a lot of scripting).  I wouldn't want to do this.

2.     Is your backup solution VMware aware?  If so, it is most likely already calling for a VMware snapshot, then taking a backup of the snapshot (and it may use an in-guest agent to capture additional information).  In this case, IO shouldn't be a problem once the snapshot is successfully taken (though if your rate of data chance is incredibly high, I could see where this could be painful when consolidating the snapshots later).

3.     It is practically possible to script the nimble to take a snapshot, make it available to your backup solution, mount the volume, backup the files, and finally cleanup the mess...but that's a lot of work.  With what I know so far from you, I don't know why you would take this approach.

[bhartm62]

We are using VEEAM at the moment to back up VMs seperately, so that talks to VMware directly and makes a snapshot to copy it afterwards and deletes it in the end. However the VMware snapshots can't cope with the high I/Os when you try to delete the snapshot again which is why I'm hoping to find a solution with nimble snapshots.

[jzygmunt70]

I've seen this issue before.  Before you go through the trouble of trying to solve this with Nimble snapshots, try experimenting by turning off application aware processing and VMware tools quiescence in veeam.  You may find you can get your backup.   If that doesn't help, I can only think of one other approach, and that's backing up off a nimble snapshot.

I would scratch and claw to find a way to get the machine quiet enough that you can get a VMware snapshot for veeam and back it up.  There are setting to increase the quiescence timeout, etc that you can experiment with.  Try also posting to the veeam forums to see if those guys have other ideas.  If you absolutely cannot get the quiet time you need, my best guess is you'll need to setup a pre-job script  for veeam to do these steps:

1. take a snapshot of the nimble volume(s) in use by the VM
2. Set the snapshot as online (if you just need to copy/backup the raw vmdk files) or mount the snapshot as a clone (if you need to bring up the vm to get in-guest access)
   1. script changes to connect the vm to an isolated network that only your backup host can access
   2. bring up the cloned vm
   3. backup the cloned vm
3. cleanup the mess

This wouldn't be my idea of a fun time, but it can be done.  Have a look through this forum, there are some good articles about how to script the cloning and brining up of Nimble volume and VMs for the purposes of provisioning.  That should get you about 75% of the way there.