How to Recover Deleted Files in Linux: Undelete Tools Tested

Updated: 11 October 2026 · Applies to: ext4 and other Linux file systems; tested on Debian 13 with a real ext4 deletion by Linux kernel 6.12 (extundelete 0.2.4, ext4magic 0.3.2, foremost 1.5.7, The Sleuth Kit 4.12.1, GNU grep 3.11); packages checked on Ubuntu 26.04 and AlmaLinux 10 with EPEL

A file deleted with rm does not go to a trash folder, but its data usually stays on the disk until something overwrites it. You can often recover it if you act quickly: stop writing to that disk, copy the file back from /proc if a program still has it open, restore it from a backup, and otherwise run a recovery tool such as extundelete, ext4magic, foremost or PhotoRec on the unmounted partition. In our test, extundelete, ext4magic, foremost and a simple grep search between them got back all four deleted files, byte for byte, but not with their names.

1. Stop writing to the disk

Every new file, log line or package install can overwrite the deleted data. Find the partition that held the file:

findmnt -T /home/alice/docs      # SOURCE shows the partition, for example /dev/sdb1

• A separate data partition: stop the services that write to it and unmount it (sudo umount /dev/sdb1), or remount it read-only (sudo mount -o remount,ro /data).
• The root partition, as on most VPS: it cannot be unmounted while the server runs. Boot the server into a rescue system and work from there (enable rescue mode in Virtualizor), or copy the partition to another disk first and work on the copy (create a disk image with dd).
• Install recovery tools and save recovered files on a different disk, never on the one you are recovering from.

2. The file is still open: copy it back from /proc

If a running program (a web server writing a log, a database, a script) still has the deleted file open, the data stays on disk until the program closes it. List deleted but open files and copy one back:

$ sudo lsof +L1
COMMAND  PID USER FD   TYPE DEVICE SIZE/OFF NLINK    NODE NAME
tail    3868 root 3r   REG   0,52       40     0 1572874 /srv/app/logs/orders.log (deleted)
$ sudo cp /proc/3868/fd/3 /root/orders.log.recovered

The number after /proc/ is the PID and the last number is the FD column without its letter. In our test the copy had all 5 lines. Do this before you restart the program.

3. Restore from a backup or snapshot

A backup gives you the file with its name, folder and permissions, which no undelete tool can promise. On cPanel hosting, see how to restore your files from backups; for code kept in Git, see how to recover deleted files in Git.

4. ext4: extundelete and ext4magic

When ext4 deletes a file, it wipes the list of blocks in the file's inode. In our test The Sleuth Kit showed the deleted inode with size: 0 and no blocks, so tools that only read the inode find nothing. extundelete and ext4magic instead look for older copies of the inode in the file system journal, so run them soon, before the journal is reused. Both are packaged for Debian and Ubuntu (sudo apt install extundelete ext4magic), but not for AlmaLinux, not even in EPEL.

We created four files on an ext4 image file, deleted them with the Linux kernel's own ext4 driver, unmounted it and then ran each tool on the image (disk.img below). On a server, give the partition instead, for example /dev/sdb1.

1. By name (the path is relative to the root of the partition) failed in our test:

   $ sudo extundelete /root/disk.img --restore-file docs/invoice.txt
   Failed to restore file docs/invoice.txt
   Could not find correct inode number past inode 13.

2. Everything worked better. Run it from a folder on another disk, because it writes to ./RECOVERED_FILES:

   $ cd /mnt/usb
   $ sudo extundelete /root/disk.img --restore-all
   (shortened)
   2 recoverable inodes found.
   $ ls -l RECOVERED_FILES/
   -rw-r--r-- 1 root root 27092 Oct 10 14:06 file.15
   -rw-r--r-- 1 root root 37087 Oct 10 14:06 file.16

   Both were identical to the deleted text file and PNG image, but named after their inode number. Use file RECOVERED_FILES/* to see what each one is.
3. ext4magic found the other two files (the JPEG photo and the ZIP archive), also identical to the originals:

   sudo ext4magic /root/disk.img -M -d /mnt/usb/ext4magic

   It sorts the results into folders by file type. According to its manual, -r -f path restores a folder by name and -a and -b set the time window; by name it found nothing in our test.

5. Any file system: carve the files out

File carvers ignore the file system and search the raw disk for known file headers, so they also work on XFS (the default on AlmaLinux and Rocky Linux), on FAT and NTFS USB drives and on damaged disks. You get the contents but not the names or folders.

sudo apt install foremost
sudo foremost -t png,jpg,zip -i /dev/sdb1 -o /mnt/usb/foremost
cat /mnt/usb/foremost/audit.txt

In our test foremost returned the PNG, the JPEG and the ZIP from the deleted files, all three byte for byte. According to its manual it also knows pdf, doc, gif, mp4, rar and other types (-t all for everything), but it has no type for plain text files. PhotoRec (package testdisk, also in EPEL for AlmaLinux 10) works the same way from a menu; a full walkthrough is in how to recover a deleted folder in Linux.

6. Text files: search the raw disk

For a config file, script or note, search the partition for a phrase you know was in it. This command prints every readable run of text that contains the phrase:

$ grep -a -c 'INV-7731' disk.img
400
$ grep -a -o '[[:print:]]*INV-7731[[:print:]]*' disk.img > /mnt/usb/found.txt

On a server, run it with sudo on the partition (/dev/sdb1). Our deleted invoice file had 400 lines, and found.txt was identical to it. Lines with tabs or non-English characters are cut at those characters, and other copies of the text (old versions, editor backups) can show up too, so check the result before you use it.

Linux file recovery tools compared

• extundelete and ext4magic: ext3 and ext4 only; can keep names when the journal still has them.
• foremost and PhotoRec: any file system, by file type; no names.
• TestDisk: according to CGSecurity it undeletes files on FAT, exFAT, NTFS and ext2 and recovers lost partitions, which suits USB sticks and Windows disks.
• The Sleuth Kit (fls, icat): forensic tools that list deleted entries; on our ext4 test it showed them only as OrphanFile-15 to OrphanFile-18 with no data left in the inodes.

What is lost+found?

lost+found is not a recycle bin. When fsck repairs a file system and finds a file that still has data but no name in any folder, it reconnects it there, named after its inode number. In our test (we removed a file's name with debugfs to simulate the damage), e2fsck reported:

Unattached inode 13
Connect to /lost+found? yes

The file then appeared as /lost+found/#13 with its contents intact. After a crash or an fsck run, look there with sudo ls -l /lost+found and identify the files with file. See how to use fsck to repair file system errors.

Avoid it next time

• Keep backups off the server, and take a snapshot before risky changes.
• Use rm -I: GNU rm then asks once before a recursive delete or before removing more than three files. Make it permanent with alias rm='rm -I' in ~/.bashrc, or use rm -i to confirm every single file.
• Use a command-line trash can for files you might need again: trash-cli.
• To find out who or what deletes files, see how to use auditd to find out who deleted a file.

If the data matters and you are not sure what to do next, stop and ask an engineer before running more commands; Ucartz can provide one through Hire an Expert.

Official documentation: extundelete, ext4magic and foremost manual pages; TestDisk and PhotoRec documentation on cgsecurity.org.