Recovery methodsTechnical

SAN Storage Stack Reconstruction

SAN recovery starts by mapping the whole path from physical disks to the application that actually uses the data — a missing layer in the middle of that path can make perfectly intact storage look gone.

Map the full stack before touching anything

A SAN commonly stacks RAID or erasure-coded groups, a storage pool, thin or deduplicated allocation, snapshots and clones, a LUN, target-to-host mapping, a host file system such as VMFS, NTFS, ReFS or XFS, and finally virtual machines or application data on top of that. See Understanding Storage Layers Before Recovery for the general layered model this follows. Every layer here carries its own metadata and, often, its own snapshots — recovering one layer is not the same as recovering the one above it.

Presentation failure is not storage failure

A host can lose a LUN because of iSCSI target configuration, network connectivity, Fibre Channel zoning, LUN masking, initiator authorization, a multipath or path failure, controller ownership or failover, or a lost target-to-LUN mapping — while the backing LUN and its data remain completely intact. Treat “the host can’t see the disk” as a presentation question first, not as proof the storage pool was destroyed.

VMFS and VMDK add their own layers

A typical chain continues: SAN pool, LUN, VMFS datastore, VMDK, guest file system, then the actual database or files inside the guest. Recovering a LUN is not the same as recovering the VM or the application running on it. VM-level snapshots have their own delta and parent-disk chains, entirely separate from any snapshot the array itself took of the LUN, and VMware’s own documentation is explicit that snapshots are not backups.

Dual-controller failover changes what “current” means

Dual-controller SAN systems add controller ownership, mirrored or otherwise protected cache, failover events, ALUA/path states, multipath behavior and firmware interaction on top of the storage stack itself. Capture which controller owned the LUN before the failure and which owned it after, the failover timestamp, cache state, any battery or capacitor warnings, host multipath logs, and controller event logs — a controller failover alone can cause presentation loss with no physical RAID failure at all.

Encryption is a separate recovery problem from reconstruction

Encryption can be applied at the NAS shared-folder or volume layer, at a self-encrypting-drive pool, at the SAN array or controller layer, or at the host layer through BitLocker, LUKS or VeraCrypt. A perfectly reconstructed LUN sitting behind any of these will expose only ciphertext. Identify where the encryption actually occurs, where the keys are kept, the passphrase or recovery key, any key manager or HSM involved, the controller’s security configuration, and any self-encrypting-drive credentials, before assuming reconstruction alone will produce readable data.

Expansion enclosures can look like simultaneous disk failure

A storage pool can span the main chassis, a vendor expansion unit, a JBOD shelf, a SAS expander, or an external RAID enclosure. A single disconnected enclosure can make many member disks disappear at once while every physical disk remains completely healthy. Capture the enclosure model and serial, its enclosure ID, the slot map, cabling, which RAID groups span which enclosures, and the timing of the last known enclosure connectivity event.

Practical rule

Vendor support bundles and diagnostics are excellent for collecting evidence. Any write-capable repair action the same tooling offers is a separate decision that should wait until the full stack, from disks to application, has been mapped.