A SAN is where an organisation puts the storage it can least afford to lose — dozens of disks, multiple controllers, LUNs carved up and served to servers full of virtual machines. When one fails, the scale is the problem: the data isn’t just spread across disks, it’s spread across a whole storage architecture that has to be reconstructed correctly. We recover enterprise SANs of every make for organisations across the UK, with priority handling and NDAs as standard. Disks by insured courier.
On a SAN, a wrong rebuild or a re-presented LUN can overwrite the very structure we need. Stop and image first.
A SAN takes everything that makes RAID recovery complex and multiplies it. Underneath are large disk arrays, but on top sits a storage layer that pools them, splits them into LUNs (the virtual volumes servers see), often thin-provisions those LUNs so they only occupy space as it’s used, and serves them over Fibre Channel or iSCSI to hosts running dozens of virtual machines. Your data is distributed not just across disks but across that whole architecture.
Recovering it means reconstructing every layer in order — the underlying RAID, the storage pool, the LUN mapping and provisioning, then the file systems and VMs on top — all offline, from images, and all from an understanding of how a specific vendor’s system lays data out. It’s among the most demanding work a recovery lab does, and it’s exactly the kind of large, layered reconstruction we handle.
Multiple disk failures. As with any array, redundancy runs out — a second or third disk fails in a degraded set and the storage goes offline. On a large SAN the odds of overlapping failures rise with the disk count.
Controller or storage-processor failure. The head unit or storage processor fails and takes the configuration — the pool and LUN metadata — with it. The disks are intact; the map that assembles them is gone.
LUN corruption, or a missing / re-presented LUN. A LUN goes corrupt, disappears, or is accidentally unmapped or re-presented to the wrong host — and the server that depended on it can no longer see its data.
Failed firmware update or expansion. An update that bricked a controller, or a pool expansion or migration interrupted partway.
Accidental reconfiguration or deletion. A LUN, pool or volume deleted or reformatted by mistake — recoverable if the underlying disks haven’t been overwritten since.
Metadata corruption after a power event. A power loss or dirty shutdown corrupts the pool metadata, and the SAN won’t assemble its volumes.
On a system this critical the pressure to restore service is immense — and acting too fast is how the data is lost for good. Before anything else:
Don’t let the array rebuild onto replacement disks if the set is degraded or inconsistent — a rebuild can write bad parity across good data permanently. Don’t reinitialise the pool, recreate LUNs, or re-present LUNs to hosts to ‘get them back’ — these can overwrite the metadata we need. Don’t run controller-level ‘repair’ or fsck on a corrupt pool as a first move. Don’t reorder or reseat disks without recording their exact positions. Power the system down, capture the configuration — RAID layout, pool and LUN mapping — and get the disks imaged before any rebuild, reinitialise or repair. On a SAN, stopping is almost always the safe move.
We start by imaging every disk read-only, giving any failing disk clean-bench attention first — on a system this size, a solid foundation matters more than ever. Nothing is written to the originals. From the images we reconstruct the underlying RAID, then rebuild the storage pool and LUN structure — including thin-provisioning maps — according to how the specific vendor’s system organises data. With the LUNs reassembled we mount their file systems, extract the virtual machines and databases on top, and repair those as needed. Every layer is verified before the next, and because it all runs on copies, even a reconstruction this complex can be worked through as carefully as it needs to be without any risk to your data.
We recover from the major enterprise storage platforms — Dell EMC (including Unity, VNX and Compellent), NetApp, HPE (3PAR, Nimble, MSA), IBM, Hitachi, Fujitsu and others — across Fibre Channel and iSCSI SANs. Any RAID level and pool layout, SAS, SATA and NVMe disks, and the LUNs, VMFS datastores, virtual machines and databases they host. Where a SAN feeds a virtualised environment or a cluster of servers, we recover the whole stack, from disk to data.
SAN recovery starts with a free assessment: we image and evaluate the disks, establish whether the pool, LUNs and volumes can be reconstructed, and give you a fixed written quote before any chargeable work. Given what’s usually at stake, a priority and emergency service is available with round-the-clock progress, and NDAs and confidential handling are standard — we routinely handle sensitive enterprise data. Pricing is per case, reflecting the scale and layers involved. You can send the disks or the array in by insured courier anywhere in the UK and Ireland, and can work to your security and chain-of-custody requirements.
In most cases, yes. Even a serious SAN failure usually leaves the data intact on the disks — the problem is that the pool, the LUNs and the volumes above them can’t be assembled in their current state. We reconstruct those layers from images of the disks, in order, and recover the data. The critical thing is to stop and have the disks imaged before any rebuild, reinitialise or re-present.
Usually, yes. A missing, unmapped or corrupt LUN can often be reconstructed from the underlying storage — we rebuild the pool and LUN structure from disk images and recover the volume and everything on it. Don’t re-present or recreate the LUN to try to restore it, as that can overwrite the metadata needed to rebuild it.
Yes. Once the LUNs are reconstructed we mount their file systems and recover the layers on top — VMFS datastores, virtual machines, and the SQL, Exchange or other databases inside them — repairing corrupt VM containers and databases as needed. We recover the whole stack, not just the raw storage.
No — not before it’s been imaged. On a degraded or inconsistent array, a rebuild can overwrite recoverable data, and reinitialising a pool or recreating LUNs can destroy the metadata we use to reconstruct everything. When the data matters, image the disks first and reconstruct offline. Power it down and ask before any such action.
Yes. We handle sensitive enterprise data as a matter of course, with NDAs and confidential handling as standard, and can work to your chain-of-custody, data-handling and security requirements. Get in touch to discuss what your organisation needs and we’ll accommodate it.
Yes. Our lab is in Belfast, but SAN recovery is done by insured courier, so we work with organisations right across the UK and Ireland. Send the disks or the array in by insured courier, with the confidentiality and priority handling enterprise recoveries need — wherever you are.
Power it down, capture the configuration, and get in touch. We’ll image the disks, work out whether the pool and LUNs can be reconstructed, and give you an honest, fixed quote before any chargeable work — priority and emergency service available, NDA as standard.