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

Data recovery under Linux holds a special place in the 2026 landscape. On Windows and macOS, users mostly deal with NTFS, ReFS or APFS. The Linux administrator juggles ext4, btrfs, XFS and ZFS every day, and sometimes f2fs on embedded workloads. Each of these filesystems needs its own recovery steps, with very different yields. This article maps out the recovery steps for each of the four main families. It covers the right tools, the useful time windows, and the point where you should turn to a pro lab or a forensic lab.

The stakes are not only technical. Linux powers most active web servers. A large share of developer workstations run Ubuntu 24.04 LTS, Fedora 41, Debian 13 or Arch. On all of them, a slip can stall a whole project: an rm -rf typo, a partition formatted by mistake, or an ext4 corruption after a power outage. The good news is that the open source community keeps a mature set of tools. Recovery on clean volumes is often good when you act fast.

Transparent affiliation. Save My Disk earns a commission if you buy a license through the EaseUS links in this article. EaseUS Data Recovery Wizard 17.2 reads ext4, Btrfs and XFS partitions read-only since November 2024. That helps Windows/Linux dual-boot users with no second Linux setup at hand. For native Linux recovery, we suggest SystemRescue plus extundelete/ext4magic/btrfs-restore, per our public methodology.

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

The ext4 filesystem has been the default on Ubuntu, Debian and Mint since 2009. It rests on a proven structure. A main superblock sits at the start of the partition and is copied every 128 MB. A journal (by default journal=data writeback or journal=ordered) traces metadata before its final write. When a file is deleted via rm or unlink(), the matching inode is marked free. But its extents, the ranges of contiguous blocks that hold the data, stay in place until a new write reuses them. This delay is what makes recovery possible.

The useful window depends on three factors you can measure. The first factor is the write rate on the volume. An active developer workstation (compilations, IDE saves, systemd logs) writes hundreds of MB per hour outside hibernation. That means a real risk of block reuse within 4 to 6 hours. On a low-activity production server (mostly read), the window stretches to 48 or even 96 hours. The second factor is the journal mode. The data=journal mode guards recent data better but slows writes across the board. The data=writeback mode, default on Ubuntu Server, gives weaker guarantees after an incident. The third factor is extent size. Files >1 GB tend to use deep extent trees (3 to 5 levels), and when those break, rebuilding costs more.

extundelete 0.2.4 stays the go-to tool for simple ext4 recovery. It reads the ext4 journal to spot blocks freed lately, then writes them to a recovery directory. Standard command:

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

On a fresh ext4 deletion (Ubuntu 24.04, Debian 13, kernel 6.5 to 6.9), extundelete recovers a good share of small files (<100 MB) when you run it within minutes. Past a few hours, the yield drops sharply.

ext4magic 0.3.2 backs up extundelete on larger volumes or fragmented extents. Its engine rebuilds inodes from the journal and from 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 (often 1 hour before deletion), -r turns on recursive recovery, and -d sets the output directory. ext4magic usually recovers more than extundelete, because it handles the folder tree better.

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

Btrfs is the default on Fedora Workstation since 33, on openSUSE Tumbleweed, and on some Ubuntu desktop installs. It works on a very different model. Each write makes a new copy of the block and updates the pointer table. That is Copy-on-Write (CoW). The result is direct: a deletion only removes the pointer. The original extent can live on for a long time, as long as existing subvolumes or snapshots still point to it.

The best defense is automatic snapshots. On Fedora 41, Snapper makes 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 takes one command:

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

Without a snapshot, things get harder but are not hopeless. btrfs-restore (btrfs-progs package) scans the superblock and leftover trees to recover orphaned extents:

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

To find available superblocks: btrfs-find-root /dev/sdX1. This binary lists the sound roots that btrfs-restore can follow. On Btrfs (Fedora 41, openSUSE Tumbleweed, Ubuntu 24.10), btrfs-restore without a snapshot recovers far less than ext4magic. But with a snapshot on hand, restoration is complete for the files it covers.

XFS and xfs_undelete: the Red Hat community fills the gap

XFS was created by Silicon Graphics in 1993 and became the default filesystem in Red Hat Enterprise Linux since RHEL 7. For a long time it had no native undelete tool. The XFS journal is tuned for I/O-heavy workloads and very large files (up to 8 exabytes). It traces metadata compactly, but it does not keep deleted blocks the way ext4 does.

The xfs_undelete tool, put on GitHub by the Red Hat community in 2024 (version 1.5 released February 2026), changed the game. It reads 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)

On XFS (RHEL 9.4, Rocky Linux 9.4, Oracle Linux 9), xfs_undelete recovers more on small files than on large ones. The drop on large files comes from harder XFS extent flushing compared to ext4. For database or virtualization workloads, where XFS is common, the practical advice holds: put LVM snapshots first (lvcreate -s), along with Borg or restic incremental backups, rather than counting on xfs_undelete.

ZFS: the snapshot-first philosophy

ZFS runs natively on FreeBSD and Solaris, and via zfs-dkms or zfs-linux on Ubuntu, Proxmox VE and TrueNAS Core. It takes a very different approach. Everything rests on snapshots, deduplication and compression built into the pool. Deleting a file only frees blocks for good once all snapshots that point to them are deleted too. This trait is both ZFS's great strength for recovery and its trap for careless 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

On ZFS (TrueNAS Core 13.3, Proxmox VE 8.2, Ubuntu 24.04 with ZFS root), recovery is complete when a snapshot covers the period, and out of reach otherwise. No third-party tool can recover a ZFS block freed for good without a snapshot. It is a cryptographic limit tied to the pool design.

Recovery distros and tools: SystemRescue, CAINE, Kali

Booting from a recovery USB key stays the critical first step when the root volume is hit. Three distros split the use cases in 2026.

SystemRescue 11.04 (May 2026, kernel 6.9 LTS) bundles the fullest set of tools: testdisk, photorec, ddrescue, extundelete, ext4magic, btrfs-progs 6.9, xfs_undelete, zfs-dkms, smartctl, GParted, and a light Xfce desktop for visual checks. The ISO image is 1.2 GB, and it boots from USB 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, so there is no risk of accidental writes. It is a must for cases with legal weight (fraudulent deletion, internal review, GDPR caution).

Kali Linux 2026.1 still fits workflows that mix recovery and post-incident review: suspected exfiltration, lateral ransomware, a security post-mortem. Its offensive focus (Metasploit, Burp Suite, Aircrack) makes it less tidy than a dedicated recovery tool. But the package ecosystem stays very broad.

Recovery by Linux filesystem

The table below sums up recovery behavior by filesystem. It draws on the documented tools, their journaling/CoW mechanics, and the consensus of public reviews. Always unmount within minutes, and image with ddrescue before any scan.

Source ext4 specifications: kernel.org ext4 documentation. btrfs-progs documentation: btrfs.wiki.kernel.org.

Special cases: LUKS encrypted, software RAID and LVM

Three common setups make the steps harder and need extra care.

LUKS encrypted. If the volume is under LUKS (default on Ubuntu 24.04 LTS Full Disk Encryption, Fedora 41 with /boot and root encrypted), open the mapping first, before you touch anything else: cryptsetup luksOpen /dev/sdX1 cryptroot, then work on /dev/mapper/cryptroot. The passphrase is a must. Without it, no recovery works, not even in a lab, unless you exploit a possible firmware flaw specific to the SSD model.

Software RAID mdadm. Assemble RAID 0, 1, 5, 6 or 10 volumes before you scan: mdadm --assemble --scan or mdadm --assemble /dev/md0 /dev/sd[abcd]1. For degraded RAIDs, or ones with a missing disk, mdadm --assemble --force tries to assemble with the superblocks on hand. Once /dev/md0 is active, the steps match those for the plain volume beneath.

LVM. Activate LVM logical volumes first: vgscan, then vgchange -ay, then lvscan to find 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. This is a safe, non-destructive step, as long as no new write has happened since the deletion.

FAQ - Frequently asked questions about Linux recovery

What first action after an accidental deletion on Linux?

Unmount the filesystem at once (umount /dev/sdX1). If the root volume is hit, boot SystemRescue or CAINE on USB. Any extra write can overwrite inodes you could still recover. That includes journalctl, atime, or an rsync backup.

Does extundelete still work on ext4 in 2026?

Yes on standard ext4, but it slows down on volumes >8 TB with deep extent trees. ext4magic 0.3.2 takes over with a usually better yield, because it rebuilds the folder tree from the journal.

How to recover a deleted Btrfs subvolume?

Three cases: 1) snapshot available → btrfs subvolume snapshot, instant full 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 way. ZFS is snapshot-first: complete with a snapshot, out of reach without. XFS has xfs_undelete 1.5 since 2024, which recovers more on small files than on large ones.

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 choices made early. The first choice is the filesystem, based on your risk profile. For a user workstation without automatic snapshots, ext4 plus ext4magic strikes the best balance on freshly deleted small files. For a server or workstation set up by an administrator, Btrfs or ZFS with automatic hourly snapshots (Snapper, sanoid/syncoid, zfs-auto-snapshot) gives near-complete recovery in seconds.

The second choice is how fast you act. On an active volume, the useful window is counted in minutes, not hours. One rule sums it all up: unmount at once, image with ddrescue, scan on the image, never on the source volume. An administrator who knows SystemRescue or CAINE well, who automates snapshots, and who can spot the target filesystem in less than 30 seconds gets through most incidents without paid help.

Some cases sit beyond what software can fix: hardware disk corruption, a degraded RAID with no superblock, or encryption with no key. For those, a lab stays essential. Count 600 to 2,200 € at Ontrack, DriveSavers or Recoveo for a standard Linux case with an intact physical disk, and up to 5,000 € for combined LUKS + RAID + LVM setups.

Related guides

• Automate Linux backups with cron and rsync