File Recovery for Linux Drives (ext4, ext3, ext2 from a Disk Image)

About the File Recovery for Linux Drives (ext4, ext3, ext2 from a Disk Image)

First make a disk image of the drive or card: one file that holds every sector of it, made with a disk-imaging program and kept on another drive with room for it (the Data Recovery Assistant shows the steps for Linux, macOS and Windows). Then open the image here. The page reads the ext4, ext3 or ext2 file system the way the Linux kernel’s documentation describes it and lists the files that were deleted, with their names, folders, sizes and dates, and how likely each one is to be whole.

ext3 and ext4 erase the list of a file’s blocks from its record when the file is deleted, so the page also reads the file system’s journal: it holds older copies of recently changed records, often from before the deletion, and those still say where the file’s data was. ext2 keeps that list, so its deleted files usually come back whole. Then each photo, video, PDF, ZIP archive and Office file found is checked by its own content and marked Opens fully, Partly damaged or Can’t be opened; kinds of file the page cannot check, such as plain text, are marked Not checked. Nothing is uploaded: the image is read on your device, a few megabytes at a time.

Common uses

• Getting back photos, videos and documents deleted from a Linux drive, an external disk formatted with ext4, or a Raspberry Pi card.
• Restoring files deleted with rm or emptied from the desktop Trash, under their names and folders.
• Copying files off an ext4 drive or card that Linux will not mount, from its image (tick “Also list files that were not deleted”).
• Checking which deleted files are still whole before deciding what to save.

Why you need an image first

A web page cannot read a disk or memory card sector by sector, and no browser setting changes that: the WebUSB standard does not let a page claim USB storage devices, and the File System Access API gives pages files and folders, never raw devices. A disk image (a file with every sector of the drive, deleted areas included) is what recovery needs, and imaging is also the safe way to work: the drive is read once and never written to, and every later step works on the copy.

On Linux, sudo ddrescue /dev/sdX drive.img drive.map (GNU ddrescue) images a drive and keeps going past read errors; sudo dd if=/dev/sdX of=drive.img bs=4M status=progress does the same on a healthy one. Unmount the drive first, and save the image on a different drive.

How deleted files are found on ext4, ext3 and ext2

Each file on an ext file system has a record (an inode) with its size, times and the list of blocks that hold its data: block numbers on ext2 and ext3, extents on ext4 (the kernel’s ext4 documentation). A folder is a list of names, each with the number of its record. Deleting a file removes its name from the folder by joining its space to the name before it, which leaves the name in place until a new name is written there, and frees the record and the blocks.

• ext2 marks the record deleted and leaves its block list, so the data is found exactly. It does clear the record number beside the deleted name, so the page matches names to records by their place in the folder (Linux gives a new file the first unused record of its folder’s group), only where the match is one to one; other records are listed under Lost files, deleted folders’ files together.
• ext3 and ext4 keep the record number beside the name but erase the block list from the record. Their journal writes every changed block of records and folders to a ring of its own before writing it in place, so it often still holds a copy of a record from before the deletion. The page reads the whole journal, also its parts already written in place, and takes the newest copy from when the file still existed, checked by the record’s generation number (which changes when a record is used for another file) and by the copies of the folder that show when the name was deleted.
• The volume’s block bitmaps say which blocks are in use today. A deleted file’s blocks that a file in use holds now, that a file deleted later used (seen in the journal’s copies too), or that now hold the file system’s own structures are marked as written over.

When the start of a volume is damaged (Linux then says it cannot find the file system), the page reads one of the backup copies of the superblock and the group descriptors that every ext volume keeps further on.

What the conditions mean

• Opens fully: the file’s own structure checks out from its first byte to its last (a JPEG to its end marker, every PNG chunk checksum, a video’s index and data, every file inside a DOCX or ZIP).
• Partly damaged: it starts correctly, but part of it is missing or was written over; or some of its blocks now belong to other files.
• Can’t be opened: its first block now belongs to another file, or the file system no longer says where its data was (an ext3 or ext4 file whose record the journal no longer holds). Its name is still listed.
• Not checked: a kind of file whose content the page cannot check (text files, for example). The note says whether another file uses its blocks now.

When a file made after a deleted one was deleted too and its own record is gone, nothing on the volume says which blocks it used. Such files are marked: their data may be that later file’s.

Measured on test images

NIST’s CFReDS deleted-file-recovery test images include 22 images made with Linux, each with an ext2, an ext3 and an ext4 partition, with NIST’s record of every file deleted from them and the sectors it used (NIST tags each 512-byte block with its file and position). The page’s results on all of them:

• ext2: 717 deleted files listed. 668 came back with every block in place (names in Devanagari, Arabic, Korean, Japanese, Chinese, Cyrillic and Hebrew characters among them, and 260 files deleted from one folder); 34 were marked as written over by later files, which they were; 14 names could not be matched to their records one to one and were listed by name, their records among the Lost files; and one small file was the desktop Trash’s note of a file it had emptied, read exactly.
• ext3: 882 deleted files listed, all but one by name. The journal still held records from before the deletion for 33 of them: 27 came back whole and 6 were marked as written over, which they were.
• ext4: 926 deleted files listed, 923 of them by name. The journal still held records for 221 of them: 218 came back whole, 2 were marked as written over, and 1 was marked as possibly holding another file’s data, which it did (a file made and deleted after it had used its blocks).
• No file was said to be whole that was not.

The other ext3 and ext4 files had lost their block lists, as these file systems do on deletion, and the journal no longer held their records: their names are listed, and the deep scan searches for them by content. With “Also list files that were not deleted” ticked, the page lists every file on the 66 partitions, also 1,022 files in nine folders. Eight of these images (24 partitions) are part of the page’s automated tests, as small extracts, with their checks, together with a modern ext4 volume (64-bit, with metadata and journal checksums).

Linux® is the registered trademark of Linus Torvalds in the U.S. and other countries. Raspberry Pi is a trademark of Raspberry Pi Ltd. MySmartCoPilot is not affiliated with either.

Limitations

• Works on disk images only, not on drives directly (browsers do not allow it). Raw images (.img, .dd, .bin, .raw, .iso), raw images saved in parts (.001, .002 …) and fixed-size VHD files open directly; E01, DMG, VHDX, dynamic VHD, VMDK, QCOW2 and VDI images are turned into raw images first by the Disk Image Converter.
• ext2, ext3 and ext4 only. Memory cards and USB sticks formatted with FAT or exFAT are undeleted by SD Card & USB Drive Recovery, Windows drives by NTFS Deleted File Recovery; Btrfs, XFS, ZFS and F2FS are not read, and the deep scan finds photos, videos and documents on any of them by their content.
• ext3 and ext4 erase where a deleted file’s data was. The page finds it only while the journal still holds an older copy of the file’s record; the journal is a ring that a busy file system fills within minutes or days, so the chances fall with every change made after the deletion. Files whose records it no longer holds are listed by name only.
• A file written and deleted after another one may have used its blocks; when that file’s record is gone too, nothing on the volume records it. The page marks such files, and the content check catches this for photos, videos and documents, not for plain text.
• Data that has been written over cannot be recovered by any software. A full format, a secure erase, or TRIM on an SSD (many Linux distributions run fstrim every week, and the discard mount option erases at once) leave nothing to find.
• Encrypted volumes (LUKS, or folders encrypted with fscrypt) cannot be read without their key, and this page does not decrypt them. Unlock the volume on Linux and image the unlocked device (under /dev/mapper). LVM and software RAID volumes are read the same way: activate them on Linux and image the logical volume or the assembled array.
• Files kept inside their record (ext4 inline data) and files with holes are listed but cannot be saved whole. Symbolic links are listed by name, as they hold no data of their own. Very large ext4 files whose extent tree was erased lose the parts the journal does not hold.
• A web page cannot set a file’s date: files saved to a folder carry the day they were saved. The ZIP keeps the original dates, shown in this computer’s time zone.

Privacy

The image is read by your browser on your device, a few megabytes at a time, in background workers; no part of it or of the files in it is sent anywhere.