CaryvaneHelp
/

Hyper-V backup

An App-consistent job for Hyper-V asks the host's VSS writer to quiesce each VM through its Integration Services, then uploads the VM's disk and configuration files. On Server 2016 and later, changed-block tracking can reduce each night to what actually changed.

Create the job #

  1. Jobs → New Job → App-consistent, choose the Hyper-V host (its agent), workload Hyper-V virtual machines, Discover on machine.
  2. Tick the VMs, or tick none for every VM on the host including ones created later.
  3. Destination and schedule as for any job. Nightly, after hours, is typical: a full-VM night moves the whole .vhdx.

What a run uploads #

For each VM: its virtual disks (.vhdx, plus any .avhdx if the VM has its own checkpoints) and its configuration (.vmcx, .vmgs, .VMRS), under <destination>/vss/<VM>/<drive>/<original path>. Sizes in Run History are the files' sizes on disk — a 1.5 TB dynamic disk with 200 GB in it uploads 200 GB. The VSS writer creates a transient auto-recovery checkpoint during the run and merges it afterwards; you will see it in the file list.

The guest is quiesced through Backup (volume shadow copy) in its Integration Services. Where the guest cannot do that — a Linux VM without the integration daemons — the capture is crash-consistent, which the log says.

Changed-block incremental (RCT) #

Server 2016 and later track which blocks of a virtual disk change between reference points. With this switched on for the host's agent (Agents → Properties → Hyper-V incremental, or the set_hyperv_rct_mode tool), each disk is archived as a chain: on the first night, and once a week, the real .vhdx layers as files; on every other night a small .avhdx holding only the blocks that changed, parented to the previous layer. A 1.5 TB mail server disk then costs its real size once a week and tens of megabytes a night.

The archive is self-describing. Under hyperv/<VM>/<disk>/full-<date>/ sit the base layer(s), diff-000.avhdx (an empty head), diff-001… per night, and chain.json listing them in order. A new folder starts when the week is up, after 30 diffs, or when Hyper-V rejects the reference point.

Three modes: Off (default: the full-VM writer path every night), Diag (takes the recovery checkpoint and logs what it would do — how much changed, whether the frozen disk opens — while the writer still moves the data; run this for a night first), Compose (the chain for real). If anything about a disk cannot be archived as a chain — an unexpected active leaf, an upload failure — that night falls back to the writer path for the whole VM set, after the checkpoint has been released, so a night is never short of a backup.

Checkpoints the agent takes #

Both modes take a recovery checkpoint (the kind backup software takes, invisible in Hyper-V Manager's checkpoint tree during normal operation) and release it at the end of the run: converted to a reference point in Compose, destroyed in Diag. The agent records every checkpoint it creates, and if a run is killed mid-way — a service stop, a reboot — the next run merges the leftover before doing anything else. A checkpoint that outlives a run is therefore a sign of an interrupted night; Troubleshooting says what to check.

Restore #

Full-VM backups: restore the files with a Restore job (or download them) and attach the disk to a new VM or import the configuration. Chains: download the folder, then either attach the highest-numbered diff — Hyper-V follows the parents by name — or Merge-VHD each diff down into its parent to leave a single .vhdx. Step by step in Restore data.