Disaster Recovery for Hyper-V

[patris1]

http://www.virtualizationadmin.com/articles-tutorials/microsoft-hyper-v-articles/installation-and-deployment/disaster-recovery-hyper-v-part1.html

PART-1

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.

---

موضوعات مشابه:

• Intelligent Disaster Recovery
• A Guide to Exchange Disaster Recovery Planning
• Tips for disaster recovery readiness

---

[patris1]

http://www.virtualizationadmin.com/articles-tutorials/microsoft-hyper-v-articles/installation-and-deployment/disaster-recovery-hyper-v-part2.html

PART-2

Introduction

In my first article in this series, I explained when it is and is not appropriate to use virtual machine snapshots and about how snapshots work. In this article, I want to show you how to actually use snapshots.
Creating a Snapshot

The procedure for creating a snapshot is actually very simple. If you look at Figure A, you can see that I have opened the Hyper-V Manager console, and selected one of my virtual machines that is presently running. If you look at the column on the right side of the console, you can see that it is divided into an upper and a lower section. The upper section contains action items that pertain to the server as a whole. The lower section contains items that are specific to the virtual machine that is currently selected. The third option from the bottom is Snapshot.

Figure A: The column on the right contains an option to create a snapshot of the currently selected virtual machine
When you click the Snapshot button, Hyper-V will begin taking the snapshot. The process does not take very long at all. If you look at Figure B, you can see that by the time I was able to click the screen capture button, the snapshotting process was already 25% complete.

Figure B: It only takes a few seconds to make a snapshot
After you create a snapshot, the snapshot will appear in the Snapshots pane beneath the list of virtual machines. If you look at Figure C, you will see that I have taken two snapshots, both of which are listed in a snapshot tree. The reason why the snapshots are listed in this way is because snapshots are cumulative.

Figure C: Hyper-V displays a list of snapshots in a tree format
Settings

As you can see in the figure above, Hyper-V tells you the date and time when each snapshot was recorded. Although this is helpful, it can be a little bit tough to remember the virtual machine state that is associated with each snapshot. Fortunately, Hyper-V allows you to make some notes regarding the purpose of each snapshot.
To do so, right click on the snapshot that you want to annotate, and then choose the Settings command from the shortcut menu. This will cause Windows to display a screen that is very similar to the virtual machine’s Settings screen. The biggest difference between this screen and the normal Settings screen is that you can not change any of the hardware settings.
Click on the Name option, and you will have the option of changing the snapshot’s name and entering some notes about the snapshot, as shown in Figure D. When you click OK, your notes will appear in Hyper-V Manager’s lower middle pane, as shown in Figure E.

Figure D: The Settings screen allows you to make notes about your virtual machine

Figure E: Your notes will appear in the console’s lower middle pane when you select the snapshot
As you saw in Figure D, the Settings screen gives you the option of renaming the snapshot. You can also rename a snapshot by simply clicking on the Rename option located in the lower portion of the console’s Actions pane.
Using Your Snapshots

As I explained in my first article in this series, snapshots are not intended as a long term backup solution. They exist so that you can make a backup prior to performing a potentially risky operation. Once you have completed the operation and tested the virtual machine to find out whether or not the operation was successful, you need to do something with the snapshot that you have taken.
If the operation was a success, then you can just delete the snapshot, and the changes stored in the snapshot will be merged with your frozen .VHD file. If the operation does not go as planned, you can roll the machine back to the time when the snapshot was made and then delete the snapshot. Performing either of these tasks will return your virtual machine to using a single .VHD file, although you will have to either reboot the virtual machine or put it into a saved state to complete the operation.
Applying a Snapshot

Suppose that you created a snapshot of a virtual machine prior to performing a risky operation. When the snapshot was complete, you performed the operation, and everything went horribly wrong. In such a situation, you would obviously want to restore the snapshot.
To do so, just right click on the snapshot that you want to restore, and then choose the Apply command from the shortcut menu. Doing so will cause Hyper-V to display the warning message that is shown in Figure F.

Figure F
As you can see from the warning message above, applying the snapshot causes the virtual machine’s current state to be lost, which is what you want if the virtual machine has been trashed. You will notice though, that you have the option of taking a snapshot before you apply the snapshot. That way, you can revert your machine to its original state at the time that the snapshot was made, but you have the option of rolling the virtual machine forward to the state that it is in right now.
Keep in mind that simply applying the snapshot does not cause the snapshot to be deleted. The snapshot remains in place in case you want to have another go at the operation that caused the failure to occur. If you want to delete a snapshot, you will have to do so manually.
Deleting a Snapshot

Whether you decide to apply a snapshot or not, you are eventually going to want to delete your snapshots so that the virtual machine’s performance can be returned to normal. The most important thing to know about deleting snapshots is that doing so does not cause data loss. Deleting a snapshot simply removes your ability to apply that snapshot. Any data that is associated with the snapshot is merged with the virtual machine.
Microsoft gives you a couple of different options for deleting snapshots. If you only want to delete a single snapshot, then you should just select the snapshot that you want to delete, and then click the Delete Snapshot option found in the lower portion of the Actions pane. If you want to delete all of the snapshots, then select the top level of the snapshot hierarchy, and then click the Delete Snapshot Subtree option.
When you delete snapshots, the snapshots will disappear almost immediately. Even though the Hyper-V Manager no longer shows the snapshots though, they still exist on disk. The .AVHD files will remain on disk until you either reboot the virtual machine or put it into a saved state. It is extremely important that you do not delete these snapshot files manually from outside of the Hyper-V Manager.
Conclusion

As you can see, working with snapshots is fairly straightforward. Even so, it is important to remember that snapshots are not true backups. In the next article in this series, I will begin exploring some of the other options in order to protect your virtual machines.

[patris1]

http://www.virtualizationadmin.com/articles-tutorials/microsoft-hyper-v-articles/installation-and-deployment/disaster-recovery-hyper-v-part3.html

PART-3


Introduction

So far in this series, I have spoken about creating virtual machine snapshots, and about the advantages and disadvantages of doing so. As you may recall from my previous article, the biggest problem with virtual machine snapshots is that they do not offer the same amount of protection as a traditional backup, and they can really hurt a virtual machine’s performance. That being the case, I want to turn my attention to more traditional backup options for Hyper-V.
When it comes to backing up a virtualized environment, you really have two choices. You can run a backup at the host server level, or you can run a backup within the guest operating system. Of course some organizations use a combination of the two methods.
Backing Up the Host Machine

One of the easiest ways of backing up a Hyper-V environment involves running a backup at the host level. Hyper-V is designed in such a way that you can create VSS based backups of guest machines by running a backup at the host machine level. There are however some things that you need to know if you are going to be using this approach.
The method that you will have to use in making the backup really just depends on whether the virtual machines are running or not. If the virtual machines are all shut down, then you do not have to do anything special. You can simply back up the .VHD files using a standard backup. Of course, if the virtual machines are shut down, then they are inaccessible to the users until they are brought back online.
You can perform a backup even if the guest machines are up and running, but there are a few restrictions that you will have to be aware of. For starters, each virtual machine must have the integration services installed, and the Backup integration service must be enabled. This rules out performing host level backups of virtual machines that are online if the virtual machine is running a non Windows OS, or if it is running an older version of Windows that is not compatible with the integration services.
The second requirement is that the guest operating systems must use volumes that are formatted as NTFS. FAT, FAT-32, and other file systems are not supported. Furthermore, the guest machines cannot be configured to use dynamic disks. The backup will only work if the guest machines use basic disks. Keep in mind that I am not referring to the volume that the .VHD file is stored on. The volume containing the .VHD file can be basic or dynamic. I am talking about whether the guest operating system sees the .VHD file as being a basic disk or a dynamic disk.
Finally, the Volume Shadow Copy Service must be enabled for all volumes that contain VM components. Each volume must be configured to store its own shadow copy data. In other words, the shadow copies for C: must reside on C:. Therefore, each volume must have enough free space to comfortably accommodate shadow copy data.
The Advantages and Disadvantages of Backing Up the Host Server

Now that I have mentioned the basic requirements in performing a host level backup, I want to talk about some of the advantages and disadvantages of backing up the host server. By far the biggest advantage to using this backup method is that it is a catch all backup solution. As such, you can back up the host operating system, the configuration settings for each virtual machine, all of your virtual hard drives, and any virtual machine snapshots that may exist.
The nice thing about this type of backup (besides the convenience) is that it allows you to backup the configuration settings for the virtual machines. When Hyper-V first came out, I backed up some individual virtual machines, but I did not create any host level backups. One day, the host operating system died and I had to rebuild the server. Even though I did not end up losing anything, it was a royal pain having to manually reconfigure the settings for each of my virtual machines. If I had not documented all of my virtual machines I would have been in trouble.
One thing that surprises a lot of people about host level backups is that they are not completely comprehensive. Being that these types of backups include the host operating system, the virtual hard drives, the virtual machine settings, and snapshot data, you would probably assume that you have all of the basics covered. However, there is one major component that does not get backed up; virtual networks.
As far as I know, there is no way to backup your virtual networks. If you ever have to restore the entire server, then you will have to manually recreate any virtual networks that you might have been using. You will also have to manually reattach each virtual machine to the virtual network. That being the case, I strongly recommend that you thoroughly document any virtual networks that you may be using so that you have all of the information that you need should you ever have to recreate them.
The Backup Application

As I mentioned earlier, performing a host level backup of a Hyper-V server requires the use of the Hyper-V VSS Writer. This means that you will have to use a backup application that is compatible with this particular VSS writer. Although Windows Server Backup (Windows Server 2008’s built in backup application that replaced NTBACKUP) is designed to create VSS backups, it is not designed to work with the Hyper-V VSS writer.
If you really want to use Windows Server Backup, then you can register the Hyper-V VSS Writer with Windows Server Backup by creating a registry key. Please remember that editing the registry is dangerous, and that making a mistake can destroy Windows, your applications, or both. Normally I would tell you to create a full system backup before attempting a registry modification, but in this case all you can really do is just be really careful (unless you want to shut down your virtual machines and then make a full backup).
To create the necessary registry key, open the Registry Editor in the host operating system, and then navigate through the registry tree to: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT \CurrentVersion\WindowsServerBackup\Application Support\{66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE}. Keep in mind that you will have to manually create the Windows Server Backup container and all subsequent containers. Once the necessary structure is in place, create a new Reg_SZ key named Application Identifier, and assign it a value of Hyper-V. This will register the Hyper-V VSS writer for use with Windows Server Backup.
Conclusion

Although making host level backups of your Hyper-V server is a fairly good backup solution, there are some major limitations to using it that go beyond what I have already discussed. It is critical that you familiarize yourself with these issues, or you could find yourself facing some serious problems if you ever have to perform a restoration. I will explain these issues and much more in Part 4 of this series.

[patris1]

http://www.virtualizationadmin.com/articles-tutorials/microsoft-hyper-v-articles/installation-and-deployment/disaster-recovery-hyper-v-part4.html

PART-4

Introduction

Although it is possible to create a Volume Shadowcopy Service backup of a Hyper-V server and all of its virtual machines, there are some major limitations that you need to be aware of. This article examines those limitations and discusses some workarounds.
In my previous article in this series, I explained that there are some major limitations to making host level backups in a Hyper-V environment. That being the case, I want to take the opportunity to talk about these limitations and some workarounds.
Dynamic Disks

Assuming that you are using the Volume Shadowcopy Service to create an online backup of the virtual machines on your host server, then the first limitation that you need to be aware of is that your virtual machines cannot contain dynamic disks. It is perfectly acceptable for the host operating system to use virtual disks, but you have to make sure that the guest operating systems treat all of their associated virtual hard drive files as basic disks.
The exact method of checking to see whether an operating system is using basic disks or dynamic disks varies a bit depending on the version of Windows that is being run. Generally speaking though, you should be able to open the Disk Management Console by entering the DISKMGMT.MSC command at the Run prompt within a guest operating system. I have included a screen capture of the Disk Management Console in Figure A for the benefit of anyone who may not be familiar with it. If you look at Disk 0, you can see that it is a dynamic disk. In some cases it is possible to right click on the disk (not on the volumes on the disk), and choose the Convert to Basic command from the shortcut menu.

Figure A: By looking at the Disk Management Console within a guest machine, you can tell whether the guest OS is configured to treat virtual hard drives as basic disks or as dynamic disks
A full blown discussion of the differences between basic and dynamic disks is beyond the scope of this article, but you do need to be aware that there are sometimes serious implications involved in converting a disk. Therefore, make sure that you have a thorough understanding of how the conversion process will impact the server before you attempt to convert a disk.
Restoring Virtual Machines

At the end of the previous article, I showed you how to modify the Windows registry so as to allow you to backup a Hyper-V server using Windows Server Backup. When you read about the technique, you may have wondered why Microsoft did not enable this capability by default. I do not have an official “Microsoft approved” answer to that question, but it could quite possibly be related to one very serious limitation.
If you perform a VSS backup using Windows Server Backup, you can not restore individual virtual machines. The restoration process (at least at the host level) is an all or nothing proposition. You can see a screen capture from Windows Server Backup’s Recovery Wizard. As you can see in the figure, we have the option of telling Windows Server Backup that we want to recover Hyper-V, but we can’t pick any individual virtual machines to restore. If I were to have continued with this restoration operation, all of my virtual machines would have been restored.

Figure B: Windows Server Backup does not allow you to recover individual virtual machines
Keep in mind that this limitation is Windows Server Backup specific. It may not necessarily apply to every VSS based backup application, but you definitely need to check your backup application to determine whether this limitation applies or not.
Another major limitation that you may encounter is that if a virtual machine contains multiple snapshots, then you would not have any trouble making a VSS backup, but you would not be able to restore the backup. Thankfully, there is a workaround to this issue.
The trick to successfully restoring the virtual machine is to manually recover the individual snapshots first. Once you have recovered the snapshots, then you can restore the virtual machine. The exact method that you will use for doing so varies considerably depending on the backup software that you are using. Here are the general steps that you would perform:

1. If the virtual machine is running, turn it off and then delete the virtual machine
2. Perform a file level restoration on the snapshot folders. By default, snapshots are stored in C:\Program Data\Microsoft\Windows\Hyper-V\Snapshots
3. After you have recovered the individual snapshots, then perform an application recovery of Hyper-V. This will restore the virtual machines

A Saved State

One last limitation that you need to know about is that under certain conditions, virtual machines may be forced into a saved state while the VSS snapshot is taken. There are three specific conditions that can cause this to occur.
First, a virtual machine will be forced into a saved state if the guest OS does not support VSS. This applies to older versions of Windows, such as Windows NT Server and Windows 2000 Server, as well as to non Windows operating systems.
The second condition that can cause a virtual machine to be forced into a saved state during the VSS snapshot is the Hyper-V integration services not being installed. Again, this mostly effects older versions of Windows and guest machines running non Windows operating systems, but it can apply to any guest operating system if the integration services have not been installed.
The third condition is that a guest machine will be forced into a saved state during the VSS snapshot process if the Backup (Volume Snapshot) component within the integration services has been disabled.
If you have not really done much with the integration services beyond installing them in a default configuration, then this concept might seem foreign to you. It is really pretty simple though. Although the integration services are usually installed as a single entity, it is actually made up of several individual services. If you want to see these individual services, right click on a virtual machine and choose the Settings command from the shortcut menu. When the Settings dialog box appears, select the Integration Services option. As you can see in Figure C, doing so will cause Windows to display the individual integration services.

Figure C: The integration services are actually made up of several different services
If you look at the figure above, you will notice that the last service on the list is the Backup (Volume Snapshot) service. This particular service must be enabled if you want to avoid putting the virtual machine into a saved state during the VSS snapshot process.
Conclusion

In this article, I have tried to explain many of the caveats associated with making a Volume Shadowcopy Service backup of Hyper-V and its guest machines. After reading about all of these issues, you may be wondering if creating this type of backup is even worth it. I am convinced however, that VSS backups for Hyper-V do have their place. In the next article in this series, I will explain what VSS backups are good for, and why these types of backups should only make up a portion of your overall backup strategy for virtual machines.

[patris1]

http://www.virtualizationadmin.com/articles-tutorials/microsoft-hyper-v-articles/installation-and-deployment/disaster-recovery-hyper-v-part5.html

PART-5

Introduction

In my previous article in this series, I spoke about numerous limitations associated with performing a host level VSS backup of Hyper-V. Some of these limitations are specific to Windows Server Backup, but even more so, the backup process is restrictive enough that you may have been left wondering if perhaps there might be a better way to backup your virtual machines.
I ended the previous article by saying that I was convinced by the advantages of using VSS backups on Hyper-V servers, but that VSS backups should only be a part of your overall backup strategy. Obviously, that’s a pretty bold statement, so I want to use this article to elaborate on why I made it.
Compatibility with Any Guest Operating System

The reason I recommend to use host level VSS backups of Hyper-V servers is that doing so allows you to get around operating system compatibility issues. Most of the backup applications that I have worked with over the years require agents to be deployed on the servers that are being backed up. Like any other type of software, the agents would not run unless certain minimum system requirements are met. This can be a real problem for organizations that are operating heterogeneous networks.
Imagine, for example, that the agents for your backup application are only compatible with Windows Server 2003 and Windows Server 2008. That is fine if those are the only server operating systems that you are using, but you have a real problem if you have any Linux servers or legacy Windows Servers.
The beauty of performing VSS backups at the host operating system level is that the backups do not care what kind of operating system is running on your virtual machines. Actually, that is not completely true. Even though your backup application neither knows nor cares what operating systems are running within your virtual machines, there is a small distinction between the way that some virtual machines are backed up.
If a virtual machine is running an operating system that supports VSS, then the Hyper-V integration services will facilitate the creating of a VSS snapshot of the virtual machine. If the virtual machine is not running a VSS aware operating system (or if the integration services are not installed onto the guest operating system) then a VSS snapshot is still made of the virtual machine. The difference is that because the guest operating system is not VSS compatible, it has no way to prepare itself for the snapshot (which is necessary for protecting the integrity of the backup). That being the case, Hyper-V momentarily hibernates the virtual machine while the snapshot is taken.
Unfortunately, there is a momentary interruption of service while the guest machine is hibernated, but the hibernation and snapshotting process usually happens fairly quickly. The reason why hibernation is necessary is because part of the hibernation process involves writing the contents of the virtual machine’s memory and in some cases even its virtual processor state to a file. This ensures that all of the data associated with the virtual machine is captured during the backup process and that transactions aren’t occurring during the backup, which would cause the backup to become corrupt.
Bare Metal Recovery

Another major benefit to performing VSS backups at the host operating system level of your Hyper-V server is that doing so allows you to perform the virtual machine equivalent to a bare metal recovery.
When you perform a full system backup of a physical server, you are backing up the server’s operating system, applications, data, and the system state. The same thing happens if you perform a full system backup of a virtual machine from within the virtual machine. The problem is that there is more to a virtual machine than there is to a physical machine, and running a typical full system backup from within a virtual machine does not capture this extra data.
So what is the extra data that I am talking about? It is the virtual machine’s configuration. When you create a virtual machine, you must tell Windows how much memory you want to assign to the virtual machine. You must also configure things like the name of the virtual hard drive file, the number of virtual processors to be used, and how you want to connect the virtual server to your network. All of this information is stored outside of the virtual machine, because the virtual machine can’t even boot without it.
My point is that if you are performing a typical full system backup from within a virtual machine, you are missing out on backing up the virtual machine’s configuration. That does not mean that your backup is useless. Certainly you can still restore the backup. You just would not be able to use the backup to completely recreate the virtual machine from scratch.
On the other hand, performing a backup at the host operating system level of your Hyper-V server captures all of the configuration information for each virtual machine, which allows you to perform the virtual machine equivalent to a bare-metal restore.
Backup Application Licensing Fees

These days everybody is worried about the cost of running a business (at least they are in the United States anyway). This leads me to another benefit in carrying out host level VSS backups that many people overlook. Obviously, every backup application is different but most of the backup applications that I have worked with over the years are licensed according to the number of servers that you are backing up. In other words, if you are backing up five servers, then you are typically going to need five licenses.
Many backup applications require you to install an agent onto the servers that you are going to be backing up. The agents not only facilitate communications between the backup application and the server, but they also typically provide the backup application with a handy way of counting how many servers are being backed up, and therefore how many licenses are being used.
When you perform a host level backup of a Hyper-V server, you are backing up multiple virtual machines, but the only agent that is required is the one that is running on the host operating system. If you have a lot of virtual machines, then this can amount to substantial cost savings.
Conclusion

As you can see, there are definitely benefits to performing host level VSS backups of your Hyper-V servers. One thing to keep in mind though, is that in order to avoid writing an article that is backup application specific, I generalized most of the concepts that I wrote about. To the best of my knowledge, the information in this article is accurate for most of the major backup applications on the market, but it is possible that some backup applications may do things a bit differently. With that said, the next article in this series will talk about some of the limitations of VSS host level backups, and how you can get around those limitations.

[patris1]

http://www.virtualizationadmin.com/articles-tutorials/microsoft-hyper-v-articles/installation-and-deployment/disaster-recovery-hyper-v-part6.html

PART-6

Introduction

In my previous article in this series, I talked about some of the advantages to performing VSS backups at the host level. Since I had already discussed the primary disadvantages of host level backups in Part 4 of this series, I want to turn my attention to guest level backups. In other words, I will take this opportunity to talk about the advantages and disadvantages of backing up individual virtual machines rather than backing up your Hyper-V server as a whole.
Granularity

If you have read some of my previous articles in this series, then you may already have a pretty good idea of what some of the advantages and disadvantages are of performing guest machine backups, but I want to discuss them anyway, just to make sure that we are all on the same page.
By far the biggest advantage to guest machine level backups is the granularity that it provides you with. Unlike a host level backup, you are free to pick and choose exactly which files, folders, applications, etc. you would like to backup. Likewise, a guest level backup also provides you with the ability to restore individual files and folders as opposed to forcing you to restore the server as a whole.
Simplicity

Another advantage to guest level backups is the simplicity involved in creating them. I will be the first to concede that some backup applications are anything but simple, but that is not really what I am talking about. What I mean is that from the standpoint of your backup application, performing a guest level backup of a virtual server is basically the same as backing up a physical server. There aren’t a lot of special considerations that you have to take into account just because you are backing up a virtual machine.
Compatibility

One possible disadvantage to guest machine backups is compatibility. I recently saw a situation in which an organization had set up a Hyper-V server with a few guest machines, and then connected a tape drive directly to the host server. The problem with this configuration was that the tape drive was only accessible to the server’s parent partition. The virtual machines that were hosted on the server were not able to communicate with the tape drive. Likewise, the backup application that was running on the host operating system was not Hyper-V aware, so it had no way of reliably backing up the guest operating systems.
License Consumption

One possible disadvantage to performing a guest level backup is that you may consume a lot more licenses for your backup application than you would have had you just performed a host level backup. Most of the backup applications that I have worked with require you to purchase an agent license for every server that you are backing up. Performing a host level backup only requires a single agent (which typically requires one license), while backing up individual virtual machines requires a separate agent for each VM which typically requires (multiple licenses).
No Bare Metal Recovery

Perhaps the biggest disadvantage of performing a backup of individual virtual machines rather than backing up Hyper-V as a whole is that you would not be able to perform a bare metal recovery should it become necessary. OK, I know that there is really no such thing as a bare metal recovery when you are dealing with virtual machines, but let me explain what I am talking about.
Imagine for a moment that your Hyper-V server dies a horrible death, and that you have to completely replace the server hardware. Once you have the new hardware in place your next task is to install Hyper-V and then return all of your virtual servers to a functional state. Easy enough, right? Well, not quite.
The problem with backing up individual virtual machines is that if you have to perform a restoration, your backup software would not recognize the fact that you are restoring a virtual server. While it is true that your backup still contains a copy of the Hyper-V Integration Services, there is more to a virtual machine than the Integration Services and the Windows operating system.
If you think back to the time when you originally set up the virtual machine in question, you will recall that you had to start out by giving Hyper-V some basic information about it. For example, you had to tell Hyper-V how much memory to allocate to the virtual machine, which files would be used as virtual hard drives, where those files would be located at, and how the virtual machine would connect to your network. This (among other information) becomes a part of the virtual machine.
What some administrators do not realize though, is that when you perform a backup of a guest operating system what you are really backing up is the contents of the virtual server’s virtual hard drive files (the .VHD files). The low level configuration information that I mentioned above does not reside on a virtual hard drive. After all, the low level configuration information tells Hyper-V which virtual hard drives to use, so windows certainly can’t embed the information within a virtual hard drive.
So what does all of this mean to someone who has to recover a failed Hyper-V server? Well, it is not impossible to recover a virtual server using guest operating system backups. It is just that the recovery process is going to take longer to perform and it is going to involve a lot more work for the administrator. An administrator will have to manually recreate each virtual machine prior to restoring the individual backups. Of course this is only true in the event of a catastrophic failure. If you only need to recover some individual files then performing a virtual machine restoration using a guest backup is no different than performing a restoration on a physical server.
Conclusion

So now that I have discussed all of the pros and cons associated with host level and guest level backups, the big question becomes which backup method should you use. My recommendation is to use both methods, but don’t do it blindly.
What I mean is that most organizations have to make sure that their backups complete within a specific amount of time (known as a backup window). There is also a finite amount of space available on the backup media. The problem is that if you are performing both host level and guest level backups, then you are backing up most of the data on the server twice. That often means that backups are going to take twice as long to complete, and that they are going to consume twice as much space on your backup media.
Believe it or not, there are some techniques that you may be able to use if you want to perform both types of backups. I will discuss these techniques in the next part of this series, as well as what you should do if you absolutely can’t perform both types of backups.