Hyper-V virtual disk recovery

A Hyper-V recovery must preserve the VHDX base disk and every checkpoint relationship.

A virtual machine may fail because of physical storage, RAID, CSV or ReFS damage, a missing VHDX, a broken AVHDX checkpoint chain, an interrupted backup merge or corruption inside the guest.

Understand the symptom

Hyper-V checkpoints form a parent-child disk chain that represents the current guest state.

WHY

What is happening

A base VHDX can have one or more differencing AVHDX files created by checkpoints or backup software. Each child references a parent and contains newer changed blocks. Missing, renamed, mismatched or partially merged files can break the chain. The virtual storage may also sit on RAID, SMB, iSCSI, Cluster Shared Volumes, Storage Spaces or ReFS, so lower-layer health must be established before repairing virtual metadata.

What you may see

Symptoms that change the recovery path.

01

VM cannot find the virtual disk

Paths, permissions, storage presentation or a chain member may be missing.

02

Checkpoint merge failed

A backup or deletion operation may have stopped with AVHDX files still active.

03

Parent identifier mismatch

The differencing disk references a parent whose ID, path or state no longer matches.

04

VM boots to file-system or database errors

The chain may attach while guest data remains inconsistent after an abrupt event.

Protect the source

Actions that can make the situation worse.

01

Manual AVHDX deletion loses newer blocks

Checkpoint files can contain the only current version of changed guest sectors.

02

Merge writes to parent disks

An incorrect or interrupted merge can alter the base and collapse useful recovery states.

03

Powering on changes the guest

Boot writes logs, journals, updates and application data into the current disk chain.

Do this now

Safe steps before evaluation.

01

Stop VM and backup activity

Prevent restarts, checkpoint creation, merge retries, replication and storage migration.

02

Copy the complete folder inventory

Preserve VHDX, AVHDX, VM configuration, runtime state, logs and backup metadata.

03

Map storage dependencies

Document host, cluster, CSV, RAID, SAN, SMB, ReFS, snapshots and recent failures.

04

Set workload priorities

Identify critical guest files, databases and the minimum useful recovery point.

NEPFOSYS process

How a data-first evaluation proceeds.

01

Stabilize underlying storage

Physical disks, RAID, volumes and file systems are protected before virtual-disk changes.

02

Reconstruct the checkpoint chain

Parent IDs, paths, generation order and merge state are analyzed on copies.

03

Validate guest applications

Recovered virtual disks are checked for file-system and application consistency in isolation.

A clear next step

Preserve the original device before another repair or recovery attempt.

Start a case with the exact symptoms, incident timeline, prior attempts, encryption details, and the files that matter most. NEPFOSYS will route the case to the appropriate DFW intake or nationwide mail-in path.

Start with a case review

Questions, answered

What customers ask before starting.

Can I delete old AVHDX files to free space?

No. An AVHDX may contain current guest blocks that have not been merged into its parent. Deleting it can remove part of the virtual disk state.

Should I retry Merge-VHD immediately?

Not on the only copy when the chain or underlying storage is damaged. Preserve the complete chain and verify parent relationships first.

Is a bootable VM proof that recovery is complete?

No. Guest file systems, databases and applications can be inconsistent even when the virtual disk attaches and starts.

DFW local · Nationwide mail-in

Protect the device. Start with the facts.

Start my recovery case