How do I back up Hyper-V virtual machines?

The right default for Hyper-V is a host-level backup: each VM captured whole from the host, configuration and virtual disks together, through Hyper-V's own interfaces. Two habits cause most of the trouble: copying live disk files and treating checkpoints as backups. This post covers both, what a complete VM backup holds, how change tracking keeps nightly backups small, and how to test a restore without upsetting the production network.

Should you back up the host or each VM?

Back up the host. A host-level backup captures each VM whole: its configuration and its virtual disks, so a restore brings back the complete machine. An agent inside each guest is for two cases: you only need files from that guest, or the guest has disks the host can't see (more on those below).

For Windows guests with integration services installed, the host asks the guest's Volume Shadow Copy Service (VSS) to flush applications to disk before the backup reads anything. That makes the backup application-consistent rather than just crash-consistent, so databases and other transactional services come back in a known good state.

Why can't you just copy the VHDX files?

Because the disks keep changing while you copy them. A plain file copy of a running VM's .vhdx files gives you a disk that is a mix of before and after. It may not boot, or it may boot with damaged files. Use Hyper-V's own interfaces instead: Export-VM, checkpoints, or a backup tool built on them.

The same goes for checkpoint files. Never delete .avhdx files by hand: that breaks the link between the differencing disk and its parent. Delete checkpoints through Hyper-V, so their changes merge back into the parent disk.

Are Hyper-V checkpoints a backup?

No. A checkpoint lives on the same storage as the VM, so it is lost with the host or the disk. While a checkpoint exists, writes go to a differencing disk (.avhdx) that keeps growing. Long checkpoint chains slow the VM down and can fill the volume.

Hyper-V has two kinds. Production checkpoints use VSS inside a Windows guest, or a file system freeze on Linux, and don't save memory state. Standard checkpoints save the running memory state too. Backup tools use a short-lived checkpoint to get a consistent view, copy from it, then remove it. That is their proper use: a moment to copy from, not somewhere to keep history.

What does a full VM backup include?

• The VM configuration: the .vmcx file and, where present, the .vmgs and .vmrs runtime state files.
• Every virtual disk and its parent chain.
• Settings such as generation, processor and memory, Secure Boot, virtual TPM handling and network adapters.

Export-VM produces a full, importable copy of a VM with all of the above, and on current Windows Server versions it works while the VM is running.

How does Resilient Change Tracking make backups smaller?

Since Windows Server 2016, Hyper-V tracks which blocks of each virtual disk have changed. Microsoft calls this Resilient Change Tracking (RCT). A backup tool records a reference point after each backup; next time it asks Hyper-V which blocks changed since that point and reads only those. The first backup reads everything, and later nights read a fraction of it.

The tracking survives crashes and power loss, unlike older in-memory methods. It can still be lost: the VM moves to another host, a disk is replaced or resized, or the reference point is missing. When the change history can't be trusted, the right behavior is a full read, never a guess.

Which disks can't be backed up from the host?

Pass-through disks (a physical disk handed straight to the VM) and disks the guest reaches over iSCSI from inside the guest. Neither is a virtual disk file on the host, so a host-level backup can't capture them.

A good tool says so plainly instead of skipping them. Otherwise the backup reports success and the data on those disks is missing, which you only discover during a restore. Back those disks up with an agent inside the guest.

How do you test a Hyper-V restore safely?

A restored VM has the same computer name and IP address as the original, and the same MAC address if it was static. Started on the production network, it can clash with the real server or cause trouble on the domain.

So restore it as a new VM with a new ID, on an isolated virtual switch or no switch at all:

Import-VM -Path <path to the .vmcx file> -Copy -GenerateNewId

Boot it, check the services you care about, and remove it when the test is done.

How does MoorNest back up Hyper-V?

MoorNest backs up Hyper-V VMs from the host: you pick the VMs in the console, next to the folders you back up. The first backup reads each VM in full through Hyper-V's own interfaces. With Resilient Change Tracking switched on (an agent setting), later nights read only the disk blocks Hyper-V reports as changed, and the agent falls back to a full read whenever the change history can't be trusted.

A VM with a pass-through disk is refused with a clear error rather than backed up without that disk. Disks a guest reaches over iSCSI aren't visible to the host, so back those up with an agent inside the guest. When you restore, the VM comes back as a new, disconnected VM, so the original is never touched.