Linux gives you better information about a failing volume than any other system and better tools for damaging it beyond repair. Nearly every Linux job that reaches this bench arrives after a repair command was run in good faith against hardware that was already failing. This page covers ext4 superblocks, LVM metadata archives, mdadm arrays, XFS logs and the one command worth never typing.
A single Linux disk or SSD is £300 + VAT; an mdadm, LVM or NAS set is from £500 + VAT. The diagnostic costs nothing and closes two working days after the media is booked in. Nothing is repaired on your disk — the work happens on an image.
Linux tells you more about what is wrong than Windows does, which helps, and it also gives you far more powerful ways to make it worse. These are the situations that arrive here, and the commands that turn each of them into a longer job.
A damaged primary superblock, a journal that cannot be replayed, or an inode table caught by a power cut. Most of it is repairable, and much of it is repairable without touching the original, because ext4 keeps backup superblocks at known offsets. What it will not survive is a repair run against a disk that is physically failing.
The most damaging four characters on this page. Answering yes to everything on a corrupt file system moves what it cannot resolve into lost and found, renames files after their inode numbers, and writes all of it back. On a healthy disk with a small inconsistency that is fine. On a dying one it destroys the structure that made your files findable.
Volume groups that will not activate, a physical volume that reports as unknown, a logical volume removed or resized in the wrong direction. The metadata is small, it is versioned, and copies of every previous layout are archived on the system itself. Recovering from that archive is often the whole job.
Software RAID with a member marked failed, a superblock that has gone stale, or an array that will not start because two disks disagree about which is current. Assembling read-only is safe. Re-creating the array with mdadm to see whether it comes back is the classic Linux disaster and it writes new superblocks over the old ones.
XFS is fast and unforgiving. Its repair tool will happily zero a dirty log to get the volume mounting again, and everything that was in flight when the machine died goes with it. Where the data matters more than the uptime, the volume should be imaged before any repair is run rather than after.
Read errors in the kernel log, a mount that hangs, a machine that freezes whenever a particular directory is touched. No amount of file system work helps here. The disk needs imaging on hardware built for failing media, and everything else happens against that image.
The single most useful habit on a Linux recovery is refusing to write to the affected device. Mount read-only if you must mount at all, and prefer not to mount. Where the data has value and no verified backup exists, take a full image with a tool designed for damaged media before running any diagnostic that could write, and work exclusively on that image afterwards. A raw copy is not glamorous, it takes as long as it takes, and it converts an irreversible situation into a reversible one.
The instinct that costs people most is reaching for the repair tool because it is right there and it is free. A file system checker is written on the assumption that the hardware beneath it is sound and only the bookkeeping has gone astray. Point one at a disk with weakening surfaces and it will hammer exactly the regions that are struggling, for hours, and then write its conclusions onto the disk you wanted copied.
ext4 scatters copies of its superblock across the volume at predictable offsets, so a damaged primary is one of the more survivable faults in the trade. The dumpe2fs output lists where those copies live, and a mount using an alternate one frequently brings a volume straight back. Where the inode tables or the journal are the problem it becomes a rebuild rather than a mount, and that is bench work: the extent trees are walked, directory entries are matched back to inodes, and the tree is put together on a copy.
Deleted files are the awkward case and it is worth being straight about it. ext3 zeroed the indirect blocks on deletion; ext4 uses extents and clears them too, so a file deleted from a mounted ext4 volume does not have a neat pointer left behind. What is often left is the data itself, sitting untouched in blocks that have not yet been reused, which can be carved out by content. That gives you the file and not its name or its folder. The odds fall away the longer the system stays running, so an unmount and a shutdown are worth more than any tool.
Anything above a simple layout is almost certainly using LVM, which adds a layer between the disks and the file systems. When a volume group will not activate, the file systems inside it are usually perfectly intact and simply unreachable. LVM writes a copy of each metadata version into an archive directory on the system whenever the layout changes, so the previous configuration is often sitting on the machine waiting to be restored. That has rescued a great many volume groups that looked catastrophic at first glance.
Two situations are harder. A physical volume that has been re-labelled or partly overwritten needs its metadata reconstructing by hand from the surviving copies. A logical volume shrunk without first shrinking the file system inside it has genuinely lost the tail of that file system, and no amount of metadata work brings back blocks that were released and reused.
Software RAID keeps a superblock near the start of each member — the offset varies with the metadata version, which matters more than it sounds. Assembling read-only, forcing an assembly of an array whose members disagree, and examining the superblocks are all safe, reversible operations. Creating the array again is not. The create command writes fresh superblocks and, depending on the version, may begin synchronising immediately, which on a parity set means writing new parity across live data. If an array will not assemble, stop there. The layout can be worked out here from the members.
Both keep checksums of everything and both keep older versions of their metadata trees, which means a pool or a volume that will not import can often be rolled back to an earlier transaction and read that way. Both are also unforgiving about missing devices in a redundant set, and both punish improvisation. The general rule is the same as everywhere else on this page: import read-only where the tools allow it, do not run a scrub on a pool with a failing member, and image first if the data matters.
LUKS behaves much like any other full-disk encryption. With the passphrase or the key file, the volume is decrypted from an image and the recovery proceeds normally, in the £400 + VAT band that covers encrypted media. The header holds the key material, so a damaged header is a serious matter and a header backup is worth taking on any machine you care about. Without a passphrase, a key file or a header backup, the volume stays encrypted. That is the design working, and no laboratory can undo it.
A single Linux disk or SSD is £300 + VAT. An mdadm set, an LVM group spanning several disks, a NAS or a server is from £500 + VAT and rises with the member count. A USB stick or memory card is £250 + VAT, an encrypted volume with the key supplied is £400 + VAT, and forensic work is £800 + VAT with a written report or £400 + VAT for a binary image with deleted-file extraction and no report. Ransomware is priced as ordinary media rather than as forensic work.
The diagnostic costs nothing and closes two working days after the media is booked in. Logical work — file system damage, LVM metadata, an array that will not assemble, deleted data — runs under no fix, no fee. Outside that guarantee sit electronic failures, mechanical failures, chip-level work, DVR jobs and forensic jobs, and physical work takes half the quoted figure upfront.
Take the drive out and send the drive. Not the tower, not the rack unit, not the laptop. An external drive in its own enclosure travels whole, a NAS travels whole, and a RAID or server sends its member disks only, each labelled with its bay order and with the chassis front photographed first. Storage soldered to a mainboard cannot be removed and therefore cannot be helped.
Include a note of the distribution and version, the file system, whether LVM or mdadm is in play, and — most useful of all — exactly which commands have already been run against the device. Nobody is judging. It changes what the bench looks for first.
Post it tracked and insured or bring it to Compass House, Vision Park, Chivers Way, Cambridge CB24 9AD, Mon–Fri 9:00am–5:30pm. From Leicester it is around 70 miles, M1 to J19 and the A14 east, about ninety minutes, two minutes off Junction 32. Plenty of this work comes from the university and De Montfort research groups, from engineering firms around Loughborough and from the small hosting and development shops in and around the Cultural Quarter, and every one of those jobs arrives by post or by car because there is no collection service and no Leicester counter.
Every repair tool on Linux assumes the hardware underneath is healthy. On a failing disk that assumption is what costs people their data.
Multi-disk jobs travel as a set of bare drives in one box, and they travel by post far more often than by car. Tracked and insured is the sensible choice for a parcel holding four disks of company data, and something handed over in Leicester before the last collection is normally logged in at Cambridge the next working day.
The general rule is the drive travels and the machine stays behind — out of the laptop, out of the tower, out of the iMac, out of the recorder under the counter. This bench does not dismantle equipment, and a repair shop will do it while you wait. Three things are the other way round, and getting them wrong costs you the recovery: an external drive stays sealed in its own case, a NAS comes as a complete unit, and a WD My Passport or My Book travels whole with its cable, because on those the encryption key is held on the bridge board rather than on the disk — separate the two and the data becomes unreadable even to us. A Fusion Mac needs both of its drives, each labelled. The one thing nobody can work round is flash soldered onto the mainboard, as on Apple Silicon machines: if it will not come off, there is nothing to post.
↓ Print the shipping & booking-in form (PDF)
Address it to Cambridge Data Recovery. It is about seventy miles from Leicester if you fancy driving it — M1 south to Junction 19, then the A14 east — and the lab is two minutes off Junction 32 with parking at the door. Posting costs you a stamp and a day instead. Whichever you choose, you hear from us the moment it is booked in, and the free diagnostic closes two working days after that.
Not certain what belongs in the box? Ring 0800 689 0668 before you tape it up, or let the free online diagnostic ask the questions for you.