Plan Linux guest backup around application consistency

You are running a Linux virtual machine on a Windows Server 2025 host and need to back it up without taking it offline. The immediate question is how to ensure the data on the virtual hard disk is consistent when the backup starts. Unlike Windows guests, Linux does not have a universal Volume Shadow Copy Service (VSS) framework built into the kernel. This means you cannot rely on a single host-side mechanism to guarantee application consistency for every workload.

The answer depends on whether your Linux distribution includes Hyper-V Integration Services (LIS) that cooperate with the host, or whether you must handle consistency inside the guest. For supported SUSE Linux Enterprise Server (SLES) versions, the integration services are built into the distribution. However, even with these services, the backup process requires specific handling to avoid corruption.

Understand the Hyper-V backup mechanisms

Hyper-V on Windows Server provides two primary approaches for backing up virtual machines: VM backups and data-only backups. A VM backup copies the entire virtual machine, including configuration files (.VMCX), guest state (.VMGS), and runtime state (.VMRS). A data-only backup extracts only the data from the virtual hard disks. Both approaches can utilise the Volume Shadow Copy Service (VSS) to create a consistent snapshot of the data at a specific point in time.

The Hyper-V VSS writer on the host is designed for small-scale operations where all virtual machines on a server are backed up simultaneously. For larger or more scalable deployments, Hyper-V supports backup through the WMI API, which uses reference points and resilient change tracking (RCT) instead of host-side VSS. This WMI-based approach allows developers to access backed-up virtual machine information more efficiently, but it still relies on VSS inside the virtual machine for the actual data consistency.

Check for Hyper-V Integration Services

The first step in planning your backup is to determine if your Linux guest has Hyper-V Integration Services (LIS) installed. Not all Linux distributions include the necessary components for VSS-based consistency. For example, SUSE Linux Enterprise Server (SLES) versions 11 SP3 through 15 SP7 include built-in Hyper-V integration services. The feature matrix for SLES indicates that “Live virtual machine backup” is supported for these versions, which implies the presence of the necessary components for VSS-based consistency.

If your Linux distribution does not include LIS with VSS support, you cannot achieve application-consistent backups using Hyper-V’s native VSS mechanisms. In this case, you must rely on application-specific methods to quiesce the workload before the backup starts. This might involve stopping the application, flushing caches to disk, and then resuming it. Without LIS, the backup will be crash-consistent, which is acceptable for some workloads but risky for databases or file servers.

Handle open file handles and mount points

Even when LIS is present, there are specific conditions that can compromise the integrity of the backup. According to the SLES documentation, if there are open file handles during a live virtual machine backup operation, the backed-up VHDs might require a file system consistency check (fsck) on restore. This means that while the backup may complete successfully, the restored data might not be immediately usable without intervention.

Furthermore, VSS backup fails if a single partition is mounted multiple times. This is a critical constraint for Linux guests that use bind mounts or complex mount configurations. If your Linux guest mounts the same partition to multiple directories, the Hyper-V VSS writer cannot create a consistent snapshot. You must ensure that each partition is mounted only once, or use alternative backup strategies that do not rely on VSS.

Plan for backup verification and cleanup

Because Linux LIS are not as universally standardised as their Windows counterparts, verification is essential. After performing a test backup, you should restore the data to a separate virtual machine and run fsck to check for inconsistencies. If the file system is clean, the backup was consistent. If errors are found, you need to investigate whether open file handles or multiple mounts were the cause.

For data-only backups, you will need to create a new virtual machine and restore the data to it. This process is more manual than a full VM restore, but it can be useful for recovering specific files or testing the backup integrity without disrupting the production environment. Ensure that the new virtual machine has the same virtual hardware configuration as the original, particularly the virtual network adapter and disk controller types, to avoid driver issues.

Reference: Hyper-V Backup Approaches.