One disk had been out for months without anybody noticing, and the second went twenty minutes into the rebuild. Or a controller card died with the whole configuration held inside it. RAID recovery Liverpool firms ask for is weekly bench work rather than a rare event, covering levels 0, 1, 5, 6 and 10 lifted out of servers, workstations and NAS units. Every disk is copied before a theory gets tested, and the set goes back together in software. Businesses that have stopped trading are looked at first.
Every raid array job is diagnosed free. One fixed figure follows in writing, agreed before a screwdriver comes out of the drawer.
No fix, no fee all jobs except electronic and mechanical failures, chip level work, DVR and Forensic jobs. Every band is listed on the data recovery cost page.
Matching the symptom to the fault underneath is the first job on any raid array, and after twenty-odd years these thirty account for very nearly everything that arrives.
Redundancy covered the first failure exactly as it was meant to. Then the rebuild reads every surviving member end to end for hours, and a tired second disk gives out under that load. This is the array disaster in its classic form and the one that reaches this bench most weeks.
A rebuild abandoned mid-run leaves parity that belongs neither to the old set nor to the new one. How far that reached is mapped from images. Nothing on the drives themselves is altered while the mapping is going on.
A RAID card keeps the array definition to itself, and when the card dies the definition goes quiet. The geometry is worked back out of the member disks instead. No replacement card is bought and no vendor utility is pointed at the drives.
Push a months-old disk into a live set and the file system tears along the line where the two versions disagree. That seam is unpicked on images, where a disagreement can be examined rather than made worse.
Somebody creates a fresh configuration on hardware that was already carrying one. Initialisation writes from the front, so stopping it early tends to leave most of the previous volume sitting intact behind it.
A spike or a failing PSU can take out more than one disk in the same second. Every casualty is treated as a drive job in its own right, repaired and imaged, long before anyone attempts arithmetic across the group.
When a whole bank of drives drops out at once, chassis wiring is a likelier explanation than six simultaneous failures. Diagnosis before panic. It is also the cheaper order to do things in.
Sometimes the array solves perfectly and the NTFS or ext4 riding on top of it is in pieces. That is a file-system job sitting on an array job. It finishes at parser level, not with a downloaded scanner.
A volume definition removed by mistake is one of the better outcomes on this page, because the blocks it described are still sitting unwritten. What spends that advantage is carrying on using the array.
A flat cache battery and a power cut leave writes half committed. That is the write hole doing precisely what it is named for. The two sides are reconciled from images, where guessing wrong costs nothing but time.
PERC H710s and Smart Array P420s fail with a layout nobody ever wrote down still inside them. The member disks know it as well, so it is read off them and the search for an identical replacement card never has to start.
A clicking disk goes to the clean bench, has its heads replaced, and only then joins the imaging queue. The set waits for it, because an array is only as recoverable as its worst disk.
Small-business arrays are built from disks bought together, running the same hours at the same temperature in the same cupboard. They wear out together too. Imaging every member in parallel is how you get ahead of the next failure.
mdadm superblocks disappear, Storage Spaces pools stop being recognised, and neither needs much provocation. Both are reassembled from the raw members by hand, which is slower than the documentation implies.
A disk reallocating sectors daily is not failing suddenly, it is failing to a timetable. Imaged while that timetable still has room in it, the whole set comes home. Left running, part of it will not.
On paper the set is finished: lose a mirror pair and the stripe has a hole in it. In practice one of those two disks will often image far enough on lab hardware to close the gap, which is where the paper and the bench part company.
The rebuild kicks off automatically onto a spare that has sat powered and idle for four years. Idle is not the same thing as healthy. Nothing enters a reconstruction here before it has been imaged, and a spare is not an exception.
A single click accepting stale metadata can reorder an entire set. The genuine layout is read back off the drives, which kept a more honest record of themselves than the controller managed.
Consumer drives have no time limit on error recovery. Under sustained load they stall on a bad sector and the controller ejects them for insolence. On imaging hardware that is prepared to wait they read perfectly well, and then the set goes back together.
Virtualisation hosts on ZFS arrive with pool metadata that a power cut caught mid-update. Complete member images come first. The transaction history is then walked backwards until a consistent point turns up.
A scheduled consistency check means hours of unbroken reading, which is exactly the work a marginal disk cannot do. It dies on time, part way through the scan. Image between checks rather than after one.
Medium errors met while the array is short of a member get written into parity as permanent holes. Those punctures are charted off the images and routed around, file by file.
Sector formats do not mix, the controller refuses the newcomer, and forcing the point turns one problem into three. On images the sector size is negotiable, which it never is on live hardware.
HBA and expander updates that failed to complete shed disks in small tired batches across the following week. It presents as a run of drive failures. The fault is on the hardware side, and identifying that comes first.
Two modules striped, no parity anywhere, chosen for the numbers. One module dies and the volume goes with it. Each is handled as an NVMe recovery on its own account, then the stripe is stitched back from the images.
The alert emails were going to the mailbox of somebody who left in March. The array has been one disk away from disaster ever since, and the phone call comes on the day that disk arrives. Every member is imaged here, including the ones the controller still calls healthy.
Two drives sold as the same capacity can differ by thousands of sectors between generations. The controller rejects the new one, somebody clears the configuration to make it fit, and now the original problem has company. Imaging removes the argument about size entirely.
Drives pulled from a retired server and pressed into a new one still carry the previous set metadata. A controller able to see both makes decisions nobody asked for. The layout is settled from the data on the platters rather than from whichever signature shouted loudest.
JBOD and spanned volumes carry no redundancy whatsoever. Data is written across the disks in sequence, so losing one leaves a gap in the middle of the file system. Anything that happened to live entirely on the survivors comes back complete, and that is a larger share than most people expect.
One disk of a RAID 1 dropped out quietly and nobody noticed the pair had stopped mirroring. When the working disk finally failed, the old one went back in carrying a copy of last summer. Both get imaged, and the recent data comes off the failed disk rather than being written off.
The layout question waits. First, each member disk is duplicated from its first sector to its last, and after that your originals are finished with arrays for good. Every later step happens against those duplicates, which means the geometry can be worked out at leisure: which disk sat in which position, how wide the stripe was, which way parity rotated, where the data offset began. All of it is deducible from the contents themselves. The volume then stands up in software on top of the images, and the file system is read out of that. Familiar cases include a drive that quietly fell out of a RAID 5 six months before anyone noticed the amber light, two casualties inside a RAID 6, nested 10s, and controllers that have forgotten their own settings entirely. Where the card is the part that died, there is no point tracking down an identical replacement, because everything needed to rebuild the set lives on the disks and not in the hardware that mislaid it.
The difficult calls are the database ones. Disks stop during a write on a SQL server, transaction logs sit across the exact moment everything halted, and a company is at a standstill while somebody explains this down the phone. Those get handled as a separate discipline. The array is rebuilt in software to begin with, and the database files are then repaired until they are consistent, with whichever tables the business runs on taken in priority order, so people are back at work long before the last of the data has finished copying. Emergency data recovery in Liverpool tends to look exactly like that: a firm near the docks or out towards Speke with twenty staff sitting idle, and the quickest safe plan agreed while still on the call. Three habits wreck more arrays than failing components ever do, and they are worth naming. Pushing an offline disk back online by force. Starting a rebuild onto a member that is clearly on its way out. And allowing one more person to have one more go. When a set goes down the right sequence is short: power off, write the bay number on each disk, then phone before anything else is done to it.
RAID work here obeys one rule: image every member first, then think about the layout. It has not been waived for anybody yet, however bad the week:
Members are cloned in parallel on dedicated imaging hardware, and that happens before anyone puts forward a theory about the layout. The risk in the reconstruction then sits on copies rather than on your disks.
Disk order, stripe size, rotation and start offset are solved against the images and the array is stood up in software. The geometry gets demonstrated before it is believed.
A dead member becomes a full drive job in its own right — heads, firmware, boards, whatever it takes to get it reading well enough to image with the rest.
Parity arithmetic and entropy testing confirm a solved layout before a single file is extracted. Nothing leaves this bench on the strength of a hunch.
NTFS and ReFS, ext4, XFS, BTRFS and VMFS are all read directly, together with any virtual disks stored inside them.
A member cannot be written to while it is being read. Whatever you posted goes home bit for bit identical, whichever way the reconstruction turned out.
Hardware card, motherboard chipset or software layer, the geometry is written on the member disks, and off those disks is where it gets read back. Dead PERCs and Smart Arrays keep their definitions to themselves. Batch-bought drives fail within weeks of each other. Desktop-grade members walk out of the set under load. Three different roads to the same arrival, and the arrival is always handled the same way: every member imaged in parallel on day one, the rebuild carried out on copies, the originals returned untouched. Array work starts at £500 + VAT and climbs with the disk count, because each member is imaged in its own right. A Merseyside firm that has stopped trading goes to the front of the queue on the day it rings.
Shut the server down before a single drive moves. Number each member as it comes out, bay one, bay two and so on, because the reconstruction leans on that order being known. A photograph of the bays before you start earns its keep later. Send the labelled disks and nothing else: the chassis and the controller stay in the rack, and they are no use to us. Post them tracked and insured to Manchester Data Recovery, Peter House, Oxford Street, Manchester M1 5AN, which is roughly 35 miles along the M62, or book a courier of your own. We do not collect, and there is no counter to visit in Liverpool. Drives can be handed in at the Manchester lab reception between 9:00am and 5:30pm, Monday to Friday, if that suits you better than the post.
Almost every job on this bench came in by tracked, insured post. It is the calmest way to move a drive that is already struggling, and a parcel handed in anywhere on Merseyside usually reaches the bench the following working day.
Still screwed inside a laptop, tower, MacBook, iMac, server or a CCTV recorder? Take the drive out and post that on its own. We do not strip machines here, and any computer shop will do it in a few minutes. The one job nobody can take on is flash soldered straight to a logic board, as on Apple Silicon Macs and a handful of very slim laptops: if the storage will not unbolt, there is nothing to send.
↓ Print the shipping & booking-in form (PDF)
Address it to Manchester Data Recovery. It is roughly 35 miles from Liverpool along the M62 if you fancy the run, and next working day by tracked post if you do not. We ring or email the moment it is booked in, and the free diagnostic closes 2 working days after that.
Not sure what belongs in the parcel? Call 0800 689 0668 before you tape it shut, or step through the free online diagnostic first.
Diagnosis free, one figure written down, and £300 + VAT covers a single drive or SSD. Start online or ring.