Backing up Hyper-V virtual machines can become complicated once you factor in host data, volumes, domains, disks, VSS writers, services and the resulting issues that can arise. To keep the backups of your virtual machines as simple and robust as the environments themselves, we’ve put together a list of 10 tips for best practice Hyper-V backups.
1. Do not install other roles or applications on your Hyper-V host.
Your physical Hyper-V host server should only have one function, to be the Hyper-V host server. It should not double as a file server, a DNS server or, even worse, an application server. Any non-Hyper-V software and data should be on another physical server or one of the Hyper-V guests (VMs).
If you don’t follow this advice, you can complicate host level backups and affect the stability of the host server itself. Any problem with another role or application on the Hyper-V host can impact the guests. Even something as simple as a patch to an application could require a physical server reboot, and cause an outage for all of your Hyper-V guests (VMs) and the services they provide.
2. Only assign a single role or application to each guest
Each Hyper-V guest (VM) should only have a single role or application. It’s easy enough to make another guest, and dedicated environments are what make virtual machines so great.
For backups, having only one role or application per guest makes it easier to:
- Recover guests and services in a managed way.
- Allocate backup agents and licenses
- Perform granular restores of data inside of Hyper-V guests.
3. Focus on guest only Hyper-V backups
The Hyper-V host provides the platform, architecture and processes required to support and maintain your Hyper-V guests (VMs). Although it’s good to have a bare-metal backup of the entire physical server, backups of just the Hyper-V guests can also be very useful as they contain all the data you need and use less space. For a recovery, you can just reinstall the Hyper-V Server and use the backup to add the guests back. A mix of weekly full-metal archive backups and daily “guest only” backups can provide a good balance.
4. Enable Hyper-V integration services
Backup software can use a VSS snapshot to maintain a copy of data that has changed during the backup, so that all of the data in the backup reflects the data as it was at a single point in time – this is called crash-consistent. Application-consistent means a VSS-Aware application checks its own files in the VSS snapshot to make sure they are correct. For example, information in memory and uncompleted database transactions are included in the snapshot, making it more accurate and consistent. This is critical, especially for applications like Exchange and SQL.
Without Hyper-V Integration Services installed, a guest will not be aware of a backup job running on the host, so you will only get a crash-consistent backup of the guest. When you install the Hyper-V Integration Services on the host, and enable it on the guest, the host and guest VSS writers can work together to create online, application-consistent backups of applications like Exchange and SQL, inside the Hyper-V guest.
5. Run the backup on the Hyper-V host server, not the guest
The easiest way to protect Hyper-V guests is to install your backup software on the Hyper-V host (physical server) and back up the guests from there. This way you can back up multiple guests using the same backup job, and have those guests in a single backup. This will also save money because you only need one backup license. Some backup solutions may require a backup agent on each guest but BackupAssist only requires a single host license.
As long as you have Hyper-V integration services installed, the Hyper-V VSS writer on the host, where the backup is running, can communicate with an application (Exchange, SQL) VSS writer on the guest, so that you have application-consistent backups of all guests – in a single backup.
To learn more about the VSS process, see our virtual shadow copy article.
6. Do not back up a CSV device directly
If your guests use a cluster shared volume (CSV), do not back up the CSV device directly because the Hyper-V Server’s VSS writer will not be involved. Back up the Hyper-V Server so that the Hyper-V VSS writer is used to make application-consistent backups of data on the cluster shared volume.
7. Put the Hyper-V host into a workgroup
This safeguard applies when one of your Hyper-V guests (VMs) has the role of domain controller. If that domain controller guest goes down and the host is on the same domain, you may not be able to log into your Hyper-V Server.
8. Backup the whole volume
When performing a Hyper-V image backup (i.e. BackupAssist System Protection backup), it’s best to back up the whole volume. This can improve the performance of incremental image backups, and it makes the backups faster.
If you follow this best practice, and backup the whole volume, you should have your non-production guests (VMs) on a different volume, so that you can exclude them from the backup. If you mix guest categories or guest files across volumes, both backups and restores become more complicated and less efficient.
9. Keep system and guest data on separate volumes.
The volume you install Microsoft Hyper-V Server onto, and the volume used by the physical server’s operating system, should not be used to store Hyper-V guest data (VHDs). For example, if your physical server uses C: drive, your Hyper-V guests should not. They should have their own volumes, and those volumes should not contain system files, such as the physical server’s swap file.
This is important for performance and to remove conflicts. It’s also important for backups because you want to be able to make “guest only” backups using complete volumes.
10. Use fixed virtual disks
The types of disks you use can have an impact on your Hyper-V host server’s performance and data integrity, both of which are important for backups. For this reason, your Hyper-V host server should use fixed virtual disks. Pass-through disks add complexity and don’t allow VM snapshots or Hyper-V replica, and dynamic and differencing disks add a performance and space overhead. Fixed disks enable better performance and data integrity. This means better backups.
BackupAssist Hyper-V backups
To learn more about Hyper-V backups with BackupAssist, check out our Hyper-V tour, and Hyper-V documentation pages. BackupAssist supports Hyper-V out of the box and, with Add-ons, it can perform granular restores of data within virtual machines and granular restores of mail items from Exchange Servers, within virtual machines.
If you’re interested in a comprehensive list of Hyper-V best practices, beyond the backup space, the following two Microsoft articles provide great tips for Hyper-V 2008 and 2012 implementations.
TechNet: 2012 Hyper-V best practices.
TechNet: 2008 Hyper-V best practices
5 thoughts on “10 tips for best practice Hyper-V backups”
Hi Rick,
was that intention:
“Do not install other roles or applications on your Hyper-V host”
versus
“Run the backup on the Hyper-V host server, not the guest”
I really get headache when I imagine installing an application which will need updates and comes with drivers, services and so on onto a system that is running my customers servers…
Regards,
Stefano
Hello Stefano,
The intention is to avoid running applications (like SQL, Exchange, AD service, DNS) on a Hyper-V host as those applications can add overheads that affect the guests on the host. Another reason is that applications have updates and can have issues that would affect all of the guests.
An exception is the backup software itself because it is part of your Hyper-V implementation. Backup software will have less overhead if installed on the host and provides better functionality when installed on the host. By less impact, we mean if you were to install BackupAssist on every single guest, then you would have to install updates and upgrades for every single guest and also run a separate backup job for each guest rather than just one host level backup.
A host level backup will allow you to include all of the guests in a single image backup, that can be mounted for granular restores using the Hyper-V Granular Restore Add-on.
If you would like to discuss the best way to set up your Hyper-V backups or have any questions specific to your environments, please contact our technical support so they can provide some one-on-one assistance.
http://www.backupassist.com/about/contact.html
Many thanks,
Rick
Ok, thanks for clarification.
I disagree with the reasoning behind putting the host on a separate domain. A domain is an administrative boundary…period. A DC in the same domain on another host or a physical machine will provide continuous access to the domain. Only in the smallest systems would there not be a 2nd DC on separate hardware. And even there, local admin accounts (of which there is at least one), and 2 sets of cached domain credentials (unless disabled by Group Policy), provide access, even if no DC is running at all. Only reason to use a different domain is in very large organizations, if an administrative boundary is desired between hosts and guests. Even at that, granular admin permissions are a better solution for most enterprises.
Hi Jeff,
First of all, thanks for sharing your expertise.
When putting together these tips, we looked at problems some of our customers have, and a lot of customers are small to medium businesses without IT staff. We aimed to provide tips that may help or highlight problems for as many customers as possible. You are of course right that in a lot of environments there will be (and should be) backup domain controllers, and that customers with IT staff and professional networks will find some of the advice unnecessary.
We also think you raise good points that do apply to our smaller customers, and we think it would be more helpful to advise they put the Hyper-V host into a workgroup rather than another domain, if they only have one domain controller.
I’ll update the article accordingly.
Thanks,
Rick
The BackupAssist team