How to Recover a Corrupted ext4 Filesystem: A Step-by-Step Guide

A corrupted ext4 filesystem is one of those problems that tends to arrive at the worst possible moment — mid-deployment, after an unexpected power cut, or right before a deadline. The good news: ext4 was designed with recovery in mind, and Linux provides a solid chain of tools to get you back on your feet. This guide walks through the full recovery process, from initial diagnosis to last-resort options.

What Causes ext4 Filesystem Corruption?

ext4 filesystem corruption most commonly results from abrupt power loss, hardware failure, or forced system shutdowns that interrupt write operations mid-flight. Understanding the cause helps you choose the right repair strategy.

The most frequent culprits are:

Sudden power loss — writes that were buffered in memory never reach the disk, leaving metadata in an inconsistent state
Bad sectors — physical degradation on spinning HDDs or failing NAND cells on SSDs can corrupt blocks silently
Kernel panics or forced reboots — the REISUB key sequence or hard resets bypass the clean unmount process
Faulty RAM or storage controllers — hardware-level data corruption that no filesystem can fully defend against
Full disk during a write — running out of inodes or disk space while writing can leave orphaned structures

ext4's journaling feature handles many of these scenarios automatically. The journal logs metadata changes before committing them, so after an unclean shutdown, the kernel replays the journal on the next mount. But journaling only protects metadata — not data blocks — and it offers no protection against bad sectors or hardware-level corruption.

Before You Begin: Safety Precautions and Data Backup

Before running any repair tool, stop writing to the corrupted partition immediately. Every write operation risks overwriting recoverable data or making the corruption worse.

Three rules before you touch anything:

1. Boot into a live or rescue environment. If the corrupted partition is your root filesystem, you cannot safely repair it while it's mounted. Boot from a Live USB — any modern Linux distribution works — or use your system's built-in rescue mode. Running e2fsck on a mounted filesystem is dangerous and will likely cause additional corruption.

2. Create a disk image first. Before any repair attempt, image the entire partition with:

sudo ddrescue /dev/sda1 /mnt/backup/sda1.img /mnt/backup/sda1.log

ddrescue is purpose-built for failing drives — it retries bad sectors intelligently and logs progress so you can resume if interrupted. Work on the image copy, not the original, whenever possible.

3. Check kernel logs for hardware errors. Run dmesg | grep -i "error\|fail\|ata\|I/O" to look for storage controller errors or I/O failures. If dmesg shows repeated hardware errors, no software repair will fix an underlying drive failure — address the hardware first.

How to Check the Filesystem with e2fsck

e2fsck is the primary repair tool for ext4 (and ext2/ext3) filesystems. Run it on an unmounted partition to check and automatically fix most common inconsistencies.

The basic command is:

sudo e2fsck -f -y /dev/sda1

Flag breakdown:

-f — forces a check even if the filesystem appears clean (the "clean" flag can be wrong after a crash)
-y — automatically answers "yes" to all repair prompts; useful for unattended recovery, but review the output afterward
-v — verbose output, helpful for diagnosing what was actually repaired
-C 0 — shows a progress bar for large partitions

e2fsck runs in five passes, checking inodes, directory structure, directory connectivity, reference counts, and group summary information. Exit code 0 means no errors. Exit code 1 means errors were corrected. Exit code 2 means the system should be rebooted. Exit codes 4 and above indicate uncorrected errors — that's when you escalate.

If e2fsck reports "filesystem has unsupported feature," you may be running an older version of e2fsck against a filesystem with newer features enabled. Update e2fsprogs with your package manager and try again.

Recovering from a Corrupted Superblock

The superblock stores critical filesystem metadata — size, block count, inode count, and the filesystem state flag. When it's corrupted, the partition won't mount at all. Fortunately, ext4 stores multiple backup superblocks across the disk.

To list backup superblock locations without modifying anything:

sudo mke2fs -n /dev/sda1

The -n flag is critical — it performs a dry run and prints what would be written, including backup superblock locations like 8193, 24577, 40961. Alternatively, if the primary superblock is readable enough, use:

sudo dumpe2fs /dev/sda1 | grep -i superblock

Once you have a backup superblock address, restore from it:

sudo e2fsck -b 8193 /dev/sda1

Replace 8193 with the actual backup superblock location from your output. e2fsck will use the backup to reconstruct the primary superblock and then proceed with its normal repair passes.

You can also use tune2fs -l /dev/sda1 to inspect filesystem parameters when the superblock is partially readable — it's a useful diagnostic step before committing to a full repair.

Using debugfs to Manually Recover Files

debugfs is an interactive filesystem debugger that lets you browse and extract files from a damaged ext4 partition when automated repair isn't enough. Always open it in read-only mode first.

sudo debugfs -R "ls /" /dev/sda1

Or launch an interactive session:

sudo debugfs /dev/sda1

Inside the interactive shell, useful commands include:

ls /path — list directory contents
cat /path/to/file — display file contents
dump /path/to/file /local/destination — extract a file to your local system
lsdel — list recently deleted inodes (useful for undelete attempts)
stat <inode> — inspect inode metadata

debugfs won't fix the filesystem, but it can save your data when the structure is too damaged for e2fsck to fully repair. Extract critical files to a separate, healthy partition before attempting any further repair operations. The tool is part of the e2fsprogs package, which is installed by default on most Linux distributions.

Fixing Mount Failures and /etc/fstab Issues

If your system drops to an emergency shell at boot with a message like "Give root password for maintenance," the problem is often a failed filesystem mount — either because the partition is corrupted or because /etc/fstab references a partition that no longer exists or has a different UUID.

From the emergency shell, remount the root filesystem read-write so you can edit files:

mount -o remount,rw /

Then open /etc/fstab with a text editor and check each entry. Common problems:

Wrong UUID — after reformatting or replacing a drive, the UUID changes. Run blkid /dev/sda1 to get the current UUID and update fstab accordingly.
Missing nofail option — for non-critical partitions (external drives, secondary data volumes), add nofail to the mount options so a missing or corrupted partition doesn't block the boot process.
Wrong filesystem type — if a partition was reformatted as a different type, the fstype column in fstab must match.

After editing fstab, run mount -a to test all entries before rebooting. If a specific partition still fails to mount, run e2fsck on it from the emergency shell before adding it back to the mount table.

When Recovery Fails: Next Steps

When e2fsck returns unrecoverable errors and debugfs can't reach your files, the filesystem may be beyond software repair. At this point, the path forward depends on what failed.

If the underlying disk is healthy (no hardware errors in dmesg, smartctl -a /dev/sda shows no reallocated sectors or pending sectors), you can reformat and restore from backup:

sudo mkfs.ext4 /dev/sda1

If smartctl shows a deteriorating health status — growing reallocated sector counts, a high raw read error rate, or a pending sector count above zero — replace the drive before restoring data to it. Restoring to a failing disk just restarts the clock on the next corruption event.

For partitions where you have no backup and debugfs couldn't extract what you need, third-party tools like photorec or testdisk can attempt deep carving of raw block data. They recover file content without metadata, so filenames and directory structure are usually lost — but the data itself may be retrievable.

The honest reality: not all data can be saved. ext4's journaling dramatically improves recovery odds after a clean crash, but physical media failure or severe logical corruption can leave blocks genuinely unreadable. A working backup strategy — even a simple weekly rsync to a separate drive — is worth more than any recovery tool.

Frequently Asked Questions

Can I run e2fsck on a mounted filesystem?

No. Running e2fsck on a mounted filesystem is unsafe and can cause additional corruption. Always unmount the partition first, or boot into a live environment if the partition is your root filesystem. e2fsck will warn you and refuse to proceed if it detects the filesystem is mounted.

How do I know if bad sectors are causing the corruption?

Check dmesg | grep -i "I/O error\|bad sector\|ata" for kernel-level storage errors. Then run sudo smartctl -a /dev/sda (from the smartmontools package) and look at the "Reallocated_Sector_Ct" and "Current_Pending_Sector" attributes. Any non-zero value in those rows is a red flag that warrants drive replacement.

What does "filesystem has unsupported feature" mean in e2fsck output?

This error means the version of e2fsck you're running is older than the filesystem features enabled on the partition. Update e2fsprogs to the latest version available for your distribution. On Debian/Ubuntu: sudo apt update && sudo apt install e2fsprogs.

How long does e2fsck take on a large partition?

On a healthy 1 TB partition, e2fsck typically completes in 2–10 minutes. On a heavily fragmented or damaged filesystem with millions of inodes, it can run for an hour or more. Use the -C 0 flag to display a progress bar. Avoid interrupting it mid-run — an incomplete repair can leave the filesystem in a worse state than before.

Will e2fsck delete my files during repair?

It can. When e2fsck finds inodes with broken directory entries or orphaned data, it may move files to the lost+found directory rather than delete them outright. However, severely corrupted files may be truncated or removed if their inode data is unrecoverable. This is why imaging the disk before running any repair tool is the single most important precaution you can take.