The call from a Linux admin usually starts one of a few ways. A production server is stuck at a mount error and dmesg is filling with EXT4-fs abort messages. A Synology or QNAP that has been running fine for three years just dropped its storage pool into a crashed state. A colleague on Slack asks whether anyone knows how to unwind an lvremove that took out the wrong logical volume ninety seconds ago. A RHEL server that got through xfs_repair -L now boots — but the /home directory is empty. A power event took down half a rack of Proxmox hosts and the ZFS pools on the survivors are refusing to import.

Every one of those situations is a Linux data recovery case, and they don’t look alike. The recovery paths depend on which filesystem is involved, what sits beneath it, and what the admin has already tried. This page is the hub for that work. Below is a routing map to each of the major Linux filesystem recoveries we handle, an overview of what makes Linux recovery different from Windows or Mac, and the failure patterns we see most often across servers, storage appliances, and workstations.

Gillware has been recovering data from Linux systems for more than two decades, out of our ISO 5 Class 100 cleanroom in Madison, Wisconsin. Every case starts with a free consultation. For the complex ones — multi-disk arrays with damaged filesystems on top, ransomware deletions on running hosts, superblock reconstructions on volumes where the standard tools have run out of options — engagement terms are agreed in writing before any work begins.

The file systems we recover

Linux has more mainstream filesystems than any other operating system, and each one fails and recovers differently. The recovery is filesystem-specific work, and knowing which one you’re on is the first step. Each of the pages below is a deep-dive on one filesystem’s on-disk layout, common failure patterns, and how our lab approaches recovery for that specific stack.

• ext4 data recovery — the Linux default filesystem, still the root filesystem on RHEL, Debian, Ubuntu Server, and most derivatives, and the underlying filesystem on the majority of consumer NAS units running Synology DSM (non-Btrfs volumes) and QNAP standard QTS. Common cases: unmountable volumes after power loss, superblock corruption, and the specific challenge of recovering deleted iSCSI LUNs and VM container files where ext4’s extent tree design makes after-the-fact recovery genuinely hard.
• XFS data recovery — the default filesystem on RHEL 7 and later, Rocky Linux, AlmaLinux, CentOS Stream, and Oracle Linux. XFS is engineered for large volumes and heavy parallel I/O, which makes it the default on production database and application servers. Common cases: metadata log replay failures, allocation group corruption, damage from xfs_repair -L run against a volume that needed something else, and recovery of files whose extents have been unmapped.
• Btrfs data recovery — the default filesystem on modern Synology DSM, SUSE Enterprise, and openSUSE Tumbleweed, and increasingly common on Fedora Workstation. Btrfs is a copy-on-write filesystem with generation tracking, which changes what’s recoverable and how. Common cases: transid mismatch after ungraceful reboot, unmountable volumes after DSM upgrades on Synology, snapshot subsystem corruption, and cases where Btrfs sits on top of mdadm and LVM in a stack that has to be reconstructed layer by layer.
• ZFS data recovery — the filesystem behind TrueNAS, Proxmox VE root pools, QNAP QuTS Hero, and most self-built enterprise storage. OpenZFS on Linux is now the dominant deployment. Common cases: pool refuses to import after power loss, a stale drive that came back online and injected old writes, RAIDZ vdev degradation, dataset deletion, and the specific class of QuTS Hero “storage pool error” cases where QNAP’s modified on-disk format complicates standard tooling.
• bcachefs data recovery — the newest mainline Linux filesystem, merged into the kernel in early 2024. Deployment is still concentrated in early adopters, home lab and Proxmox test rigs, and developers building on the tiered-storage and encryption features. We’re seeing the first cases now; this page covers what recovery looks like on a filesystem whose on-disk format is still evolving.

The above covers the filesystems we see most often. We also handle recoveries on older Linux and Unix filesystems — ext2 and ext3, ReiserFS (still deployed on long-running SUSE installations), JFS on legacy IBM AIX and Linux systems, HFS+ where Linux is reading Mac media, F2FS on Android devices and Linux systems using flash-native filesystems, and UFS/UFS2 on FreeBSD and Solaris volumes that come to us through Linux hosts. If your filesystem isn’t in the primary list, the initial consultation will confirm whether we can help.

What makes Linux data recovery different

Windows data recovery is usually a matter of understanding one filesystem (NTFS, occasionally ReFS or exFAT) sitting on top of a partition table. Mac data recovery is one filesystem (APFS or HFS+) inside a container. Linux is different. The filesystem is usually just the top layer of a stack, and the stack itself has to be understood to get to the data.

A typical Linux server storage layout might look like this from the bottom up: several physical drives; an mdadm software RAID array assembled from partitions on those drives; LVM providing volume management on top of the RAID; a LUKS-encrypted logical volume; an ext4 or XFS filesystem inside the encrypted volume. A NAS running Synology DSM does something similar: mdadm RAID at the bottom, then Synology’s custom SHR (Synology Hybrid RAID) layout that partitions drives into slices and pools multiple mdadm arrays through LVM, then Btrfs on top. QNAP standard QTS is mdadm plus LVM plus ext4. QuTS Hero replaces the mdadm-plus-LVM stack with ZFS pools.

When a Linux storage system fails, the failure can be at any layer of that stack, and diagnosing where the failure actually is matters as much as any specific recovery technique. A Synology “Volume Crashed” error can mean the mdadm array lost a member drive, or that LVM’s logical volume mapping was damaged, or that Btrfs metadata inside the logical volume won’t mount — three different problems with three different recovery approaches, all reported identically in the admin UI. A boot failure that looks like “filesystem corruption” sometimes turns out to be a RAID member that dropped out during the last shutdown. An LVM logical volume that has “disappeared” may be intact under an unallocated part of the volume group that a subsequent operation is about to overwrite.

The other property that makes Linux recovery different is the culture around it. Linux admins are more inclined than Windows or Mac users to try recovery themselves before calling for help — running fsck, xfs_repair, btrfs restore, zpool import -F, testdisk, photorec, or extundelete. Sometimes those tools solve the problem. When they don’t, the situation is usually worse than it was before, because most of those tools write to the source device by design. On several occasions per year, we see cases where the underlying data was fully intact when the failure first happened, and where destructive tool use during the DIY phase converted a straightforward recovery into a difficult one. If the situation is unclear, imaging the drives first and running everything against copies is almost always the safer path.

Where we see Linux in the lab

The Linux cases that come through our lab span most of the ways Linux gets deployed in real environments. In rough order of frequency:

• Consumer and small-business NAS units — Synology, QNAP, Netgear ReadyNAS, TerraMaster, ASUSTOR, Buffalo, and similar. Every one of these runs Linux underneath. Failure modes tend to cluster around firmware updates, RAID rebuild edge cases, aging drives, and ransomware. See our NAS data recovery hub for the brand-specific pages.
• Linux servers running production workloads — web servers, application servers, mail servers, container hosts, and the databases behind them. These are usually running RHEL/Rocky/AlmaLinux, Ubuntu Server, Debian, or SUSE. Failures come from power events, controller failures on the RAID hardware beneath, filesystem corruption after unclean shutdowns, and human error during maintenance.
• Virtualization hosts — Proxmox VE (which is Debian-based Linux with ZFS or LVM-thin storage), KVM on Linux, Xen on Linux, and Nutanix (which is Linux with a custom stack). These are usually recoveries within recoveries: the host’s storage has failed at some layer, and each guest VM is a separate filesystem inside a container file (qcow2, raw, or vmdk) sitting on the host’s filesystem.
• iSCSI and SAN target hosts — Linux servers exposing block storage via tgt, LIO, or vendor stacks. The LUNs are files or logical volumes on the host’s filesystem; when the host goes sideways or someone deletes the wrong LUN, the recovery is a Linux filesystem problem with an embedded guest filesystem to extract afterward.
• Storage appliances built on Linux — TrueNAS, iXsystems appliances, self-built ZFS servers, Ceph clusters (rarer), and a wide variety of vendor-branded units that are Linux underneath the branding. Recovery involves the appliance vendor’s specific storage layout on top of the underlying Linux stack.
• Linux desktops and workstations — less common in our caseload than servers, but a steady presence. Developers with Docker overlay storage, GNOME or KDE users with LUKS-encrypted home directories, and workstations set up as personal virtualization hosts all end up in our lab occasionally.
• Legacy Unix systems — Solaris on SPARC or x86, AIX, HP-UX, and occasionally older BSD variants. Case volume is low, but the systems are still in production in industries where replacement is expensive (industrial, utilities, some government). The recovery work applies the same principles adapted to older on-disk formats.

Common failure patterns across Linux systems

Most Linux recoveries fall into a handful of recurring patterns. The specifics differ by filesystem — and the spoke pages above cover each one in depth — but the general categories are consistent.

Power loss or kernel panic during heavy I/O. The canonical filesystem-corruption case. A server loses power or hits a hard reboot in the middle of a write. Journal-based filesystems (ext4, XFS) are designed to handle this by replaying the journal at mount time, but the replay can itself fail if the metadata is inconsistent or if the underlying storage returned bad data during the crash. Copy-on-write filesystems (Btrfs, ZFS, bcachefs) handle interrupted writes differently — the old data is intact by design — but they have their own failure modes: transid mismatch on Btrfs, uberblock inconsistency on ZFS, and the moving-target problem on bcachefs.

Silent corruption from failing drives. A drive in an array or a single-drive server develops bad sectors slowly. Reads succeed most of the time but return corrupted data occasionally. Filesystems without integrity checksums (ext4, XFS on older kernels, non-checksummed configurations) accept the bad data as valid. Filesystems with checksums (Btrfs, ZFS, bcachefs, XFS with metadata CRCs) detect the mismatch and either self-heal from redundancy or refuse to serve the corrupted data. The recovery here often has to unwind the corruption trail: identifying which files were affected, whether the corrupted data made it into backups, and reconstructing what’s recoverable from surviving good copies.

Storage stack layer failures. Failures at the mdadm, LVM, or LUKS layer that manifest as filesystem-level symptoms. mdadm arrays can drop members without warning; LVM metadata can be damaged by aggressive vgchange or pvremove operations; LUKS headers can be overwritten by an errant dd. In every case the filesystem above is fine — but it can’t be accessed because the layer beneath it is broken. Diagnosis and recovery start at the broken layer, not at the filesystem.

Human error at the shell. The category that has to be listed. rm -rf against the wrong directory. mkfs.ext4 on the wrong device node. lvremove of a logical volume that was in production, discovered five minutes later. vgchange -a n during troubleshooting followed by vgcreate that overwrites the metadata for the intended volume group. dd with the source and destination reversed. xfs_repair -L on a volume that needed the log intact. Every one of these is recoverable to some degree, and the recoverability depends entirely on what has been written to the affected device since the error — every write is another chance to overwrite something the recovery would have wanted.

Ransomware and malicious deletion. Growing as a percentage of our caseload. Linux hosts have become primary targets for ransomware families that specifically go after virtualization storage: ESXiArgs, LockBit’s Linux variant, and a handful of others that log into ESXi and Proxmox hosts and remove or encrypt VM container files. The recovery is a Linux filesystem recovery with a strong overlap with our ransomware recovery work.

Failed OS upgrades and migrations. The RHEL 7 to 8 migration, the CentOS to Rocky/Alma migration, DSM upgrades on Synology, TrueNAS Core to TrueNAS SCALE migrations, and the Btrfs feature flag transitions all produce occasional failures where the upgrade doesn’t complete cleanly and the volume is left in a state neither the old kernel nor the new one can fully mount. Recovery involves identifying the transition point and rebuilding the filesystem state to match one side or the other.

How we approach Linux recoveries

The first step on every Linux case is imaging. Every physical drive gets a forensic image through hardware that will not write back to the source. For a single-drive Linux server that’s straightforward. For a multi-drive array — whether that’s an mdadm software RAID, a hardware RAID with a controller card, a ZFS vdev group, or a Btrfs multi-device volume — every constituent drive is imaged and every downstream operation is performed against the copies.

From there the work moves up the stack. Any failed drive that’s preventing a good image is dealt with first — head-stack replacement in the cleanroom for mechanical failures, controller board repair for electrical failures, or firmware-level work for drives that report to the host but return errors during read. The next layer is whatever RAID or volume management sits below the filesystem: mdadm, LVM, hardware RAID metadata, ZFS vdev labels, or a NAS vendor’s custom volume management. Each of these layers has its own metadata format and its own reconstruction techniques.

Only once the underlying storage is virtually assembled do we get to the filesystem itself. And this is where the work becomes filesystem-specific. Ext4 recovery from a damaged superblock uses different techniques than Btrfs recovery from a transid mismatch or ZFS recovery from a faulted vdev. The spoke pages above cover the specifics for each filesystem in depth.

Our internal tool for this work is HOMBRE, developed by our own engineers over the past two decades and continually updated as new filesystems and storage stacks appear. HOMBRE handles every mainstream Linux filesystem, every common RAID and volume-management layer, and the vendor-specific storage stacks used by the major NAS platforms. When cases require capabilities beyond what any single tool provides — the truly damaged filesystems, the unusual stack configurations, the cases where standard tools have given up — the work is done by hand on the images by the engineers who built the tools.

What to do (and not do) right now

If you’re on this page because a Linux system just failed and the data on it matters, the actions that make the biggest difference to the recovery outcome are the simplest ones.

• Stop writing to the affected storage. Take the host offline if it’s a system disk. Unmount the volume if it’s data. If neither is possible without operational impact, stop the workloads that write to it. Every write is potential overwrite of recoverable data.
• Do not run repair tools yet. No fsck -y, no xfs_repair -L, no btrfs check --repair, no zpool import -F, no mkfs, no testdisk or photorec against the live device. If a tool’s help text says it will write to the source, the answer is no until we’ve talked.
• Do not restore from backup onto the failed volume until it’s been imaged. If the backup turns out to be incomplete or the restoration goes wrong, the original data is gone.
• Document what you’re seeing. Kernel messages from dmesg, mount error output, fsck output if you’ve already run it, the storage layout as you understand it (RAID level, filesystem, encryption), the sequence of events leading up to the failure. Screenshots or copy-pastes are fine. This shortens diagnosis significantly on the initial call.
• If you can safely image the drives yourself, do so. ddrescue to a large enough destination volume is the standard approach for drives that are still responsive. If you can’t image safely — the drive is making unusual noises, or you don’t have suitable destination hardware — wait until we can do it here.
• Call us or start a case. The initial consultation is free. We’ll walk through what realistic outcomes look like for your specific situation, what the engagement terms would be, and what to do with the hardware in the meantime.

How the engagement works for Linux cases

For straightforward single-drive Linux recoveries, our standard risk-free engagement applies: free evaluation, flat-rate quote in writing before any work begins, payment only on successful recovery.

Complex Linux cases — multi-drive arrays with damaged filesystems on top, ransomware or malicious-deletion scenarios on running hosts, superblock or vdev reconstructions on volumes where standard tools have given up, migrations gone wrong across major upgrade transitions — involve engineering hours that aren’t always predictable in advance. On those cases the engagement is:

• Free initial consultation, no charge for the conversation, no obligation afterward.
• Evaluation phase may be free or fixed-price depending on what’s involved in safely imaging the source drives. We tell you which before we start.
• Recovery work on complex cases may carry engineering charges that apply regardless of final outcome. When it does, the structure is explained clearly and in writing before any work begins. You decide whether to proceed on those terms.
• Where the case fits our standard risk-free model, we use it. Many Linux recoveries do qualify; we tell you which category yours is in during the consultation.

The principle across all of our complex-storage work is the same: terms agreed in writing up front, no surprise billing at the end.