Datastore missing or will not mount
The hypervisor sees the storage device differently, reports an unknown filesystem, or no longer presents the expected datastore.
Missing-datastore guidance →Virtualization recovery
Recover virtual machines and datastores after the backing storage fails.
When VMware or another virtualized environment loses a datastore, virtual disk, or backing RAID volume, ADR evaluates the physical and logical storage layers before attempting VM-level repair.
Record the hypervisor, datastore, backing storage, RAID/controller, virtual-disk formats, symptoms, and actions already attempted.
Backing storage firstRAID, SAN, NAS, or local disks
Datastore reconstructionBefore VM repair
Priority-VM focusRecover what the business needs
Remote or in-labBased on source condition
Recognize the failure
The VM symptom may originate several layers below the guest operating system.
A missing VMDK or unavailable virtual machine can result from the datastore, filesystem, RAID, controller, NAS, SAN, or physical members that support it.
Virtual disks are missing
VM configuration remains but one or more virtual disks, extents, descriptors, or snapshot-chain members cannot be opened.
VMDK-chain guidance →Backing RAID volume disappeared
The host cannot see the logical volume after reboot, power loss, controller change, or rebuild failure.
Missing virtual-disk guidance →VMs fail after storage recovery
The RAID or datastore is online, but guest filesystems, databases, or virtual disks are inconsistent after reconstruction.
Post-storage VM guidance →Snapshot chain is incomplete
Descriptors, delta disks, parent references, or extents no longer form the expected VM state.
Snapshot-chain guidance →Multiple storage members failed
The NAS, SAN, or local RAID backing the datastore exceeded fault tolerance or became unstable during repair.
Multiple-member guidance →A controlled recovery path
Reconstruct the foundation before extracting virtual machines.
- 1
Map the dependency chain
Identify host, datastore, filesystem, virtual disks, snapshots, backing RAID, and physical members.
- 2
Protect the sources
Preserve storage configuration and image unstable members before repeated scans or reconstruction.
- 3
Recover datastore and disks
Reconstruct the backing volume and datastore, then evaluate virtual-disk extents and snapshot relationships.
- 4
Verify priority VMs
Check guest filesystems, databases, and application data rather than assuming a VM that opens is complete.
Choose the recovery location and scope
The objective may be selected VMs, databases, or files—not the entire environment.
ADR can prioritize the systems carrying the greatest business impact. Stable logical cases may qualify for remote recovery; unstable backing storage requires protected imaging or physical escalation.
Follow the failure to the right service
Choose the path that matches the failed layer.
Storage failures often cross controller, RAID, filesystem, virtualization, and application boundaries. These services connect the next layer without asking the failed system to make another decision.
Backing-array failureRAID recoveryWhen the datastore disappeared because its local, SAN, or NAS RAID is offline or uncertain.Review this recovery path →Onsite recovery pathRemote RAID recoveryFor stable backing storage with suitable access and separate destination capacity.Review this recovery path →Database workloadSQL database recoveryWhen a recovered VM opens but its database remains pending, corrupt, or unable to attach.Review this recovery path →
Before another repair attempt
Describe the hypervisor, backing storage, and missing workloads.
ADR will determine whether the case begins at the RAID, datastore, virtual-disk, guest filesystem, database, or application layer.