Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I wanted to make some changes to a file server VM today on ESXi 4. The machine is a Debian Lenny guest with two virtual disks - one is 8GB and the other is 500Gb (data). In order to protect the machine from unwanted changes, I made a snapshot of the machine. I went ahead and made my changes and it didn't work out well. So, I powered off the VM and went into snapshot manager and reverted to snapshot. However I reverted to an older snapshot and not the one I just made by mistake. I then (idiotically) deleted the snapshot I just made in snapshot manager. This has resulted in me losing about one year's worth of data.

Is there any way to recover this deleted snapshot file? I'm using vmware esxi 4. When I browse the VMWare repository I can see various vmdk files - is it possible the data I need is still there? What should I look for?

Thanks, Mark.

share|improve this question

3 Answers 3

up vote 1 down vote accepted

This is probably going to sound harsh..

Do you have a backup? It's entirely feasible that you can back up the data from inside the Virtual Machine, or the vmdk image itself, and the config of the VM host platform.
Restore that, and you'd probably restore the system state to before you deleted it.

If you can see the vmdk image itself, and you know that it's the one you deleted, perhaps can you get a VM to mount that directly by just adding it as another disk?

share|improve this answer
    
No backups - this is a home server. I know, I know. –  Mark Allison Apr 3 '10 at 10:01

You are almost certainly out of luck but it might be worth inspecting the VMDK and the remaining linked snapshots just in case.

The VMDK structure consists of a root descriptor ( the small file called diskname.vmdk) and root data (the large file called diskname-flat.vmdk) and then possibly a series of linked descriptor vmdk (named diskname-0000n.vmdk) and delta (redo log) files (named diskname-0000n-delta.vmdk) containing chained descriptors and redo logs for each snapshot. You can open the descriptor VMDK's in any text editor and see what the parent vmdk's are (if they exist)- the fields you are looking for in the snapshot VMDK's are the CID and the parentCID. Those will allow you to identify the linked list of snapshots. Note that the root VMDK has a parentCID of all "F"'s and their may be independent lists so you have to map them all out carefully.

If you have carried out the steps you describe it's very unlikely that you'll be able to recover anything because by deleting a snapshot you cause the re-do log data to be merged into the parent. I've seen corrupted snapshot lists in the past that were recoverable in scenarios like this but the combination of circumstances that enabled that to happen are not very likely. Still if you can find snapshots that create a valid linked list that present you with valid data you might be in luck and since you clearly have some snapshots still active there might be a chance.

Also I don't want to preach about backups given your situation but you must make a clean backup copy of all of these files before you go messing about with them.

share|improve this answer

Given it is a home server, perhaps you can find a way to shut everything that is writing to the disk off, then try and recover raw data directly from the disk. It's a long shot, but the ones and zeros making up your data may still be on the disk. I don't know off the top of my head any software that would help. OnTrack Data Recovery claim to be able to recover VMWare virtual disks, so perhaps they can help. I guess it depends how much they charge, and how much you want your data back. But to be in with any kind of chance, you need to stop using the physical hard disk the data was on immediately!

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.