List of Effective Hyper-V Backup Strategies

Common Hyper-V Backup Strategies

Backing up Hyper-V virtual machines can be straightforward; however, things may get complex, too, depending on your setup.

There are several common disaster recovery scenarios for Hyper-V:

  • Backup the VMs and keep a backup history. For example, back up every night and keep the last 7 days
  • Live backups and offline backups (hot or cold backups) known as agentless backup
  • Saved State backups (freeze backups)
  • Backups taken inside the VM (agent backup)
  • Live Hyper-V VM Replication


Backups Taken From the Host

Live Hyper-V Backups

Live backups is what most users want. Live backups are provided by Hyper-V and VSS, the Volume Shadow Service of Microsoft Windows XP and later.

Older operating systems do not supply VSS and are hence incompatible with live backup tools.

For live backups to work properly you must have the following:

  1. VSS capable host operating system and VSS working properly. (Windows Server 2008 and later)
  2. VSS capable guest operating system. The VMs need to run Windows XP or Server 2003 and later. Some Linux variants may be supported depending on your host operating system version.
  3. You need to have the latest Hyper-V Integration Services installed in each VM
  4. You need to use NTFS file systems
  5. You must have enough RAM and disk space available (10 GB disk space and 1GB RAM minimum)
  6. You need to have a large enough VSS storage area. Use VSSUIRUN.EXE or vssadmin to set unbounded or high limits above 10 GB to avoid issues

The backup application initiates the process and involves Windows, Hyper-V, and VSS. The backup signal is also pushed into the VM. The VM’s VSS is then triggered and notifies all services inside the VM which may be able to handle VSS requests. Then the backup is taken via a virtually frozen, application and crash consistent state of the VM, while the VM continues to operate without interruption.


Offline VM Backups

Offline VM backups are great when you don’t have VSS capable services or operating systems. But also because offline backups are sometimes “better”. All services are required to shut down, including the VM’s operating system. The backup is then taken and the VM boots up again. This ensures that the VM is bootable at regular intervals; however, the downtime required may be an issue in many settings.

Rebooting VMs is good because it clears Windows and other temp areas in the system and it ensures the VM is actually bootable. Sometimes VHDs may become corrupted or a virus or software fault may cause issues with the boot procedure. If backups are always taken live and the VM is never rebooted, the errors will never surface and go unnoticed.

In addition, many times the admin doesn’t know whether there are VSS incompatible services running on the virtual server.

Examples include:

  • Microsoft Access
  • MySQL
  • Proprietary databases and flat file datastore arrangements


Saved State Backups

Saved State is what Microsoft invented to be able to take somewhat useful backups with (usually) minimal data loss of non VSS compliant operating systems, these include:

  • Most Linux variants on Windows Server 2008 / R2 and 2012 host servers
  • Windows Server 2000 and older
  • Modern Windows versions with old or non-existent Hyper-V Integration Services

If the VM lacks an up-to-date Hyper-V Integration Service installation it will be backed up in Saved State mode.

Saved State backups may also be done (the decision is up to Hyper-V Management, not the backup application) if:

  • There aren’t enough resources (RAM, as in the case of heavily fragmented RAM)
  • The VM OS is in a boot or shutdown process


Live Hyper-V VM Replication

You can replicate VMs from one server to another and keep X number of past versions, too, using BackupChain. Instead of compressing and deduplicating virtual disks, they can be copied instead once VSS has brought them in a crash and application-consistent state. On the recovery server you can boot them up any time you need them without delay as the virtual disks are in their native format and ready to be started.


Backups Taken Inside the VM (Agent Backup)

Some scenarios require backups to be taken inside the VM:

  1. You are using a VSS incompatible OS which can’t be backed up live from the host, such as Linux, or Windows Server 2000
  2. You are using directly attached storage inside the VM, like iSCSI or a mounted partition which is physical to the host


Another Solution to Get Both Strategies to Work

Granular Backup for Hyper-V is an innovative feature in BackupChain that allows IT admins to access files inside VMs from the host. See this post as well.

You can perform a live backup of VM folders without installing software inside VMs if the VM’s virtual disks are accessible from the host.