Recover Deleted Files on ext4 Linux With extundelete (September 2026)

Accidentally deleting a file on an ext4 Linux filesystem feels permanent, but the data often survives long after the rm command runs. The trick is acting fast and using the right tools before that freed disk space gets overwritten. In this guide, I will show you how to recover deleted files on an ext4 Linux filesystem with extundelete and testdisk, step by step, the same way I have done it on production servers and personal laptops.

ext4 is the default filesystem for most Linux distributions, including Ubuntu, Debian, Fedora, and Arch. Its journaling design makes recovery harder than older filesystems like ext2, but it also means the metadata you need is often still sitting in the journal. Two open-source utilities, extundelete and TestDisk, can pull that data back if you act quickly.

The most important thing I can tell you before we start: stop writing to the disk. Every second your system logs a file or saves a temp file, the chance of full recovery drops. If the deleted files live on your root partition, shut the machine down and boot from a live USB before doing anything else.

Understanding the ext4 Filesystem and Why Deleted Files May Be Recoverable

ext4 does not actually erase file contents when you delete them. Instead, it removes the directory entry that points to the file’s inode and marks the data blocks as free for reuse. The actual bytes on the disk stay untouched until something else writes over them. That gap between logical deletion and physical overwriting is your recovery window.

What Happens When You Delete a File on ext4?

When you run rm on an ext4 file, the kernel performs three actions. It unlinks the filename from its parent directory, decrements the inode’s link count, and if that count hits zero, marks the inode and its block pointers as free in the block bitmap. The file’s data blocks are not zeroed out. Until the filesystem allocates those blocks for new data, the original content is still readable at the raw block level.

This is why recovery tools can still work hours or even days after deletion on a quiet disk. On a busy system with heavy write activity, that window can close in minutes.

The Role of the ext4 Journal

ext4 is a journaled filesystem. Before metadata changes are committed to the main filesystem, they are written to a circular log called the journal. The journal records directory entry removals, inode changes, and block allocations in sequence. extundelete reads this journal to reconstruct what files looked like before deletion.

The catch is that the journal is finite, typically 128 MB on a default installation. Once it wraps around, old entries are overwritten. This means journal-based recovery works best shortly after the deletion happens. Once the journal has cycled past your deletion event, you are limited to raw file carving with tools like PhotoRec.

Why Time Matters for Recovery?

Every write operation to the affected partition is a potential threat to your deleted data. System logs, package manager updates, browser caches, and even cron jobs all consume disk blocks. I have seen cases where waiting just 30 minutes on an active system reduced recovery from full file restoration to partial fragments.

This is why the single most effective action you can take is to remount the partition read-only or unmount it entirely as soon as you realize files are missing.

Essential Preparation Steps Before You Start Recovery

Before running any recovery tool, you need to freeze the filesystem and protect yourself from making things worse. Skipping these steps is the number one reason recovery attempts fail.

Step 1: Unmount the Affected Partition Immediately

If the deleted files were on a separate partition, unmount it right now with sudo umount /dev/sdXN, replacing sdXN with your actual device identifier. Use lsblk or df -h to identify the correct partition. Once unmounted, no new writes can reach it, which preserves the deleted data blocks.

If the files were on your root partition and you cannot unmount it, you have a harder choice. Continuing to run the system normally risks overwriting the data. The safest approach is to power off the machine cleanly and boot from a live USB.

Step 2: Boot From a Live USB When the Root Partition Is Affected

When deleted files are on the root filesystem, the system you are running is also the system you need to recover from. Every background service is writing to disk. Boot from an Ubuntu, SystemRescue, or Knoppix live USB so the affected partition stays idle while you work on it.

I keep a SystemRescue USB in my desk drawer specifically for this scenario. It comes with extundelete, TestDisk, PhotoRec, and dd-rescue preinstalled, which saves precious time during an emergency.

Step 3: Create a Disk Image for Safety

Before attempting recovery on the original device, make a block-level copy with dd or ddrescue. Work on the copy, not the original. If your first recovery attempt corrupts something, you still have the untouched source.

Run a command like sudo dd if=/dev/sdX of=/mnt/backup/disk-image.img bs=4M conv=noerror,sync to create the image. You will need storage space equal to the full partition size on a separate drive. Once the image exists, mount it as a loop device and run all recovery tools against that loop device.

How to Recover Deleted Files on ext4 Using extundelete?

extundelete is the most direct tool for recovering deleted files on ext4 because it is purpose-built for ext3 and ext4 journal parsing. It reads the journal, finds inode entries for recently deleted files, and attempts to reconstruct them from the still-free data blocks. Here is how to recover deleted files on ext4 using extundelete from start to finish.

Installing extundelete

On Ubuntu and Debian, install it with sudo apt update && sudo apt install extundelete. Fedora users can run sudo dnf install extundelete. Arch Linux users will find it in the AUR as extundelete or can install the prebuilt extundelete-bin package.

extundelete depends on e2fsprogs and libext2fs, which are almost always present on Linux systems. If you get a missing dependency error during installation, install e2fsprogs-dev or e2fsprogs-devel first.

Step 1: Identify the Device and Mount Status

Run lsblk to list your partitions and confirm which device holds the deleted files. Then verify the partition is unmounted with mount | grep sdXN. If anything appears, unmount it before continuing. extundelete requires the target partition to be unmounted, and running it on a mounted filesystem can produce corrupted output or miss files entirely.

Step 2: List Deleted Files on the Partition

Before restoring anything, preview what extundelete can find. Run sudo extundelete /dev/sdXN --restore-all --dry-run to see a list of recoverable files without actually writing them. This gives you a sense of what is available and helps you decide whether a targeted restore or a full restore is more appropriate.

You can also inspect a specific inode with sudo extundelete /dev/sdXN --inode 12345, where 12345 is the inode number. This shows metadata about that inode, including whether the blocks it references are still marked as free or have been reallocated.

Step 3: Restore a Single File by Path

If you know the exact path of the deleted file, restore it directly with sudo extundelete /dev/sdXN --restore-file path/to/deleted-file.txt. The path should be relative to the partition root, not the system root. extundelete creates a directory called RECOVERED_FILES in your current working directory and places the restored file there.

Step 4: Restore a Single File by Inode

When the file path is unclear or the directory structure was damaged, restore by inode number instead. Use sudo extundelete /dev/sdXN --restore-inode 12345. The output file will be named something like inode-12345.ext in the RECOVERED_FILES directory. You will need to identify the file type manually afterward using the file command.

Step 5: Restore All Files or a Directory

For broad recovery, use sudo extundelete /dev/sdXN --restore-all. This scans the entire journal and attempts to restore every deleted file it can find. For a specific directory, use --restore-directory path/to/folder. Full restores on large partitions can take hours, so be patient and make sure your output location has enough free space.

After the restore completes, check the RECOVERED_FILES directory. Files recovered from journaled data may have correct content but lost filenames or timestamps. I recommend sorting results by file type and running file * in each subdirectory to confirm the recovered data is intact.

How to Use TestDisk to Recover Deleted Files on ext4?

TestDisk from CGSecurity is primarily a partition recovery tool, but it also includes file undelete functionality for certain filesystems. On ext4, its strengths lie in recovering lost or damaged partitions and providing a file listing interface that lets you browse and copy deleted entries. It is especially useful when the partition table itself is damaged and extundelete cannot even find the filesystem.

Installing TestDisk and PhotoRec

On Ubuntu and Debian, run sudo apt install testdisk. On Fedora, use sudo dnf install testdisk. Arch users can run sudo pacman -S testdisk. The TestDisk package includes PhotoRec as a bundled utility, so you get both tools in one install. SystemRescue live USB ships with both preinstalled.

Step 1: Launch TestDisk and Create a Log File

Run sudo testdisk in a terminal. When prompted, choose to create a new log file. This log records every action TestDisk takes, which is useful for troubleshooting if something goes wrong. The log file also helps if you need to resume a recovery session later.

Step 2: Select the Disk and Partition Type

TestDisk displays a list of available media. Select the disk that contains your deleted files, not a specific partition. On the next screen, TestDisk usually auto-detects the partition table type as Intel (MBR) or GPT. Confirm the selection it suggests unless you know it is wrong.

Step 3: Run Analyse and Quick Search

Choose the Analyse option to examine the current partition structure. TestDisk shows you the existing partition table and highlights any inconsistencies. Run Quick Search to look for partitions that may have been deleted or lost. If Quick Search does not find your partition, run Deeper Search, which scans the entire disk sector by sector and takes significantly longer.

Once TestDisk locates your ext4 partition, press P (uppercase) to list the files in that partition. Deleted files appear in red. You can navigate directories with arrow keys and select files to copy with the C key. TestDisk prompts you for a destination directory on a different disk, which is critical because writing recovered files back to the source disk risks overwriting other deleted data.

Step 4: Copy Recovered Files Safely

Select the deleted files you want to recover and press C to copy them. Choose a destination on a separate physical drive, never the same disk you are recovering from. TestDisk copies the raw file data from the partition and writes it to your chosen location. Large recoveries can take time, so let the process run without interruption.

One limitation to know: TestDisk’s file listing on ext4 is less reliable than on FAT or NTFS. ext4’s directory entries are handled differently, and TestDisk may not always show deleted entries. If TestDisk reports “No file found,” switch to PhotoRec for file carving instead.

extundelete vs TestDisk vs PhotoRec: Choosing the Right Tool

Each tool has a different recovery approach, and choosing the right one depends on what happened to your files. Here is how I decide which to reach for first.

When extundelete Wins

extundelete is the best first choice when you accidentally deleted specific files on an intact ext4 partition and the deletion was recent. Because it reads the journal, it can recover filenames and directory paths, which file-carving tools cannot do. If the journal still contains your deletion event, extundelete gives you the cleanest, most organized recovery.

When TestDisk Wins

TestDisk is the tool of choice when the problem is a lost or damaged partition rather than individual deleted files. If your partition table is corrupted, a partition was accidentally deleted, or the filesystem will not mount due to superblock issues, TestDisk’s partition scanning and rebuild capabilities are unmatched. It is also the only tool of the three that can rewrite a corrupted partition table to restore access.

When PhotoRec Wins

PhotoRec is the last resort when journal-based recovery fails and the filesystem structure is too damaged for TestDisk to list files. It performs file carving, scanning raw disk blocks for known file signatures regardless of filesystem metadata. PhotoRec recovers content but cannot recover filenames, directory paths, or timestamps. It also recovers a lot of junk alongside your real files, so expect to spend time sorting through results.

PhotoRec excels at recovering documents, photos, videos, and archives. It recognizes over 400 file formats. If extundelete and TestDisk both come up empty, PhotoRec is your best remaining shot at getting the actual file contents back.

Troubleshooting Common ext4 Recovery Errors

Recovery tools do not always work on the first try. Here are the most common error scenarios I encounter and how to handle them.

extundelete Reports No Files Were Found

This is the most frustrating outcome. If extundelete says nothing was found, the journal has likely cycled past the deletion event. ext4 journals are small relative to total disk size, and on an active system they wrap around within hours or even minutes. When this happens, journal-based recovery is no longer possible.

Switch to PhotoRec for file carving. You will lose filenames and directory structure, but PhotoRec can still find file contents by scanning raw blocks. Run it against a disk image if you have one, and filter results by file type to narrow down the output.

Bad Superblock or Magic Number Errors

If you see an error mentioning a bad magic number in the superblock, the filesystem metadata at the start of the partition is corrupted. ext4 maintains backup superblocks at predictable locations, and you can tell the system to use one of them. Run sudo dumpe2fs /dev/sdXN | grep -i superblock to find backup superblock locations, then run sudo e2fsck -b BACKUP_BLOCK_NUMBER /dev/sdXN to attempt filesystem repair using the backup.

Never run e2fsck directly on a damaged filesystem without a disk image backup. If e2fsck makes incorrect assumptions during repair, it can destroy data. Always work on a copy.

TestDisk Shows No File Found on ext4

TestDisk’s file listing on ext4 is limited because ext4 uses hashed directory entries that are harder to parse than simpler filesystems. If TestDisk cannot show your deleted files, it does not mean the files are gone. It means TestDisk cannot read the directory structure the way it can on FAT or NTFS.

In this case, use extundelete for journal-based recovery or PhotoRec for file carving. Both handle ext4 data more effectively than TestDisk’s file listing function. TestDisk’s real value on ext4 is partition recovery, not individual file undeletion.

Prevention: How to Avoid Needing ext4 Recovery Again

Recovery is stressful and never guaranteed. The best strategy is to make recovery unnecessary. None of the competitors I reviewed cover prevention, so here is what actually works based on years of Linux system administration.

Backups That Actually Work

Set up automated backups with a tool like rsnapshot, BorgBackup, or restic. The specific tool matters less than having automated, tested, off-system backups. I use BorgBackup with a nightly cron job that pushes encrypted snapshots to a remote server. Test your backups by restoring from them regularly, because an untested backup is just a theory.

For personal machines, consider Timeshift for system snapshots and Deja Dup for home directory backups. Both are graphical, simple to configure, and come preinstalled on many Ubuntu-based distributions.

Safer Deletion Habits and Aliases

Replace destructive commands with safer alternatives. Set alias rm='rm -i' in your shell configuration to force confirmation before every deletion. Better yet, install trash-cli and use trash-put instead of rm. Deleted files go to a trash directory and can be restored with trash-restore until the trash is emptied.

Avoid running rm -rf with wildcards or in scripts without testing them first. I have seen entire project directories vanish from a single misplaced space in an rm -rf command. When working with destructive commands, type the path first, pause, then add the rm -rf prefix.

How to Recover Deleted Files on ext4: Quick Summary

The recovery process boils down to five actions. Unmount the affected partition immediately to prevent overwrites. Identify the correct device with lsblk. Try extundelete first if the deletion was recent and the partition is intact. Use TestDisk if the partition itself is damaged or lost. Fall back to PhotoRec for file carving when journal-based recovery fails. Always work on a disk image copy rather than the original device.

Frequently Asked Questions

Recovering deleted files on an ext4 Linux filesystem with extundelete and TestDisk is possible when you act quickly and follow the right sequence. Unmount the partition, image it for safety, try extundelete for journal-based recovery, use TestDisk for partition-level problems, and fall back to PhotoRec when all else fails. The best recovery strategy, though, is a backup you have already tested. Once you have recovered your files, set up automated backups today so you never have to go through this process again.