Proxmox VM recovery

A missing Proxmox VM disk is a storage-mapping problem before it is a guest-filesystem problem.

Proxmox VE can store VM disks as raw volumes, qcow2 files, ZFS zvols, LVM-thin volumes, Ceph RBD images, or files on shared storage. Recovery starts by identifying the actual backend and the VM disk mapping.

Start a recovery case Call 682-325-7712

Understand the symptom

The VM configuration, storage backend, and guest filesystem form separate recovery layers.

WHY

What is happening

A VM can disappear from the interface while its disk blocks still exist, or remain listed while the backend volume is missing. LVM-thin metadata, ZFS pool state, Ceph placement, directory paths, snapshots, and replication history determine where blocks belong. Starting a recreated VM or restoring over the same ID can allocate new data on the storage being recovered.

What you may see

Symptoms that change the recovery path.

Volume does not exist

The VM configuration references a volume ID the storage backend cannot currently resolve.

Storage shows inactive

A failed mount, pool, thin pool, network target, or cluster service can hide every VM on that backend.

VM disk appears unused

Configuration changes may detach a surviving disk without deleting its underlying volume.

Snapshot chain will not start

A missing base, overlay, parent snapshot, or metadata record can break the virtual disk chain.

Protect the source

Actions that can make the situation worse.

New volume reuses extents

Creating a replacement can overwrite blocks from the missing VM disk.

Restore can target the source

A backup restore to the affected pool changes allocation and metadata needed for recovery.

Snapshot deletion merges data

Removing snapshots can trigger large writes and alter the only surviving chain.

Do this now

Safe steps before evaluation.

Stop writes to the backend

Pause VMs, replication, backups, migration, trim, and new volume creation on affected storage.

Export configuration

Preserve storage.cfg, VM and container configs, cluster information, volume lists, and task logs.

Identify the exact backend

Record whether the disk used ZFS, LVM-thin, Ceph, NFS, iSCSI, directory, or another storage type.

Protect physical members

Label and image unstable disks before attempting pool, volume, or virtual-disk repair.

NEPFOSYS process

How a data-first evaluation proceeds.

Configuration-to-storage mapping

NEPFOSYS correlates VM IDs, volume IDs, snapshots, and backend metadata.

Virtual disk reconstruction

Surviving extents or files are assembled into a protected VM disk image where possible.

Guest data validation

Partitions, filesystems, databases, and requested files inside the reconstructed disk are evaluated by priority.

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 the VM configuration enough to recover the disk?

No, but it identifies expected volume IDs, controllers, snapshot references, and storage targets that guide reconstruction.

Can a qcow2 snapshot chain be recovered?

Potentially, when the base and overlay files are present and their relationships can be verified. Preserve every chain member.

Should I restore a backup to the failed storage?

No. Restore to separate healthy storage so the affected pool and its unallocated space remain unchanged.

DFW local · Nationwide mail-in

Protect the device. Start with the facts.

Start my recovery case