If you would like to read the next parts of this article series please go to:
- Disaster Recovery for Hyper-V (Part 2)
- Disaster Recovery for Hyper-V (Part 3)
- Disaster Recovery for Hyper-V (Part 4)
- Disaster Recovery for Hyper-V (Part 5)
- Disaster Recovery for Hyper-V (Part 6)
Introduction
Although backing up and recovering a server is often simple and straightforward, virtualization can bring an extra layer of complexity into the picture. In this article series, I will discuss your options for disaster recovery within a Hyper-V environment.
Although there are many benefits to server virtualization, there is no denying that virtualization also adds an extra layer of complexity to server management. Perhaps nowhere is this more true than when it comes to backup and restore initiatives. What is even more frustrating is that there is a lot of misinformation on the Internet regarding backups and disaster recovery for virtual servers. In this article series, I am going to try to set the record straight by explaining the various disaster recovery options that are available to you in a Hyper-V environment.
Snapshots
The first subject that I want to address is snapshots. As you probably know, Hyper-V has a built in mechanism that allows you to take a point in time snap shot of your virtual machines. Although snapshots certainly have their place, a snapshot is not a substitute for a virtual server backup.
Over the last several months, I have stumbled onto quite a few Web sites that have said that making a snapshot is the preferred method for backing up virtual machines in a Hyper-V environment. Although a snapshot is not a replacement for a backup, I think that I know where the confusion came from. Most of the backup applications on the market today use the Volume Shadow Copy Service (VSS). The VSS Writer creates a snapshot as a part of the backup process. It is important to understand though, that VSS snapshots and Hyper-V snapshots are not the same thing.
Creating a snapshot in Hyper-V provides you with a quick and easy way of reverting a virtual machine to its previous state. For example, suppose that you were about to install a new version of an application onto a virtual machine. You could create a snapshot of the virtual machine before beginning the upgrade process. That way, if something were to go horribly wrong during the upgrade process, you could just restore the snapshot and your system would be back to the way that it existed before you attempted the upgrade.
Even though this probably sounds an awful lot like a backup, there are some important differences between snapshots and backups. For one thing, snapshots are stored locally on the server. This means that if the server were to suffer a hardware failure, then you might end up losing your snapshots. In contrast, backups are usually either written to removable media or to a disk array on a dedicated backup server.
Another very important distinction between Hyper-V snapshots and backups is that Hyper-V snapshots are not application aware. In fact, if you look at Microsoft’s support policy for virtualizing Exchange 2007, they specifically say that “Making virtual machine snapshots of an Exchange guest virtual machine is not supported”.
So why is that? Well, as I said, Hyper-V snapshots are not application aware. Exchange Server 2007 uses an extensible storage engine database to store Exchange Server data. Although a snapshot will include the database in its current state, data is initially written to database pages in memory, as a way of reducing Exchange Server’s I/O requirements. A Hyper-V snapshot does not backup the contents of the system’s memory, which in the case of Exchange Server could lead to data loss, an inconsistent database, or both.
Of course that’s just one example of why taking a hyper-v snapshot is not always a good idea. Whether your virtual server is running Exchange or something else, you must remember that if you restore a Hyper-V snapshot, the server will expect everything to be the same as it was at the time that the snapshot was taken. For example, if a virtual server is hosting a database, the database application may expect the same clients to be connected to the database as were connected at the time when the snapshot was made.
This does not mean that Hyper-V snapshots are useless, quite the contrary. Snapshots are a great way of hedging your bets against a disaster when you are going to perform a risky procedure. The key to using snapshots successfully is planning for their use rather than using them recklessly.
As I said earlier, Microsoft does not support the use of Hyper-V snapshots in an Exchange Server environment. Having said that though, you can safely make a Hyper-V snapshot if you first dismount the database and stop the Exchange related services. I am not advising anyone to do that, I am only pointing out that if you plan for a snapshot, and use snapshots responsibly, then they can be of benefit to you.
I have previously mentioned some of the reasons why using a snapshot is not a good alternative to a more traditional backup method, but I never really took the time to explain what happens when you create a Hyper-V snapshot.
As I am sure that you probably know, virtual machines running on Hyper-V use virtual hard drive files (.VHD files) instead of physical hard drive volumes. When you create a snapshot of a virtual machine, you are essentially freezing the virtual hard drive file so that you can go back to it at a later time if necessary. The problem with freezing your virtual hard drive files is that you would not be able to use your virtual machines as normal if the server was completely frozen.
To get around this problem Microsoft has designed Hyper-V so that when you create a snapshot, the virtual hard drive is frozen, and a snapshot file is created. A lot of people assume that the snapshot file is a mirror image of the virtual hard drive file, but this is simply not the case. Taking a snapshot only usually takes a few seconds. With today’s technology it would be physically impossible to duplicate a 500 GB virtual hard drive file in a few seconds time.
What happens is that the snapshot consists of a .AVHD file, which is stored alongside the virtual machine’s other files. The virtual hard drive file is frozen, but that does not mean that it is not used. It only means that the virtual hard drive file becomes read only. From that point on, data may be read from the virtual hard drive file, but all writes occur within the snapshot file.
One thing to keep in mind is that having a snapshot means that there are now two possible places in which a file might exist. When Windows needs to read a file, it must first check to see if an updated version of the file exists within the snapshot. If not, then the file will be read from the virtual hard drive file. The implication is that having one or more snapshots of a virtual machine can have a major impact on the virtual machine’s performance! Fortunately, this performance impact does not have to be permanent. You can roll the system back to its previous state and then remove the snapshots, or you can merge the snapshot into the .VHD file. I will show you how to do that and more in Part 2.
Conclusion
In this article, I have explained that although snapshots are not a substitute for a traditional backup, they do have their place. In Part 2, I will show you how to manage snapshots in Hyper-V. Later in this series, I will show you some techniques for performing traditional backups of virtual machines.
If you would like to read the next parts of this article series please go to:
