You might have heard that WS2012 R2 Hyper-V changed how it performs backups of virtual machines but not heard how. I’ll give you a glimpse of what that change was in this post.
First some terminology:
- Volume Shadow Copy Service (VSS) Snapshot: VSS performs a snapshot of a volume to get a consistent backup of a file or files/folders.
- Checkpoint: Formerly known as a (Hyper-V) snapshot, a checkpoint (matching the SCVMM term) creates a crash consistent copy of a VM at a point in time, using AVHD or AVHDX files that are linked to a parent VHD or VHDX file – or linked to a parent AVHD or AVHDX files in the case of nested checkpoints.
In the past, VSS is used to create a VSS snapshot of the volume(s) containing the files of a VM that is to be backed up. The snapshot was mounted and the required files (identified by the Hyper-V Writer) were backed up. The process was pretty complex and could lead to problems for some customers. The quality of storage hardware VSS writers had too much impact on the process. Once you have a pretty clean environment (network/storage design, patching, drivers and firmware), backup was the one problem that could hurt. CSV 2.0 sorted out most of that, but Microsoft wanted to simplify the backup process.
Thanks to live merging of checkpoints (snapshots) that was added in WS2012, and the experience Microsoft has gained by using checkpoints (snapshots) for other features (such as Hyper-V Replica), WS2012 R2 Hyper-V has switched to using checkpoints instead of VSS snapshots.
Now a checkpoint is created of every virtual machine that is to be backed up. Writes are temporarily redirected to the checkpoint’s AVHDX/AHVD file(s). This gives the backup requestor a clean & crash consistent copy of the virtual machine’s VHD or VHDX files that are safe to read. After the backup, the checkpoint is merged and the job is done.
Note: You might notice that a VSS snapshot is still taken of the relevant volume(s).
We’ve moved from application consistent backup to the next (small) step down with a crash consistent backup. This isn’t a big deal – not for backup experts anyway. For products like SQL Server or Exchange, restoring this VM is like someone reset the VM. The restored database starts up, does a quick cleanup, and carries on operating as it did before the backup operation. In return, we get a much simpler backup process that should prove to be more resilient and selective.