Hyper-V backup process

The host side includes Hyper-V VSS writer, the VSS provider, and the backup application, which acts as the VSS requestor. DPM acts as the VSS requestor, which initiates the backup operation periodically and triggers the Hyper-V VSS writer to quiesce the VM.

To enable an application-consistent snapshot of the application running within the VM, Hyper-V communicates to the guest operating system through the Hyper-V integration service. Hyper-V inside the guest acts as the VSS requestor and requests the workloads to quiesce. For instance, if SQL Server is running inside the VM, the SQL Server writer participates in the VSS protocol and flushes in-flight data buffers to the disk, and when it is done, the VSS provider takes a volume snapshot.

After the volume snapshots have been created inside the guest, the VSS provider on the host creates a shadow copy of the volume that contains the VHDs. The volume snapshot enables the application, the VM in this case, to continue to make changes to the VHDs that are attached to the VM while the backup operation takes place.

DPM maintains a bitmap file per VHD that is being tracked, and it can easily identify the blocks that have been modified since the last synchronization event. The block size is maintained as 16 KB to optimize the amount of data that is transferred and stored on the replica. Since the bitmap only indicates which 16-KB blocks are modified, the DPM backup agent reads the modified data from the storage snapshot. These changes are then transported to the DPM replica server and stored on the replica volume. To maintain versions of backup data, DPM maintains recovery points, which are essentially snapshots of the data on the replica storage pool. When a new recovery point is created on the DPM replica storage, a volume snapshot is taken, and only new changes are written to the replica volume, while shadow copies are maintained for older recovery points. This mechanism of synchronization is called an express full backup.

Because DPM maintains a bitmap for each file that is being backed up, it requires a list of files to back up. The Hyper-V VSS writer not only participates in the backup operation, but it also enables the VSS requestor to track the list of files that need to be backed up. For instance, if a VM has two VHDs, the file specification with VSS will maintain a list of VHDs and their locations. This not only enables DPM to maintain the right tracking mechanism, but also enables DPM to capture the corresponding volume on the host machine. This enables the backup operation to detect any changes in the file specification. For instance, when a new VHD file is attached to the VM, DPM automatically makes an initial copy of the VHD as part of the next synchronization event.

During the restore process, an administrator can recover the entire VM or restore files and folders that are within the VM. For a VM, the restore can be to the same host, to the same cluster, or to a different cluster.

To ensure consistent backups are captured for Linux VMs, it is critical to install Linux Integration Services. The mechanism to quiesce the workloads within the guest operating system exists only in a Windows operating system. Hence, for Linux VMs, the Hyper-V VSS writer uses a different approach to quiesce the workloads. The Hyper-V writer leverages the file system-level operations, such as freeze and flush, to ensure that the data is file-system consistent. Therefore, from a user’s perspective, the file-level consistency is always maintained by the backup process.

Source of Information : Microsoft System Center