Hyper-V virtual machines
This section provides considerations and requirements for protecting Hyper-V environments.
Preparing for Hyper-V backups
Following is a summary of the high-level steps for backing up Hyper-V virtual machines. The information includes links to detailed instructions for each procedure.
Step 1: Review Best practices and requirements for Hyper-V protection.
Step 2: Install the Unitrends Windows agent on your Hyper-V host. See Installing the Windows agent.
NOTE For most Windows servers, the appliance can push-install the agent when you add the asset. If you will be push-installing the agent, skip to Add the Hyper-V host to your Unitrends appliance. See Adding a virtual host.. For push-install requirements, see Windows agent requirements.
Step 3: Add the Hyper-V host to your Unitrends appliance. See Adding a virtual host.
Step 4: Create backup jobs for your VMs:
● To create a job manually, see To create a Hyper-V backup job.
● To create a job by using an SLA policy, see To create an SLA policy for Hyper-V assets.
● For a comparison of the manual and SLA policy job creation methods, see About creating backup and backup copy jobs.
Best practices and requirements for Hyper-V protection
Review the information in these topics before implementing Hyper-V host-level protection:
Hyper-V best practices
Follow these recommendations:
● Adhere to Microsoft’s best practices for virtualization. For a list of Microsoft documents on virtualization, see Microsoft Virtualization: Hyper-V best practices.
● Install the latest Windows agent on your Hyper-V host for best performance. (If needed, upgrade the appliance first to ensure it is running an equal or later version.)
● To protect the file system and operating system of the Hyper-V host, you must run file-level backups. For details, see File-level Backups Overview. Any files belonging to the Hyper-V application are automatically excluded from file-level backups of the Hyper-V host.
● In some cases, you may want or need to protect VMs using file-level backups. For recommendations, see Protecting Hyper-V virtual machines with file-level backups.
● To protect a VM with both host-level and file-level (agent-based) backups, ensure that the VM's host-level and file-level jobs do not overlap. Running both simultaneously may lead to undesirable results.
● If recovery time objectives are important, set up Virtual machine instant recovery to quickly to spin up a failed VM from host-level backups.
● Full and incremental backups are supported for Hyper-V VMs.
● A new full backup is required in these cases:
● The VM configuration has changed since the last backup. This includes any configuration changes made to a VM in the Hyper-V manager, such as creating or deleting a snapshot, adding a new disk, or converting a disk from VHD to VHDX format.
● The VM's configuration version is not present in the last backup.
● The VM's configuration version has changed since the last backup.
If the VM configuration has changed since the last backup, the next incremental fails. After this failure, the appliance promotes the next scheduled backup to a full (or displays a message indicating a full is required if an on-demand incremental is attempted). Once a full backup succeeds, subsequent incrementals run as scheduled.
● Beginning in release 10.0, additional VM configuration version checking is used to support Hyper-V's VMCX format (introduced in Windows 2016). If you are using hosts running Windows 2016 or later, or protecting VM configuration version 6.2 or higher, see Virtual machine configuration for additional requirements.
General Hyper-V requirements
The following requirements must be met for host-level protection of Hyper-V virtual machines.
|
Item |
Description |
|---|---|
|
Hyper-V host |
The following are required for the Hyper-V host: ● The Hyper-V host must be a supported version listed in the Unitrends Compatibility and Interoperability Matrix. ● The Unitrends Windows agent must be installed on the host as described in Installing the Windows agent. (It is not necessary to install agents on your virtual machines.) ● The Hyper-V PowerShell module must be installed on the host. In most cases, this module is installed by default. In some Windows Core OS versions, this module is not included in the default installation. ● To protect VMs running on Hyper-V 2022, both the Unitrends appliance and the Windows agent on the Hyper-V host must be running version 10.6.2 or higher. ● To protect VMs running on Hyper-V 2019, both the Unitrends appliance and the Windows agent on the Hyper-V host must be running version 10.3.8 or higher. ● To protect VM configuration versions 6.2 or higher, both the Unitrends appliance and the Windows agent on the Hyper-V host must be running version 10.0 or higher. (If using a host that is running Windows 2016 or later, note that VMs are created with configuration version 8.0 by default.) ● For cluster configurations: ● Each node in the cluster must be running agent version 10.6.9 or higher. ● Be sure to install the same agent version on all nodes in the cluster. |
|
Microsoft VSS |
Microsoft’s Volume Shadow Copy Service (VSS) and the Hyper-V VSS writer must be installed and running on the Hyper-V host. |
|
Integration Services |
To avoid VM downtime, Unitrends recommends online backups. To perform online backups, you must install Integration Services in the guest operating system to enable the VM to create a child state snapshot. The host then uses this snapshot to perform an online backup of the virtual machine. For online backups, the following conditions must be met on the protected VMs: ● The latest version of backup Integration Services must be installed and enabled. For a list of guest operating systems for which Integration Services is supported, see the Microsoft document Hyper-V Overview. ● The VM’s VHD(X) files and snapshot file location must be set to the same volume in the host operating system. ● All volumes must reside on basic disks and the VMs cannot have dynamic disks. ● All disks must use a file system that supports snapshots (for example, NTFS). If an online backup cannot be performed, the VM is temporarily put in a saved state. In saved state there is a brief downtime during the backup. |
|
VMs must meet the requirements listed below. For VMs that do not meet these requirements, install the Windows agent on the VM and run file-level backups. ● If the VM configuration is 6.2 or higher, both the Unitrends appliance and the Windows agent on the Hyper-V host must be running version 10.0 or higher. If the host is running agent version 10.0 or higher but the appliance is running an older version, backup and recovery jobs fail for VM configuration version 6.2 or higher. NOTES ● Starting with VM configuration 6.2, Microsoft implemented a binary-based configuration format (VMCX). On Windows Server 2016 and later, VMs are created by default with this VMCX configuration. VMCX requires new backup and recovery methods that are available in Unitrends release 10.0 and later. ● Additional VM configuration version checking is used to support the VMCX format. A new full backup is required in these cases: the VM's configuration version is not present in the last backup, or the VM's configuration version has changed since the last backup. ● If you attempt an on-demand incremental, the appliance promotes the backup to a full. ● If the next job is a scheduled incremental, the job fails due to the configuration change. After this failure, the appliance promotes the next scheduled run to a full. Once this full succeeds, subsequent incrementals run as scheduled. (If you upgrade a VM's configuration version, you can opt to run an on-demand full, rather than letting the appliance fail then promote the next incrementals.) ● The VM cannot be configured with shared VHDX disks. ● The VM cannot be configured with pass-through disks. ● The VM cannot be configured in a VHDS cluster or in a VHD Set. ● The VM cannot be configured as a shielded VM. ● The VM cannot be configured in a Hyper-V container. |
|
|
VM name and location |
The VM name and path to the virtual machine on the Hyper-V host must not contain escape or special characters. Backups fail if escape or special characters are present in the pathname. |
Additional Hyper-V requirements
These additional requirements may apply to your environment.
|
Item |
Description |
|---|---|
|
Faster incrementals for VM configuration version 5.0 and higher (2012, 2012 R2, 2016, 2019, and 2022 hosts) |
For VM configuration version 5.0 and higher, Unitrends leverages a Hyper-V changed-block-tracking (CBT) driver that greatly increases incremental backup performance. To use this driver: 1. If using a Windows server to host your VMs, enable the Hyper-V role. NOTE For Windows servers, you must enable the Hyper-V role before you install the Windows agent. If the Hyper-V role is not enabled, the CBT driver is not installed with the Windows agent. 2. Install the Windows agent on your Hyper-V host. The CBT driver is automatically installed with the Windows agent. To verify that the CBT driver was used, view backup details and look for the following in the Output: CBT DRIVER ACTION IS ENABLED. If the driver has been uninstalled or corrupted, backups complete with a warning to indicate that the CBT driver was not used. |
|
Windows agent push |
To use the push feature to install the Windows agent and agent updates on the Hyper-V host, see Installing the Windows agent for additional requirements. |
|
Microsoft Hyper-V Replicas feature |
Microsoft's Hyper-V Replicas feature is not compatible with the Hyper-V CBT driver. If you are using this feature, you must manually uninstall the Hyper-V CBT driver. For details, see Manually installing and uninstalling the Hyper-V CBT driver. Once the driver has been uninstalled, Hyper-V incrementals are supported but do not use the driver. The Hyper-V CBT driver is installed each time the Windows agent is installed or updated. Manually uninstall the driver as needed after updating or reinstalling the Windows agent. |
|
Virtualized Active Directory servers |
To ensure database consistency, you must set up the virtualized Active Directory (AD) server in accordance with Microsoft best practices. If all Microsoft considerations are not addressed, backup and recovery of the virtual machine may yield undesired results. If you prefer not to research these best practices, it is recommended to install the agent on the VM and protect it as you would a physical server (leveraging Microsoft’s VSS writers). |
|
Distributed File System environments |
Distributed File System (DFS) Namespaces and DFS Replication offer high-available access to geographically dispersed files. Because of the replication and syncing operations in DFS environments, you must set up the virtual machine in accordance with Microsoft best practices to ensure database consistency. If all Microsoft considerations are not addressed, backup and recovery of the virtual machine may yield undesired results. If you prefer not to research these best practices, it is recommended to install the agent on the VM and protect it as you would a physical server (leveraging Microsoft’s VSS writers). |
|
Multi-point Services Role and RDS User Profile Disks |
Windows VMs with the Multi-point Services Role and RDS User Profile Disks are not supported. |
|
Cluster shared volumes (CSVs) |
Adhere to the following requirements when using CSVs: ● A cluster with a single cluster shared volume does not follow Microsoft’s best practices and may be unreliable. If you have VMs in a cluster with a single CSV, protect them as you would physical machines, by using file-level backups. ● A VM's data cannot reside on both CSV and SMB shares. Using a combination of CSV and SMB shares for a single VM is not supported. ● Avoid backing up a set of VMs in the same schedule (i.e., at the same time) where some of the VMs are based on SMB storage and others are based on CSV storage. This can lead to backup failures. |
|
Storage on SMB 2.0 shares for Hyper-V 2022/2019/2016 |
For Hyper-V 2022, 2019, and some later Hyper-V 2016 versions, additional configuration is required to protect VMs with data that resides on SMB 2.0 shares. For details, see Protecting Hyper-V 2019/2016 VMs with disks that reside on SMB 2.0 shares. |
|
Storage on SMB 3.0 shares |
Unitrends can protect virtual machines with disk storage located on SMB 3.0 shares. When these VMs are backed up, the Hyper-V agent creates a VSS snapshot on the remote server and exposes it to the Hyper-V host through the SMB share pathing. The agent then backs up the VM’s files from the remote snapshot location. When the backup completes, all VSS snapshots created for the backup are removed from the server hosting the SMB share. The following are required to protect Hyper-V VMs with SMB 3.0 file storage: ● The File Server and the File Server VSS Agent Service roles must be installed on the server hosting the SMB 3.0 shares. For instructions on installing these roles, see How do I install the File Server and File Server VSS Agent Service roles on a server hosting SMB shares?. ● The Unitrends Hyper-V agent installed on the Hyper-V host must be granted read/write access to remote SMB 3.0 shares. The most secure option to provide all necessary access is to change the login account for the Unitrends Hyper-V agent service from bpagent to the domain administrator account. If permissions for the domain administrator do not allow access to all files for file-level backups of the Hyper-V host, run the agent as a local system account on the Hyper-V host and grant it read/write permission for the SMB shares. For instructions, see Running the Windows agent as local system account on Hyper-V server and granting account read/write permissions for SMB shares. ● The servers hosting the VMs and SMB shares must belong to the same Windows domain. ● The VM can contain one or more disks on SMB 3.0 shares. Disks can reside on the same share or different shares hosted by one or more servers in the same domain. All servers participating in the VM backup must belong to the same domain. ● If multiple Hyper-V hosts are using the same SMB server, avoid backing up VMs on different hosts at the same time. A single SMB server can only service one VSS snapshot request at a time from remote hosts. ● A VM's data cannot reside on both CSV and SMB shares. Using a combination of CSV and SMB shares for a single VM is not supported. ● Avoid backing up a set of VMs in the same schedule (i.e., at the same time) where some of the VMs are based on SMB storage and others are based on CSV storage. This can lead to backup failures. ● If the VM contains multiple disks on SMB 3.0 shares, the storage paths to all disks must use the same naming pattern (all must include the NETBIOS or FQDN or IP). Using a mix of naming patterns is not supported. Example of mixed naming that causes the backup job to fail: \\HVSMBServer\Share1\WinVM\Disk1.vhd \\HVSMBServer.qatest.local\Share1\WinVM\Disk2.vhd \\192.168.199.215\share1\WinVM\Disk3.vhd Examples of consistent naming where the backup job succeeds: \\HVSMBServer\Share1\WinVM\Disk1.vhd \\HVSMBServer\Share1\WinVM\Disk2.vhd \\HVSMBServer\share1\WinVM\Disk3.vhd or \\HVSMBServer.qatest.local\Share1\WinVM\Disk1.vhd \\HVSMBServer.qatest.local\Share1\WinVM\Disk2.vhd \\HVSMBServer.qatest.local\share1\WinVM\Disk3.vhd or \\192.168.199.215\Share1\WinVM\Disk1.vhd \\192.168.199.215\Share1\WinVM\Disk2.vhd \\192.168.199.215\share1\WinVM\Disk3.vhd |
