Principale utente con più risposte

Hyper-V Deleted Snapshot Issue

Domanda

We accidentally deleted a hyper-v snapshot from the windows explorer view without merging it back into the main .vhd file and since it was such a big file it skipped the recycle bin. Now before removing this snapshot file in windows explorer we had in the past removed the snapshot via the GUI. We just never knew we needed to merge the files back into the main .vhd. The reason we removed the snapshot .avhd file was because we needed to expand our virtual hard drive size and it said we couldn't as snapshots existed. Hence we figured since we had removed the snapshot via the GUI that the file could be removed safely. We found out wrong.

When we went and booted up the original .vhd it set us back four months in time and we had to restore our windows server from backups to bring it up to date. Now our virtual machine is currently running and we can power it off and back on with loosing any data but we have noticed a difference in the vm's behavior since the night we recovered. Other virtual machines that are running will update the time stamp on the .vhd file as time goes on. This .vhd that we reverted back to and then restored on top of does not update the .vhd file time stamp. The only time that .vhd file time stamp gets updated is when the virtual machine is powered off and back on.

I understand that when the snapshot was removed without being remerged it got rid of a portion of time. How can we get our .vhd file to go back to updating properly? Any suggestions? This is a production server so we need to get this fixed so any help is really appreciated.

Risposte

the reason that I say that is that you were in a snapshotted situation and you broke the chain.

You mention using Windows Backup - but I don't know if you did that within the existing Vm, a new VM, at the host level, where. The implications for each is very different.

You could restore and thus repair points in that chain and continue to run in a differencing disk chain - but then I would expect that your root VHD would not be modified at all.

Also, a running VM does run in a type of cached state. You won't always see the time stamp on the disk changing.(I find it hard to explain, but I have seen it)

If you are concerned about the timestamp issue I say to take the time to export the VM to a new copy, be sure to export that to the location you want the VM to be running from, (rename the origional VM) then import the exported copy.Brian Ehlert
(hopefully you have found this useful)

General speaking, we don’t recommend that you use snapshots in production environment. As BrianEh mentioned, make sure you have a good backup anyway, especially in production environment.

After you take a snapshot on the VM, it will create a avhd file, after that, all changes will be save in the avhd file, so if you delete the avhd file manually before your merge it into the original vhd file, you will lost the data after you take the snapshot.

For more information about snapshots, I recommend that you have a read of the following blogs.

Tutte le risposte

The easiest thing to do it to take the restored VHD and produce a new VM from it.

If you had snapshots, deleted them, then recoved the disk to the exact same location you might be having errors with the VMMS service under the hood and you just are not realizing it.

If all you are doing is booting the VM and powering it off, you should not see any disk change until the running VM is writing to its disk. There are cases where your described behavior would be considered normal. If you restored into the existing VM, then you still might have pending merges wanting to happen int eh background, which means that you are sitll in a snapshotted state.

If you have a good copy of the VHD, simply create a new VM from the good VHD and delete the old VM and VHD.

If you are using the hyper-V manager - deleting a VM does not delete its VHDs.

(but always make sure you have a good backup anyway, no promises).

If you have the time, you could export the VM to a new copy - but that requires both space and vm downtime.Brian Ehlert
(hopefully you have found this useful)

The easiest thing to do it to take the restored VHD and produce a new VM from it.

If you had snapshots, deleted them, then recoved the disk to the exact same location you might be having errors with the VMMS service under the hood and you just are not realizing it.

If all you are doing is booting the VM and powering it off, you should not see any disk change until the running VM is writing to its disk. There are cases where your described behavior would be considered normal. If you restored into the existing VM, then you still might have pending merges wanting to happen int eh background, which means that you are sitll in a snapshotted state.

If you have a good copy of the VHD, simply create a new VM from the good VHD and delete the old VM and VHD.

If you are using the hyper-V manager - deleting a VM does not delete its VHDs.

(but always make sure you have a good backup anyway, no promises).

If you have the time, you could export the VM to a new copy - but that requires both space and vm downtime.
Brian Ehlert (hopefully you have found this useful)

Thanks for the response Brian. I believe I was a bit vague in my response before when I said power off and on. I meant to say that the file time stamp of the VHD file only updates when the VM is shut down and restarted. Our VM has been running now for a few weeks and files are constantly changing on the VM but yet the VHD time stamp does not update like our other VM that handles a file server. This VM I'm referring to is a domain controller and email storage server so it is always changing and is running SBS 2008.

Could you maybe expand on what you mean by a good copy of the VHD? Our current VM VHD file was the original file before the snapshot was taken. So it's state in time was from November 4th of 2009. At that point in time our domain controller hadn't been setup nor had our email server. So we had to take a windows backup we had and have it restore the OS to a state from January 26th of 2009, when we had recovered, so that now it is all back up and running. The only defect I see of this VM is that the time stamp on the file doesn't change. So... would an export of the VM in a powered off state and then making a new VM based on that exported VM be the best case for getting the VM back to updating the VHD file time stamp? Or is there another step you'd recommend? Just want to get some clarification before we schedule some downtime for the VM.

Also how can one figure out if there are errors with the VMMS service under the hood?

the reason that I say that is that you were in a snapshotted situation and you broke the chain.

You mention using Windows Backup - but I don't know if you did that within the existing Vm, a new VM, at the host level, where. The implications for each is very different.

You could restore and thus repair points in that chain and continue to run in a differencing disk chain - but then I would expect that your root VHD would not be modified at all.

Also, a running VM does run in a type of cached state. You won't always see the time stamp on the disk changing.(I find it hard to explain, but I have seen it)

If you are concerned about the timestamp issue I say to take the time to export the VM to a new copy, be sure to export that to the location you want the VM to be running from, (rename the origional VM) then import the exported copy.Brian Ehlert
(hopefully you have found this useful)

the reason that I say that is that you were in a snapshotted situation and you broke the chain.

You mention using Windows Backup - but I don't know if you did that within the existing Vm, a new VM, at the host level, where. The implications for each is very different.

You could restore and thus repair points in that chain and continue to run in a differencing disk chain - but then I would expect that your root VHD would not be modified at all.

Also, a running VM does run in a type of cached state. You won't always see the time stamp on the disk changing. (I find it hard to explain, but I have seen it)

If you are concerned about the timestamp issue I say to take the time to export the VM to a new copy, be sure to export that to the location you want the VM to be running from, (rename the origional VM) then import the exported copy.
Brian Ehlert (hopefully you have found this useful)

We deleted the snapshots in the snapshot folder. So all we were left with is a VHD file DSISBS-2K8.vhd. This file had a timestamp from November 4th of 2009. So sure enough when we booted our VM off that VHD file it was the state in time right before we had made a snapshot. So from this point we had a VHD file with an installed SBS 2008 installation. SBS 2008 as a built in backup utility called wbadmin. We had nightly scheduled task that would run and backup a full backup to a network share. So we grabbed the backup files and then used wbadmin to restore the system state to the state in time of the backup that was January 26th of 2010. The command we ran was "wbadmin start recovery -version:VersionNum -backupTarget:\\PathToNetworkShare" So that's how we restored.

So now this VHD file is as far as we know what currently holds the state of the VM. Is there anyway to check if there are other differencing disks? So does an export grab all needed information and package it into one VHD file again so it can be imported?

General speaking, we don’t recommend that you use snapshots in production environment. As BrianEh mentioned, make sure you have a good backup anyway, especially in production environment.

After you take a snapshot on the VM, it will create a avhd file, after that, all changes will be save in the avhd file, so if you delete the avhd file manually before your merge it into the original vhd file, you will lost the data after you take the snapshot.

For more information about snapshots, I recommend that you have a read of the following blogs.