Nomad_Soul - Fotolia

Can you recover data after an unwanted Hyper-V Checkpoint restoration?

If you mistakenly restore a VM to a previous state, have you forever lost changes that were made after the Checkpoint was created?

Dear SearchServerVirtualization,

Our server, which is running Windows Server 2008 R2, restored an old Hyper-V snapshot by error, which erased all our recent databases. Is there any solution for that situation? We really appreciate your help.

Dear BitsBeGone,

Sorry for your loss -- of data. It’s always a bad day when, as an admin, you immediately know you did something wrong and you are powerless to stop what you just set in motion. In my office we have a rubber chicken award we pass around for such an occasion. However, all may not be lost. Hyper-V is just a combination of other Microsoft technologies that are placed on top of a bare metal hypervisor. In your case this is just a file services issue. And like any file delete, the key to getting your data back is getting a particular file or files back from before the incident.

Let me explain. When you create a Hyper-V Checkpoint (snapshot was the name for the feature in the 2008 R2 generation), what you do is freeze the existing virtual hard disk file, a VHD or VHDX file, and Hyper-V creates an AVHD or AVHDX file. This file is where all the new writes and changes happen. If you take another Checkpoint, then another AVHD(X) file is created, which piggybacks on the previous AVHD(X) file that is now frozen from all new writes (and so on as you create more Checkpoints). From what you said, it sounds like you took a Checkpoint and instead of removing the previous state of the VM, you restored the previous state by deleting the Checkpoint. This is, in essence, a rollback of the VM to the original state before the Hyper-V Checkpoint, which immediately brought about your sinking feeling since the AVHD(X) file was deleted from the volume.

So how do you bring it back? Well, as I mentioned above, this is a file services problem, and we need to find a way to bring the AVHD(X) back. If you can bring back the VHD(X) file from that time period, all the better. If you have backups, that's great, it's the best method. Any modern backup application can restore a VM to the original location or can put it to a new location. But if you had those, then you probably wouldn’t be asking the question.

So, let’s look at other options. Since what really happened was that the AVHD(X) file was deleted from disk, you need to find a way to undelete it. Just as if Mom was asking you to help get all her pictures back after she mistakenly deleted them on her laptop, you need a utility that can restore these files off of the volume that hopefully has not been overwritten. A product like EaseUS Data Recovery Wizard is an example of such a product, but there are others out there, and some that are free. If you can get at least the AVHD(X) file back, you have a chance here. As a side note, if this VM was in a cluster and sat on a Clustered Shared Volume (CSV), then you will most likely have to remove the volume from being a CSV, which will make it a normal cluster disk volume and run whatever utility you choose from the owning node of that volume.

Say you do get the AVHD or AVHD(X) file back, then what? Then it’s all just a technical game. If you have both the VHD(X) and the AVHD(X) files, but nothing else, you can do a manual merge of the AVHD(X) file into the VHD(X) file and you will have a whole copy of the operating system, application and data that you could reattach to the VM and boot the system. The best resource to explain how to do this is can be found on TechNet. Basically, change the file name on the AVHD(X) file to a VHD(X) file and go through the wizard to manually merge it into the original VHD(X) file. If you had multiple Checkpoints, this would mean multiple files. Hopefully it is just one in your case, as the odds of recovering all the AVHD(X) files would be slim without a true backup of the VM. Even if you do not get the original VHD(X) file back and only get the AVHD(X) file from before the incident, then you still have an outside chance. You can attempt to rename the AVHD(X) file to a VHD(X) file and try to merge it into the current VM's VHD(X) file. I shouldn't need to reiterate at this stage that you should make copies of what’s left of the current VM before doing any of this so that you have a fallback plan, or at least a way to retry the merge process again if it goes wrong for some reason.

That’s about all that can be done. Without the files in some form it is impossible, but this isn't much different from trying to get vacation photos back after you mistakenly delete them. One of the beauties of Hyper-V is that it's built off many of the technologies you already know.

Others with troubles? You can always submit your questions to our SearchServerVirtualization experts by emailing [email protected].

Next Steps

How Hyper-V Checkpoints work behind the scenes

Six mistakes to avoid when backing up Hyper-V VMs

Dig Deeper on Downtime and data loss in virtualized environments