What you will learn in this tip: Users of Microsoft Hyper-V have some of the same problems with data backup that VMware users have. Learn the best Hyper-V backup strategy in this tip.
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
Microsoft Hyper-V users have the same core issue with backup and recovery that VMware users have -- physics. When you move 20 or so physical servers into one physical server, many applications work just fine; however, one application does not -- data backup. Backup is a very I/O-intensive operation that likes to take complete control over the CPU, memory and I/O resources of the server. That's why when you back up several virtual machines at one time, physics gets in your way.
One of the secrets to doing this right is to perform the backup at the Hyper-V level -- not at the virtual machine level. A backup application that runs at the Hyper-V level can be cognizant of the underlying architecture of Hyper-V and behave accordingly.
Hyper-V backup and VSS
The challenge of backup at the Hyper-V level is that the file systems on the virtual hard drives in the virtual machines are continually changing -- and you need them to stand still while you back them up. The good news is that Microsoft already has a built-in framework for dealing with this issue, called Volume Shadow Copy Services (VSS). VSS can create a virtual snapshot of these drives and will give your backup system something stable and unchanging while it is backing the system up.
The VSS system consists of three parts: a requester, a provider and a writer. The requester is simply the application that requests that a snapshot be taken. The provider is what will create the snapshot. In a basic system, the provider is the Windows operating system itself, but in a larger system the provider could be a storage system that interfaces with VSS. Finally, each application wishing to be supported by VSS must create its own VSS writer that quiesces that application when it's time to create a snapshot.
For example, the VSS writer for SQL Server will put the database into a special mode prior to creating snapshot. Once the snapshot has been backed up, the requester can tell the VSS writer that the backup was successful, and the SQL Server VSS writer will truncate SQL Server's transaction logs so they don't fill up.
This multitiered architecture of VSS allows the requester to control and back up applications without having to write a separate
Interfacing with VSS is not enough to solve the physics problem of backing up virtual machines.
interface to those applications -- it only needs to know how to talk to VSS. Hyper-V is really just another application running within Windows that can be controlled via VSS. Backup applications wishing to back up Hyper-V simply need to talk to the VSS infrastructure on the Windows server running Hyper-V. The VSS requester will then be informed that a Hyper-V VSS writer is present, and that it should communicate with it.
When requested to create a backup, the Hyper-V VSS writer becomes a VSS requester to the VSS systems in each underlying virtual machine (VM). It finds out what writers are present in each VM, instructs them to do the appropriate thing, and creates a snapshot in each VM. Once all of this has been done, it can create the snapshot on the volume containing the Hyper-V virtual disk images. Once that snapshot has been created, it can tell the backup application to back up that snapshot.
Other Hyper-V backup strategies: replication, CDP and near-CDP
Interfacing with VSS is not enough to solve the physics problem of backing up virtual machines. You also need to employ incremental-forever backup techniques. Full backups, however infrequent, can place quite an I/O load on Hyper-V and its underlying VMs. This is why you should strongly consider using a backup product that uses an incremental-forever backup technique. Replication, continuous data protection (CDP), and near-CDP are all examples of such technologies.
Another feature to consider is the ability to recover both an entire VM as well as individual files within that VM. Both recovery scenarios are very typical, so you want to make sure your backup product supports both image-level and file-level restores.
The most important piece of functionality you must look for in a Hyper-V backup product as part of your Hyper-V backup strategy is full integration with VSS. Once you have that, you should look for incremental-forever backup techniques and the ability to recover individual files as well as an entire VM. Once you have all that, all you need to do is argue over price. Good luck with that.
About this author: W. Curtis Preston (a.k.a. "Mr. Backup") is an independent backup expert and has been singularly focused on data backup and recovery for more than 15 years.