SAN (Storage Area Network) failures cause all servers using it to go down at once. For enterprises and IT service companies around York and North Yorkshire, we recover their collapsed SAN (Storage Area Networks) systems. These are often found to be missing their LUNs (Logical Unit Numbers), or their disk pools are damaged, and/or their virtual machine file system (VMFS) mounts fail. Our SAN recovery services cover both single shelf configurations and multi-shelf array configurations. All of our enterprise level server work is treated like standard bench trade versus an infrequent adventure.
All SAN jobs are diagnosed without charge. The fixed price quote is generated in writing prior to us ever lifting a screwdriver.
In most cases you only pay if we recover your data. Chip level, electronic and mechanical repair is charged at 50% at start-up, and the other 50% only upon successful recovery of your data; all BitLocker, ransomware, forensic and CCTV/DVR recoveries are charged at start-up when you accept our fixed quote. More information can be found on the data recovery cost page.
The very first thing we do on any SAN is to match the symptoms you have identified with the fault. Twenty-odd years into this business, these twenty-five faults account for nearly every failure we see walk through the door.
Enterprise shelves lose drives by the handful, not one at a time. Each one is repaired individually and imaged separately before group maths can resume.
Your server's block device has disappeared. When it is rebuilt, the process starts with the pool metadata, followed by the individual RAID groups; no skipping steps.
The block-to-volume map failed. We are going to reconstruct it from raw on-disk structures that the block-to-volume map was describing all along.
Management plane dead mid-flash; data motionless behind. Work proceeds straight against drives.
Pairs die together more readily than the datasheet suggested. Recovery goes drive-direct which never reads datasheets anyway.
VMware layer collapses first. Datastores get parsed out. Then every VMDK is extracted and mended individually.
Seconds to do, days to regret. What survives depends on writes since, so freeze the platform and the arithmetic improves.
A broken link destroys all dependent volumes. Link by link, the chain is re-forged at image level.
If a thin provisioned pool has promised more capacity than it actually owns, each volume drawing on that pool will be corrupted. The volumes are rebuilt from images, with accurate accounting restored.
An outage plus expired cache batteries leave parity contradicting data across a whole group. This contradiction can be resolved affordably at the image level.
EMC pools and NetApp aggregates will lose track of where their volumes reside. Reconstruction starts at the RAID group level and continues up through each level until it remembers.
The 520-byte, 524-byte and 528-byte formats defeat desktop tools. Our lab fabric can read these formats natively; therefore, we do not need improvised adapters.
HPE's small-business staple arrives here with its vDisk structures torn. We have been rehearsing this reconstruction for years.
After a power event, V3700 and V5000 systems lose their extents. We map the extents back from the drives, one at a time.
The system has lost its target definition. The volume behind it very rarely fails too. We extract it and present it again over honest plumbing.
The index was corrupted and all references failed to work at the same time. The index had to be rebuilt until it resolved properly again for the shared blocks.
Two controllers were writing to disk with two different versions of data after failing to complete a proper handoff. The two versions were combined at the image level, have a timestamp and are auditable.
There are no supported paths for arrays far beyond their EOL. Our lab path never expires; data can't read contracts.
Replacement drives on mismatched firmware cause problems inside older groups. Stabilise, image, reconstruct, in that order.
Fabric or masking changes will blind all hosts at once while volumes stay healthy. The rebuilt mapping is handed back to the customer.
Identical lots of drives experiencing an hours-count firmware flaw have been failing within days of one another (a known industry embarrassment). We can quickly image the surviving units prior to them joining this group.
Nearline SATA drives behind SAS interposers fail much more frequently at the interposers than at the drives. We simply bypass the adapters and image bare.
When an SSD (solid-state drive) tier fails, each tiered volume will lose its most active block(s). Only the cold tiers and other tiering-related information can be used to rebuild the missing data that was lost by the failed SSD tier.
A zoning slip without a CFS (cluster file system) equals interleaved corruption. We separate the two write histories from images, operation by operation.
The service processor died and the credentials left with a contractor. The array does not respond but the drives are willing to talk. The extraction occurs without needing a password.
A SAN is a multi-level abstraction: disks in RAID groups, RAID groups combined together as a pool, pools split into LUNs (logical unit numbers), file systems and hypervisor datastores at the highest level. To recover data we go down and back up through these levels in order: image the disk drives, build the RAID groups, rebuild the pool metadata, lift the LUNs and finally mount the datastores so that your VMs and databases can be accessed. All of the major hardware vendors including Dell EMC, HPE MSA/EVA, NetApp, IBM and Fujitsu are very well known to us, and NDAs and change-control paperwork fit into our recovery process easily.
No business wants to get raw blocks back: they want the three machines that run everything else online again. Therefore, after mounting your datastores from the rebuilt LUNs, repairing VMDK/VHDX files, and moving your named SQL/Exchange workloads to the front so operations can begin again, the remaining terabytes continue to copy in the background. This process is called triage and performed under calm conditions.
Recovering from SAN disasters requires enterprise plumbing as well as recovery skill. We provide both in depth at our workshop.
All of the shelves and disks connect via our own Fibre Channel (FC), Serial Attached SCSI (SAS) and Internet Small Computer System Interface (iSCSI) infrastructure, including the odd size sectors that come with enterprise products.
All RAID groups are captured side by side, once any casualty drive has completed its trip to the PC-3000 workbenches.
Vendor metadata is restored in its natural order: groups, then pools, then LUNs, then whatever file systems sit atop.
Restored LUNs bring their datastores back into view; each virtual disk can then be removed from the datastore and independently fixed.
The SQL Server and Exchange named workloads are the ones that are checked first. The services that you want up and running will be back online as quickly as possible.
Each original drive is treated as a read-only unit when it arrives in our facility. Each one will remain read-only until the day it is posted back to you.
An unfamiliar badge on a piece of equipment rarely means unfamiliar hardware. Enterprise companies rebadge components from a shared parts bin endlessly, and this workshop has seen most of that bin at least twice. A pool without its map is rebuilt from the RAID groups upwards. If both controllers fail at the same time, the work simply goes drive-direct. Eccentric sector sizes are read natively on our lab fabric, so there's no arguing with desktop adapters. Once you have your quote, post every drive, each labelled with its bay or slot number; the shelf can keep its rack bolts.
All of the drives in the enterprise configuration must be marked with their specific shelf and slot before leaving the rack. Guessing where something went is unacceptable in enterprise environments. Photograph the configuration before removing anything; only the tagged drives go on the trip. None of the shelves or controllers leave site.
Get a quote first, by calling us on 0800 689 0668 or using our free online diagnostic tool. After receiving your quote, tracked and insured post is how nearly every job reaches us: it is the fastest and safest way to get your drive to our lab in Leeds. There's no collection service, so the parcel is yours to send, or you can hand it in at the Leeds lab's reception.
Is the hard drive or SSD still inside a machine, such as a laptop, MacBook, iMac, CCTV/DVR system or server? Please remove the hard drive or SSD from the machine first and then post just the bare drive by itself; we do not provide a service for removing drives from devices. For a server or RAID, send every disk, each clearly marked with its bay. For a NAS, send its disks labelled by bay if you can remove them, otherwise send the NAS itself. We cannot work on storage soldered to the motherboard (e.g. Apple Silicon Macs, T2 Macs and certain slim laptops): if it doesn't come out, it can't come in. If you are unsure whether your storage is removable, call us before sending.
↓ Print the booking-in & shipping form (PDF)
Once you have your quote, send your package addressed to Leeds Data Recovery (about a 40 minute drive from York on the A64 & A1(M) or next working day if you want to send it using trackable post). We will contact you as soon as we have taken delivery of your package and put it in line to be worked upon.
Can't figure out what to pack? Ring 0800 689 0668 first, or try our free online diagnostic tool.
Free diagnosis, fixed written quote, and on most work you only pay if we recover your data. Start online or call our freephone.