8/4/2019 Hyper Disater
1/22
Introduction
Although backing up and recovering a server is often simple and straightforward, virtualizationcan 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 truethan 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 builtin 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-Venvironment. 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 machinebefore 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 uplosing 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 atMicrosofts support policy for
virtualizing Exchange 2007, they specifically say that Making virtual machine snapshots of an
Exchange guest virtual machine is not supported.
http://technet.microsoft.com/en-us/library/cc794548.aspxhttp://technet.microsoft.com/en-us/library/cc794548.aspxhttp://technet.microsoft.com/en-us/library/cc794548.aspxhttp://technet.microsoft.com/en-us/library/cc794548.aspxhttp://technet.microsoft.com/en-us/library/cc794548.aspxhttp://technet.microsoft.com/en-us/library/cc794548.aspx8/4/2019 Hyper Disater
2/22
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 asnapshot will include the database in its current state, data is initially written to database pages in
memory, as a way of reducing Exchange Servers I/O requirements. A Hyper-V snapshot does
not backup the contents of the systems memory, which in the case of Exchange Server could
lead to data loss, an inconsistent database, or both.
Of course thats 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, thedatabase 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 greatway 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 themrecklessly.
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 youfirst 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 harddrive 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 youwould 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 todays 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
machines other files. The virtual hard drive file is frozen, but that does not mean that it is notused. 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.
8/4/2019 Hyper Disater
3/22
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 anupdated 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 machines performance! Fortunately, this performance
impact does not have to be permanent. You can roll the system back to its previous state and thenremove 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.
Part -2
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 machinesthat is presently running. If you look at the column on the right side of the console, you can seethat 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.
8/4/2019 Hyper Disater
4/22
Figure A: The column on the right contains an option to create a snapshot of the currentlyselected 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 clickthe screen capture button, the snapshotting process was already 25% complete.
8/4/2019 Hyper Disater
5/22
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 ofvirtual 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 becausesnapshots are cumulative.
8/4/2019 Hyper Disater
6/22
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 notesregarding 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 machines 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 Nameoption, and you will have the option of changing the snapshots name and
entering some notes about the snapshot, as shown in Figure D. When you clickOK, your noteswill appear in Hyper-V Managers lower middle pane, as shown in Figure E.
8/4/2019 Hyper Disater
7/22
Figure D: The Settings screen allows you to make notes about your virtual machine
8/4/2019 Hyper Disater
8/22
Figure E:Your notes will appear in the consoles lower middle pane when you select thesnapshot
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 portionof the consoles 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 thatyou have taken.
If the operation was a success, then you can just delete the snapshot, and the changes stored inthe 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.
8/4/2019 Hyper Disater
9/22
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 messagethat is shown in Figure F.
Figure F
As you can see from the warning message above, applying the snapshot causes the virtual
machines 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 applythe 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. Thesnapshot 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 machines 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 isassociated with the snapshot is merged with the virtual machine.
Microsoft gives you a couple of different options for deleting snapshots. If you only want todelete 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 clickthe Delete Snapshot Subtree option.
8/4/2019 Hyper Disater
10/22
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 .AVHDfiles 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.
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 ofprotection as a traditional backup, and they can really hurt a virtual machines performance. Thatbeing 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 thehost 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 nothave 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 fewrestrictions 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 outperforming 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.
8/4/2019 Hyper Disater
11/22
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 guestmachines 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 VMcomponents. 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 totalk 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 backupthe 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 completelycomprehensive. 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 backedup; virtual networks.
As far as I know, there is no way to backup your virtual networks. If you ever have to restore theentire 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 haveto 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
8/4/2019 Hyper Disater
12/22
compatible with this particular VSS writer. Although Windows Server Backup (Windows Server
2008s built in backup application that replaced NTBACKUP) is designed to create VSSbackups, 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 theregistry 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 registrymodification, 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, createa new Reg_SZ key named Application Identifier, and assign it a value ofHyper-V. This willregister the Hyper-V VSS writer for use with Windows Server Backup.
Conclusion
advertisement
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 iscritical 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 muchmore in Part 4 of this series.
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 opportunityto talk about these limitations and some workarounds.
8/4/2019 Hyper Disater
13/22
Dynamic Disks
Assuming that you are using the Volume Shadowcopy Service to create an online backup of thevirtual 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 systemstreat 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 haveincluded 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
8/4/2019 Hyper Disater
14/22
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 toallow 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 berelated 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 Backups Recovery Wizard. As
you can see in the figure, we have the option of telling Windows Server Backup that we want torecover Hyper-V, but we cant 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
8/4/2019 Hyper Disater
15/22
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 backupapplication 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 beable 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 backupsoftware 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 machine2. 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 ofHyper-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 specificconditions 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 itcan 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 VSSsnapshot 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 defaultconfiguration, 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 ofseveral 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.
8/4/2019 Hyper Disater
16/22
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
advertisement
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 convincedhowever, 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.
8/4/2019 Hyper Disater
17/22
Part -5
IntroductionIn 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 toWindows 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 backupstrategy. Obviously, thats 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 applicationsthat 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 operatingheterogeneous networks.
Imagine, for example, that the agents for your backup application are only compatible withWindows 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 notcompletely 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 arenot 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 hasno way to prepare itself for the snapshot (which is necessary for protecting the integrity of the
8/4/2019 Hyper Disater
18/22
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 writingthe contents of the virtual machines 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 arent 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 baremetal recovery.
When you perform a full system backup of a physical server, you are backing up the serversoperating 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 atypical 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 machines configuration. Whenyou 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 virtualmachine cant 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 machines 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 youto 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 backupsthat 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
8/4/2019 Hyper Disater
19/22
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 ofcounting 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 operatingsystem. 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 articlethat is backup application specific, I generalized most of the concepts that I wrote about. To thebest 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 ofVSS host level backups, and how you can get around those limitations.
Part -6
Introduction
In my previous article in this series, I talked about some of the advantages to performing VSSbackups 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 prettygood 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
8/4/2019 Hyper Disater
20/22
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 bethe 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 arent 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 thenconnected a tape drive directly to the host server. The problem with this configuration was that
the tape drive was only accessible to the servers parent partition. The virtual machines that were
hosted on the server were not able to communicate with the tape drive. Likewise, the backupapplication 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 purchasean 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 virtualmachines 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 talkingabout.
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.
8/4/2019 Hyper Disater
21/22
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 virtualserver. 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 virtualmachine.
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 servers virtualhard 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 tellsHyper-V which virtual hard drives to use, so windows certainly cant embed the informationwithin a virtual hard drive.
So what does all of this mean to someone who has to recover a failed Hyper-V server? Well, it isnot 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 torestoring 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
advertisement
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 recommendationis to use both methods, but dont 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 andguest 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 cant perform both types of backups.
8/4/2019 Hyper Disater
22/22
Top Related