While working with customers, I have frequently run into situations where they need help with Hyper-V snapshots. Help with understanding what snapshots are, how to use them, best practices with them, or, in worst case scenarios, they may need help in recovering them in order to use a VM.
What I’d like to do in this post, is run down some quick and helpful topics that will keep you on track to being successful each time you use the Hyper-V Snapshot feature.
Do not use Snapshots as a backup strategy
Snapshots can be very useful during the ‘Test and Development’ stage in your environment. And in fact, that’s pretty much what they were designed for.
Snapshots should not be used in a production environment as a replacement for having a well thought out backup strategy.
There are multiple backup solutions and configurations available for Hyper-V at this time and I’ll have some links at the end of this post for more information.
We encourage our customers to use Snapshots in a production environment prior to patching servers. This creates a point in time to fall back to if something doesn’t go according to plan. Once the patch or other system update is applied successfully to the VM, I usually suggest letting the VM run a day or so, and if it’s operating as expected, remove the Snapshot.
Manually interacting with Snapshot files
Snapshot files have long file names made up of the GUID associated with the Virtual Machine they are from and have extensions of .AVHD, .XML, .BIN, and .VSV. I’ve run into a couple of instances where customers have found these strange files, and not knowing what they were, removed them because some were rather large and the server was low on disk space. In these instances, the customers run into problems when rebooting the VMs that had Snapshots configured because the files are now gone
If you need to use Snapshots in your testing environment, and you are not using R2, I suggest the following configuration changes to avoid running space concerns with the system volume:
Change the default location of where Virtual Machines will reside.
Place this location on other media than the system volume to avoid running out of space.
Choose a location that is sufficiently large enough to accommodate the number of snapshots you expect to have in your environment.
If you are using R2, then as previously mentioned, the Snapshot location will default to the same location as Virtual Hard Disks.
A key thing to remember with snapshots is that moving, renaming, deleting, or otherwise altering files associated with snapshots may result in the associated VM not working properly next time it’s restarted.
Once a snapshot, or multiple snapshots are created for a VM, all of the associated files must be present when the VM starts in order for the process to be successful.
The “Merge Rule”
Another area where customers can sometimes run into some trouble with snapshots is when they want to start pruning their snapshot tree and they aren’t sure which ones will be merged and which ones will be outright deleted.
This is where “The Rule” comes in:
1) If there are snapshots above the current running state (Now) that are deleted, then a merge will occur when the VM is shut down, turned off or saved.
2) If there are snapshots below the current running state (Now) that are deleted, then a merge will NOT occur when the VM is shut down, turned off or saved.
When a snapshot is deleted, saved state files (.bin and .vsv) get deleted immediately, even if a merge will occur when the VM is shutdown, turned off, or saved.
When you delete a snapshot, the .avhd file(s) that store the snapshot data remain in the storage location until the virtual machine is shut down, turned off, or put into a saved state
NOTE: What happens to the AVHD file(s) depends on the location of the deleted snapshot relative to the running state of the VM as noted in the 2 part table above.
In the times where customers have ended up needing to call into support for help with recovering from deleted snapshots, or have needed some other type of assistance with a heavily nested snapshot tree, I have noticed that only rarely have they taken the little extra effort to rename the snapshots to something effective and descriptive.
Choosing the default naming convention is fine for 1 or 2 snapshots, but frequent snapshots result in a multi-branch, multi-level listing; not having the snapshots named something effective can result in conversations having a lot of “I don’t know”’s in them.
As you can see by this example, this is not a very clear indication of the differences between the snapshots on the 20th, versus the one I took on the 21st.
How to rename your snapshots
One thing you’ll notice is that when you right click a VM through Hyper-V Manager, and choose snapshot, you don’t get a choice of names. It just stamps the snapshot with the VM name, date and time. How boring!
There’s two ways you can add some helpful text to these titles.
Choosing descriptive snapshot names may take a few seconds extra time up front, but in my experience, this effort can save hours of labor on the other end should there be a need for troubleshooting of a problem.
In closing I wanted to summarize some quick Best Practices when dealing with snapshots.
Do not use them as a backup strategy
DO use them for point in time “safety nets” during patching or VM system updates.
Do not store snapshots on the C:\ drive.
Do not move, delete, rename, edit, the associated snapshot files.
DO make sure you name your snapshots in a helpful & descriptive manner
I hope you found this post helpful!
Support Escalation Engineer
Microsoft Enterprise Platforms Support
Ben Armstrong’s blog: Virtual Machine Snapshotting under Hyper-V
Ben Armstrong’s blog: Managing Snapshots with Hyper-V
Hyper-V Snapshot FAQ
Video discussion with Ben Armstrong discussing Snapshot common issues
Backing up VMs:
How to backup Hyper-V vms using Windows Server Backup