{"id":4684,"date":"2015-02-17T14:00:41","date_gmt":"2015-02-17T14:00:41","guid":{"rendered":"http:\/\/www.backupassist.com\/blog\/?p=4684"},"modified":"2019-11-07T06:18:21","modified_gmt":"2019-11-07T06:18:21","slug":"should-you-back-up-a-hyper-v-host-yes-no-depends","status":"publish","type":"post","link":"https:\/\/www.backupassist.com\/blog\/should-you-back-up-a-hyper-v-host-yes-no-depends","title":{"rendered":"Should you back up a Hyper-V host? Yes, no, and it depends"},"content":{"rendered":"

\"back<\/a><\/p>\n

In a number of online forums and blogs recently the debate has been heating up over whether or not it’s necessary to back up a Hyper-V host.  There are passionate arguments on both sides, so we thought we’d take the time to weigh in and offer our perspective on the issue.<\/p>\n

Is backing up Hyper-V<\/a> hosts a necessary part of a well-rounded strategy, or simply a waste of time and resources? Well, let’s find out.
\n
\nHere are the arguments for and against backing up the Hyper-V host.<\/p>\n

In the “No” camp…<\/h2>\n

\"hyper-v<\/p>\n

Surely backing something up is better than not backing it up, right? Well, according to one school of thought when it comes to Hyper-V host backups, not necessarily.  The reason for this is that in an ideal Hyper-V environment, there really shouldn’t be anything on your host other than the guests, and configuring a new host for those guests should be a simple process.<\/p>\n

That means that by backing the host up, all you’re doing is backing up data that shouldn\u2019t be there, and configurations that are easy to perform.  Still not sure why this makes host backups unnecessary?<\/p>\n

Well, it’s because in a disaster recovery situation, it may actually be just as quick to re-install the Hypervisor on a new machine and then just restore your backups of the guests, rather than perform a bare-metal recovery of an entire host and guests.  Therefore by diligently backing up your host every time, you’re slowing down your backup process and spending valuable storage space, potentially without any real gains in recovery time.<\/p>\n

From an ideological point of view, the idea of Hyper-V technology is that VMs are independent, and meant to be flexible and easy to restore, migrate, and move to other Hypervisors. The idea that they have been implemented with such a degree of host dependency that you must backup their host as well, just isn\u2019t in line with the flexibility with which VMs are meant to be implemented.<\/p>\n

It’s definitely a valid argument, and many would argue it’s best practice in a contemporary virtualized environment.<\/p>\n

In the “Yes” camp…<\/h2>\n

\"hyper-v<\/p>\n

The other side of the coin is that the configurations, roles and connections setup in the hosts, are important and can take time to implement.  Therefore, they should also be backed up with the guests, by performing a full image backup of the server.<\/p>\n

Often when setting up a Hyper-V host, you’re going to invest a decent amount of time and effort into optimizing it for your environment.  That means setting up various permissions and roles.  It means configuring networking and virtual switches. It means taking the time to ensure complete integration with your domain services.  And let’s not even get into the complexity of some CSV environments.<\/p>\n

In a Disaster Recovery scenario<\/a>, downtime is deadly.  That means that while, yes, you may be able to re-install the Hypervisor just as quickly as performing a bare-metal restore from an image of your host server, how long is it going to take you to reconfigure it to be as it was before the crash?  Do you even have the documentation in place to be able to do that?<\/p>\n

What if you inherited a legacy environment that you didn’t actually configure yourself?  Or, what if you’re on vacation and it’s left to someone who isn’t as technically savvy as you to get things back up and running?<\/p>\n

In these instances, having a complete system-backup of your host so that you can simply recover to bare-metal is going to make life a whole lot easier.<\/p>\n

So take the middle ground instead<\/h2>\n

\"hyper-v<\/p>\n

Wow, what a surprise… The best option may not lie at either extreme of the argument, but somewhere in the middle!<\/p>\n

Arguably the best course is to focus your backups on the guests – after all, that’s where the vast majority of your mission-critical data is going to be – but also take periodic backups of the host as well, so that if you need a bare-metal recovery of an entire Hyper-V system, you have that option too.<\/p>\n

A good middle-ground could be to implement a schedule where you take a weekly, full-metal archive backup that includes the host, and then daily backups of just the guests.  That way, no matter what goes down you have options on hand for recovering your important systems and data as quickly as possible.<\/p>\n

And just for the record, with BackupAssist you can<\/a>:<\/p>\n