Why Hyper-V Snapshots Don’t Replace Backups Hyper-V Snapshots (called “Checkpoints” in System Center Virtual Machine Manager, as they were called in Virtual Server), are a tool used best for short-term testing on virtual machines. They are absolutely not intended as a replacement for a proper backup.
What Are Snapshots? When you instruct Hyper-V Manager to take a snapshot or use SCVMM to create a checkpoint, Hyper-V does a couple of things. One of those things that is often overlooked is that it saves a copy of the VM configuration (memory quantity, CPU count, etc.). The key thing it does is create a new .AVHD file. By default, this file lives in the same folder as the virtual machine’s .VHD files, but the location is configurable on the property sheet for the VM. An .AVHD file is a “differencing disk”. Changes to the VM’s data (called “deltas”) are written to the .AVHD instead of overwriting or adding to the .VHD. When the VM reads data, it looks at the .VHD and .AVHD(s) for the most recent version. You can create multiple snapshots simultaneously, and the process simply chains among the various .VHDs.
What Are Snapshots Used For? Hyper-V Snapshots are best used when you want to test a change to a virtual machine that might require a complete rollback. For instance, if you are concerned that an operating system patch or an application update might cause problems, you can create a snapshot, install the patch, and then stop the snapshot when you are certain that the update works as desired. Because a snapshot saves the entire configuration of the VM, you can also test such things as changing the memory or CPU or any of the other items in the VM’s property sheet – if you believe that such a change has the potential to result in a permanent negative change to the VM.
I Took a Snapshot. What Do I Do With It? Hopefully, whatever you were testing worked out just fine. In that case, you simply delete the snapshot from within Hyper-V Manager or SCVMM. The next time the VM is shut off, Hyper-V will merge the .AVHD file(s) back into the .VHD. If your change resulted in a problem, then you can revert to the snapshot. When you do that, the machine is restored to the exact condition it was in when the snapshot was taken. If it was powered on then, it is powered on when it is restored. If there was one network card when the snapshot was taken but you added another later, there will be only one when it is restored. If you had two applications open on the VM’s console, they will be open when it is restored.
The Benefits are Fairly Obvious, What are the Drawbacks of Snapshots?
Disk space: for a VM without snapshots, changes directly overwrite whatever is in the .VHD just like they would on non-virtualized storage. For a dynamic VHD, there may need to be some expansion if the changes are only additions, but growth is still typically minimal. For a fixed VHD, bits are changed, but no new space is consumed. For the differencing .AVHD file, growth is much more difficult to predict, but it is certain they will use more than fixed or dynamic disks. If they expand to consume an entire CSV or LUN, the owning VMs (and any others using VHDs on the same CSV or LUN) will pause until the disk has free space again – unplanned downtime. It should be noted that unless you’re already low on disk space, this danger is easy to overstate. Some maintenance required: If you take a snapshot of a VM and then delete it, you’ll need to shut down the VM at some point and wait for Hyper-V to merge the .AVHD(s) back in. The progress can be tracked using Hyper-V Manager. The amount of time this takes is entirely dependent upon the size of the .AVHD(s) and your hardware. Note that if you revert to an earlier snapshot and remove any later ones, Hyper-V deletes those instantly without downtime since they have nothing to merge back in. Human error: With only Hyper-V Manager and SCVMM, there isn’t an “at-a-glance” way of knowing which of your VMs are running on snapshots or have AVHD(s) that need to be merged back in. AVHD growth usually isn’t a meaningful threat unless you completely forget about it. Snapshots should never be used with domain controllers unless you only have one DC in your entire forest. This is because when a DC is reverted (or woken from a saved state), it has no idea that anything happened. It believes that the update sequence numbers (USNs) that it keeps for every object are all completely up-to-date and will being updating them again. If it detects this scenario, it will stop accepting changes and cease participating in replication. That DC will need to be demoted and promoted back in as a new DC. If it doesn’t detect this situation, then there will be mismatched USNs in the domain and Active Directory will not contain consistent information.
Full post here: http://www.altaro.com/hyper-v/why-hyper-v-snapshots-dont-replace-backups/