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?

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.

I Understand the Risks, Why Can’t I Use Snapshot for Backup?

The first and best reason not to use snapshot as a backup is because it isn’t even remotely like a backup. A true backup involves some form of duplication. At least two copies of the protected data exist, at least at the time that the backup was made. With snapshots, there is no duplication whatsoever. Only one base .VHD file exists and its deltas exist in one or more .AVHDs. If the .VHD file is ever lost or damaged, that constitutes complete data loss. If any of the .AVHDs are ever lost or damaged, all of the deltas they contain are lost as well.

The second reason is related to the first, and that is that snapshots are an all-or-nothing thing. For instance, let’s say that you use snapshots to track a file server. A user creates a file on Tuesday, deletes it on Wednesday, and then wants it back on Thursday. In a normal backup scenario, you’d access Tuesday’s backup and restore that file. With a snapshot scenario, if you simply revert to Tuesday’s snap, you’ll regain that file but lose everything else that was changed in the interim. You could take a new snap, revert to the old one, copy the file to a different location, and then revert to the latest snap. However, that introduces downtime over a simple file restoration, you’ll be running on yet another snapshot, and someone out there is not going to heed your warnings to not use the file server until you’re done and will save something to the reverted VM right before you switch back to the latest snap – such changes are lost forever.

The third reason chains directly from the other two: snapshots quickly lose value as they age. Because a snapshot is an all-or-nothing situation and doesn’t actually provide any protection of the data, then having a snap that’s a couple of months old is probably not useful. The space consumption and amount of time it takes to revert to a very old snapshot almost always negates any potential value it might have.

The fourth reason is human management overhead. As mentioned under risks, a human being is ultimately responsible for keeping track of which VMs are using snapshots. A backup system is designed to track backups for you. If you have been using snapshots repeatedly on a VM, you’ve probably noticed that the snapshot tree becomes downright cryptic at a few levels; that’s because it wasn’t ever designed with the idea that you’d be using it for long-term backups.

The fifth and final reason, the performance impact, is much lesser than the others but not unimportant. On a VM without snapshots, Hyper-V doesn’t have a lot of choices on where to get the data from. In a snapshot, it’s going to have to sort through the VHD and AVHD(s) to find what it wants. In my testing on a dynamic VHD, the performance impact was minimal and difficult to measure until the AVHD aged for a couple of weeks, but not all environments and scenarios are the same. I have read multiple complaints from users of moderate-to-high usage fixed VHDs that performance on a snapshot was noticeably worse.

What is a Reasonable Approach?

Both backups and snapshots have purpose and usage. Unlike (most) backups, snapshots are taken and reverted very rapidly. They are a good choice for high-risk situations in which the need to quickly revert is high and downtime for a reversion needs to be minimal. The more likely it is that the change will be positive, the more likely that it will take some time for problems to be noticed, and the more likely that problems will not mean complete failures, the more attractive a standard backup approach becomes.

A third, often forgotten option for patch testing is cloning. SCVMM allows you to clone a VM directly. Hyper-V Manager alone doesn’t, but with some care you can export and import a VM for similar results. This allows you to set up a copy of the VM to test patching without risking your production environment at all. The downside is that testing in a controlled, limited access system is never as thorough as the situations that will be encountered in production, but it is so much safer that its usage is highly recommended.

Long-term backups can only be covered by using a dedicated backup system that duplicates the live environment in some fashion. Whether you do this with dedicated backup software or by exporting VMs should be determined by your situation, desires, and budget. No matter what, snapshotting will never serve as a substitute for backup.