Best practices for Hyper-V backups

Hello and welcome to this Backup Academy video titled “Best Practices for Hyper-V Backups.” My name is Greg Shields and I’m a MVP with Microsoft, also a senior partner with Concentrated Technology. That’s ConcentratedTech.com. I’ve been asked to come talk with you a little bit about Hyper-V and some of the backup tactics, and even some of the strategies that you’ll go through for backing up your Hyper-V virtual machines and also your Hyper-V hosts as well. Over the next 30 or 40 minutes or so I hope to help you understand what those best practices are associated with Hyper-V, and then some of the backup tools that are out there, some of the tactics that you will go through for actually implementing those tools, and really where you might want to focus your attention so that you can be guaranteed to have a good and successful experience with Hyper-V and backing up those virtual machines.

Now the first question you may be asking is, “Well, who am I?” As I mentioned, I’m Greg Shields with Concentrated Tech. I’ve been doing this Windows IT thing for about 15 years and have run the gamut of IT really, all the way from help desk through administration, engineering and architecture, and I now spend a lot of my time on the road doing consulting, speaking, analysis, and columnist type things. You’ll probably find my work in many of the various magazines and online magazines that you will read related to the IT industry.

Now when it comes to Hyper-V and the virtual machines and the hosts associated with Hyper-V and all this backup stuff that’s involved, you’re probably here listening to this presentation right now because you maybe just simply scratching your head about all the different things that you’re reading in the IT press. Some of those things may not necessarily make a lot of sense. To be perfectly honest, and let’s have an honesty moment here, when it comes to backing up Hyper-V, this isn’t terribly fun. The reason for this is in many ways Hyper-V backups are not really as trivial as they might seem.

A little later on I’m going to talk about some of the architectures associated with Hyper-V and some of the design decisions that Microsoft made that kind of impact why this backup process is sometimes a little more difficult than really it would seem. The reasons for that, there are various reasons. One of the reasons is there are simply lots of locations and lots of things where backup could potentially be located, and there are lots of things that you may want to back up. Your Hyper-V host, for example, requires being backed up, as do the virtual machines on top of that host. Even the files inside those virtual machines are going to need to be backed up with your solution, and well, even the system state if you plan on doing any kind of restores that don’t involve entire virtual machines with their VHD files.

Now what’s particularly challenging, at least with Hyper-V, is that Hyper-V is kind of set aside as being this easy virtualization solution, and if you have a single Hyper-V server, well it can be a very easy virtualization solution. But once you get past the button clicking with the virtualization part of Hyper-V, some of the more architectural elements are actually somewhat challenging. Bad decisions that you make in the beginning with Hyper-V can actually mean that you won’t get the granularity of backups that your operations really needs, when you think about the things that you might need, “I need to grab a file off of VM.” Okay, you need to design your backups to support that. You may need to grab a SQL database or even just a database row out of that VM. So that design needs to incorporate application aware backups as well. I might need to recover an individual email from Exchange, so I have to have an Exchange aware backups. Or I might even need to bring back an entire virtual machine from a specific point in time.

Now the technologies and the tactics you will use for actually bringing back an entire virtual machine from a single point in time are different than the ones that you will use for grabbing a file off of a specific virtual machine. So we have to think up front, because any of the decisions that we make as we implement Hyper-V can definitely impact what we’re going to get down the road.

Now I will suggest that at a very high level, before we get into actually clicking any buttons or looking at anything inside of Hyper-V, I will suggest that your steps in constructing the right backup solution, there really are four. You need to start with determining really what you want to backup. What’s important? What is your scope of backup? Is it file and folders? Is it applications? Is it objects within those applications, like I said, SQL rows, Exchange emails, those sorts of things? Is it an entire virtual machine? So you have to determine what is important to you? Your vendors will tell that you need to be just as aware of files and folders as are you of entire VMs, but maybe you don’t care. So you can make those decisions based off of what you need.

Once you understand what you need, what you want to backup, you then have to determine from where you should back those things up. I say all the time that virtualization improves backups while at the same time it actually makes them a little more complicated. The problem here really relates to this whole notion of perspective with backups. Virtualization introduces this concept that I call perspective in that you can source your backups from various different locations, and where you source those from will give you different types of granularity for the items that you’re going to be able to backup and restore.

Once you determine where you want to source those backups, then there are a couple of decisions that you have to make in terms how you want to back those up. Now, with Hyper-V doing this for really anything over and above just specific files and folders is going to involve needing to understand the Volume Shadow Copy Service. So, understanding backups with Hyper-V means understanding VSS at the same time, and I’ll talk about what that is here in just a little bit.

Once you’ve figured out those three things and only after you’ve figured out those three things the last step is really figuring out with what you’re going to want to backup. What sort of tool are you going to use? You’ve kind of got two things. You’ve got whatever is available on the operating system, the native tools, and then you have these third party solutions that you’ll add over the top. I’m going to show you Windows Server Backup, and then I’m going to let you determine, probably find out for yourself where it’s limitations are.

Now let’s start with Step One. What do you want to backup? Virtualization adds to the list of objects, just the shear catalog of things that could potentially be backed up. So back in the old days we had to think about files and folders and maybe systems state. But now with virtualization, we have to add in, in addition to even applications, objects, and applications, entire operating systems and virtual machines and the host. We have to add the cluster if we have multiple virtual machines that are linked together, virtual hosts that are linked together to equal a cluster. So there are more layers as you can see here to this stack of technologies that are required for us to backup. I can look at the various different colors here and the different blocks that I have, that the applications are going to have to have things that need to be backed up. So is the operating system. Even the hypervisor and the virtual host are going to have to have things that have to be backed up as well. So the spread of what your attentions should be when you are considering backup with Hyper-V is going to be a lot wider than what it was with just simple physical servers.

Now helping you understand why we have to worry about this, I what to spend just a minute taking a look at the Hyper-V architecture. You may have seen these many stacks of graphics before, and what they do is they illustrate the different layers that comprise this virtualization stack, the different technologies that go into that virtualization stack. Then of those technologies, what sorts of pieces of code or what sorts of products are going to actually fulfill what’s needed here inside of what each layer of the stack is.

Now it’s easiest perhaps to explain Hyper-V, because Hyper-V is kind of a unique virtualization solution, by comparing it with VMware and vSphere. With VMware and vSphere, you see here at the bottom, we just have storage. Typically with most vSphere environments, and you'll see the same thing with Hyper-V, not always, but with most vSphere environments you have storage that probably sits somewhere else in the SAN, and you have server hardware that drives the processing of memory needs of that virtual machine. Then installed over the top you have this thing that we think of as vSphere, or ESX or ESXi, that is this hypervisor that also kind of has this little management OS that is not really part of it, but can’t be unlinked with it. Now built into that hypervisor are going to be the device drivers that the hypervisor uses to translate the requests for resources from the virtual machine to the server hardware. Now the virtual machines sit on top, and I can have as many virtual machines as I need that sit on top. So a virtual machine runs through hypervisor to get to server hardware and ultimately on its way to storage.

I introduce the vSphere architecture because I also need to contrast it with how Hyper-V is actually configured. Now if you’ve installed Windows Server 2008 or R2 and you’ve added a Hyper-V roll, you may have been confused about the fact the there was this OS and I added a Hyper-V roll and suddenly I just had the ability to create virtual machines somehow associated with this OS. Now Hyper-V, when you add the Hyper-V roll to a Windows Server 2008 computer, what you’re effectively doing is you’re kind of shimming this hypervisor underneath the operating system, the operating system that used to be the only OS on the system before you installed Hyper-V. You’ve shimmed that hypervisor underneath the OS and elevate up the original OS to create what is commonly called the primary partition. Inside that primary partition, again that’s the original OS on that computer, are going to be your device drivers. Now notice how this is different from the location of those device drivers back with vSphere in that that old OS is where those device drivers are contained, and that old OS kind of sits at the same level almost as the virtual machine. So each additional partition on top of that hypervisor is a virtual machine, and it uses, it shares the device drivers that the core OS use. So this architecture is somewhat different than vSphere in that where you’re going to be positioning you backup clients may be just a little bit different.

Understanding this architecture also helps you answer that first question, which is, “What do you want to backup?” Once you’ve figured that out, once you understand what it is that you want to backup, the next step really is determining, “Well, where do I need to go? Where do I need to apply some sort of backup agent in order to gather that kind of data?” If I need files and folders inside of that virtual machine, well do I need to put an agent inside that virtual machine? If I want to grab the entire VM, well I can’t put an agent in the VM if I want to grab the entire VM as one VHD file. So we think of this concept of perspectives as an easy way for you to understand where are the different areas in this virtualization stack where I could potentially install some sort of agent to back up the data that I need.

I will submit that there are kind of four general perspectives when it comes to virtualization with Hyper-V. Up here at the top, I have essentially backing up virtual machines, just like traditional physical servers. This is really no different than as if that virtual machine were a physical computer. I could also backup those virtual machines from the host’s perspective as well. So instead of maybe being in that virtual machine and looking down at all the different files and folders, instead I’m installing that agent to the host looking up at all the virtual machines and all the VHD files that make up those virtual machines.

Now, in addition to whether or not I put the agent in one place or another, I have to backup the host itself. I may need to restore that host because the host fails. So I have to backup the host configuration as well. I also have a fourth perspective, which exists at the level of the storage, that black box that we saw in the previous graphic down there at the bottom underneath all of the server hardware. Now the perspective of the storage, it can look at perhaps the virtual machines in a different way than it can if I've put that client, for example, on the virtual host. So I have these multiple different perspectives which I can install my agents to.

This whole notion of perspective drives the different locations where you could potentially install that backup agent. Now, just in your mind, just think for a minute about all the different places where you might potentially install some sort of backup agent that would collect all that data. The first place, you might think, “Well I’m moving to virtualization, Gregg, and this is great so I want to be able to install that agent onto the primary partition. As one of the primary device drivers, I can, from that agent, look up into the virtual machine, grab that one VHD file that corresponds to the virtual machine’s C-drive, stick it off on a tape or disk, and I’m good.” Now this is a great desire, because if I have that single VHD file that is that virtual machine, well then if I lose that virtual machine, then I can at some point in the future come back and actually restore that virtual machine back to a single point in time.

Now depending on what that agent is, however, if I’m sitting in this primary partition – remember I’m now installed into the host OS and not the guest OS – and I’m sitting in there and if I’m not well instrumented enough, then what processes would I have to go through if I’m not interested in the entire virtual machine, but instead just one file on that virtual machine? Maybe I didn’t lose the VM, but maybe Stan from accounting lost his spreadsheet again. He calls up and says, “Hey, I need to get that spreadsheet.” Well, what sorts of steps are you going to have to through if you install that agent into that primary partition and it is not well instrumented and you need to go and grab a file off of that virtual machine? Well, all you have is a VHD at this point. So your restore process might involve bringing down the VHD and then opening it up through some sort of tool, and then grabbing the file, and then getting rid of the VHD, and wow that’s a lot of extra steps. So depending on what tool you use, an agent in the primary partition gets you some things and it may cost you some things as well.

Now I could actually solve this problem by installing agents inside the virtual machine. There are a lot of organizations today that actually install their backup agents just like they normally have, and probably because they’ve P to V’d their virtual machines from the physical host and never thought to adjust where their agents are installed. They may still have the agent inside the virtual machine, so they’re grabbing the gazillion files that make up a Windows OS, one file at a time and dropping it onto disk or tape. There’s nothing really wrong with doing this. You may incur some performance issues if you’re doing this, particularly if you’re doing all of the virtual machines all at once on a host. But you’re not getting those single VHDs. You’re not actually getting any of the benefits of virtualization. If I install an agent inside that virtual machine, it’s just as if I were a physical computer, and I’m not enjoying that quick ability to restore a computer if it should die. So I get some things and then I also have to pay some things as well.

Now there’s a third perspective here, and that is way, way, way down at the bottom in the storage layer. Your storage vendor may provide some sort of backup solution for you that allows you to take the virtual machine, and maybe even the contents of the virtual machine because they’re sitting on storage, and roll that off onto disk or tape somewhere. So putting that agent inside the storage layer can be good as well. Yet doing so at the storage layer means that the storage may not necessarily, again, unless it is well instrumented, know what is going on at the physical hardware layer and at the hypervisor layer for it to grab the things that it needs out of the virtual machine. So being that far away in the stack can be a good thing because it’s right there, but it could also potentially be a bad thing if I’m not doing a good job of understanding, “Is this virtual machine being used, and I’m only going to back it up and maintain its consistency?” So the storage layer, again, is another potential option for you, but well maybe not the option that you’re looking for depending upon what you need.

There is a final location here too, and this location becomes really important as you move from just a single Hyper-V server and you move yourself into the multiple Hyper-V server arrangement. Here I’ve got six representations of Hyper-V servers with all of the virtual machines sitting on top, and they’re all talking to the same central storage SAN device. Well, then I have some cluster services there, and maybe I install the agent so that it is in some sort of cluster aware location, that it can work with the storage and work with those hosts and their virtual machines, so that it has all of those synchronization pieces in place. So your determination about which solution you chose is going to really need to be based on where you want that agent to be located – in the virtual machine, on the host, in the storage, or cluster aware, somewhere in your infrastructure that has awareness of the cluster in its entirety.

Now what’s interesting about all of this is the fact that some of these perspectives simply cannot deliver the types of results that you may be looking for based off of your answer to the first question. Remember that the first question was, “What do you want to backup?” Now if you’re looking for better granularity, if you’re looking for files and folder, well there are some perspectives that, as I said, are going to make it a little more difficult for you. There are some other perspectives that are going to actually improve the granularity. There are some perspectives where it is going to involve more effort for you to actually get that single file as opposed to a complete virtual machine or vice versa. So determining what level of granularity of the data that you want – files, folders, applications objects, applications, entire virtual machines, entire clusters – will help you determine which of those perspectives. Hopefully you have an idea now of the different perspectives and the different agent locations that may or may not facilitate those perspectives.

Some of those perspectives simply cannot deliver on what you want to backup, so you have to kind of take an architectural view of how you want to backup your Hyper-V environment so that you can get the right perspective, and you can ultimately find the right product that delivers on that perspective.

So at this point you understand, probably, what you want to backup, and you probably have an idea from where it might be a good idea to backup that stuff. Well, the next thing is really understanding how you want to backup. I mentioned earlier that backing up files and folders is really easy. It’s never really been that difficult. You just backup the file and folder. You take off of the server and you put it on a disk or tape. Well, doing anything else, applications, application objects, virtual machines, clusters, what have you, requires the assistance of the Microsoft Volume Shadow Copy Service or VSS. You probably played with VSS before. VSS was originally created so that it could put together these volume snapshots. Remember the previous Versions Client, if you haven’t implemented it. That previous Versions Client was a mechanism whereby your users could actually go and restore their own documents if they accidentally overwrote them or deleted them. So they wouldn’t have to come to you and ultimately to the backups. Now VSS has gone very far in improving that whole experience because of this whole snapshot approach that it does to the file system and quiescence of that file system – we’ll talk about that here in a second – that is necessary for you to be able to actually backup Hyper-V.

So VSS is now a major component of all application aware backups because VSS is necessary in order to tell those applications, “Well, just hold on for just a second. I’m about to gather the backup that I need.” So in a way VSS is sort of the enabler of how you do this backup. Now VSS is a Windows service. It interacts with installed applications, and it really does three things.

It starts by letting the applications know that a backup is about to occur. In the case of Hyper-V, that application is, well, Hyper-V. So the virtual machines are going about doing their whatever it is they do, operating, having a nice day, doing whatever it is that they have queued up as the activities, and when the backup needs to occur, well the backup application tells VSS, “Hey, I’m about to start a backup. Go ahead and kind of pause things. Then let me take the backup. Then I’m going to let you report back to me when that backup is complete, and ultimately let any of those other applications Exchange SQL or Hyper-V, let them know that if there are any post backup tasks that are required, well go ahead and do those.”

VSS’s primary job is to facilitate what is called the quiescence or the quieting of the file system. For you to be able to take a backup, whether it’s Hyper-V or anything, you have to have this period of sort of no activity that occurs. During this period of no activity, that creates kind of a point in time whereby the backup can start from, gather all the stuff it needs to, and then roll the incremental changes in at the very end. So the first job of VSS is quiescence in that it coordinates backup jobs with Hyper-V so that the virtual machines can get backed up without being corrupted. If it I didn’t have VSS, then I might start the backup and that virtual machine might change a little bit between the beginning of the backup and the end of the backup. It’s almost guaranteed that it will. Then my resulting backup will end up corrupted. So the second job is coordinating Hyper-V, the other applications, the data, and then the backup applications. So this is ultimately the role of VSS in Hyper-V backups. I bring this up because, as I mentioned before, you have to understand what VSS is for you to understand how it impacts Hyper-V.

VSS is used anytime you have a transactional based application, and whether you be Exchange, SQL, Active Directory, Oracle, Hyper-V, or any of the transactional based applications, they will have a little piece of code that they inject onto the system to make it VSS aware. Now a virtual machine, a Hyper-V virtual machine is in a way a transactional based application. That VHD file that is the virtual disk for that virtual machine, it’s kind of like a database, right? So in order to be able to backup that constantly adjusting database, I have to have this quiescence in order to do it. I can think of these VHD files as these little transactional databases, and invoking VSS allows me to essentially pause those transactional databases, just like Exchange and SQL, so that I can gather the backup correctly.

Now there are three components that make up VSS. I don’t want to spend a lot of time here because I know that there’s another Backup Academy video that’s going to talk about VSS, but the Volume Shadow Copy Service combines three different components together on a single server to accomplish this goal. On the right-hand side, we have what we call the requester and that is essentially your backup application. If you’re using Windows Server Backup, then Windows Server Backup will be the requester. The requester will work with the provider, which is essentially either your operating system or whatever your storage array is, the storage piece of all of this. It will tell the writer, which is installed onto your operating system, it will tell that writer that a backup is about to begin, go ahead and do whatever needs to be done before the backup. It’s going to complete the backup, and then it’s going to let it know, “Okay, well I’m done, go ahead and finish whatever you need to do.” We have to have this kind of extensibility here with Windows because Exchange, SQL Server, Oracle, Hyper-V, or whatever, each one of those is going to have some different set of activities that are required for this backup to complete successfully. By breaking apart these three things, I now do a better job of allowing multiple different backup applications – because remember there’s more than one backup app out there – work with multiple different kinds of installed applications across multiple different kinds of storage. That’s really the reason for breaking it apart in the way that they do.

When we add Hyper-V to the mix, things get a little more complicated. So I have the original sort of triumvirate down here at the bottom, and on the host, everything here on the bottom half is really the host, and at the host the Hyper-V writer, the VSS writer here is the Hyper-V writer. So when Window Server Backup or whatever your backup tool is goes to the host, the agent is installed on the host, and it says, “Hey look, I need to a backup.” What it’s going to do is it’s going to instruct that Hyper-V writer there on the left to go ahead and pause the virtual machines. Now inside of those virtual machines there’s going to be another three-part Volume Shadow Copy Service, because remember in Hyper-V the host and the guest are sometimes the same operating system. So inside of that virtual machine, let’s just assume that it’s Windows Server 2008 or R2 also, and maybe it’s got an Exchange server on it. Well another job of this whole infrastructure here is so that the Hyper-V writer can let whatever VSS writers are inside the virtual machine know that the backup is taking place so that they can pause themselves inside the virtual machine as well. Remember when we were talking about the different positioning of those agents. Well this is an important difference between whether you would put the agent inside the virtual machine or whether you would put the agent here inside of the host.

Now not withstanding how you install Hyper-V, there are going to be a number of different ways in which you can actually manifest its disks. You’ve probably heard of the different types of disks that Hyper-V has. We have these fixed size VHDs, and we have these dynamically expanding VHDs. So a fixed size is I give it a specific fixed size, and then it never changes. Dynamically expanding is I give it kind of a maximum, and it just grows to that level. Well, both of those are useful if I want to consolidate all of that data into a VHD file, but there may be some sort of applications that I might not want to actually encapsulate into a VHD. So for those I can connect them to the host and then pass them through to the virtual machine. These are called pass through disks.

Another type of disk is one that uses iSCSI directly into the virtual machine. Now these are a little lower performing, but it’s a little easier because there’s a little these orchestration that’s involved. But an iSCSI direct disk actually plugs an iSCSI connection, not through the hypervisor and not through the physical hardware, but directly from storage to virtual machine.

Now these are the different types of disks that you can have in a Hyper-V environment, but different types of disks are going to require different backup approaches. I’m going to tell you some of the gotcha’s here in just a little bit, like the fact that pass through disks may not get backed up directly or that iSCSI direct disks may not get backed up directly by the VSS writer. So you have to be kind of conscious about which disks you’re going to use, and you’ll find out here in just a minute why you might want to use different disks for different reasons. Fixed size disks, dynamically expanding VHDs, both of them fully supported by VSS; some of the other ones, not so much. So the perspective you chose for which backup location you want to put your agent is going to be impacted by which disks you need to select.

We now have an idea about how this backup thing works. VSS is really kind of the way in which all if this is enabled. So we’ve started with understanding what do we want to back up, and then we know, based off of that, where do we need to position our agents, and then based off of that, how is VSS sort of worked into the mix. The last piece we have to figure out then is, therefore with what you want to accomplish that backup. So your options are limitless. You have Windows Server Backup, which is built into Server 2008 and R2, and you have pretty much everything else. So you can choose the tools that are available on the system, or you can go to someone else for other tools.

I’m going to show you here what Windows Server Backup looks like, and I’m just going to show you a quick demo of what it looks like. Windows Server Backup is a tool, and it provides some of the abilities that you may need. You may find it to be a little idiosyncratic, but Windows Server Backup is an option for you. Now Windows Server Backup is indeed Microsoft’s native solution for backing up Server 2008, R2, and Hyper-V. You install Windows Server Backup by going to the server manager’s screen and right clicking features, and adding the Windows Server backup features. I’m not going to show you how that works. You know how to install features at this point. But it is a disk to disk backup solution. It is designed for small environments, limited uses, and its biggest limitation is the fact that it’s really focused on single server. If I have one server, well then Windows Server Backup might work just fine for me, but as I move past a single server into clusters of servers, then Windows Server Backup really starts to choke on some of those configurations. Windows Server Backup also has a focus on disk volumes. It is predominately focused on, if you want to backup virtual machines, then you’re going to have to backup the disk volume where those virtual machines are. You can’t just backup the VHD file. You’ve got to backup everything associated with that virtual machine. So at the end of the day, you’re backing up a lot of stuff.

Now Windows Server Backup does not easily restore virtual machines or individual machines directly. There is no real direct restore ability for virtual machines, nor is there direct restore ability for files. I can actually restore a volume of VMs and then grab the one I want and then grab the files off of it, but there’s no way that I can go into Windows Server Backup and click on Stan’s accounting spreadsheet and expect it to quickly arrive to me. The same goes with application objects. There is no real direct restore ability for application objects. I can backup applications, and the objects in those applications will get backed up, and I can restore them from an entire machine perspective and ultimately grab what I need. But the real easy “I just need one email” sort of use case that I think you probably want, well, that’s probably not going to be a solution you’re going to get out of Windows Server Backup.

In order to get Windows Server Backup installed, as I said before, you’ve actually got to go through and install its feature to your Windows Server host. But what a lot of people don’t realize is that installing that feature to your host does not necessarily register the Hyper-V VSS writer. Now here is the long list of things that you need to do. But in short, what you need to do to go to the Current Version registry key and then add in a series of keys, the Windows Server Backup key, followed by the applications support key, followed by that very long GUID, followed by Application Identifier, and then ultimately add the Hyper-V string value to the application identifier. So that’s what you need to do in order to register the VSS writer with Windows Server Backup.

This is a picture of what that might look like. Here you can see we are going to HKey/local machine/software/Microsoft Windows NT/current version and then Windows Server Backup/application support/really long GUID/application identifier, and then Hyper-V. So this is what you have to do in order to get Windows Server Backup just simply registered and aware of Hyper-V, that little VSS writer that we talked about before.

Once I’ve gone through all of those steps, as you can see here I have my Hyper-V manager here. This is Server 3. I’ve got one virtual machine that’s currently running on this server. What I have here is essentially a copy of Windows Server Backup. Now you may be asking at this point, “Well, Greg, why did you wait until this long to actually show me the demo for Windows Server Backup?” Honestly, there’s not that much to see here. I’ve got three different backups. Here’s all three that actually occurred today. If I wanted to create another backup, I would go here under “Action” and then “Backup Once” or “Backup Schedule.” If I chose “Backup Once,” I could essentially backup the server one time. If I wanted to, I could also create a schedule for backing up that server as well.

Now what’s interesting is that when I go through and create a backup schedule here, Windows Server Backup really likes to use a direct, dedicated piece of hardware, maybe it’s a USB drive or just some sort of volume that it can associate with the backups for this computer. This is particularly the case in the Backup Schedule Wizard, because it’s going to use that volume and incrementally add in all the changes as they are necessary. So when you are configuring Hyper-V or whatever, you’re getting ready to do backups with Windows Server Backup, be prepared that although you can do individual one-time backups to a remote file location on some other disk, it’s going to overwrite that file every time it tries to do the next backup. So creating a backup schedule really needs to focus in on associating that backup schedule with some sort of configured device. You’ll see here I’m doing a once a day full sever backup here to a hard disk that is dedicated for backups.

Once I’ve done that, it will begin the process of actually going through and doing all the stuff that backup solutions do, and eventually someday I may need to actually go through and restore a computer. Here’s where things really get kind of itchy, particularly with Hyper-V. Now you’ll see here under “Recover,” I can go through and recover a backup that was stored either in another location or that is plugged in directly into this host. Remember, as I said, we’re looking for dedicated volumes most of the time with Windows Server Backup. I’m not going to go through all of this list to show you all of the recovery stuff. There are some idiosyncrasies associated with how you’re actually going to recover your virtual machines. For example, recovering individual virtual machines is not the trivial experience that I think you are probably looking for, and trying to get individual files off of those virtual machines, well, it’s just not there. So recovering virtual machines with Windows Server Backup is not a terrifically easy thing to do.

Part of the reason for that is that Windows Server Backup in order to be able to gather the virtual machine files it’s actually going to need to backup all of the volumes that are hosting those VM files. So if you remember kind of your advanced Hyper-V, there are these VM configuration files and then there are the VHD files. If you put the config files in one location and the VHD files in another, then you’ve got to back them both up, not just the individual files, but the whole volume. WSB can either dedicate that drive to the backups, or if you don’t decide to dedicate that drive, it’s kind of like being punished. It’s going to overwrite the previous backup every time you launch a new backup.

Windows Server Backup also cannot restore individual virtual machines. I can’t just go and point at a VM and say, "Okay, I want that VM." I’ve got to restore the volume associated with that VM. If I make the – I don’t want to use the word mistake – but if I turn on cluster shared volumes, which is one of the new features with Hyper-V in R2, well those can’t be backed up by Windows Server Backup. I have to use some other solution that is cluster shared volumes or CSV aware.

Also VMs that contain two or more snapshots are not going to be automatically restored by WSB. It’s simply going to just skip over them. Now there is some manual intervention you can do to restore those snapshots. You can go through and actually restore the specific snapshots to a different location and then copy them over, but this is not something that is going to be automatic for you.

VSS itself has some idiosyncrasies as well. I mentioned how those disk types can impact the backups. Well, pass through disks, these disks that are connected to the host and then pulled or passed through into the virtual machines, well they can’t be backed up by the Hyper-V VSS writer, nor can iSCSI direct ones. So if I create a pass through disk, one of these great disks, it doesn’t mean I have to encapsulate things into the VHD format. Well, I can’t actually back it up, and if I do iSCSI direct, I can’t actually back it up. I can actually back up things if I have an iSCSI LUN that’s attached to my primary partition. So if I plug it into the primary partition, I can back it up from there, but not inside of the virtual machine. If I happen to make the mistake of creating a dynamic disk, well that virtual machine is going to have to be backed up offline and not online. So stick with the basic disks, or Windows Server Backup is not going to give you the experience you want because you don’t want to have to power off those virtual machines to male them work.

Now, VSS has a couple of different ways in which it can go about backing up things. The least painful way is the way, as you would think, it will actually backup the virtual machine without actually losing any uptime. No downtime will be experienced by that virtual machine. If the virtual machine does not however meet the necessary requirements of VSS, well then it reverts back to this other type of backups called saved state backups. A saved state backup essentially occurs when a virtual machine doesn’t meet VSS requirements. Maybe it’s missing integration services, or they’re broken, or they have an operating system that lacks support for VSS, like Windows XP or Windows 2000. Now the saved state downtime occurs when that snapshot is being created. So as the snapshot is being created, then I have to put myself into a saved state to create the snapshot, come out of saved state, and then I can continue the backup. So it’s a period of downtime, but it’s a period of downtime you want to avoid.

At the end of the day, Windows Server Backup, well, a great try on the part of Microsoft, but really there are quite a few of these really necessary functionalities that Windows Server Backup really kind of got wrong. So there is an entire third party solution ecosystem that has developed in order to support Hyper-V because your environment is probably more than one Hyper-V host and you probably need do more granular backup and restore, and you probably want better RTO these days than yesterday’s backup. If I lose that VHD file and I can restore it to yesterday, well that’s just not that great.

The solutions that you want, the solutions that you should be looking for today in order to support Hyper-V backups, you’re not necessarily going to find them directly on the operating system. They will typically interact with VSS. They’re going to have to because VSS is there in order to do the quiescence, but these are solutions that do change block tracking, and they deduplicate and they compress the data when they’re going from disk to disk. The ones that you’re really looking for are the ones that take all of this complexity associated with these perspectives and consolidate them down into a single experience for restoring data no matter whether it’s files or folders or application objects or entire virtual machines, and a single experience or solution for backing up that data no matter what its disk type is, no matter what its connection, no matter what its location is. Really, at the end of the day, what you’re looking for is a solution that brings you dead simplicity because you’re really not going to get that out of Windows Server Backup alone.

Hopefully over the last few minutes I’ve given you a little bit of understanding, a little bit more education, a little bit more awareness about some of the best practices associated with Hyper-V backups. The native tools are probably not going to be enough if you are anything more than a very small environment, probably a single server environment. But more so than just that wag the third party ecosystem is a recognition that there are lots of different perspectives out there for backup, and the things that you want to do, the types of data that you want to backup are going to determine which of the perspectives that you need to be aware of and ultimately which solution you need to find.

Again, my name is Greg Shields with Concentrated Technology. I want to thank you for spending a few minutes with me in this Backup Academy video talking about best practices for Hyper-V backups.

Thank you very much.