The backup job ran last night and came back red. The VM is up, users are working, nothing looks wrong from the outside — but the protection you thought you had didn’t happen. A failed Hyper-V backup is one of those problems that stays quiet until the day you actually need the restore.
Almost every Hyper-V backup failure traces back to one of a few places: a VSS writer that went into a failed state, integration services that are out of date, the wrong checkpoint type, a volume that ran out of room, or a leftover AVHDX from a previous job that never merged. The backup tool on top — whether it’s Windows Server Backup or a third-party agent — mostly just reports what Hyper-V and VSS told it. So the fix is to work down the same chain those components use, in the order that finds the fault fastest.
Read the actual error first
Before changing anything, get the real error code. “Backup failed” in a dashboard tells you nothing; the underlying VSS or checkpoint error tells you everything. Two places to look:
- The backup software’s own log. It almost always names the VM that failed and a VSS or Hyper-V error, often a hex code or a writer name.
- The Hyper-V logs in Event Viewer. Go to Applications and Services Logs → Microsoft → Windows → Hyper-V-VMMS and Hyper-V-Worker, and check the standard Application log for VSS events around the time of the job.
# Pull recent Hyper-V VMMS and Worker errors from the last day
Get-WinEvent -FilterHashtable @{
LogName = "Microsoft-Windows-Hyper-V-VMMS-Admin","Microsoft-Windows-Hyper-V-Worker-Admin"
Level = 1,2,3
StartTime = (Get-Date).AddDays(-1)
} | Format-List TimeCreated, Id, LevelDisplayName, MessageCause 1: A VSS writer is in a failed state
Hyper-V backups rely on the Volume Shadow Copy Service to capture a consistent point in time. If a writer — on the host or inside the guest — is failed, timed out, or stuck, the snapshot can’t be taken and the job dies.
Check the writers from an elevated prompt:
vssadmin list writersEvery writer should report:
State: [1] Stable
Last error: No errorAnything else — Failed, Timed out, Waiting for completion that never clears — is a
problem. The Hyper-V backup depends on the Microsoft Hyper-V VSS Writer on the host and the
standard writers inside the guest (System Writer, Registry Writer, and for app-consistent
backups, things like the SQL writer).
A failed writer usually clears by restarting the service that owns it. When you’re not sure which service that is, a reboot resets every writer cleanly:
# Example: the System Writer lives in Cryptographic Services
Restart-Service -Name CryptSvc
# The Hyper-V host writer is part of the management service
Restart-Service -Name vmmsCause 2: Integration services are missing or outdated
The guest cooperates with host backups through Hyper-V integration services, and the Backup (volume shadow copy) integration service in particular. If it’s disabled, or the guest’s integration components are old, the host can’t trigger an in-guest VSS snapshot and falls back to a crash-consistent backup — or fails outright.
Confirm the integration service is enabled for the VM:
Get-VMIntegrationService -VMName "MyVM" |
Format-Table Name, Enabled, PrimaryStatusDescriptionThe VSS (Backup) service should be Enabled: True with a status of OK. Enable it if it’s
off:
Enable-VMIntegrationService -VMName "MyVM" -Name "VSS"On modern Windows guests, integration services update through Windows Update. Older guests
(Server 2012 R2 and similar) may need the components refreshed inside the VM. Linux guests rely
on the kernel’s hv modules and the hyperv-daemons package — if those aren’t present, the guest
can’t do an online, application-consistent backup and the host will either degrade to a saved-
state backup or fail depending on the tool.
Cause 3: Standard vs production checkpoints
This one trips people up because both are called “checkpoints.” A production checkpoint uses VSS inside the guest to create an application-consistent, restorable image — which is exactly what backup software wants. A standard checkpoint captures live memory and device state, which most backup tools refuse to use.
Check and set the checkpoint type:
# See the current setting
Get-VM -VMName "MyVM" | Select-Object Name, CheckpointType
# Set production checkpoints, and allow fallback to standard if VSS isn't available
Set-VM -VMName "MyVM" -CheckpointType ProductionOnly
# or, to let it degrade gracefully instead of failing:
Set-VM -VMName "MyVM" -CheckpointType ProductionProductionOnly fails the backup if VSS can’t run in the guest, which is useful when you must
have an app-consistent backup. Plain Production falls back to a standard checkpoint instead of
failing — handy for guests that can’t do VSS, but be aware the resulting backup is only crash-
consistent. If you’re already chasing checkpoint creation errors specifically, the dedicated
guide on why Hyper-V checkpoints fail covers that path in more
detail.
Checkpoint types and what they mean for backups
| Production (recommended) | VSS-based, app-consistent; falls back to standard if VSS fails |
|---|---|
| ProductionOnly | VSS-based; the backup FAILS if VSS can't run in the guest |
| Standard | Saves live memory/device state; usually rejected by backup tools |
Cause 4: The volume is out of free space
Creating a checkpoint writes a differencing disk (AVHDX) next to the VHDX, and that file grows with every change made during the backup window. When the job finishes, Hyper-V merges the AVHDX back into the parent — which also needs room. If the volume holding the VM’s disks is nearly full, either the checkpoint can’t grow or the merge can’t complete, and the backup fails.
Check free space on the volumes that hold your VHDX files:
Get-Volume | Where-Object DriveType -eq "Fixed" |
Format-Table DriveLetter, FileSystemLabel,
@{N="Free(GB)";E={[math]::Round($_.SizeRemaining/1GB,1)}},
@{N="Size(GB)";E={[math]::Round($_.Size/1GB,1)}}There’s no single magic number, but plan for the VM’s change rate during the backup. A quiet file server might only churn a few GB; a busy database VM can write far more. As a working rule, keep at least 10-20% of the disk free, and more for write-heavy VMs. If the target backup volume is also tight, the job can fail at the write stage rather than the snapshot stage — so check both the source and destination.
Cause 5: Leftover AVHDX files from an interrupted job
This is the failure that compounds. A backup creates a temporary checkpoint, and when the job is interrupted — a crash, a timeout, a host reboot mid-backup — the AVHDX differencing disk can be left behind. The VM keeps running, but it’s now writing to an orphaned differencing chain instead of the base disk. That chain grows, free space disappears, and the next backup fails for a reason that looks unrelated.
First, see whether the VM is running off a differencing disk it shouldn’t be:
# List the disks attached to the VM and what they point at
Get-VMHardDiskDrive -VMName "MyVM" | ForEach-Object {
Get-VHD -Path $_.Path | Select-Object Path, VhdType, ParentPath
}If Path ends in .avhdx and there’s a ParentPath, the VM is on a leftover checkpoint chain.
The clean fix is to merge it back into the parent. In Hyper-V Manager, deleting the stray
checkpoint triggers the merge automatically; if there’s no checkpoint listed but the AVHDX is
still attached, you have an orphaned file that needs a manual merge. The full procedure —
including how to merge safely while the VM is off — is in the guide on
merging Hyper-V AVHDX checkpoint files.
Cause 6: Permissions and service accounts
When the writers are stable, integration services are on, there’s plenty of room, and the disks are clean, the remaining suspect is access. The backup process needs rights to the VM’s configuration and to the folders holding the VHDX files. This shows up most after VMs are moved, restored to a new path, or when a third-party agent runs under a service account that wasn’t granted access to the new storage location.
Things to confirm:
- The backup service or agent account can read and write the VM’s storage path.
- The VM’s own files are owned by the right SIDs — Hyper-V uses per-VM virtual accounts
(
NT VIRTUAL MACHINE\<GUID>). If files were copied or restored with a tool that stripped those ACLs, the VM may run but fail to snapshot. - On a cluster, the backup runs against the node that owns the VM; pointing it at the wrong node produces access and ownership errors.
If you moved or restored a VM and backups started failing right after, re-apply the correct permissions to the storage folder rather than loosening ACLs broadly.
The fast path
When a Hyper-V backup fails and you want the shortest route to the cause:
Backup failure troubleshooting order
- Read the real error in the backup log AND the Hyper-V-VMMS/Worker event logs
- Run vssadmin list writers; reset any writer that isn't Stable / No error
- Confirm the VSS (Backup) integration service is enabled and up to date in the guest
- Check the VM uses Production checkpoints, not Standard
- Verify free space on both the source VHDX volume and the backup target
- Look for leftover AVHDX chains and merge them back into the parent
- If all else is clean, check storage-path permissions and the backup service account
Most failures land on steps 2 through 6. VSS writers and disk space account for the majority; leftover AVHDX files account for the ones that “started failing for no reason.” Work top to bottom and you’ll rarely need the last step.
Wrapping up
A failed Hyper-V backup is almost never random. Read the error, check the VSS writers, confirm integration services and the production checkpoint type, make sure there’s room for the checkpoint and its merge, and clear any orphaned AVHDX chains before they snowball. Permissions are the quiet edge case, usually after a VM move or restore.
The habit worth building: don’t treat a green dashboard as proof. Test a restore on a schedule, because a backup that never restores is just a job that turns red later. For related disk and checkpoint work, the virtualization guides cover checkpoints and AVHDX merges in depth.
