VMware, Hyper-V and SAN Data Recovery for Companies

Virtualisation failures are rarely a single-file problem. A missing datastore may involve controller metadata, a broken RAID set, unstable SAS/SATA media, a failed NAS head, a damaged VMDK/VHDX chain or stale snapshots after a power event. In business cases around Warsaw and across Poland, our role is to make the incident reversible before recovery work begins.

Most common failure scenarios

In virtualised environments, symptoms often look like a software issue even when the root cause sits lower: in RAID metadata, a SAN path, a NAS head, a controller cache, a member disk or a damaged datastore structure.

• ESXi or Hyper-V stops seeing a datastore, CSV or LUN after restart.
• A LUN is visible, but the VMFS volume cannot be mounted safely.
• The array returns I/O errors, path flapping, APD/PDL events or disappearing devices.
• A rescan, import or migration was started during an already unstable incident.
• A power loss damaged datastore metadata, VM snapshots or VMDK/VHDX chains.

What not to do in production

• Do not run VMFS repair, CHKDSK or datastore repair tools on the only production copy.
• Do not mount the LUN as read/write on another host just to see what happens.
• Do not reinitialise, resignature, import or rebuild the storage layer before preserving logs and disk order.
• Do not copy random VM files from a datastore that reports I/O errors.
• Do not assume that snapshots are a backup when the storage layer itself is failing.

Why server and SAN failures are risky

Hypervisors and storage arrays are designed to keep services online, so they often keep retrying a failing path. That can be useful in normal operation, but dangerous during data loss. A forced rescan, rebuild, VMFS repair or LUN remount may overwrite metadata that explains how the environment was assembled.

What a safe recovery workflow looks like

We start by mapping the architecture: physical disks, RAID level, storage controller, SAN/NAS layer, hypervisor, datastore format and virtual-machine inventory. When media is unstable, each source disk or LUN is imaged first. Recovery then happens from verified copies, not from the only production evidence.

That workflow matters when a VMware datastore disappears after restart, Hyper-V reports a damaged CSV, a SAN presents the wrong LUN, or a RAID controller imports the array with a suspicious disk order. Guessing disk order or forcing a controller to repair things can turn a structured incident into a much harder reconstruction.

When to involve a lab immediately

• critical VMs, databases, ERP systems or file shares live on the affected datastore,
• the failure followed power loss, migration, controller replacement or an interrupted rebuild,
• the host reports I/O errors, path flapping, APD/PDL events or disappearing LUNs,
• someone has already tried repair on production and the symptoms are changing,
• there is no current independent backup that has been restored and verified.

Safety rule:
Preserve the current state first. Use the contact form or call 573 532 490 before another rebuild, rescan or repair attempt.

What to prepare before handover

Useful evidence includes controller logs, NAS/SAN event logs, ESXi vmkernel messages, Hyper-V event IDs, datastore names, LUN IDs, screenshots of alarms, a list of disks in slots and information about the newest verified backup. Do not worry if the list is incomplete; the point is to avoid losing facts that are still available.

How to keep the incident organised before production turns chaotic

Assign one person to collect facts and pause improvised fixes. Write down which hosts saw the datastore, what changed before the failure, which VMs are critical and which backups were actually restored and verified. This makes the next technical decision cleaner and prevents conflicting actions from different administrators.

A simple priority list helps more than a long description: accounting database first, then ERP files, then shared folders, then archived VMs. If the environment is backed by RAID or NAS, keep the physical disk order and controller/NAS messages with the case notes.

When to seek external help

If the same incident keeps changing after each restart, import, rescan or repair attempt, stop treating it as routine administration. A virtualisation incident becomes a data recovery case when the storage layer is unstable, the controller metadata is suspect or the only available copy sits on the affected LUN/datastore.

That is especially important when a company cannot verify a current backup, the failure affects databases or many users, or previous actions already changed the visible state of the environment.

Related enterprise recovery guides

For the first incident checklist, read what to do after a company server or NAS failure in the first 24 hours. For a concrete storage-layer example, see the case study VMware ESXi cannot see the datastore after restart. If the virtualisation failure is backed by an array, compare symptoms with RAID/NAS data recovery.