Reattach or copy data from Snapshot

[kopper27]

hi guys

We had a Avamar issue Avamar created a snapshot to make a backup but we dont know the reason why VM kept using the snapshot that Avamar did not delete

Now I have a 270GB disk which has a 00001 snapshot file of 67 GB, now My customer has lost 1 week of email....how do I reattach or commit this data from this snapshot my VM......

the point is the disk are poiting to the original disks not the snapshots but the snapshot shows up in the snapshot manager

any idea how to fix this?

thanks a lot

[Gkeerthy]

It is better to log a case with Avamar, there are ways to commit the snapshots to the base disks, refer the below

Here in this case it is risky, make the entire vm backup and you can do at your risk. I recommend to seek help from the Avamar.

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=100231...

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=100684...

http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&e...

http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&e...

http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&e...

[a_p_]

Basically it's pretty easy to re-attach a snapshot .vmdk to a base disk, but you may run into data corruption issues with this. Keep in mind that snaphsots only contain changed data blocks (not files, ...), so the longer the VM ran on the base disk the higher the chance of data corruption!

What we might try is to clone the virtual disk - including the  snapshot - to see whether the missing data can somehow be extracted. Do you have a chance to take the VM down and is there enough free disk space for a clone?

Regarding the attached base disk: I never saw an issue like this which was not caused by a user/admin who manually attached the virtual disk to the VM.

André

[ngarjuna]

A VMware ESX virtual machine disk consists of a descriptor (ends in .vmdk) and an extent (ends in -flat.vmdk). When a virtual machine has been snapshotted, the attached virtual hard disks (otherwise known as the base disks) no longer receive guest OS modifications or writes; they are stored in separate virtual machine delta disk files (ending in -delta.vmdk). There is one delta file per base disk that is snapshotted.

With exception to thin-provisioned virtual machine disks, virtual machine disks typically have a reserved or set space requirement on a datastore. Snapshots, however, require additional space and consideration. They increase in size as further modifications or writes are stored.

For example:

1. If 10GB of changes were completed on one snapshotted virtual machine, its delta disk file size will increase proportionally by 10GB.
2. Creating another snapshot causes the existing snapshot delta disk to retain its current size, however the next delta disk will begin to store all forthcoming modifications and writes. The base disk is still left unmodified since inception of the first snapshot.
3. If another 15GB of changes were performed by the guest operating system, a total of 25GB of snapshot delta has now been recorded over the respective virtual machine's two snapshot delta disk files.
4. For versions prior to VMware ESX 4.0 Update-2, the task of consolidating all snapshots (Remove All Snapshots task) causes unique changes stored only in the second snapshot delta disk to be copied upwards through the snapshot chain and into the first snapshot, or its "parent."
5. This effect is recursive for each preceding parent file. As a result, the first snapshot delta disk file will grow by up to 15GB, accommodating all new blocks. Any common changes stored in both snapshot levels does not require additional space, however.
6. The end result is a datastore requiring 40GB, or 25GB + 15GB.