Backup EnginebackupEngine
Docs/Server Backup/Hyper-V Incremental Backup

Hyper-V Incremental Backup & Chain Promotion

RCT-based incremental chains, chain restore, and synthetic-full promotion for bandwidth-efficient long-running Hyper-V protection.

What Changed in v1.6.0

Through v1.5.x, every Hyper-V backup re-uploaded the full VHDX. v1.6.0 moved the Hyper-V runner to Resilient Change Tracking (RCT)-based incremental chains. The wizard's Schedule step now offers a Backup type selector: "Full only" or "Incremental chain". The default is Incremental, with one full plus six daily incrementals before a new chain starts.

How RCT Works (Briefly)

Hyper-V tracks which 4 KB blocks of each VHDX have changed since a reference checkpoint. BackupEngine creates a checkpoint after every successful backup, then on the next run uses Export-VMSnapshot to extract only the changed regions, streams them through the chunk pipeline, and writes a manifest with parent_manifest_id pointing at the previous chain entry.

Chain shape
Sun  full          chain_index=0   parent_manifest_id=NULL
Mon  incremental   chain_index=1   parent_manifest_id=<Sun>
Tue  incremental   chain_index=2   parent_manifest_id=<Mon>
...
Sat  incremental   chain_index=6   parent_manifest_id=<Fri>
Sun  promotion     chain_index=0   parent_manifest_id=NULL  (synthetic full)

Chain Restore

Restore validates the chain before reassembling. Validation checks that every entry shares the same backup set, the same VMs and disks, contiguous reference checkpoints, and a passing encryption gate per entry. If anything is missing — for example, a deleted intermediate manifest — the restore stops with a clear error before any disk is written.

The walk runs Merge-VHD on the agent host: full → diff1 → diff2 → ... → leaf. The output is a single consolidated VHDX per disk that you can attach to a Hyper-V VM through the auto-generated RESTORE_INFO.txt PowerShell commands.

What v1.7.1 Adds — Chain Promotion

When the chain reaches its length cap, instead of re-uploading the live VHDX as a fresh full (the v1.6.0 behavior), BackupEngine reassembles the existing chain locally and re-streams it as a synthetic full. Every chunk that is already in cloud storage is matched by SHA-256 hash and deduped — typically zero new bytes uploaded. The synthetic full becomes the new chain root for the next incremental run.

Why This Matters

For a 100 GB VM with weekly chain rolls, synthetic-full promotion saves roughly 5 TB/year of bandwidth (52 weeks × 100 GB) compared to the v1.6.0 live-VHDX-full behavior. For larger VMs the savings scale linearly, and for VMs with low day-to-day churn the dedup hit rate during promotion is essentially 100%.

Wizard Control

A new "Synthetic full when chain reaches cap (recommended)" toggle in the Hyper-V wizard's Schedule step controls this behavior. The toggle is ON by default for new sets. Switching it OFF reverts to the v1.6.0 behavior, where the chain cap triggers a live-VHDX full upload.

ℹ Note

Existing pre-v1.7.1 backup sets keep their original behavior until you edit them. Open the set's settings to opt in.

What to Expect During Chain Promotion

Promotion is local-IO heavy and network-light. Expect CPU and disk activity while the chain is reassembled into a temporary VHDX, followed by a chunk-pipeline stream that is roughly 99% dedup hits. The manifest that lands has chain_index=0 (new chain root), no parent_manifest_id, and a fresh reference_checkpoint name in the format BackupEngine-Reference-<setId>-synthetic-<ts>.

  • •Local temp space: enough for the reassembled VHDX (sum of chain entries, bounded above by full VHDX size).
  • •Network: tiny — only chunks that hash to values not already in cloud storage are uploaded.
  • •Time: bound by local disk throughput, not network.
  • •Outcome: a clean new chain root ready for the next incremental.

Edge Case — VM Deleted Mid-Promotion

If the source VM is deleted while a synthetic full is in progress, the synthetic full still completes and uploads. The resulting manifest is flagged "no incrementals possible until next full" because there is no live VM to take a fresh checkpoint against. The next backup of this set will be a true live-VHDX full (which will fail with "VM not found" if the VM is still gone).

Schedule Recommendations

  • •Full weekly on Sunday + incremental daily Monday through Saturday is a typical pattern for production VMs.
  • •Chain length cap of 7 (the default) keeps merge time bounded during restore — a longer chain means more diffs to walk.
  • •For very large or churn-heavy VMs, lower the cap to 3 or 4 so promotion runs more often and individual restores stay fast.
  • •For low-churn VMs, you can safely raise the cap; promotion is cheap because dedup keeps bandwidth near zero.

💡 Tip

Chain restore time grows linearly with chain length. If you optimize for restore RTO, lower the cap; if you optimize for backup throughput, the default 7 is fine.
Hyper-V VM BackupSQL Server Backup