Enterprise failures are almost always a chain rather than an event — a disk, then a rebuild, then a failover that did not complete cleanly. The disks themselves are frequently healthy; what has been lost is the map that made sense of them. Reconstruction works from the bottom up through every layer the vendor stacked, and each layer depends on the one beneath it being right, which is why the full shelf in its original order matters more than any single component.
$ cdr diagnose /dev/san → Array: Dell EMC Unity · 24 × 1.8 TB · RAID 5 → Status: POOL OFFLINE — 2 disks failed in pool → Client: confidential · Cambridge CB2 $ cdr engineer-working → Member disks: all 24 imaged read-only → Storage pool: rebuilt off the array → LUNs: remapped · volumes back $ cdr verify → ✓ datastores — 31 TB → ✓ VMs — restored → ✓ SAN recovered — data back
It fails in sequence, and reconstructing it means unwinding that sequence in the order it happened.
The typical SAN incident is not a catastrophe. It is a disk failing, then a rebuild starting, then a second disk dropping under the rebuild load, then a controller failover that did not complete cleanly, then somebody power-cycling the shelf to see whether that helps. Each step is individually reasonable and the cumulative result is a storage pool that will not assemble.
What makes this different from ordinary RAID work is the layering. Physical disks form a RAID group; the group feeds a storage pool; the pool is carved into LUNs, usually thin provisioned; each LUN carries a file system or a datastore. Recovery works upward through every one of those, and each layer depends on the one beneath being reconstructed correctly first. Get the pool geometry wrong and the LUNs above it are meaningless.
Disk order, stripe geometry and parity arrangement across the member disks, exactly as with any array — but frequently across several shelves rather than one chassis.
How the RAID groups combine into a pool, where the vendor wrote its own structures, and what reserved regions exist. This is where vendor-specific knowledge matters most.
Which pool extents belong to which LUN. On thin-provisioned storage this map is the critical structure — without it the pool is a pile of blocks with no way to know what belongs where.
NTFS, VMFS, ext4 or a datastore holding virtual machines. Only reachable once every layer beneath has been correctly reassembled, which is why this is the last step and not the first.
SAN work in this region comes almost entirely from two places. Milton Keynes and the northern distribution estates run genuine enterprise storage behind warehouse management and ERP, and when a controller pair fails or a LUN goes offline the volumes involved are measured in tens of terabytes. The other source is institutional — research computing estates where a storage tier has become detached from its metadata.
Both are reconstruction problems rather than repair problems. The disks are frequently healthy; what has been lost is the map. Send the full shelf in order, with whatever configuration documentation still exists.
Every member, every shelf. Enterprise layouts stripe across the whole set, and several platforms will not assemble at all with a member missing. Partial sets are the most common reason a SAN job stalls before it starts.
Enterprise storage recovery starts at £1,250 +VAT and is quoted individually above that, because member count, capacity and platform vary far more here than on single arrays.
What does not vary is the arrangement: one figure agreed in writing before work begins, and it does not move afterwards. No percentage of the data and no hourly rate.
Then the problem is in the mapping rather than the media, which is the usual case. Thin-provisioning tables and pool metadata are the structures that fail here, and they are reconstructable given the full member set.
Almost certainly not. Controllers hold configuration, not data. Once the on-disk layout is identified the volumes are reassembled without the original hardware, which is exactly what this work consists of.
Every disk, yes, in its original shelf and slot order. Several platforms stripe metadata across the entire set and will not assemble without every member present.
Then reconstruction runs one layer further — pool, LUN, VMFS, then the VMDK files inside it. Virtual machines are extracted and repaired as guests rather than as flat files, so they boot rather than merely existing.
Ten to twenty working days is typical. Imaging tens of terabytes takes real time, and reconstruction cannot begin until every member is imaged. You get a realistic date with the written verdict rather than an optimistic one.
Work is in-house, nothing is subcontracted, no data leaves the UK and one named engineer handles the job throughout. We will sign your own confidentiality terms before the equipment arrives.
From £1,250 +VAT, quoted per array — member count, shelf configuration and vendor format all move the figure, which is why this one is scoped rather than listed. A 50% deposit applies, with the balance on success.