Recovery methodsTechnical

VHDX and QCOW2 Internal Metadata Recovery

Sparse virtual-disk formats carry their own allocation metadata and transactional structures — recovering the outer VHDX or QCOW2 file does not guarantee that its internal guest-block map is actually valid.

VHDX builds in redundancy from the start

Microsoft's VHDX specification defines a file identifier, two headers, two region tables, a metadata region, a Block Allocation Table (BAT), a log, payload blocks and sector bitmap blocks. The first 1 MB of the file holds the file type identifier plus both header copies and both region-table copies, though only one header is actually active at a time — sequence numbers and CRC-32C checksums determine which one is current and valid. VHDX was specifically designed so that critical metadata updates can survive an interrupted write through this redundant header-and-log structure.

The BAT is the logical-to-physical map

The Block Allocation Table carries one entry per virtual payload block, recording its allocation state and host file offset. A BAT entry can also mark a block as simply not present, which for a differencing disk means “retrieve this logical data from the parent instead.” BAT corruption can therefore leave payload blocks physically present on disk while making them logically unreachable, because the map connecting virtual address to physical offset is what actually broke, not the payload itself.

Differencing disks can be sector-granular within one block

Microsoft documents sector bitmap blocks for differencing VHDX, where each bit inside a partially present payload block decides whether that specific sector comes from the child or has to be retrieved from the parent. This goes deeper than simple block-level inheritance: a single virtual block in a VHDX differencing chain can combine child and parent data sector by sector, which is exactly why ad-hoc concatenation of VHDX files can never substitute for actually interpreting the format's own structures.

The parent locator identifies where the parent actually lives

VHDX Parent Locator metadata describes the identity and location of the parent virtual device, and Microsoft's specification explicitly allows that parent to be another VHDX, a different virtual disk type entirely, or another logical block device. Recovery should preserve the child, the parent, the metadata region, the parent locator, the virtual disk ID and any path information exactly as found — and should not “repair” the parent locator before those original values have been preserved somewhere safe.

The VHDX log is transactional metadata recovery

Microsoft's VHDX log specification includes log entries, sequence numbers, checksums, descriptors and logged data or zero writes. When a non-empty log exists, a compliant implementation must identify the newest valid, complete log sequence and replay it before any normal I/O proceeds — conceptually similar to filesystem journaling. A VHDX that looks metadata-inconsistent after a crash may simply need that valid log sequence replayed to reach the state it was actually left in, rather than needing any deeper repair at all.

Log replay validates a coherent sequence, not just the newest sector

Microsoft's replay algorithm validates signature, checksum, sequence continuity, tail and head markers, the log GUID, and file offsets before trusting a log sequence; if no valid active sequence can be found, the VHDX is considered corrupt. This reinforces a theme that recurs across this entire site: newest readable metadata alone is not enough on its own — transaction continuity is what actually decides whether a sequence can be trusted.

QCOW2 is its own copy-on-write mapping format

QEMU documents QCOW2 with a header, an L1 table, L2 tables, a refcount table and refcount blocks, an optional backing file, and a snapshot table. A guest cluster address resolves through an L1 entry into the appropriate L2 table, which then yields the actual host cluster; if a cluster is unallocated in the current image and a backing file exists, the read falls through to that backing file instead — the same layered block-address translator pattern that VMDK and VHDX chains both use, expressed through QCOW2's own structures.

Refcounts decide ownership, not just cosmetic bookkeeping

QEMU documents a refcount of 0 as free, 1 as used by exactly one owner, and 2 or more as shared — meaning a write to that cluster requires copy-on-write first. Corrupt refcount metadata is a real recovery hazard: it can cause leaks, double allocation, overwrite risk, or a false read of which clusters are actually free, since the refcount table is what the format itself relies on to know whether a cluster can be safely reused.

Internal snapshots and backing chains are different mechanisms

QCOW2 internal snapshots preserve an alternate L1-table state inside the very same file, which is structurally unrelated to an external QCOW2 child pointing at a separate backing file or raw base image through its own backing-file reference. “QCOW2 snapshot” should never be treated as one single mechanism — an internal snapshot is an alternate mapping table inside one file, while an external backing chain spans multiple files entirely.

Practical rule

Recovering the outer VHDX or QCOW2 file is not the finish line. Validate the BAT, sector bitmaps, L1/L2 tables and refcounts before trusting that the guest-visible disk is actually coherent.