Backup / Restore of Microsoft Hyper-V (VSS-aware backup sets)

Knowledge Base: BACKUP : Backup / Restore of Microsoft Hyper-V (VSS-aware backup sets)

Creation Date: March 25, 2010

Revision Date: October 28, 2015

Product: DS‑Client (Windows)

Summary

This article covers various backup / restore issues for Microsoft Hyper-V backups (using the VSS-aware backup set type). With the DS-Client software you can perform online backups of Hyper-V virtual machines.

See Also

“Creating a VSS-aware backup set”

Features supported


Features	Microsoft Windows Server 2008 R2 SP1		Microsoft Windows Server 2012 / 2012 R2 with Hyper-V role
Features	with Hyper-V role	Operating System	Microsoft Windows Server 2012 / 2012 R2 with Hyper-V role
VSS-aware backup set (using Microsoft VSS writers)	+	+	+
Online backup (of Hyper-V Server and at individual virtual machine level)	+	+	+
Hyper-V Server browsing	+	+	+
Alternate Server restore (VSS Restore)	+	+	+
Alternate individual virtual machine restore (VSS Restore)	+	+	+
Alternate restore as pure files (File system restore)	+	+	+
Visualize VSS Component details at virtual machine level during restore (VSS Component)	+	+	+
Incremental backup			+
File Level Restore			+

Requirements for the backup and restore of Hyper-V virtual machines

• To perform backup/restore with Microsoft Hyper-V VSS Writer, the “Hyper-V Virtual Machine Management” service must be running on the target server.

• Each target virtual machine must have “Integration Services” installed to be backed up using Microsoft VSS Writers (volume snapshot).

Backup policy

• Based on Microsoft Hyper-V VSS Writer for both backup and restore.

• The backup unit is the Hyper-V virtual machine (not individual files within the virtual machine). A Hyper-V virtual machine is a group of files governed with strong data integration. The backup mechanism is called the "Saved State" method, where the virtual machine is put into a saved state during the snapshot process. Snapshots are taken of the appropriate volumes, and the virtual machine is returned to the previous state after the snapshot process is done.

• The GUID of Hyper-V virtual machine is the identifier for the Hyper-V virtual machine. This means, the GUID of Hyper-V virtual machine is considered as the file name of the virtual machine. The name of the virtual machine may be saved as a description of the virtual machine (note that the virtual machine name may not be unique for all virtual machines in a host).

• Hyper-V WMI APIs are used to search for the virtual machines in a host server. This is required when creating a Microsoft Hyper-V backup set, allowing users to browse for virtual machines to back up. Users can also select “all” virtual machines to be backed up.

• VSS provides a consistent interface that allows online backup of a Hyper-V virtual machine.

• VSS-related metadata is saved with the backup data to provide the rules for data integration in each backed up component (virtual machine).

• Master / Delta and library files are supported for this type of backup set.

Hyper-V backup policy options (incremental backup)

Hyper-V backup policy options can help reduce the backup time for very large virtual machines (where the dump takes up significant time).

This feature is for Microsoft Hyper-V backup sets for standalone Hyper-V Servers or Hyper-V clusters.

Requirements and conditions for incremental backup:

• The target backup must be of a Hyper-V 2012 server (or higher version).

• The target Hyper-V host must have Windows Server 2012 installed, and the virtual machine must use the Windows Server 2012 version of the Hyper-V Integration Services.

• You must configure the Microsoft Incremental Backup on the Hyper-V host (this is normally done using PowerShell). The Microsoft incremental backup setting is applied as a property to each individual virtual machine. All virtual machines selected for backup must be configured with the Microsoft incremental backup setting. (Note: If any virtual machine in a backup set is not configured with this setting, the whole backup session will be backed up with the “Full Backup” method.)

• It is recommend to apply all Microsoft hot-fixes related to any target Hyper-V host. At minimum, Microsoft KB 2919355 must be applied on the Hyper-V host or the Hyper-V cluster.

When creating or editing a VSS-aware backup of a Hyper-V Server, the backup set properties options tab has the following options for backup policy configuration:


Full dump: Always	[Default] This is the default behavior for all VSS-aware standalone Hyper-V and Hyper-V cluster backups. Each backup of the Hyper-V Server performs a full dump (VSS Snapshot) of each virtual machine.
Full dump: Plus Incremental	Performs a full dump of the virtual machine on first backup, followed by incremental backups until another full dump is needed (*).
(*) A full dump is needed (other than first time) when: • a virtual machine has been backed up by another backup set (or manually by the Windows Server Backup using the VSS Full Backup option); • a virtual machine has been restored from an earlier generation; • the virtual machine properties have been modified; • a set number of consecutive incremental backups have been performed, unless over-ruled with the Do not start full dump option. This uses the same number set in the DS-Client Advanced Configurations MasterGenerations parameter (note: this parameter is also used for another purpose).

Rules for overriding a full backup schedule in the Hyper-V backup policy:

These rules are optional. They allow greater control when a full backup can occur (e.g. not during business hours).

IMPORTANT: Full dumps can be delayed, but a full database dump needs to be performed at regular frequency to protect the integrity of the database backup. By default, DS-Client allows a full backup to be skipped a maximum of 120 consecutive times. This number is configurable in the DS-Client Advanced Configuration options MaxNonFullDumps parameter (see “DS-Client Advanced Configurations”).

For more information about backup policy options, see “Advantages and disadvantages of different database backup policies”.

Restore policy

For Restore, three models are supported:

• VM-level restore (VSS Restore )

• Restore as files (File Restore)

• File level restore (FLR)

VM-level restore

“VM-level restore” uses the Hyper-V VSS Writer to restore the whole virtual machine and maintain data integration.

For “VM-level restore”, the restore unit is a virtual machine. All files (a “snapshot” at a particular moment) involved in the virtual machine are provided based on the saved Metadata.

Exactly one generation (or session) can be selected for restore.

Restore as files

Restore as files does not guarantee data integration. This method restores the selected individual files the same way as for a File system backup set. End-users (customers) are responsible for the result of the restore.

This option is suitable for scenarios where VM-level restore is not possible (e.g. alternate restore, if some files are corrupted so that VM-level restore is not possible, etc.) or not necessary (usually for advanced users that understand Microsoft Hyper-V very well and can manually manage the restored files, or the files are restored for other purposes than as part of a virtual machine).

• Before performing an alternate restore, make sure that there is no virtual machine with the same GUID (see Backup Policy above) on the target machine. If there is a virtual machine with the same GUID, the existing virtual machine will be overwritten.

• For alternate restores, if you would like to change the path for the virtual machine files, use the Restore Option File option and specify the vssrestore.xml file. You can rename the .xml file as you wish ("vssrestore" is a generic name).

• The .xml file should be created under the DS-Client installation path.

File level restore (FLR)

FLR is available if the backup set was backed up with the “Use FLR” backup set option enabled (Sets > Backup Set > Properties > Options).

This method restores the selected individual files the same way as for a File system backup set. Using FLR means the files you select for restore are from the Hyper-V virtual disk’s data (i.e. files like users logged on to the backed up virtual machine would see).

FLR limitations:

• The Hyper-V virtual machine must be running either a Windows NTFS or Linux Ext4 file system.

• The Hyper-V Server must be version 2012 or higher.

• Local-Only and Self-Contained backup sets do not support the FLR feature.

• FLR is not supported if the backup set is configured with the Use Local Storage option.

• BLM and Disc/Tape restores do not support FLR.

Data integration issues

Each virtual machine is presented as a component by the Hyper-V VSS Writer. In the VSS-based VM restore, a component must be restored with all its contents (the file snapshot) based on the rules specified in its Metadata.

Components

Each virtual machine is presented as a component by the Hyper-V VSS Writer. In the VSS-based VM restore, a component must be restored based on the Backup Components Document and Writer Metadata Documents.

The component data integration metadata file includes an entry for each individual file belonging to this component and the component itself. The entry contains the following information:

• File ID

• Generation ID

• Backup Time

• Full Path (directory and file name)

DS-Client and DS-System use the combination of File ID / Generation ID to identify the backed up component generation.

BLM uses the full path and backup time to identify the backed up component generation.

A component (virtual machine) is represented by the component data integration metadata. Retention, delete, BLM request and Disc/Tape request work at the component-level. Validation works at the level of the individual backed up files.

Component Restore

Restore works both at the component-level (virtual machine) and individual file level. This is selectable from the DS-User. A component generation is considered “complete” if all its referenced contents exist. Otherwise it is considered an “incomplete component” by the DS-Client. A file that is not referenced by a complete component generation is called an unreferenced file.

Incomplete Components

Incomplete component generations are allowed to facilitate individual file restore from incomplete components.

Files that are backed up in an incomplete component generation could be referenced by later generations of the same component (thereby avoiding re-backup of the unchanged file again).

In the Retention Rules of DS-Client, options are provided to Delete incomplete components and Delete unreferenced files.

Incomplete component generations are not visible in the restore tree for VM-level restore.

The component data integration metadata are backed up as separate files with the Microsoft Hyper-V backup, and will be backed up the same way as data file (except that it is not encrypted). This is because the metadata is parsed by DS-System / BLM / etc., without knowing the encryption keys.

DS-Client will save the component data integration metadata in its database. Metadata is required by activities like restore / delete / retention, etc. Synchronization is responsible for synchronizing them with the corresponding on-line file.

BLM and components

When a component generation is moved to BLM, all its referenced files (if any exist) must be copied to BLM. When generating a BLM restorable image, if a component generation is included, that image must also include all its referenced files.

Backup requirements for Hyper-V clusters

IMPORTANT: Backup of a Hyper-V Cluster 2012 is only supported by DS-Clients running on Windows 7 and up (64-bit only).

Backup of Hyper-V in a clustered configuration is supported through the VSS-aware backup set type. The following requirements must be met to back up a Hyper-V cluster:

• Add the IP address and computer name for all the nodes in the Hyper-V cluster to the DS-Client computer's "Hosts" file, which is found in:

C:\WINDOWS\system32\drivers\etc\Hosts

• Create a VSS-aware backup set and select Microsoft Cluster Hyper-V.

• Specify the computer using the IP address of the ‘cluster virtual node’. (This is configured on the Hyper-V cluster itself.)

If you can connect to the specified computer, you will see an additional folder level named “<HAVMs>”. This contains the cluster’s high availability virtual machines that can be selected for backup.

All other steps are the same as for Microsoft Hyper-V backup sets for standalone Hyper-V.

Issues related to Hyper-V clusters

When restoring virtual machines, you must make sure that the same virtual machine (based on GUID) does not exist on any other node that is part of the same Hyper-V cluster (for reasons such as migration, failover, and renaming).