To back up, or not to back up? That is the question. What do you back up on your Hyper-V hosts, if anything? This came to me from a discussion on Spiceworks recently. The original topic was a different matter, but the challenge I raised was that the Hyper-V host itself doesn’t need to be backed up, if you do Hyper-V well. As an important side note, definitely back up the VMs! You can use Veeam for that, it just works!

But back to the central point of the Hyper-V host itself, does it need to be backed up? In the purest sense, my claim is that you don’t need to back up the host. Here is my reasoning for this approach:

Automation: If you’ve been listening to Microsoft recently, you’ve surely heard that PowerShell is part of your administrative arsenal today. The best part is that getting Hyper-V host information is very easy. Let’s take an example of, arguably, the most specific configuration about your host; the virtual switch configuration. Simply run the Get-VMSwitch PowerShell cmdlet. That’s it! This step is shown in the figure below:


I realize that you may have a more complicated virtual switch configuration, so have no fear! There are additional PowerShell cmdlets that can retrieve host data, in particular any switch extensions that may be in use.

Hardware abstraction from virtualization: This is effectively a “mission statement” type of thing, why virtualize if you are tied to a particular host? I really like the ability to restore or replicate VMs to different hosts. Therefore, anything that would lock a VM’s ability to run on a particular host should be considered heavily.

Migration: Hyper-V makes migration easy. You can migrate directly from Hyper-V Manager to another host. Additionally, Veeam can help with migrations to different hosts, different storage,e and even a different data center with the ability to roll back if the situation changes during your tasks. In all of these situations, the Hyper-V host is simply the platform for the VMs.

Free tools can move what I need: If I do, indeed, have data or other content on a Hyper-V host that must be moved around, I’d recommend the File Copy Job. It comes free with Veeam Backup Free Edition, and is very helpful here. You could set up a scheduled task to run the Get-VMSwitch PowerShell cmdlet and export the contents to a text file. That text file could be the source of the File Copy Job, as well as any configuration files (maybe an .ISO file or two) and moved to a desired location for safe keeping.

Keep it simple on the host. Key host attributes like updates, security membership and more should leverage Group Policy, Active Directory and possibly System Center Virtual Machine Manager. While I realize not everyone uses all of those components, they can provide the central administration that many organizations require. Specifically with System Center Virtual Machine Manager 2012, one of the coolest new features is the Hyper-V host profile. The host profile is a library resource that contains operating system and hardware settings to deploy to a managed Hyper-V host. This is a great central administration framework for the hosts, and of course back up the System Center Virtual Machine Manager server (with Veeam!).

What is your take? Do you back up your Hyper-V host as an entire image or system state backup? If so, why? Additionally, what have you ever had to restore from it? Share your comments below!

GD Star Rating
Hyper-V hosts: To back up, or not to back up?, 3.5 out of 5 based on 11 ratings

View posts related to category:

All Veeam Products Top List
Technology Bloggers on Air
  • Stefano

    Just read that, Rick. But have to admit that I don’t really get your intention. No need to back up host you argue with automation, hardware abstraction etc. I understand that virtualization has to do with automation and hardware abstraction. But still I have the problem of reinstalling and reconfiguring the host in case of disaster, instead of simply restoring it from backup. How does automation and hardware abstraction prevent me from this need?

    • Maximillian Carper

      Stefano, I agree, and have been baffled by that notion ever since I first started hearing it (generally from Veeam employees, of course!) a few years ago. RTO isn’t just important for VMs–it’s just as important for the physical servers that HOST those VMs… so I’ve never understood the whole claim that you don’t need to back up host servers. Installing the OS, drivers, updates, iSCSI targets, MPIO paths, and cluster configuration on a single server generally takes HOURS. If I lost my DAS RAID on a physical server somehow, or suffer some complete server failure that requires me to replace with a (hopefully) identical server, I would like to be able to boot to a recovery program that can restore the host from backup, and be back up in 30 minutes or so, WITHOUT a stressful, high-pressure, race-to-reconfigure experience. And then there’s, of course, the documentation factor. It’s the worst thing when you suffer a failure, and go to reinstall a replacement server, only to realize in the middle that you can’t find some config info you need. A backup solves all of these problems! With all due respect, Rick, I’m honestly curious…have you ever had to replace a mission-critical Hyper-V server (especially one in a cluster, with iSCSI, MPIO, and NICs with VLANs and failover to configure) after a major failure?

      • Habibalby Al Sayed

        Well-said, recovery from a physical server failure with lots of dependencies, its a challenge for IT Admins to be back up and running within the RTO time frame. Where does No need to back up you physical virtualization hosts stands in this?

        • Rick Vanover

          Well, you can run Veeam Endpoint Backup on a Hyper-V hist, just exclude the path of the VMs. That’s an option, but I don’t do it.

      • R.

        I agree. Just test the following for yourself: how long does it take to install a new host vs. how long does it take to restore a host. IMHO it’s a simple question of math. 🙂

  • Matthew Yauch

    It sounds like the idea is to abstract the VMs from the host as much as possible and make it so the host is as vanilla and interchangeable as can be. If you then automate the setup of a host’s software into a fully working state, you no longer need backups. I have no experience doing so, but I believe it to be a feasible and valid goal. Plenty of platforms are built on such a premise.