Enterprise Storage Array Recovery
SAN Storage Data Recovery
We recover data from failed SAN arrays by extracting drives, imaging them through SAS HBAs, and reconstructing LUN layouts from vendor-specific on-disk metadata. Dell EMC, NetApp, HPE, Pure Storage. Free evaluation. No data = no charge.
How SAN Storage Arrays Fail and How We Recover Them
A SAN (Storage Area Network) presents block-level storage to host servers over iSCSI or Fibre Channel. The SAN controller manages RAID groups, thin provisioning, snapshots, and LUN mapping. When the controller fails or multiple drives in a RAID group degrade simultaneously, the LUNs go offline and all connected hosts lose access to their storage. Recovery requires extracting the physical drives, imaging them with SAS-aware hardware, and reconstructing the vendor-specific RAID group and LUN metadata from raw images.
The key distinction between SAN recovery and standard RAID recovery is the additional abstraction layers. A SAN controller maps physical drives into RAID groups, carves RAID groups into pools, and presents pools as LUNs. Each layer has its own metadata structure that must be reconstructed correctly. Standard RAID recovery tools designed for consumer NAS or Linux mdadm arrays cannot parse these vendor-proprietary formats.
Supported SAN Platforms and Their Storage Architectures
Each SAN vendor implements RAID, LUN mapping, and data placement differently. Below is how we approach recovery for each major platform.
Dell EMC Unity and VNX
Dell EMC Unity runs its own Unity Operating Environment (OE) on dual storage processors. Legacy CLARiiON and VNX1 systems used FLARE; VNX2 used MCx (Multi-Core Everything). Unity has a distinct storage stack. All three platforms write proprietary RAID metadata to reserved sectors on each member drive. RAID groups are carved into storage pools, which are thin-provisioned into LUNs.
- RAID types: RAID 5, RAID 6, RAID 1/0 with hot spares. Unity also supports dynamic RAID pools that distribute data across all drives in a pool.
- Sector format: VNX historically used 520-byte sectors on SAS drives. Unity supports both 512-byte and 520-byte depending on the drive model and firmware. Our imaging process auto-detects and preserves the native sector size.
- Common failure: Storage processor panic loop after firmware update. Both SPs reboot continuously, making all LUNs inaccessible. The drives themselves remain healthy.
NetApp FAS and AFF (ONTAP)
NetApp ONTAP uses WAFL (Write Anywhere File Layout), a copy-on-write filesystem that writes modified data to new disk locations on each consistency point. WAFL maintains consistency through consistency points (CPs) triggered at a default maximum interval of 10 seconds. The underlying RAID uses RAID-DP (double parity, similar to RAID 6) or RAID-TEC (triple parity for large aggregates).
- WAFL structure: Data blocks are organized into aggregates, which contain flexible volumes (FlexVols). Each FlexVol contains NFS exports or iSCSI LUNs. WAFL's write-anywhere design means data blocks are scattered across the aggregate rather than sequentially allocated.
- Sector format: NetApp uses 4KB block sizes internally on WAFL, typically on drives formatted with 520-byte sectors. ONTAP 9.x added support for 512e Advanced Format drives.
- Common failure: Multiple drive failures exceed RAID-DP parity tolerance. WAFL goes read-only, then offline if additional drives fail. Aggregate reconstruction requires all surviving members plus accurate RAID-DP geometry.
HPE Nimble and 3PAR
HPE Nimble uses a CASL (Cache Accelerated Sequential Layout) architecture that writes data sequentially to flash-backed cache, then destages to spinning disk in large sequential writes. 3PAR uses a chunklet-based architecture that distributes data across all physical drives in small (256MB on 3PAR) or larger allocations.
- Nimble recovery: CASL's sequential layout simplifies drive-level imaging because data is written in large contiguous blocks. The flash cache (SSD tier) must be imaged alongside spinning capacity drives to capture in-flight writes.
- 3PAR chunklets: 3PAR breaks every physical drive into chunklets (small fixed-size allocations). RAID groups are built from chunklets scattered across multiple drives. This fine-grained distribution requires precise chunklet mapping to reconstruct the virtual volume.
- Common failure: Controller node failure in a multi-controller 3PAR cluster. If the surviving node cannot assume ownership of all virtual volumes, LUNs go offline. The chunklet metadata is stored on dedicated metadata drives that must be identified and imaged first.
Pure Storage FlashArray
Pure Storage FlashArray is an all-flash platform that uses proprietary data reduction (deduplication and compression) with RAID-HA (a distributed RAID implementation). Data is written in variable-length segments after deduplication, making traditional RAID reconstruction insufficient.
- Deduplication-aware recovery: FlashArray stores deduplicated segments with a metadata index that maps logical addresses to physical segment locations. Losing the metadata index makes data unrecoverable through standard RAID methods. Recovery requires parsing Pure's proprietary segment tables.
- NVMe drives: Newer FlashArray//X and //XL models use NVMe DirectFlash modules. These require NVMe-capable imaging hardware, not SAS HBAs.
- Common failure: Controller pair failure with corrupted NVRAM cache. The NVRAM holds uncommitted writes that have been acknowledged to the host but not yet written to flash. Losing NVRAM can result in data loss for recent writes.
Non-Standard Sector Sizes in Enterprise SAN Drives
Enterprise SAN platforms commonly format SAS drives with 520-byte or 528-byte sectors instead of the standard 512-byte sectors used by consumer drives. The additional 8 or 16 bytes per sector carry T10 DIF (Data Integrity Field) checksums, reference tags, and application tags used by the SAN controller for end-to-end data integrity verification.
520-Byte Sectors (T10 DIF Protection)
Used by Dell EMC VNX/Unity, NetApp FAS, and older HP EVA arrays. Each sector contains 512 bytes of user data plus an 8-byte protection information field: 2-byte guard tag (CRC), 2-byte application tag, and 4-byte reference tag. The SAN controller verifies these checksums on every read and write.
528-Byte Sectors (Legacy Format)
Used by IBM DS8000, some Hitachi VSP configurations, and older mainframe-attached storage. The additional 16 bytes per sector include 8 bytes of T10 DIF-style protection plus 8 bytes of vendor-specific or legacy metadata fields inherited from mainframe CKD-to-FBA conversion. These sectors must be preserved during imaging to maintain RAID parity calculations that include the protection fields.
Consumer imaging tools that strip the extra bytes or zero-fill them will produce images that fail RAID reconstruction. Our imaging hardware preserves the full sector contents, including DIF fields, at the native sector size. For RAID reconstruction, PC-3000 RAID Edition accounts for the non-standard sector size when calculating parity and stripe offsets.
Common SAN Failure Scenarios
Controller Pair Failure
Both SAN controllers fail simultaneously (firmware bug, power event, or environmental failure). Drives are healthy but no controller is available to present LUNs. We bypass the controller entirely.
RAID Group Degradation
Multiple drives in a RAID group fail beyond the parity tolerance (two drives in RAID 5, three in RAID 6). The SAN marks the RAID group as faulted and the LUNs on it go offline.
Firmware Update Gone Wrong
Storage processor firmware update fails mid-write, corrupting the controller's internal configuration database. All RAID group definitions and LUN mappings become unreadable from the controller, but the on-disk metadata on each member drive is intact.
Cache Battery Failure
SAN write cache uses battery-backed or supercapacitor-backed RAM. When the battery fails during a power outage, uncommitted cached writes are lost. The SAN may force a full parity consistency check or refuse to bring LUNs online.
Accidental LUN Deletion
Administrator accidentally deletes a LUN or destroys a storage pool. The SAN controller marks the space as free, but the data remains on the physical drives until overwritten by new allocations. Stop all I/O to the pool immediately.
Environmental Damage
Flooding, fire suppression discharge, or HVAC failure causes condensation on drive platters or PCB corrosion. Individual members require board-level repair or head swaps before imaging can begin.
LUN Reconstruction and Destriping Methodology
This section details the technical process for IT administrators evaluating our capability to handle SAN-level recoveries.
1. Drive Extraction and Slot Mapping
Drives are extracted from the SAN chassis with precise slot labeling (enclosure ID, slot number). SAN controllers map drives to RAID groups by physical slot, so preserving this mapping is essential. We photograph each enclosure and label drives before removal. If the SAN uses multiple enclosures (DAEs/JBODs), each enclosure is documented separately with its SAS topology (SAS expander chain order).
2. SAS Imaging with Sector-Size Preservation
Each drive is connected to an imaging workstation through a SAS HBA (Host Bus Adapter). PC-3000 queries the drive's reported sector size and configures imaging accordingly. For 520-byte sector drives, the full 520-byte sector is captured; the extra 8 bytes are not stripped or modified. Imaging throughput for healthy SAS 10K/15K drives averages 150-200MB/s. Drives with media defects are imaged with head maps and adaptive retry parameters.
3. RAID Group Metadata Parsing
Each SAN vendor stores RAID group definitions in reserved sectors on the member drives. Dell EMC writes metadata in the last sectors of each drive (similar to DDF but proprietary format). NetApp stores RAID-DP geometry in the aggregate's WAFL metadata region. PC-3000 RAID Edition reads these metadata blocks and constructs a virtual disk definition: RAID level, stripe size (typically 64KB or 256KB for SAN arrays), member ordering, parity placement (left-synchronous, right-asynchronous), and rebuild state. For metadata-less scenarios (zeroed or overwritten metadata), we detect parameters through brute-force testing of stripe size and member order permutations against known filesystem signatures (NTFS MFT, VMFS superblock, ext4 superblock).
4. LUN Mapping and Thin Provisioning
After reconstructing the RAID group as a virtual disk, we map LUN extents within it. Traditional (thick-provisioned) LUNs occupy contiguous ranges within the RAID group and can be extracted by offset and size. Thin-provisioned LUNs use an allocation table maintained by the SAN controller that maps logical LUN blocks to physical RAID group blocks. We parse this allocation table from the controller's on-disk metadata to reconstruct the LUN. If the allocation table is damaged, we fall back to filesystem-level carving within the RAID group image.
5. Filesystem Extraction
The reconstructed LUN image is mounted read-only for filesystem extraction. Common filesystems on SAN LUNs include VMFS (for ESXi datastores), NTFS/ReFS (for Windows servers), ext4/XFS (for Linux hosts), and raw block devices for databases (Oracle ASM, SQL Server). For VMFS-backed LUNs, we hand off to our VMware ESXi recovery pipeline for .vmdk extraction. Database volumes are delivered as raw LUN images for the client's DBA to attach.
SAN Recovery Pricing
SAN recovery follows the same transparent pricing model as every other service: per-drive imaging based on each drive's condition, plus a $400-$800 reconstruction fee per RAID group. No data recovered means no charge.
| Service Tier | Price Range (Per Drive) | Description |
|---|---|---|
| Logical / Firmware Imaging | $250-$900 | Firmware module damage or SMART threshold failures on individual SAS members. Most healthy SAN drives fall in this tier. |
| Mechanical (Head Swap / Motor) | $1,200-$1,50050% deposit | Donor parts for SAS drives matched by model, firmware revision, head count, and preamp version. |
| RAID Group Reconstruction | $400-$800per RAID group | Metadata parsing, RAID reconstruction, LUN extraction, and filesystem mount. One fee per RAID group in the SAN. |
No Data = No Charge: If we recover nothing from your SAN, you owe $0. Free evaluation, no obligation.
Enterprise competitors charge $5,000-$15,000 with opaque "emergency" surcharges. We publish our pricing because the work is the same regardless of what label gets put on the invoice.
We sign NDAs for corporate data recovery. All drives remain in our Austin lab under chain-of-custody documentation. We are not HIPAA certified and do not sign BAAs, but we are willing to discuss specific compliance requirements before work begins.
SAN Storage Recovery; Common Questions
Can you recover data from a SAN with a dead controller?
What about SAN drives with non-standard sector sizes?
Do you recover Dell EMC Unity and VNX arrays?
Can you recover from NetApp FAS and AFF systems?
Does the SAN protocol (iSCSI vs. Fibre Channel) affect recovery?
How is SAN recovery priced?
Ready to recover your SAN array?
Free evaluation. No data = no charge. Mail-in from anywhere in the U.S.