Ext4 File Recovery: How to Recover Deleted Files

Ext4 file recovery is the process of restoring deleted or lost files from an ext4 filesystem, the default for most Linux distributions. You can often recover recently deleted files using tools like extundelete or debugfs, but success depends on acting quickly and understanding how ext4 handles deletion.

Background: What Is Ext4?

Ext4 (fourth extended filesystem) has been the default filesystem for most Linux distributions since 2008. It is the successor to ext3 and ext2, bringing improvements like larger file and volume sizes, extents (which reduce fragmentation), and delayed allocation. Unlike some filesystems, ext4 does not have a built-in “recycle bin” for files deleted from the command line or via GUI without a trash option. When you delete a file, the filesystem marks the space as available, but the actual data blocks are not immediately overwritten. This is why recovery is possible—until new data uses those blocks.

How Ext4 Deletion Works

When you delete a file on ext4, the filesystem performs two main actions:

• It removes the directory entry (the filename and inode number) from the directory’s index.
• It marks the inode (the metadata structure holding file size, permissions, and data block pointers) as free.

The actual file content remains on the disk in the data blocks. The inode is now available for reuse, and the data blocks are added to the free list. Until new files are created and use those blocks, the old data is still physically present. This is the window for recovery.

However, ext4 has a feature called delayed allocation. When you write a file, the filesystem may delay allocating the data blocks until the write is flushed to disk. This improves performance but can complicate recovery because the inode may not have the final block pointers if the file was never fully synced. For deleted files, the inode still contains the block pointers, so recovery tools can read them directly.

Choosing the Right Recovery Tool

Several tools can recover deleted files from ext4. The most common are:

• extundelete: A dedicated ext3/ext4 undelete utility. It reads the filesystem and attempts to restore files based on inode information. It works best when the filesystem is unmounted or mounted read-only.
• debugfs: A built-in ext4 debugging tool that can also be used for recovery. It allows you to inspect and manipulate the filesystem directly. It is more complex but often available by default.
• testdisk and photorec: These are general data recovery tools that work on many filesystems, including ext4. Testdisk can recover deleted partitions, while Photorec recovers files by scanning for file signatures, ignoring the filesystem structure. This is useful if the inode is damaged.
• ext4magic: Another tool that can recover deleted files and even some overwritten data, using the journal.

Choose the tool based on your situation. If you know the file path and the filesystem is intact, extundelete is often the easiest. If you have lost an entire partition or need to recover many files, testdisk or photorec may be better. If you are comfortable with low-level commands, debugfs gives you fine control.

Step-by-Step Recovery with extundelete

Here is a typical workflow using extundelete (run as root):

1. Stop using the filesystem immediately. Unmount it if possible: umount /dev/sda1. If it is your root filesystem, boot from a live USB and work from there.
2. Install extundelete if not already installed: sudo apt install extundelete (on Debian/Ubuntu) or use your package manager.
3. Run the recovery to a different drive to avoid overwriting data: sudo extundelete /dev/sda1 --restore-all. This will create a directory RECOVERED_FILES in the current directory.
4. If you know the specific file, use --restore-file path/to/file or --restore-inode INODE_NUMBER.
5. Check the recovered files. They may be corrupted if the blocks were partially overwritten.

If extundelete fails, try debugfs. First, find the inode number of the deleted file using lsdel in debugfs, then use dump to extract it.

Common Problems and Misconceptions

One common misconception is that you can recover a file after you have written new data to the same disk. In reality, the more you use the disk, the higher the chance that the deleted file’s blocks are overwritten. For example, if you delete a large video file and then download a new file, the new file may occupy the same blocks, making recovery impossible.

Another issue is that ext4’s journal (the jbd2 feature) does not store file data by default, only metadata. This means you cannot recover file content from the journal as you might with some other filesystems. ext4magic can sometimes use the journal to recover files that were recently created, but it is not a guarantee.

Also, if the file was deleted and the system was then shut down cleanly, the inode may still be intact. But if the system crashed or the disk has errors, the inode might be corrupted, and recovery becomes much harder.

Comparison: Ext4 vs. Other Filesystems

Compared to Windows’ NTFS or macOS’s APFS, ext4 does not have a native “previous versions” or “snapshot” feature (though LVM or btrfs can provide snapshots at a higher level). NTFS has a Master File Table that can sometimes make recovery easier, but it also has no recycle bin for command-line deletions. APFS has a snapshot feature that can be used for recovery if enabled. Ext4 is generally considered reliable, but its recovery options are less user-friendly than those of some other filesystems.

For example, on btrfs, you can use btrfs restore to recover files from a damaged filesystem, and snapshots are a core feature. On ext4, you need external tools and a bit of technical knowledge.

Safety and Best Practices

To maximize your chances of recovery and avoid further damage:

• Do not write anything to the disk after deletion. This includes mounting it read-write, running system updates, or even browsing the web if your home directory is on that disk.
• Use a live USB to boot into a separate system, so the target disk is not in use.
• Recover to a different physical drive or a network location, not to the same disk.
• Make a disk image first with dd or ddrescue if you can afford the space. Then work on the image, not the original disk.
• Do not defragment or run filesystem checks (like fsck) that might modify the filesystem before recovery.

Alternatives: Prevention and Backup

The best way to avoid ext4 file recovery is to have a solid backup strategy. Tools like rsync, restic, or borgbackup can automate backups. For desktops, using the GUI trash (which moves files to ~/.local/share/Trash) instead of rm gives you a second chance. For servers, consider using a filesystem with snapshots like btrfs or ZFS, or use LVM snapshots. Also, enabling the ext4 feature filetype (which is on by default) does not help with recovery, but journal can help with metadata consistency.

Frequently Asked Questions

Can I recover a file deleted with rm on ext4?

Yes, it is possible if you act quickly and the data blocks have not been overwritten. Use extundelete or debugfs immediately, and do not write new data to the disk.

How long do deleted files remain recoverable on ext4?

There is no fixed time. It depends on how much new data is written to the disk. On a lightly used system, files can remain recoverable for weeks; on a busy server, it might be minutes.

Does ext4 have a recycle bin?

No, ext4 itself does not. The desktop environment (like GNOME or KDE) provides a trash folder, but files deleted from the command line with rm bypass it.

Can I recover a file from an ext4 partition that has been formatted?

Formatting creates a new filesystem, which usually overwrites the superblock and inode tables. Recovery is possible with deep scanning tools like photorec, but it is much harder and less likely to succeed.

Is it safe to run fsck before recovery?

No. fsck can modify the filesystem to fix errors, which may overwrite the very metadata you need for recovery. Run fsck only after you have exhausted recovery attempts or have a backup image.

What if extundelete says “No files were found”?

This can happen if the inode has been reused or the filesystem is too damaged. Try photorec, which scans for file signatures and does not rely on inodes. It may recover files but with original filenames lost.

Related

• Smart Home Privacy Concerns & How to Fix Them
• Pixel Replacement: When to Upgrade Your Google Phone
• Manual J Load Calculation Online: How It Works