Linux gives you better information about a sick volume than anything else and better instruments for finishing it off. Most of the Linux work reaching this bench arrives after a repair command was run in perfectly good faith at hardware that was already going. Here are the spare superblocks, the LVM archive nobody remembers, the mdadm command worth never learning, XFS logs, LUKS headers, and where the honest limits sit.
One Linux disk or SSD is £300 + VAT; an mdadm, LVM or NAS set is from £500 + VAT. Looking costs nothing and the answer arrives on the second working day after your media is logged in. Nothing gets repaired on your drive — every attempt happens against an image of it.
Linux will tell you far more about a sick volume than any other system, which helps enormously, and hands you far better tools for finishing it off, which does not. These are what turn up, alongside the command that made each one worse.
A wrecked primary superblock, a journal that refuses to replay, an inode table caught out by the power going. Most of it repairs, and a good deal of it repairs without the original being touched at all, because copies of the superblock live at known offsets. What none of it survives is a repair pass run over hardware that is physically on its way out.
The dearest four characters on this page. Agreeing to everything on a damaged file system relocates whatever cannot be resolved into lost and found, renames files after inode numbers, and commits the lot. On a sound disk with one small inconsistency that is a useful five minutes. On a failing one it dismantles the structure that made your files findable.
LVM reporting a physical volume as unknown, a group that refuses to come up, a logical volume removed or resized the wrong way. The metadata involved is tiny, it is versioned, and every earlier layout has been archived on the machine itself. Fetching the right version back out of that archive is often the entire job, start to finish.
Software RAID with a member flagged out, a superblock gone stale, or two disks arguing about which is current. Assembling read-only is safe, examining superblocks is safe, and forcing a read-only assembly is safe. Creating the array again is the classic Linux catastrophe, because create writes new superblocks straight over the old ones.
XFS is fast and it does not forgive. Its repair tool will zero a dirty log to get the volume mounting, and everything that was in flight when the machine died departs with it. Where the contents are worth more than the uptime, the volume gets imaged before any repair runs — not after somebody has already tried one.
Read errors filling the kernel log, a mount that hangs indefinitely, a machine that locks up whenever one directory is opened. File system work achieves nothing against any of that. The drive wants imaging on equipment designed for failing media, and every other question waits until the image exists.
Never write to the affected device. Mount read-only if you must mount, and prefer not to mount. Where the contents matter and no restore has been tested, take a full image using something written for damaged media before any diagnostic capable of writing gets near it, and do the rest of your thinking against that image. A raw copy is unglamorous and takes exactly as long as the disk permits, and it converts a one-way situation into one you can back out of. That is the whole argument, and there is not a second one.
What costs Linux users most is reaching for the repair tool because it is installed, free and immediately to hand. A checker is written assuming the hardware below it is sound and only the bookkeeping has drifted. Aim one at a disk with failing surfaces and it will pound precisely the areas that are struggling, for hours on end, and then commit its findings to the disk you were hoping to copy.
Copies of the superblock sit at predictable offsets throughout an ext4 volume, which makes a damaged primary one of the friendlier faults in this trade — dumpe2fs will list where those copies are, and mounting from an alternate frequently returns the volume immediately. Once the inode tables or the journal are the problem it stops being a mount and turns into a rebuild, and that is bench work: extent trees walked, directory entries married back to inodes, the tree reassembled on a copy.
Deleted files are the awkward part and deserve straight talk. ext3 zeroed indirect blocks when a file went; ext4 uses extents and clears those as well, so unlinking a file from a mounted volume leaves no convenient pointer behind. What often does remain is the content itself, sitting in blocks nothing has claimed since, and that can be carved out by recognising the file type — which gives you the file without its name or its folder. The odds decay for every hour the system stays up, so unmounting and shutting down is worth more than any package you could install. Deleted file recovery covers the same question across every platform.
Anything beyond the simplest arrangement is running LVM, which inserts a layer between the drives and the file systems. When a group will not activate, the file systems inside are very often entirely sound and merely unreachable, which is a much better position than the error messages suggest. Every time the layout changes, LVM writes a copy of the new metadata into an archive directory on the machine, so the previous configuration is frequently sitting on the system waiting to be put back — and that has rescued a great many groups that looked terminal at first glance.
Two variants are harder work. A physical volume relabelled or partly written over needs its metadata assembled by hand from whichever copies survived. And a logical volume shrunk without the file system inside it being shrunk first has genuinely surrendered the tail of that file system, because those blocks were handed back and reused. No amount of metadata work returns data that is no longer present.
Software RAID writes a superblock near the start of each member, at an offset that depends on the metadata version — which matters more than it sounds, since the version also fixes where the data area begins. Assembling read-only is reversible. Forcing an assembly of members that disagree is reversible. Examining superblocks is reversible. Creating the array again is none of those things: create writes fresh superblocks and, depending on version and level, may start synchronising there and then, which on a parity set means laying new calculated blocks over live data. If a set will not assemble, stop. The layout can be worked out here from the members, and RAID 5 recovery explains how that is done.
Both keep checksums for everything and both retain older copies of their metadata trees, so a pool or a volume refusing to import can often be wound back to an earlier transaction and read from there. Both are also unforgiving about a device missing from a redundant set, and both punish guesswork hard. The rule is the one running through this entire page: import read-only wherever the tools allow it, never scrub a pool with a failing member in it, and take an image first whenever the contents matter.
Hand over the passphrase or a key file and the volume decrypts from the image, after which the recovery proceeds like any other, in the £400 + VAT band covering encrypted media of every kind. Key material lives in the header, which makes a damaged header a serious event and a header backup a sensible thing to hold for any machine you care about. With no passphrase, no key file and no header backup, the volume stays encrypted permanently. That is the encryption succeeding rather than a laboratory failing, and no honest bench will suggest otherwise.
One disk, or one SSD, on its own: £300 + VAT. Several disks in one box — an mdadm set, an LVM group spanning drives, a NAS, a server: from £500 + VAT, climbing with the member count. A stick or a card: £250 + VAT. An encrypted volume with the key available, or a recorder disk: £400 + VAT. Forensic casework reported in full: £800 + VAT, or £400 + VAT for the verified image and its extracted deletions with no report attached. Media encrypted by malware is charged as media, never as investigation.
Looking is free and the answer arrives on the second working day after your media is logged in. Logical work — file system damage, LVM metadata, a set that will not assemble, deleted material — runs under no fix, no fee. Outside that guarantee sit chip-level work, DVR jobs, forensic jobs and any failure that is mechanical or electronic, with half the agreed figure payable upfront on invasive work.
The drive travels and the machine stays: not the tower, not the rack unit, not the laptop. Two things go the other way, an external drive sealed in its own case and a NAS complete with its disks in their bays, while a RAID or server sends members only, marked with the bay order and photographed first. Storage soldered flat onto a mainboard cannot be unbolted and therefore cannot be helped, which rules out a fair number of slim machines before the conversation starts.
Say which distribution and version, which file system, whether LVM or mdadm is involved, and — the single most valuable line in the box — exactly which commands have already been aimed at the device. Nobody is keeping score, and on Linux that history is worth more than it is anywhere else, because it decides what the bench looks for first. Oxford takes drop-offs on weekdays from 9:00am to 5:30pm, fifty-five miles down the M40. A good deal of this work arrives from the two universities, from software and hosting firms around the city centre and Ansty, and from engineering offices where one Ubuntu workstation quietly holds a whole department simulation output.
Every repair tool on the system assumes healthy hardware beneath it. On a dying disk that assumption is what costs people their files.
Multi-disk jobs travel as a set of bare drives sharing one padded box, and that parcel wants tracking and covering for what is written on it rather than what it weighs. Booked over a Coventry post office counter in the afternoon, it usually reaches the Oxford bench the next working morning — faster than most firms manage to spare somebody for the run down the M40.
As a rule the storage comes out and the machine stays where it is. That applies to a laptop, a tower, an iMac and to the recorder sitting under a counter. Taking equipment apart is not something this bench does, and a repair shop will free a drive in a few minutes. Two things go the other way: an external drive stays sealed inside its own case, and a NAS travels as a complete unit with its disks still in their bays. A Fusion Mac is a third case — both of its drives come out and travel together, each one labelled. The single situation nobody can work around is memory soldered flat onto a mainboard, which is how Apple Silicon Macs and a good many slim laptops are built: if the storage will not unbolt, there is no parcel to send.
↓ Print the shipping & booking-in form (PDF)
Put Oxford Data Recovery on the label. From Coventry it is roughly fifty-five miles straight down the M40, about an hour if you would rather drive it in than post it. Either way you are told the moment it is logged, and the free diagnostic finishes two working days later.
Unsure what ought to go in the box? Ring 0800 689 0668 before you seal it, or work through the free online diagnostic and let it do the asking.