Shared storage does not go down by itself. Everything relying on it will come crashing down at the same moment. That's why these are so much different than every other call we take all week. We rebuild SAN estates here: offline LUNs, damaged pool metadata, unmountable datastores. Companies have us do this type of work directly, as well as their IT providers acting for them. One shelf or an entire room of them. Enterprise storage is core bench trade, not a favour.
There are no diagnostic charges for any SAN jobs. The fixed cost will be provided to you in writing prior to any tools coming out, and once we have agreed upon it, then we can proceed with fixing your problem.
In most cases you only pay if we recover your data. The exceptions are electronic/mechanical failures, chip level work, DVR and forensic jobs. All pricing information can be found on the data recovery cost page.
We always begin each new SAN issue with diagnosing the root cause of the failure based on the symptoms presented. After twenty-odd years, these twenty-five causes cover nearly every failure that reaches this bench.
Enterprise storage shelves lose multiple disk drives at once and we must individually repair each lost drive in addition to creating an exact copy of what was contained on it before the group arithmetic can resume.
The block device your servers depended on has been destroyed. We start rebuilding it at the lowest level possible and work our way up. This means that first we restore the RAID groups (the lower level building blocks) and next we restore your pool metadata (the upper level building blocks), strictly in that order. Any attempt to do otherwise would prove nothing.
A "map" exists from the physical "blocks" where your data resides to the virtual "volumes", and that map is what has failed. NetApp aggregates and EMC pools lose their volumes in exactly the same way. This "mapping information" is recovered directly from the raw on-disk structures that the map described during its lifetime.
When your management plane stopped functioning in the middle of a firmware flash, the underlying data remained stationary; therefore, we proceed to recover from the disks directly without even using the controller.
Paired controllers tend to fail together much more frequently than almost any datasheet would indicate. We perform recovery operations directly against the disks themselves, which has the advantage that we don't need to consult any datasheets.
The collapse starts in the virtualisation layer and takes all things visible down with it. We parse out the datastore(s) into individual components. Then we take each virtual disk and work to fix/repair it based upon how badly damaged (or otherwise broken) it was when collapsed.
Time to run: seconds. Time to regret: days. Whether or not your data can survive is dependent upon whether there have been any changes made to the environment since. By freezing the environment you will immediately improve your chances and cost yourself nothing.
If a single link fails, every volume that relies on that link also fails. The chain is rebuilt at image level, one link at a time, until all volumes are back online.
If more capacity is promised than exists, every thin volume that feeds off this pool becomes corrupted as soon as the pool runs out of space. Once repaired using images, any accounts within these volumes will pass an audit afterwards.
Batteries in cache systems that have exceeded their useful life, plus one outage, leave parity discrepancies with the data throughout a group. Repairing these disparities at image level is affordable. Repairing them live will be destructive.
Ordinary tools typically cannot read 520, 524 and 528 byte formats, and that is by design. In our lab fabric, these formats are read natively without the need for either improvised adapters or hopeful conversions.
HPE's small-business staple is discovered to have had its vDisk structures torn open. This workshop has rehearsed that type of reconstruction to the point of boredom, which is the right amount of practice.
When there has been a power event, V3700 and V5000 units can shed extents, and therefore the volume above them doesn't make any sense. It is remapped from the disks, extent by patient extent, until it is complete.
After a botched handover, both controllers wrote to the storage independently. This creates two versions of events. A reconciliation process takes place at image level, timestamped and audited.
An array has failed past end of support. There is no official route available anywhere to resolve the failure. However, our lab work carries no expiry date (data never reads a support contract).
Modify masking or fabric and all hosts will lose sight at once while all underlying volumes remain healthy. Mapping is rebuilt and returned to owner/operator.
Disks from one lot fail as the firmware has a defect in the hours counter, which results in multiple disks failing within days of each other. This is a documented industry embarrassment. Not bad luck. Surviving disks are imaged quickly before they follow suit.
When the "fast" or "quick" tier fails, each of the tiered volumes loses the most used block(s) it had. This leaves the "cold" tiers behind, which make no sense individually. These cold tiers, along with all of the tiering metadata, rebuild what was being stored on the quick tier.
Zoning errors can cause data corruption interleaved from both directions simultaneously when you don't have a clustered file system. The two write history streams are then separated from images, operation by operation.
When the service processor dies and the credentials have left along with a contractor, the array will not communicate. The disks do not share the array's reservations, therefore extraction proceeds with no password at all.
The snapshot reserve is limited space; the majority of platforms respond to this limitation by silently deleting the oldest snapshots. The restore point someone was counting on is deleted prior to anyone being aware of its existence. Any remaining items are recovered from unallocated space on the imaged member(s).
A failover test, a mislabelled site name, or restarting relationships in reverse and the stale copy writes back over the healthy copy at full line speeds. We then image the overwritten side and we recover the older structures from under the newer ones. This works much better the sooner the overwrite is stopped.
If an array encrypts data at rest (i.e., while stored) the encryption keys reside either within the controller itself or on a key manager. If you lose both then every single disk is readable but completely worthless. That fact is established during the diagnostic and clearly communicated, because there isn't any honest way around it.
Shelves are connected in a daisy chain configuration therefore one bad connection (cable), or one bad unit (expander) or a shelf brought up out of order may make a whole level of disk drives disappear at once. This will present itself to you as a complete loss; however, it often is a cabling issue. Which of the two it is gets determined before anyone rebuilds anything, and then the necessary action(s) can be taken.
A new server is presented with multiple volumes and a well-meaning administrator initialises whatever appeared as a free volume. A quick format writes a minimal amount, so most of what was written below it remains intact, provided that the host is disconnected before it starts to fill space it believes belongs to itself.
Shared storage is layers upon layers. The disks within RAID sets. Those sets reside within a pool. That pool is divided up into logical units or LUNs. Then file systems and hypervisor data stores are placed atop these LUNs. So as to restore from a disaster you have to work through that stack and go back through it in the same order. All of the physical disks will be captured in an image. All of the RAID sets will be rebuilt. The pool's metadata will be corrected. And all of the LUNs will be extracted. Once that has been done, the virtual machines and databases contained within them can be accessed. The hardware is well-trodden ground for us: Dell EMC and NetApp, HPE MSA and EVA, IBM and Fujitsu. Neither is the paperwork a problem: NDAs, change control or any form of organisational governance can fit into this process flow without taking away from the amount of time available for recovery.
Nobody ever wants raw blocks back. What is needed are a handful of systems that the business actually relies on to be up by morning. So datastores will be standing on top of the reconstructed LUNs and VMDK/VHDX files come out and get fixed. Named SQL/Exchange workloads go first in line. Operations restart while the rest copy quietly behind them. This is triage not heroics and it is done at a pace that makes sense. Hurry an enterprise job and you make the second mistake, which is always the one that costs.
Recovery from SAN failures will require both enterprise storage (plumbing) and the recovery skills. This workshop has both in depth:
All the shelves and disks are connected using our own fibre channel, SAS and iSCSI plumbing, including the unusual sector sizes found in enterprise storage.
We image entire RAID groups simultaneously, after any damaged disk has first been round the mechanical and firmware benches.
We rebuild vendor specific metadata in the order it was originally created: groups, then pools, then LUNs, then whichever file systems sit on top of them.
Once we have restored the LUNs that were lost, they present their datastores again. All the virtual disks are taken out of each datastore and fixed individually.
You name your SQL Server and Exchange workloads at the outset, and these are validated first and placed at the front of the queue. Therefore, you will see your critical services returned first.
Each of the original disks remains read-only from arrival until the time they leave. There is no phase of the process where someone may bypass this rule.
It is fairly rare for an unusual badge to indicate unusual equipment. The enterprise vendors rebadge their gear out of a common parts bin, and most of what is in that bin has come through this bench several times over. A pool that lost its map will be rebuilt up from the RAID groups. If there are two dead controller units, the work simply goes direct to the drives. Any odd sector size can be read natively on our lab fabric (i.e., without trying to convert or match it). Operators, engineering contractors and service companies all throughout the harbour area and the surrounding industrial estates work these types of systems harder than most, and our intake shows it. Get a quote first and then post us the disks with the tags on them. Leave the shelf in its rack bolts.
Tag each of your disks prior to removal from the rack using both the shelf number and the slot number. The most damaging element for enterprise setups is being unsure of where something is. Take a photo of how things were set up. First get a quote (by phone or via the free online diagnostic) before sending only the labelled disks. Shelves and controllers will remain on site. Post everything tracked and insured. Alternatively you can arrange a courier. Collection is not a service we offer. If preferable, you may also bring the disks into reception at our Edinburgh lab, 4 Redheughs Rigg, Westpoint, South Gyle, Edinburgh EH12 9DQ, Monday to Friday, 9am to 5:30pm, with no appointment needed.
Get a quote first by telephone or use our free online diagnostic. Most of what you see on this bench will then be delivered via tracked, insured post. This is one of the safest ways to move a failing drive and packages handed in at a North-East post office are normally delivered here the next working day.
Still attached to a laptop, desktop, MacBook, iMac, server or CCTV/DVR unit? Remove the hard drive or SSD first. The bare drive travels on its own; when removing disks from a server remove all the disks and label each disk by its bay. This lab does not take machines apart. Any storage that has been soldered onto a motherboard (as in T2 and Apple Silicon Macs and a couple of thin laptops) will not be worked on: if it will not unbolt, we cannot work on it. If you're not sure what type of machine you have, ring us first. Phones and tablets are also not taken on.
↓ Print the shipping & booking-in form (PDF)
Your parcel should be addressed to Edinburgh Data Recovery, approximately two and a half hours (and 130 miles) from Aberdeen via the A90; alternatively it can reach us the next working day by tracked post if this journey time / distance is prohibitive to travel. As soon as your drive has been scheduled in we will contact you.
Still unsure about what should be placed inside of the packaging? Please call us first on 0800 689 0668, or use our free online diagnostic tool to assist you in deciding which items belong inside of the packaging before sealing.
Free diagnosis, one fixed price quoted in writing, and in most cases you only pay if we recover your data. Start online or phone it in.