Hyper-V Checkpoints – Part 2 – Working and Management

Quick Bites:

• The blog discusses Hyper-V checkpoints, focusing on their types, usage, management, and differences from backups
• It covers the two types of checkpoints: standard and production, explaining their respective use cases
• It details how Hyper-V checkpoints work, including file types and configuration options
• The blog emphasizes the importance of proper checkpoint management and highlights the differences between Hyper-V checkpoints and backups, advocating for the use of dedicated backup solutions for data protection

Table of Contents

1. Types of Hyper-V Checkpoints
2. Use Case for Standard and Production Checkpoint
3. How Hyper-V Checkpoints Work
4. Configuring Hyper-V Virtual Machine Checkpoint Type
5. Hyper-V Checkpoints vs Hyper-V Backups

In summary, to manage checkpoints effectively:

• Keep only as long as needed
• “Production” is default in Windows Server 2016+
• Use ReFS with block cloning for faster merging
• Use PowerShell for bulk management

In part one of How to Use Hyper-V Virtual Machine Checkpoints series, we took a look at:

• What are Hyper-V checkpoints
• Why and how to use checkpoints
• How to create checkpoints in Hyper-V

In this post – part two, we will take a look at the types of checkpoints, how they work, managing them, and finally the differences between Hyper-V checkpoints and Hyper-V backups.

The Hyper-V checkpoint is a “snapshot” in time of the virtual machine that can be used for a later purpose such as rolling back after a failed update. This is a strong use case for Hyper-V checkpoints and is arguably one of the primary reasons for their use. Creating Hyper-V checkpoints using the Hyper-V Manager GUI and also with PowerShell are equally straightforward and provides flexibility in managing the creation of the checkpoint on a Hyper-V virtual machine.

Types of Hyper-V Checkpoints

With Hyper-V, there are actually two different types of checkpoints.

Checkpoints prior to Windows Server 2016 contained the virtual machine configuration, state (memory information), and the data on the virtual disk. Starting with Windows Server 2016, these types of checkpoints have been rebranded as standard checkpoints. And, with the release of Windows Server 2016, Microsoft has introduced a new use case for Hyper-V checkpoints – production checkpoints.

Production Checkpoints vs Standard Checkpoints

Snapshots or Checkpoints typically have never been supported as “production” technologies. VMware and Microsoft have regarded these mechanisms as an only very short-term and temporary and not supported with virtual machines that were running production workloads. Microsoft, however, has changed this with Windows Server 2016 and production checkpoints.

Standard checkpoints provide an exact state of a virtual machine, including memory information. When you revert to a standard checkpoint, you will have the exact virtual machine at that particular point in time when it was taken. Even though the standard checkpoint is noted in Hyper-V as being application consistent due to having an exact copy of the memory and disk contents, the Windows guest operating system has no knowledge of the checkpoint that is being taken. Windows do not interact with Volume Shadow Copy service to create the snapshot, so it has no VSS reference point for the standard checkpoint.

With virtual machines running production workloads with applications such as Microsoft SQL Server, this is not good. You always want VSS to be involved in creating a point in time “state” of a Windows Server virtual machine running applications such as Microsoft SQL Server.

Production checkpoints are carried out in a very similar way as the application-aware backups performed by most modern data protection solutions that backup virtual machines. Backup vendors interact with VSS to properly flush data from memory to disk and write pending I/O operations during a backup iteration. This ensures that the backup captures all of the data in a consistent fashion.

Production checkpoints perform the same operation by flushing memory and pending I/O operations when creating the checkpoint. This results in applications such as Microsoft SQL Server remaining in a consistent state in the production checkpoint. The production checkpoint is basically an application-aware “image” of the virtual machine. One thing to note with a production checkpoint, when restored, the virtual machine will be powered off. The reason for this is when a production checkpoint is created, the memory contents are flushed to disk, so the virtual machine has no memory “state” contained in the checkpoint. This results in the virtual machine being in a powered off state. This is similar behavior experienced as when a VSS, application-aware image-level backup is restored. Thus, one of the important points to realize about the “Production” checkpoints are, they are supported in production environments.

Use Case for Standard and Production Checkpoint

With the characteristics of each type of checkpoint, which use case is each type of checkpoint suited for?

Standard Checkpoint:

• DEV/STG/TEST environments for quick rollbacks
• Quick rollbacks from configuration or other software changes
• If you need to capture the exact state of the virtual machine, including memory
• Not supported in production environments

Production Checkpoint:

• If you need to provide backup containing the full application state of the virtual machine
• If you need to take a checkpoint of a virtual machine in production
• If your virtual machine runs applications such as Microsoft SQL Server or any other transaction aware database

How Hyper-V Checkpoints Work

Let’s take a look at the anatomy of a Hyper-V Checkpoint and how they work.

To understand how they work, we need to look at the files that get created when a new checkpoint is captured.

Below is a screenshot from a Windows Server 2019 Cluster Shared Volume running on a Windows Server 2019 Hyper-V cluster. In the config folder, a Snapshots folder is created containing the new binary file format for Windows Server 2016 and higher – VMCX and VMRS, and VMGS.

VMCX – This file is the binary configuration file that replaces the XML file found in 2012 R2 and earlier.

VMRS – This file contains various information about the state of the running virtual machine.

VMGS – This file is used for version 8.2 or higher Hyper-V virtual machines and is used to store the virtual machine guest state

Under the configured Disk folder on the CSV volume, we see the following file types with the presence of a Hyper-V checkpoint(s).

• RCT – These files are a new addition to Windows Server 2016 Hyper-V. The RCT file tracks change between backup operations. This allows backup solutions to only have to copy the changes since the last backup operation. This provides a much more efficient way of backing up data as only the changes are copied instead of all the data in the VHDX file.
• MRT – The MRT file helps to provide resiliency in case of a host crash or BSOD of the host. This helps to ensure no data is missed during a backup operation that was unexpectedly interrupted due to one of these aforementioned scenarios.
• AVHDX – This is the differencing disk that is created when you create a checkpoint. Once a checkpoint is deleted, the differencing AVHDX file is merged with the VHDX file.

Configuring Hyper-V Virtual Machine Checkpoint Type

Navigate to the Hyper-V virtual machine in Hyper-V Manager, right-click the virtual machine and select Settings. Under Checkpoints → Checkpoint Type select the default checkpoint option.

The options are:

• Production checkpoints (selected by default)
• Standard Checkpoints

Managing Hyper-V Virtual Machine Checkpoints

The expression “too much of a good thing” can certainly apply to checkpoints. While checkpoints provide extremely powerful functionality, managing them can become difficult since they are not really visible from an operational standpoint in working with a guest virtual machine. Checkpoints can be “out of sight, out of mind” and grow in number and size. The longer that checkpoints reside on a virtual machine, they grow in size. Checkpoint differencing disks capture all the “writes” that take place on a virtual machine from the time they are created until they are deleted and merged back into the base virtual disk.

Hyper-V checkpoints are organized into a structure called a “Checkpoint Tree”. Each subsequent checkpoint after the last depends on the previous checkpoint for reference. Using checkpoints, administrators can move between the different points in time on the virtual machine. This includes moving to a previous checkpoint or to a later checkpoint.

With the Windows Server 2016 Production Checkpoints, the checkpoints are perfectly consistent from a data perspective as all information is purged from memory and pending writes committed. Like an “application aware” backup, the checkpoint is in an application consistent state.

Managing Hyper-V checkpoints should be performed in a proactive manner. Following these best practices will help alleviate any difficulties as a result of mismanaged checkpoints.

• Keep checkpoints around only as long as they are needed
• “Production” checkpoints are the default option when using Windows Server 2016 and later
• Production checkpoints do not retain memory contents
• Use ReFS file system with the block cloning technology to significantly reduce the Hyper-V checkpoint merge operation time
• Use PowerShell as an effective way to keep a check on existing snapshots and to delete them

Using Hyper-V Manager, checkpoints can be reverted to, renamed, and merged easily. To perform these operations, simply right-click on the checkpoint you want to manage and the context menu contains the following:

• Apply – Revert to a specific checkpoint
• Rename – Renames the checkpoint
• Delete Checkpoint – Merges the data contained in the specific checkpoint
• Delete Checkpoint Subtree – Merges the data on the specific checkpoint and all checkpoints following

PowerShell One Liners to Manage Checkpoints

To get all checkpoints on a given host:

• Get-VM | Get-VMSnapshot

To remove all the checkpoints found on all VMs on a Hyper-V host:

• Get-VM | Get-VMSnapshot | Remove-VMSnapshot

To apply a Hyper-V snapshot:

• Restore-VMSnapshot -Name ‘Before updates’ -VMName TestVM

To rename a Hyper-V checkpoint:

• Rename-VMSnapshot -VMName TestVM -Name “Checkpoint1” -NewName “Before Software update”

To merge a Hyper-V checkpoint:

• Get-VM TestVM | Remove-VMSnapshot -Name “Before Software update”

Hyper-V Checkpoints vs Hyper-V Backups

Since production checkpoints perform similar tasks as an application aware backup, are Hyper-V checkpoints the same as Hyper-V backups?

Many have made the mistake of relying on checkpoints/snapshots as a form of “backup”. They may rationalize that checkpoints preserve a known good state of a virtual machine or in a certain state they want to retain as a potential restore point.

Why is relying on checkpoints dangerous?

Simply put, this can and most likely will eventually lead to data loss. Checkpoints are not designed to be backups. Backups must meet certain criteria that cannot be satisfied by the way checkpoints work and the requirements of checkpoints to be viable.

Backups:

• Need to be totally separate from any reliance on production infrastructure. Checkpoints do rely on the production infrastructure. They must have access to the base disk of the virtual machine to function. If any type of corruption occurs with the base disk, the checkpoint is also corrupt.
• Checkpoints are not meant to be kept around long term as they can certainly impact the performance of the virtual machine. After backups are taken, they have no impact on performance since the data is processed and held separate from the production infrastructure.
• Backups should be able to meet the 3-2-1 best practice methodology. This requires having at least (3) copies of the data on (2) forms of media, with at least (1) being kept offsite. Again, checkpoints are totally reliant on the virtual machine disk infrastructure. There is no way to separate the checkpoint from the base disk.
• Backups should allow restoring data without reliance on the production infrastructure or virtual machine files. Checkpoints are not able to restore a working state of a virtual machine without the base virtual machine files. If these are corrupt the checkpoint will be unusable.
• Backups much more easily allow restoring data in a granular fashion – single files, databases, etc

While Hyper-V checkpoints are powerful, data protection software in the form of backups is still crucial and very much needed to properly protect business-critical data.

Backup your Hyper-V VMs with BDRSuite

BDRSuite provides powerful Hyper-V backups second to none with modern Hyper-V capabilities suiting the needs of all enterprise environments. Vembu provides industry-leading Hyper-V backup capabilities, including the following:

• Hyper-V Cluster Support
• Host-level Virtual Machine Backups
• Hyper-V Checksum Based Incremental Change Tracking
• Full Hyper-V Application-aware backup support including Log Truncation
• Cluster Shared Volume (CSV) Support
• Supports protecting Hyper-V virtual machines running from SMB Shares
• Live Recovery for Hyper-V Virtual Machines
• Efficient backup storage including Compressed and deduplicated backups
• Powerful VembuHIVE File System allows easily converting or migrating Hyper-V backup data

Vembu allows organizations to meet and exceed the 3-2-1 backup best practice methodology and leverage the power of Hyper-V Clusters while having effective enterprise backups protecting business-critical workloads running in Hyper-V.

Wrapping Up

Hyper-V checkpoints provide a great way to quickly create point-in-time “snapshots” of virtual machines running in the Hyper-V environment. This is especially useful when applying patches or other software updates. There are certainly best practices that need to be considered when utilizing Hyper-V checkpoints to ensure there are no issues as a result. While Hyper-V checkpoints are a great feature to leverage for many use cases, they are not a replacement for proper backups. Backups are necessary to properly protect business-critical data in a way that is recoverable. By using enterprise backup solutions such as BDRSuite to protect Hyper-V hosts and Hyper-V clusters, organizations can rest assured their data is safely protected using best practices that are easily implemented with robust Hyper-V backup solutions like BDR Suite.

Related Posts

What are Hyper-V Checkpoints-Part 1: Why and how to use them?

Beginner’s Guide for Microsoft Hyper-V: What are Hyper-V Checkpoints – Part 21
How to Merge Hyper-V Checkpoints using Hyper-V Manager and Powershell
How to use Hyper-V Virtual Machines Checkpoints

Follow our Twitter and Facebook feeds for new releases, updates, insightful posts and more.