EXT4 File System Recovery on Linux: How to Recover Deleted Files Without a Backup

The ext4 file system uses a journalling mechanism along with a unique extent-based architecture. Both features contribute to the fact that ext4 data recovery on Linux is fundamentally more complex than on older file systems. Storage administrators can use open-source utilities such as TestDisk, PhotoRec, extundelete, debugfs, and R-Linux to attempt journal-based inode reconstruction or signature-based file carving from unmounted partitions. However, used incorrectly, these tools can permanently destroy recoverable metadata. Their effectiveness is also limited by timing, since the journal retains pre-deletion data only for a short period before it is overwritten. When DIY methods fail, data recovery engineers rely on inode-level reconstruction to recover deleted files from Linux ext4 systems.

Losing files on a Linux system without a backup is not necessarily permanent. However, the window for recovery is narrow, and the margin for error is smaller than most administrators expect. ext4 data recovery is more challenging than ext3 because of what happens at the moment of deletion. The file system clears the extent tree entries inside the inode. These entries are the metadata that map a file’s logical blocks to their physical locations on disk.

The data blocks remain on the disk until the file system overwrites them. However, the information indicating these blocks is deleted immediately. Recovery depends more on what happens after deletion than on the deletion itself. The amount of metadata still available in the journal (JBD2) sets the limit for how much can be recovered. The recovery tool used and whether the drive remains unchanged in the minutes after deletion also affect the outcome.

Why ext4 Recovery Is More Difficult Than ext3

The way ext3 and ext4 handle file deletion creates a significant difference in the difficulty of data recovery.

ext3 uses indirect block pointers to track where files are stored on disk. These pointers are references inside the file’s information structure that point to each data block. When a file is deleted on ext3, the kernel marks it as deleted and removes its link, but the pointers that indicate where the file’s data actually resides remain readable. This allows recovery tools to follow these pointers and locate the data blocks.

ext4 replaced this system with a more efficient structure called extents. An extent is a descriptor that describes where a large chunk of contiguous data is stored, and can describe up to 128 MiB of data in a single record. When a file is deleted on ext4, the kernel erases the extent entries from the file’s information structure. It clears the starting block location, the size, and the extent header.

🚨 Critical: The actual data blocks remain on the disk until new data overwrites them, but the metadata describing their locations is deleted. This complicates ext4 file system recovery, as recovery tools cannot simply examine the file’s information structure to determine where the data blocks reside. 

How ext4 Journalling Works and Its Limitations

ext4 uses a dedicated journalling subsystem called JBD2 (Journaling Block Device 2). JBD2 exists as an independent software layer between the file system and the block device. It maintains a circular log (a fixed-size region of disk space that records metadata changes before they are written to the main file system structures).

By default, the journal is stored in a specific location on the same device. The journal size automatically adjusts based on the file system size. ext4 allows you to place the journal on a separate device for better performance.

Note: The kernel documentation sets the upper limit at 10,240,000 file system blocks. The mke2fs man page caps custom journal sizes at 102,400 blocks. These figures describe different limits; the kernel documentation should be referenced for accuracy.

The journal protects the file system from corruption when operations are interrupted unexpectedly. This can happen due to power loss, a system crash, or a forced reboot. Without the journal, an interrupted write could leave some metadata updated whilst other parts remain unchanged. This mismatch could cause the file system to point to the wrong data locations or reference inodes that were never fully created, resulting in serious data corruption.

The JBD2 Journal and Transaction Stages

The journal operates through three stages:

Two additional mechanisms activate under certain conditions:

Most Linux distributions, including Ubuntu, Debian, and RHEL, use a default journalling mode called data=ordered . In this mode, the journal records only metadata, such as file information, system records, and directory listings. The actual file content is not journalled. An alternative mode called data=journal journals both metadata and file content, but production systems rarely use it. Journalling every piece of data twice significantly reduces write performance, a cost most deployments cannot afford.

The Journal’s Limits for Deleted File Recovery

The default journalling mode directly limits what is possible during ext4 file system recovery. Even when the journal contains a snapshot of the file before deletion, only the block addresses can be retrieved from it. If those data blocks have been overwritten by new files between deletion and recovery, the journal alone cannot help.

ext4 Recovery Tools: extundelete, TestDisk, and PhotoRec

extundelete and TestDisk are two of the most commonly used ext4 recovery tools. They are frequently confused because both are open-source and used after data loss, but they solve different problems. Understanding these differences is essential when choosing the right tool.

extundelete: Journal-Driven Inode Reconstruction

extundelete searches the journal for older copies of files that still contain the information needed to locate their data blocks. When it finds a usable file snapshot, it reads the relevant data blocks and saves the recovered file to a designated location.

The affected partition must be unmounted or mounted as read-only for the tool to work safely. extundelete allows you to search by filename, directory path, or file ID. It also accepts timestamp filters to narrow the search window to a specific time range.

However, extundelete cannot recover files whose journal entries have been overwritten by newer activity. It does not restore hard links, symbolic links, or file attributes. On large partitions, some versions of extundelete can experience stability problems including crashes. Because of this, some users choose to use extundelete-ng, an updated version of the tool, instead.

TestDisk: Partition and Superblock Recovery

TestDisk operates at the partition level. It locates lost or damaged partitions, rebuilds corrupted partition tables (MBR and GPT), and restores damaged superblocks. TestDisk cannot recover individual deleted files. It can only restore partition-level and superblock-level structures, which may allow the file system to become readable again.

PhotoRec: File Signature Carving

PhotoRec ignores file system metadata entirely. It scans raw disk sectors for magic-byte sequences, which are signature headers that identify file formats such as JPEG, PDF, SQLite, and ZIP. When PhotoRec finds a recognised header, it carves the subsequent blocks into a recovered file. However, PhotoRec cannot distinguish between a valid file and a stale fragment that shares the same header signature, so its output may include corrupted or partial files alongside genuine recoveries.

Why These Tools Are Not Interchangeable

extundelete and TestDisk are not interchangeable and address distinct issues. extundelete reads information about each deleted file from the journal to rebuild it. To restore the visibility and mountability of a damaged disk, TestDisk rebuilds superblocks and partition tables. 

If a partition is missing, TestDisk must be used first to make the volume accessible. If a file is deleted but the partition is intact and mounted, extundelete is the appropriate tool. Many real recovery situations require both tools; run one after the other in sequence.

debugfs and R-Linux: Manual Inspection and Graphical Recovery

debugfs is included with e2fsprogs and provides raw, interactive access to the internal structures of ext4. It is not an automated recovery tool, but a diagnostic instrument used for manual inspection and, in some cases, manual recovery. The  lsdel  command lists deleted inodes that have not yet been reallocated. The logdump -i <inode_number> command extracts journal entries tied to a specific inode. Once block addresses are identified, dd can copy the raw data from those locations into a new file.

⚠️ Requires Expertise: The process requires a detailed understanding of inode structures and journal mechanics, and debugfs includes no built-in safety checks. An incorrect command can cause further corruption.

R-Linux is built differently. The engine comes from R-Studio, a commercial product, but the interface here is graphical, with no command line involved. Partitions in ext2, ext3, and ext4 formats are within its scan range. Live partitions can be scanned directly, or a disk image can be analysed instead. Files disappear for different reasons — a formatting mistake, a damaged partition, a straightforward deletion — and R-Linux is built to find them regardless of the cause. 

Step-by-Step: Safe ext4 Data Recovery Checklist for Linux

Anyone attempting to recover deleted files on a Linux ext4 system should follow this sequence instead of running a recovery tool directly on the affected drive.

Which ext4 Recovery Tool Fits Which Data Loss Scenario

Choosing the correct recovery tool depends entirely on the type of data loss encountered. The table below matches common failure scenarios to the most effective tool and explains what each can and cannot recover.

Scenario	Recommended tool	What it recovers	Key limitation
Recent deletion, partition undamaged	extundelete	Files with original names and paths	Requires journal to still hold pre-deletion metadata
Known inode number, targeted recovery	debugfs + dd	Single files via manual block extraction	No safety checks; requires technical expertise
Partition table missing or corrupted	TestDisk	Partition visibility and superblock integrity	Does not recover individual deleted files
Metadata destroyed, last resort	PhotoRec	File content by signature detection	Loses filenames, paths, and directory structure
GUI-preferred, formatted partition	R-Linux	Files from reformatted ext4 volumes	May lose directory structure on raw recovery

The Risks of Misusing e2fsck

e2fsck is the standard consistency checker for the ext file system family. Its purpose is to make an ext4 volume mountable and internally consistent, not to preserve or recover files.

• e2fsck first attempts to replay the journal, which is often sufficient to restore consistency after an improper shutdown. If file system damage remains, it runs a full five-pass scan covering inode structures, block references, directory consistency, the directory tree from root, link counts, and metadata against on-disk bitmaps.
• The core issue is that e2fsck treats unvalidatable structures as errors to be eliminated. Orphaned inodes are moved to /lost+found , where they are deleted or renamed by inode number with their original path removed. Each removal breaks the link between file metadata and physical data blocks, destroying the information that recovery tools such as debugfs and extundelete depend on.
• The -y flag increases this risk because it automatically accepts every proposed correction. On a significantly corrupted volume, this can result in mass inode clearing, directory truncation, and block reallocation within a single pass. The volume may become mountable afterwards, but the metadata required for ext4 data recovery is often permanently altered.
• Running e2fsck on a mounted file system carries the highest risk. The kernel retains cached metadata in memory whilst e2fsck writes corrections directly to the underlying block device. The two versions diverge, and the resulting conflict can corrupt an otherwise healthy volume.

When DIY Recovery Is No Longer Safe 

Several technical conditions can push ext4 data loss beyond what open-source utilities can address.

• Extent clearing and the metadata gap: ext4 zeroes the extent header and block pointers inside the inode at deletion. Once those references are gone, no software tool can determine where the file’s data blocks reside unless the journal still contains a pre-deletion inode snapshot.
• TRIM and SSD garbage collection: On solid-state drives mounted with the discard option, the file system issues TRIM commands for freed blocks immediately upon deletion. The drive controller may physically erase those blocks at any time thereafter. Once erased at the hardware level, no data recovery method can retrieve the data.
• Cascading metadata damage: Repeated unsuccessful recovery attempts progressively overwrite the residual metadata and unallocated data blocks that a data recovery effort depends on.

Signs It Is Time to Stop and Call a Professional

Not every case of data loss is suited to DIY recovery. Certain warning signs indicate physical or deeper logical damage, in which continued attempts at home are more likely to cause harm than good.

Inode-Level Recovery: The Professional Approach

Professional ext4 file system recovery follows a workflow that separates hardware stabilisation from logical reconstruction, with all analytical work performed on cloned disk images, never on the original media.

• Imaging Before Analysis: The first priority for a data recovery expert is to build a bit-for-bit image of the affected device. All subsequent data recovery is carried out on the cloned image. Professionals use hardware imagers instead of standard operating system drivers to clone an affected drive. If the drive has mechanical damage, engineers perform component-level work in a Class 100 cleanroom before imaging begins.
• Inode and Extent Tree Reconstruction: Engineers perform software-based journal replay on the forensic image, scanning JBD2 transactions for pre-deletion inode snapshots without writing changes back to the clone. When the journal has already wrapped, they use a second technique to target the extent tree directly. Although ext4 zeroes the root extent node inside the inode at deletion, the index nodes stored in separate data blocks may survive. Engineers scan unallocated space for the extent header magic number (0xf30a) to locate these orphaned nodes and reconstruct the file’s block map.

Why Professional Recovery Succeeds Where DIY Tools Fail

Every recovery method described in this guide depends on metadata surviving long enough to be read, and on the drive remaining healthy enough to reliably yield that metadata. In practice, many ext4 data loss cases reach a point where the journal has cycled past the critical transaction, an aggressive e2fsck pass has cleared the inode references, or the drive has begun clicking, throwing I/O errors, or reporting incorrect geometry because its internal firmware translator has failed.

✅ Result: At Stellar Data Recovery, expert engineers recover data from ext4 file systems even under these conditions, drawing on established procedures for mechanical stabilisation, forensic imaging, and inode-level reconstruction on Linux systems.

If a Linux drive has failed or files have been lost from an ext4 partition, call a Stellar Data Recovery expert at 1800 102 3232 for a free consultation.

FAQs

1. Does ext4 Delete Data Immediately When a File Is Removed?

Deletion on ext4 deallocates the inode and marks the data blocks as free, but it does not overwrite the block contents. The data persists until the file system assigns those blocks to a new file. SSDs with TRIM enabled are the exception, since the drive controller may physically erase freed blocks independently of the file system.

2. Can ext4magic Still Be Used for ext4 Recovery?

ext4magic has not been updated to support modern e2fsprogs versions, and the project maintainer recommends against its use on current ext4 file systems. Journal-based metadata recovery is better supported by extundelete and debugfs, both of which remain actively maintained.

3. Does Remounting a Partition as Read-Only Prevent Further Data Loss?

Remounting read-only stops new user data from overwriting freed blocks, but it does not stop ext4 from replaying the journal, which can still alter metadata. A full unmount with umount is the safer approach, or booting from external media to avoid mounting the affected partition entirely.

4. Is File Carving Effective for Recovering Database Files From ext4?

Contiguous, self-contained file formats such as JPEG or PDF suit signature-based carving well. Database files (MySQL, PostgreSQL, and SQLite) span many interdependent blocks and rely on internal structural consistency, so carving may retrieve fragments, but producing a usable database typically requires metadata-aware inode-level reconstruction.

5. How Long After Deletion Can Files Be Recovered on ext4?

No fixed window applies to ext4 file system recovery. Recovery time depends on how quickly the JBD2 journal cycles past the pre-deletion transaction, a system activity that determines it. A busy server generating frequent metadata writes can overwrite the relevant journal entries within minutes, while a lightly used workstation may retain recoverable metadata for hours or days. Stopping all writes to the affected drive as soon as data loss is noticed remains one of the most effective ways to preserve the recovery window.