Server 2012 and Windows Server 2012 R2. Backups taken at the Hyper-V host call the
VSS writers within the virtual machine through the Backup integration service in both
scenarios, which ensures application-consistent backups even when the backup is
taken at the Hyper-V host. In Windows Server 2012, there’s a delay between the time
the VSS snapshot is taken within the virtual machine and the time the VSS snapshot is
taken at the Hyper-V host (because it takes time to pass back the various VSS
communications between the guest and the host), which means that data could
change in that time delta, therefore introducing the risk of data corruption.
To solve this problem, the snapshot taken of the VHD at the host is mounted as a
volume on the Hyper-V host as part of the backup process; this enables the snapshot
VHD to be rolled back to the state of the snapshot taken inside the virtual machine
(the guest VSS snapshot) and then that state is backed up at the host. This approach
creates scalability concerns, because large numbers of VHDs might need to be
mounted; in addition, VHDs from virtual machines are being mounted on the Hyper-V
host, which could be a security concern.
Windows Server 2012 R2 solved this problem; Hyper-V pretends that it has hardware-
based snapshot support (which is typically part of high-end SANs). Therefore, when a
VSS snapshot request is made inside the virtual machine, the Hyper-V VSS writer is
piped directly in the host, which triggers creation of a checkpoint (which in turn
creates an AVHD differencing file on the host). Then that checkpoint is used by the
VSS running on the Hyper-V host, which removes the need for VHDs to be mounted in
the host. However, as part of this process, an AutoRecovery VHDX has to be mounted
to the virtual machine to expose the snapshot back to the virtual machine as part of
the fix-up phase near the end of the backup process, and then the AutoRecovery
VHDX is removed. This is invisible to the end user; however, this hot-add of a VHD is
possible only on the SCSI controller, which is why the virtual machine must have an
SCSI controller present in Windows Server 2012 R2 to allow host-level backups, or
backup will fail and you receive an Event ID 10103.
The process to back up VMs has changed again in Windows Server 2016 in two ways;
however, the end user experience for performing backups is unchanged. The first
change relates to the new production checkpoint feature (covered later in this
chapter), which leverages the VSS infrastructure inside the VM that is now leveraged
as part of a host-level VM backup. A new Hyper-V WMI call is utilized to trigger the
backup by the backup application and via the new WMI call, the Hyper-V
infrastructure is responsible for getting the VMs ready for the backup, specifically
creating the required AVHDX file which, at the backup application’s convenience, can
then be persisted to the final backup target via a separate host-level VSS snapshot. The
major difference here is that in the past, every VM that was backed up resulted in a
separate VSS snapshot on the underlying storage. If you backed up 100 VMs at the
same time, there would be 100 hardware snapshots, resulting in backup scale
challenges. With Windows Server 2016 and the decoupling between the VM snapshot
and the host snapshot, all of the data from multiple VMs can be backed up by using a
single hardware VSS snapshot, enabling greatly improved scale.