Although the Hyper-V environment provides quite a lot of technologies of high availability and fault tolerance for running virtual machines (such as failover clusters, Live Migration, replication, etc.), an administrator must implement traditional ways to back up virtual machine instances. All these technologies can minimize the VMs downtime in various scenarios, but do not provide any disaster recovery options due to human errors, hacker or virus attacks, competitor attacks or similar circumstances. In this article I will try to review the basic requirements for Hyper-V backup solutions, backup strategies and the features of free and commercial backup products.

You can backup virtual machines running on the Hyper-V host using the built-in Windows Server Backup features (or wbadmin scripts based on it), as well as other free or commercial products. All of them are using snapshot (checkpoint) technology to backup running Hyper-V VMs. A checkpoint is a state of a virtual machine at some point of time. The checkpoint stores the state of virtual disks, the contents of RAM, as well as the settings of a VM.

How Does the Hyper-V Virtual Machine Backup Work?

Let’s consider the operation scheme of any modern Hyper-V virtual machine backup solution.

The backup tool instructs the Hyper-V host to create a checkpoint. After receiving the command, the hypervisor creates some new files (delta files) and the VM goes on working and starts saving changes in the files. Now the backup tool must copy the original VM files (no changes are written to them) to the backup media and then delete the checkpoint. When deleting the checkpoint, Hyper-V consolidates (merges) the original and delta files, in the meantime the VM goes on working. If you lose the productive VM, you will be able to recover its state at the point of time when the backup was created.

Hyper-V VM Backup Best Practices and Requirements

This is general information about the Hyper-V backup, but actually, there are a ton of nuances and issues. I will try to list the most common problems:

1. The longer the backup tool is copying the checkpoint (backup), the more changes are logged in the delta files. If there are many changes in the VM while the checkpoint is being copied, merging files after deleting the checkpoint may high load the storage subsystem, the Hyper-V host, and the VM itself. It means that it is better to copy the checkpoint as quickly as possible. In Hyper-V Server 2016, the Resilient Changed Tracking (RCT) technology is used to make backup faster due to copying only the blocks of data changed since the last backup. Thus, you do not need to copy the VM as a whole.
2. When copying the VM checkpoint data over LAN from the Hyper-V host to the backup storage, the network may be highly loaded. So it is better to use a separate server network or HBA interface for the backup traffic or copy the data over SAN.
3. Based on the points described above, when using external data storage to store VM files, you can use the features of data storage integration with the backup product (such a hardware snapshots).
4. Originally, the guest OS does not know that it is backed up. So when trying to restore a VM from that backup, the OS tries to continue its operation since the moment the checkpoint has been created. In some cases, it may result in some issues in the OS itself and losing data in the running apps (especially in transaction ones, like Exchange, SQL, ADDS, etc.). To solve this problem, a new checkpoint type — Production Checkpoints appeared in Hyper-V 2016. (Microsoft recommends using Standard Checkpoints only in test or laboratory environments or to backup stopped VMs.) The production checkpoints are working due to Hyper-V integration tools in the guest OS and are based on Volume Shadow Copy (Windows) or file system freezing daemon on Linux (fsfreeze). However, the state of the memory is not copied. It means that Hyper-V notifies the guest OS of creating a checkpoint, the app supporting VSS consolidation ends up the current transactions, goes into a consistent state and the VM checkpoint is created. When recovering from a checkpoint, the guest OS is powered off (since the memory state has not been saved), and after being turned on it thinks that an emergency shutdown has occurred. The app (if it supports VSS) starts working from the saved consistent state.
5. To store virtual machine backups you need quite a lot of space. The more often you make checkpoints, the more place you need in the backup storage. Typically, you can use the Data Deduplication technology (integrated into Windows Server) or the deduplication solution from the backup provider. If you are using differential disks, choose the backup tool that supports this technology. Otherwise, you can store the same VM data several times.
6. If the density of VMs on the host is high, it is worth to plan the backup time to prevent high load on the productive systems in the working hours.
7. If you have to store multiple VM copies for several days, you will have to manage the number of the stored VM copies (you can automatize backup management using scripts or your backup tool features).
8. Backup monitoring tools are also important. It would be frustrating to learn that you cannot back up something due to the lack of free space in the data storage. The backup verification tool is also recommended.
9. Quite often you have to recover a certain file from a VM backup. Some backup/recovery products allow fine-grained recovery of files/folders without the need to restore the whole VM or its virtual disk.
   Note. Also, there are some tools that can recover specific mailbox databases, mailboxes, and even the specific emails from a VM backup with Exchange installed.
   .
10. You can split the access privileges with the role-based backup management model (it is relevant for administrators responsible for different system or device groups).
11. Don’t forget about implementing the traditional backup strategy 3-2-1 (three copies on two different media with one of them being stored on a remote site).

Next, we’ll consider some common solutions for Hyper-V VM backup based on the features described above.

Backup Hyper-V VMs Using Windows Server Backup

A free way to organize VM backup on Hyper-V suggests using the built-in Windows Server Backup feature. You can use WSB via the graphic backup/restore wizard or the wbadmin command-line tool (it is a part of WSB). Windows Server Backup supports VSS and incremental backup. This feature is available both on Windows Server 2012 (and newer) and on Hyper-V Server. To install WSB component, go to the Server Manager console or run this command:

Install-WindowsFeature Windows-Server-Backup -IncludeManagementTools

Windows Server Backup has the GUI console (wbadmin.msc) that allows to create and manage Hyper-V backups, create backup schedule, etc. To backup a VM, just start a simple wizard, select which VMs from your Hyper-V server have to be backed up and where the backups are to be saved, and specify the backup schedule.

Usually, it is easier to use the command prompt to backup a Hyper-V VM. Moreover, you cannot create more than one VM backup task in the graphic interface, and the task will overwrite all previous backup tasks.

To back up a VM named “Server 1” to a local folder on disk C: (it is not the best idea, is it?), just run this command:

wbadmin start backup –backupTarget:C: –hyperv:"Server 1"

For example, to back up two VMs and save them to a network shared folder (suppose, it is the external NAS storage), it is enough to run the following command:

wbadmin start backup -backuptarget:\\192.168.2.15\HVMback: -hyperv:"TestVM01,TestVM02" -allowDeleteOldBackups -quiet

You can add this command to the Windows Task Scheduler using PowerShell and thus schedule regular VM backups (older backups will be removed in this case).

For example, to backup a VM with the AD domain controller, you can reset the AD transaction logs after the backup is over in order for the ADDS database in the backup to be consistent (in the same way you can back up a VM with Exchange or SQL Server):

wbadmin start backup -backuptarget:\\192.168.2.15\HVMback: -hyperv:PAR-DC1 -vssFull

To get the list of backups registered in the system, run this command:

wbadmin get versions

WSB is a simple, but reliable solution for Hyper-V VM backup. It is quite fast and allows to manage the backup schedule. However, Windows Server Backup has its drawbacks:

• There are no tools to monitor backup process, to verify the consistency of VM backups or apps in them.
• It is hard to manage backup in medium and large Hyper-V installations (it is suitable only for small environments with 1-3 Hyper-V hosts).
• You cannot automatically recover the specific file or the app state. (You will have to manually mount a .vhdx file of a backup and manually copy the file you need).
• With high density and large sizes of VMs on a host, you will have to schedule backups using Windows Task Scheduler to prevent server overloads , as well as high load on LAN/SAN/iSCSI network during the business hours (if you store your backups on an external storage).

Top Third-Party Hyper-V Backup Products

It is impossible to use the Windows Server Backup if there are a lot of Hyper-V hosts and virtual machines. In this case you will have to choose one of the third-party solutions. You cannot say for sure that this or that product would be an ideal solution for Hyper-V backup since there are a lot of things to be considered. They include the number of hosts, licensing limitations, necessary features, network architecture, etc.

There are many commercial and free backup products in the market, and it is hard to choose the right one. Usually, Gartner magic quadrant is used to determine the niche leaders. I have found this image that shows the main players and leaders in the market of backup solutions for data centers in 2019.

As you can see, Gartner names the following companies and products among the leading providers of backup solutions: