VMFS metadata recovery

Power loss can leave VMFS metadata inconsistent even when the virtual-disk payload still exists on the LUN.

A torn or lost metadata write can prevent ESXi from mounting a VMFS datastore after a power, fabric, HBA, or backend storage incident. vCenter may show zero capacity or an inaccessible volume while many VMDK blocks remain present.

Start a recovery case Call 682-325-7712

Understand the symptom

VMFS depends on coordinated volume, resource, file, and allocation metadata.

WHY

What is happening

A datastore mount can fail when resource clusters or other control structures no longer describe the on-disk state consistently. Recovery distinguishes path loss from metadata corruption, protects the LUN, and correlates VMFS records with VMDK descriptors, extents, snapshots, and guest structures rather than creating a new empty file system.

What you may see

Symptoms that change the recovery path.

Datastore reports 0 B

The device is visible but capacity or VMFS metadata cannot be read correctly.

Cannot open volume

ESXi detects the LUN yet refuses to mount the datastore.

VMFS corruption messages

vmkernel or vobd reports damaged resource-cluster or on-disk metadata.

VMs become inaccessible together

Multiple guests disappear because their shared datastore cannot be traversed.

Protect the source

Actions that can make the situation worse.

Creating a new datastore overwrites metadata

Fresh VMFS structures can replace allocation evidence and file records.

VOMA repair on mounted storage is unsafe

VMware requires the datastore to be unmounted for analysis and repair operations.

Rescan and host retries do not repair torn writes

Repeated discovery can add noise without preserving the incident state.

Do this now

Safe steps before evaluation.

Stop datastore writes

Power off or isolate dependent workloads when that can be done without writing to the affected LUN.

Capture array and host evidence

Save vmkernel, vobd, HBA, fabric, controller, UPS, and storage-event timelines.

Take a storage-level snapshot

Protect the LUN before VOMA, restore, resignature, partition, or datastore operations.

Inventory every VM file

Record accessible VMX, VMDK, snapshots, directories, UUIDs, sizes, and priority guests.

NEPFOSYS process

How a data-first evaluation proceeds.

Path-versus-metadata triage

NEPFOSYS verifies device visibility, partitioning, VMFS identity, and storage-path history.

Datastore reconstruction

VMFS metadata and surviving file extents are evaluated on protected LUN copies.

Guest-level verification

Recovered virtual disks are tested through partitions, file systems, databases, and requested data.

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 VOMA repair VMFS corruption?

It can analyze and sometimes repair supported metadata faults, but the datastore should be unmounted and a protected LUN copy should exist first.

Why does the datastore show 0 B?

ESXi may see the device but be unable to interpret VMFS capacity or resource metadata.

Should I recreate VMFS and restore VMs later?

Only after all required data is safely migrated, recovered, or backed up. Recreation overwrites the existing datastore structures.

DFW local · Nationwide mail-in

Protect the device. Start with the facts.

Start my recovery case