QCOW2 image recovery

A QCOW2 repair should begin with the full backing chain and protected copies of every image layer.

QCOW2 can store data in an overlay while unchanged clusters remain in one or more backing images. Corruption, a missing parent, an incorrect rebase, or partial host-storage failure can make a VM unbootable or expose an incomplete point in time.

Understand the symptom

Consistency repair and backing-chain repair are different problems.

WHY

What is happening

qemu-img can inspect a backing chain and check supported image formats. Its repair modes modify the image, and QEMU warns that broad repair can choose an incorrect fix or hide existing corruption. A valid QCOW2 header does not prove that its parent path, cluster map, guest filesystem, or newest data layer is complete.

What you may see

Symptoms that change the recovery path.

01

Backing file not found

The overlay references a parent path or format that is unavailable or changed.

02

Image check reports corruption

QCOW2 metadata contains invalid, leaked, or inconsistent clusters.

03

VM boots to an older state

The overlay may be bypassed, detached, or linked to the wrong parent.

04

I/O errors occur at certain offsets

The QCOW2 layer or underlying host storage cannot return required clusters reliably.

Protect the source

Actions that can make the situation worse.

01

Repair modifies allocation metadata

qemu-img -r can change the source and may hide damage that needs forensic comparison.

02

Rebase can select the wrong parent

An incorrect backing image can silently supply unrelated sectors.

03

Commit writes into the base

Merging an overlay changes another chain member and reduces rollback options.

Do this now

Safe steps before evaluation.

01

Stop the guest and hypervisor writes

Do not boot, snapshot, commit, rebase, repair, or convert the affected image.

02

Collect the complete chain

Preserve overlays, backing images, libvirt or VM configuration, snapshots, logs, and original paths.

03

Record qemu-img info output

Capture format, virtual size, actual size, backing filename, chain order, and error messages without repair flags.

04

Protect the host filesystem

Image unstable disks or storage pools before running full-image checks.

NEPFOSYS process

How a data-first evaluation proceeds.

01

Backing-chain analysis

NEPFOSYS maps image metadata, parents, snapshots, timestamps, and guest-storage objectives.

02

Layer preservation

Every available image and the underlying host storage are acquired before modification.

03

Virtual disk reconstruction

Candidate chains are tested on copies and guest filesystems or priority data are extracted separately.

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.

Is qemu-img check read-only?

A check without repair flags is intended to inspect consistency, but the image and host storage should still be protected first. Repair modes modify supported formats.

Can I rebase to a file with the same name?

Name alone is insufficient. The parent must contain the exact expected sector state and format for that overlay.

Why keep every snapshot layer?

The newest guest data may be distributed across overlays and their parents. Removing one layer can make later sectors unavailable.

DFW local · Nationwide mail-in

Protect the device. Start with the facts.

Start my recovery case