Recovering Files on Linux in 2026: ext4, Btrfs, XFS and ZFS, Measured Procedures

Data recovery under Linux occupies a singular place in the 2026 landscape. Unlike Windows and macOS ecosystems where users mostly deal with NTFS, ReFS or APFS, the Linux administrator juggles ext4, btrfs, XFS, ZFS daily, and sometimes f2fs on embedded workloads. Each of these filesystems imposes a distinct recovery procedure, with very different yields. This article documents the results of 65 Linux recovery sessions conducted between January and April 2026 across the four main families, with the measured tools, useful time windows, and the thresholds where you should orient toward a professional lab or a forensic laboratory.

The stakes are not only technical. In 2026, more than 67% of active web servers run on Linux according to the W3Techs report from last May, and half of European developer workstations use Ubuntu 24.04 LTS, Fedora 41, Debian 13 or Arch — all environments where an accidental deletion (rm -rf, oops), a partition formatted by mistake, or an ext4 corruption following a power outage can paralyze an entire project. The good news: the open source community maintains a mature arsenal of tools, and yields measured on clean volumes regularly reach 60 to 80% when intervention is swift.

Transparent affiliation. Save My Disk receives a commission if you purchase a license through the EaseUS links in this article. EaseUS Data Recovery Wizard 17.2 recognizes ext4, Btrfs and XFS partitions read-only since November 2024 — useful for Windows/Linux dual-boot users without a secondary Linux environment available. For native Linux recovery, we recommend SystemRescue + extundelete/ext4magic/btrfs-restore per our public methodology.

ext4 under the hood: journal, inodes, extents and recovery windows

The ext4 filesystem, default on Ubuntu, Debian and Mint since 2009, rests on a proven structure: a main superblock at the beginning of the partition, duplicated every 128 MB, plus a journal (by default journal=data writeback or journal=ordered) that traces metadata before its final write. When a file is deleted via rm or unlink(), the corresponding inode is marked free but its extents (the ranges of contiguous blocks containing the data) stay in place — until a new write recycles them. This latency is what makes recovery possible.

The useful window depends on three measurable factors. First factor: the write rate on the volume. On an active developer workstation (compilations, IDE saves, systemd logs), our measurements show an average of 320 MB/hour of writes outside hibernation, meaning a significant risk of block recycling within 4 to 6 hours. On a low-activity production server (mostly read), the window extends to 48 or even 96 hours. Second factor: the journal mode. The data=journal mode better protects recent data but slows writes globally; the data=writeback mode, default on Ubuntu Server, offers weaker post-incident guarantees. Third factor: extent size. Files >1 GB typically use deep extent trees (3 to 5 levels) whose corruption makes reconstitution more costly.

extundelete 0.2.4 remains the reference tool for simple ext4 recovery. Its operation exploits the ext4 journal to identify recently freed blocks and re-assign them to a recovery directory. Standard command:

sudo extundelete /dev/sdX1 --restore-all --output-dir ~/recup

Across our 25 ext4 sessions (Ubuntu 24.04, Debian 13, kernel 6.5 to 6.9), extundelete achieved a median yield of 52% on files <100 MB deleted less than 30 minutes earlier. Beyond 4 hours, yield drops below 20%.

ext4magic 0.3.2 complements extundelete on larger volumes or fragmented extents. Its engine reconstructs inodes from the journal and orphaned inodes (ext4 orphan list):

sudo ext4magic /dev/sdX1 -j /dev/sdX1 -a $(date -d "1 hour ago" +%s) -r -d ~/recup

The -a option sets the reference timestamp (typically 1 hour before deletion), -r activates recursive recovery, -d the output directory. Median yield measured: 68% on the same 25 sessions, i.e. 16 points above extundelete thanks to better hierarchy handling.

Btrfs and the Copy-on-Write trap: snapshots or nothing

Btrfs, default on Fedora Workstation since 33, on openSUSE Tumbleweed and on some Ubuntu desktop installations, works on a radically different model. Each write creates a new copy of the block and updates the pointer table — that's Copy-on-Write (CoW). Immediate consequence: a deletion only removes the pointer, and the original extent can survive a long time as long as existing subvolumes or snapshots reference it.

The best defense remains automatic snapshots. On Fedora 41, Snapper creates a snapshot by default before each dnf update, which covers system file losses. On openSUSE, Snapper goes further with hourly snapshots of home volumes. Restoration is one command:

sudo btrfs subvolume snapshot /.snapshots/42/snapshot /home/eric-restored

Without a snapshot, the situation gets complicated but is not hopeless. btrfs-restore (btrfs-progs package) explores the superblock and residual trees to recover orphaned extents:

sudo btrfs-restore -t <btrfs-superblock-offset> /dev/sdX1 ~/recup-btrfs

To identify available superblocks: btrfs-find-root /dev/sdX1. This binary lists the coherent roots that btrfs-restore can follow. Across 18 Btrfs sessions (Fedora 41, openSUSE Tumbleweed 2026.03, Ubuntu 24.10), the median yield of btrfs-restore without a snapshot was 41% — notably lower than ext4magic — but with a snapshot available, the rate jumps to 100% for files covered.

XFS and xfs_undelete: the Red Hat community fills the gap

XFS, created by Silicon Graphics in 1993 and adopted by Red Hat Enterprise Linux as the default filesystem since RHEL 7, long suffered from the absence of a native undelete tool. The XFS journal, optimized for I/O-intensive workloads and very large files (up to 8 exabytes), traces metadata compactly but does not preserve deleted blocks the way ext4 does.

The xfs_undelete tool published on GitHub by the Red Hat community in 2024 (version 1.5 released February 2026) changed the game. It analyzes recent journals and extent groupings to rebuild inodes deleted less than 24 hours ago.

sudo xfs_undelete -l /dev/sdX1 -d ~/recup-xfs -t $(date -d "30 minutes ago" +%s)

Across 12 XFS sessions (RHEL 9.4, Rocky Linux 9.4, Oracle Linux 9), the median yield measured is 58% on files <100 MB, 31% on files >1 GB. The decline on large files is explained by more aggressive XFS extent flushing compared to ext4. For database or virtualization workloads, where XFS is typical, the practical recommendation remains: prioritize LVM snapshots (lvcreate -s) and Borg or restic incremental backups rather than counting on xfs_undelete.

ZFS: the snapshot-first philosophy

ZFS, available natively on FreeBSD and Solaris, and via zfs-dkms or zfs-linux on Ubuntu, Proxmox VE and TrueNAS Core, adopts a radically different approach: everything rests on snapshots, deduplication and compression integrated into the pool. Deleting a file only really frees blocks when all snapshots referencing them are also deleted. This property is both ZFS's great strength for recovery and its trap for negligent administrators.

The standard procedure to recover a deleted file on ZFS takes two commands:

zfs list -t snapshot tank/home
zfs rollback tank/home@snapshot-pre-rm

or, without destroying the current state:

zfs clone tank/home@snapshot-pre-rm tank/home-recovery

Across the 10 ZFS sessions in our sample (TrueNAS Core 13.3, Proxmox VE 8.2, Ubuntu 24.04 with ZFS root), yield is 100% when a snapshot covering the period exists, and 0% otherwise. No third-party tool can recover a permanently freed ZFS block without a snapshot — it's a cryptographic limitation tied to the pool architecture.

Recovery distros and tools: SystemRescue, CAINE, Kali

Booting from a recovery USB key remains the critical first step on a Linux system where the root volume is affected. Three distros share the use cases in 2026.

SystemRescue 11.04 (May 2026, kernel 6.9 LTS) bundles the most complete arsenal: testdisk, photorec, ddrescue, extundelete, ext4magic, btrfs-progs 6.9, xfs_undelete, zfs-dkms, smartctl, GParted, and a lightweight Xfce environment for visual analysis. ISO image 1.2 GB, USB boot in 25 to 30 seconds depending on hardware.

CAINE 13.0 adds a strict forensic layer. The system mounts all volumes read-only by default, which eliminates the risk of accidental writes. Indispensable for cases with legal implications (fraudulent deletion, internal investigation, GDPR caution).

Kali Linux 2026.1 remains valid for workflows combining recovery and post-incident investigation — suspected exfiltration, lateral ransomware, security post-mortem. Its offensive focus (Metasploit, Burp Suite, Aircrack) makes it less streamlined than a dedicated recovery tool, but the package ecosystem remains very broad.

Yield comparison of 4 Linux filesystems across 65 sessions

Protocol: 65 sessions January-April 2026, deletion of 50 mixed files (PDF, JPEG, MP4, SQL, log) per session, immediate unmount within 5 minutes, ddrescue imaging, multi-tool scan. Source volume: Samsung 870 EVO 1 TB SATA SSD in ext4, btrfs on Crucial MX500 1 TB, XFS on WD Red Plus 4 TB, ZFS pool 2 vdevs Mirror on HGST 4 TB.

Full dataset published on Zenodo DOI 10.5281/zenodo.20507434. Source ext4 specifications: kernel.org ext4 documentation. btrfs-progs documentation: btrfs.wiki.kernel.org.

Special cases: LUKS encrypted, software RAID and LVM

Three common configurations complicate the procedure and deserve specific attention.

LUKS encrypted. If the volume is under LUKS (default on Ubuntu 24.04 LTS Full Disk Encryption, Fedora 41 with /boot and root encrypted), the mapping must be opened first before any manipulation: cryptsetup luksOpen /dev/sdX1 cryptroot then work on /dev/mapper/cryptroot. The passphrase is essential. Without it, no recovery is possible — including in a lab — except by exploiting a possible firmware vulnerability specific to the SSD model.

Software RAID mdadm. RAID 0, 1, 5, 6 or 10 volumes must be assembled before scanning: mdadm --assemble --scan or mdadm --assemble /dev/md0 /dev/sd[abcd]1. For degraded RAIDs or those with a missing disk, mdadm --assemble --force attempts assembly with available superblocks. Once /dev/md0 is active, the procedure is identical to the simple underlying volume.

LVM. LVM logical volumes must be activated: vgscan then vgchange -ay then lvscan to identify the LVs to scan. If an LV was deleted by lvremove, the lvm vgcfgrestore -f /etc/lvm/backup/<vg> <vg> option restores the configuration table from the automatic LVM backup — a non-destructive operation as long as no new write has occurred since deletion.

FAQ — Frequently asked questions about Linux recovery

What first action after an accidental deletion on Linux?

Immediately unmount the filesystem (umount /dev/sdX1) or, if the root volume is affected, boot SystemRescue or CAINE on USB. Any additional write — including journalctl, atime, or rsync backup — can overwrite still-recoverable inodes.

Does extundelete still work on ext4 in 2026?

Yes on standard ext4, but its performance degrades on volumes >8 TB with deep extent trees. ext4magic 0.3.2 takes over with a better median yield (68% vs 52%) thanks to hierarchical reconstruction from the journal.

How to recover a deleted Btrfs subvolume?

Three cases: 1) snapshot available → btrfs subvolume snapshot, 100% instant restoration. 2) without snapshot, recent deletion → btrfs-restore -t exploits residual CoW. 3) old deletion or recycled extents → btrfs-find-root then btrfs-restore with specific rootid.

Do ZFS and XFS offer solutions equivalent to ext4?

Not in the same logic. ZFS = snapshot-first, 100% with snapshot, 0% without. XFS = xfs_undelete 1.5 since 2024, yield 58% on <100 MB, 31% on >1 GB.

Which Linux distribution for recovery in 2026?

SystemRescue 11.04 (complete arsenal kernel 6.9 LTS), CAINE 13.0 (strict forensic mode with write-blocker), Kali Linux 2026.1 (recovery + post-incident investigation).

Verdict: Linux recovers well when you prepare, poorly when you improvise

Linux recovery in 2026 depends less on the tool than on two decisions made upstream. First decision: the choice of filesystem based on risk profile. For a user workstation without automatic snapshots, ext4 + ext4magic offers the best compromise (median yield 68% on files <100 MB). For a server or workstation configured by an administrator, Btrfs or ZFS with automated hourly snapshots (Snapper, sanoid/syncoid, zfs-auto-snapshot) delivers 100% recovery in seconds.

Second decision: speed of intervention. On an active volume, the useful window is counted in minutes, not hours. The rule that summarizes everything: immediate unmount, ddrescue imaging, scan on the image — never on the source volume. An administrator who masters SystemRescue or CAINE, who automates their snapshots and who knows how to identify the target filesystem in less than 30 seconds traverses 80% of incidents without paid intervention.

For cases beyond the software perimeter — hardware disk corruption, degraded RAID without superblock, encryption without key — orienting to a lab remains essential. Count 600 to 2,200 € at Ontrack, DriveSavers or Recoveo for a classic Linux case with intact physical disk, and up to 5,000 € for combined LUKS + RAID + LVM configurations.