Managing Hyper-V Snapshots (Part 1)

If you would like to read the other parts in this article series please go to:

• Managing Hyper-V Snapshots (Part 2)
• Managing Hyper-V Snapshots (Part 3)

Introduction

One of the really great features and Microsoft’s Hyper-V is snapshotting. Snapshots allow you to revert an entire virtual machine back to an earlier point in time without the hassles of restoring a backup. As great as Hyper-V snapshot capabilities are however, snapshots can be tricky to work with. As such, my goal in this article is to share with you some practical advice on how to get the most out of Hyper-V snapshots, but without shooting yourself in the foot in the process.

Some Words of Caution

Before I jump straight into a discussion of Hyper-V snapshot management, there are some cautions that I want to share with you regarding the use of Hyper-V snapshots.

Performance Issues

The first thing that you need to know about snapshots is that they should be used sparingly. The main reason for this is that snapshots can adversely affect the read performance on your virtual hard disks. The reason why this happens has to do with the anatomy of the snapshots themselves.

As you probably know, most Hyper-V virtual machines make use of virtual hard disk files. When you create a snapshot you aren’t actually creating a backup of the virtual hard disks. Instead, Windows flags the virtual hard disks as read-only. This ensures that the virtual hard disk contents remain in an unaltered state from this point forward. The other thing that happens is that Hyper-V creates a new virtual hard disk for the virtual machine, and redirects all write operations to this new virtual hard disk.

The reason why this method of snapshot can result in read performance issues is because Hyper-V is smart enough to know that the most recently created virtual hard disk (the one associated with the snapshot) contains the most recently written data. When a read operation is performed Hyper-V first attempts to read the requested data from the virtual hard disk file that is used by the snapshot. If the requested data does not exist on this virtual hard disk then Hyper-V will attempt to read the data from the original virtual hard disk instead.

There usually isn’t much of a noticeable performance hit for virtual machines that contain only one snapshot, but Hyper-V allows you to create multiple snapshots of a virtual machine. Each time a snapshot is created, a new virtual hard disk is created. Long chains of snapshots usually result in significantly diminished read performance. That being the case, it is a good idea to keep snapshot to a minimum and to retain only the snapshots that you really need.

Snapshots Are Not a Backup Replacement

As previously mentioned, Hyper-V snapshots give you the ability to roll a virtual machine back to an earlier point in time. This capability makes the snapshot feature sound a lot like a backup alternatives. However, it is extremely important to understand that snapshots are not intended to serve as a backup replacement.

As I explained in the last section, when you create a snapshot Hyper-V flags the virtual machines virtual hard disk as read-only, and then creates a new virtual hard disk to which read operations can be redirected. Nowhere in the process does Hyper-V ever make a copy of a virtual hard disk. This means that the snapshot and process does not make any sort of backup of the virtual machine.

Is also worth noting that snapshots are usually stored in the same folder as the rest of the virtual machine components. This means that if your host server suffers a storage array failure then you will lose not only the virtual machine, but the snapshots as well.

Snapshots are primarily designed to be a convenience feature. They make it easy to roll back a virtual machine when things go horribly wrong. For example, many administrators will create a snapshot prior to applying a service pack to a virtual machine. That way, if the new service pack causes any problems then there is an easy way to return the virtual machine to a functional state.

You must keep in mind however that applying a snapshot is a virtual machine level operation. In other words, when you apply a snapshot to a virtual machine you are rolling back the entire virtual machine. You cannot use a virtual machine snapshot (at least not a native Hyper-V snapshot) to roll back an individual file, folder, application, or even virtual hard disk within a virtual machine. Virtual machines have to be rolled back as a whole. Granular rollbacks simply are not supported.

Data Integrity Issues

The third bit of caution that I want to pass along is that using snapshots can sometimes cause data integrity issues. Before I collaborate on this point, let me be clear and say up front that Hyper-V does not contain a bug that causes virtual machines to become corrupted once snapshots are applied. From everything that I have observed using snapshots myself, the snapshot component is rock solid. Even so, you can cause data corruption within a virtual machine by using snapshots in an improper manner.

The corruption issue primarily occurs when you snapshot a server that is running a database application. As you saw from my earlier description of the snapshot process, creating a snapshot is a disk level operation. The problem with this is that many database applications hold transactions in memory before those transactions are committed to disk. If you create a snapshot of a virtual server that is running such an application, the application will continue to function normally. The problems occur when you apply the snapshot.

Applying a snapshot causes the virtual machine to use a virtual hard disk that was from an earlier point in time. However, transactions that were in memory at the time that the snapshot was created are lost unless the database application includes support for Hyper-V snapshots. These incomplete transactions and lost memory data can lead to database corruption.

There can also sometimes the unexpected side effects to applying a Hyper-V snapshot even if a virtual machine is not running a database application. One example of this is the Microsoft Exchange Server hub transport role.

For those who are not familiar with Exchange Server, it is Microsoft’s email server solution. Some versions of Exchange Server use a server role called the Hubcap transport for message routing. When you create a snapshot of a hub transport server, you capture the state of that server as it existed at a specific moment in time.

The problem with this is that the hub transport server’s job is to route email messages. At any given moment there are likely to be messages passing through the messaging queues. This means that if you revert a hub transport server to an earlier state by using a snapshot, the messaging queues will also be reverted. This will most likely cause email messages that had previously been sent to be reset, thereby resulting in a great deal of confusion for the recipients.

Conclusion

Although I have spent the bulk of this article explaining some precautions related to using Hyper-V snapshots, it doesn’t mean that you should never use the snapshot feature. Snapshots can be tremendously beneficial when used appropriately. In the next article in this series, I want to show you some techniques that will help you to use snapshots in an effective and efficient manner.

If you would like to read the other parts in this article series please go to:

• Managing Hyper-V Snapshots (Part 2)
• Managing Hyper-V Snapshots (Part 3)