We use Netapp snapshots/snapvault as a way to take backups of VMs.
This is done using a script that does something like this:
1. look for all VMs on a datastore
2. take a VMWare snapshot of all VMs on that datastore to quiesce the .vmdk file
3. take a netapp snapshot of the datastore
4. delete all VMWare snapshots taken in step 2.
All of this is done to ensure that the .vmdk file is not written while taking a Netapp snapshot.
Now, I'm wondering: as far as I know, the NetApp snapshot is an atomic action for an entire volume. So does it actually make a difference to quiesce the VMs beforehand, given that all .vmdk files of a VM are on the same volume ?
We've been successful in restoring non-quiesced .vmdks so I'm wondering if anybody has an opinion on this.
I still believe that there are scenario's where you still can have a corrupt system: but my experiance is that the change is very low.
Now, in this case you are making a backup from your system-disk only? When you are running a database, you do the backup of your data on an other way?
When this is the case, than I think the risc is almost zero and when you take every hour a snapshot (NetApp level) without a vmware snapshot, than you will always have a copy that will boot (from the last 24 hours).
So my conclusion: for the system partition: no risc to do this. For your data, use an other way. We use snapdrive (with the microsoft initiator) in the VM for the backup of our data in our VMWare environment.
I have also a question: the delete of a VMWare snapshot works great with iSCSI (on ESX level) but our test with nfs is not so good. There we see a timeout of the VM for more the 15 seconds when the ESX is deleting a VMWare snapshot. Do you see the same?
we have made some backup on VMs on datatsores located on NFS.
Netapp has a tool called : VIBE (perl script) available for XP and Windows 2003 or Linux. It works fine.
- specify a specific or a list of datastores
- specific or a list of VMs or ALL
- request a crash-consistent snapshot on ESX --> VMWARE snapshot done before the snapshot of Netapp
- can also be include in your snapmirror scenarios --> Replication/DR
- can also be include in your Snapvault scenarios --> Backup to disk (Neartsore)
the only think that seems 'strange' is that when you have a crash-consistent snapshot include into your Netapp snapshot, when you will do the restore the VMWARE snapshot is back but the snapshot is not listed into ESX Snapshot Manager so you can't delete it from your VC. Maybe need to be done via script.
++<span class="jive-thread-reply-body-container">the only think that seems 'strange' is that when you have a+
crash-consistent snapshot include into your Netapp snapshot, when you
will do the restore the VMWARE snapshot is back but the snapshot is not
listed into ESX Snapshot Manager so you can't delete it from your VC.
Maybe need to be done via script.+
We did a recovery of a machine yesterday and had the same experience. Things are actually even worse, because trying to create additional snapshots on the recovered machine doesn't work any more, the poor thing is totally confused.
This strengthens my idea that it's actually better not to perform a VMWare snapshot before taking a Netapp snapshot. Recovering machines that have associated snapshots seems trouble.
If you're using VIBE with VMware snapshots, you should just those exclusively. Taking VMware snapshots with VIBE as well as VMware snapshots for other purposes can lead to VMware not knowing which snapshot to revert to. Ideally if you need the snapshot of a particular VM after the VIBE backup then simply connect to the datastore and get it from the VM directly.
It is an interesting use case question, though -- why might you need VMware snapshots with VIBE and other tools?
Lack of NFS file locking can cause two hosts to run the same virtual machine at the same time. This is bad and the VM will usually be corrupted very qucikly. This is no longer reccomended by Netapp or vmware. Performance issues around this and snapshot problems appear to be addressed in the latest set of patches
I have had nothing but trouble with VMware snapshots, after a failed quiesce I had to manually fix the header information linking the snapshots together in each snap vm file.
I am now relying solely on Netapp snapshots, which I have restored from successfully multiple times. That being said, I would still recommend backing up the VMs in power off state occasionally, just to make sure you have a non-running guaranteed backup.