How to recover deleted files using Linux

Recovering deleted files on Linux prevents loss of configuration, application data, and user documents that may be costly or impossible to recreate. Accidental removal of a home directory, log file, or project tree does not always mean the underlying bytes vanish immediately, so targeted recovery can often restore at least part of the missing data.

Linux file systems typically mark directory entries and inodes as free while leaving the actual data blocks untouched until reused. Desktop environments often move removed items into per-user Trash directories, whereas command-line deletions with rm bypass this safety net and update file-system metadata directly. Recovery tools exploit this gap by scanning metadata structures or raw blocks to locate traces of deleted entries.

Effective recovery depends on acting quickly, avoiding new writes to the affected volume, and choosing tools appropriate for the file system and failure mode. The steps below focus on ext3 and ext4 volumes and common utilities such as extundelete, testdisk, photorec, lsof, and debugfs, assuming access to a terminal with sudo privileges, ideally from a live environment so the target file system stays offline. Backups remain the most reliable option, so manual recovery attempts should be balanced against the risk of further data loss.

Steps to recover deleted files using Linux:

Minimize activity on the file system that contained the deleted files to reduce the chance that new writes overwrite recoverable data.

Continuing to download data, grow logs, or install packages on the same volume can permanently overwrite blocks that still contain deleted content.
Open a terminal with sudo privileges on a system that has direct access to the storage device that needs recovery.
```
$ whoami
user
```
Use a user account that can run sudo, or switch to the root account when appropriate.
Inspect the per-user Trash directory for items deleted through graphical file managers.
```
$ ls ~/.local/share/Trash/files/
report.odt
old-photo.jpg
##### snipped #####
```
Files removed from common desktop environments such as GNOME or KDE are often moved to /homeusername.local/share/Trash/files instead of being erased immediately.
Identify the block device that stores the directory where the deletion occurred.
```
$ df -h /home/user/Documents
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda3       200G  120G   75G  62% /
```
df maps a path like /homeuserDocuments to a device such as /dev/sda3, which is required by low-level recovery tools.
Unmount the file system that contains the deleted data before running tools that scan raw metadata.
```
$ sudo umount /dev/sda3
```
Unmounting the root file system on a running system causes processes to fail; perform recovery on /dev/sda3 from a live Linux environment when it holds the root (/) volume.
Use extundelete on an unmounted ext3 or ext4 device to restore a specific deleted path when its original location is known.
```
$ sudo extundelete /dev/sda3 --restore-file home/user/Documents/report.odt
NOTICE: Extended attributes are not restored.
Loading filesystem metadata ...
##### snipped #####
```
extundelete expects paths relative to the file system root (without a leading slash) and writes recovered entries into a directory such as RECOVERED_FILES in the current working directory.
Recover all recently deleted entries from the same device when exact file names are unknown.
```
$ sudo extundelete /dev/sda3 --restore-all
Loading filesystem metadata ...
Restored inode 123456 to file RECOVERED_FILES/home/user/Documents/report.odt
##### snipped #####
```
Restoring all inodes can produce many files; ensure there is enough free space on the destination volume before running this operation.
Run testdisk to scan the disk or partition for lost partitions and undeleted files using its interactive menu.
```
$ sudo testdisk
TestDisk 7.2, Data Recovery Utility, April 2024
##### snipped #####
```
Select the correct disk, confirm the partition table type, and use the Advanced or Undelete menus in testdisk to browse deleted entries and copy them to a different storage device.
Use photorec to carve files of known types from a device or disk image when file-system metadata is badly damaged.
```
$ sudo photorec
PhotoRec 7.2, Data Recovery Utility, April 2024
##### snipped #####
```
Configure photorec to save files onto a different volume than the one being scanned to avoid overwriting blocks that may still contain recoverable data.
Search for deleted but still-open files using lsof when an application continues to hold a handle to the removed data.
```
$ sudo lsof | grep deleted
nginx    2134 www-data   5w   REG  8,3 10485760  524321 /var/log/nginx/access.log (deleted)
##### snipped #####
```
Entries ending with $begin:math:text$deleted$end:math:text$ indicate files that have been unlinked from the directory tree but whose content is still accessible through an open file descriptor.
Copy the content of a deleted file that remains open by copying from the corresponding /proc file descriptor to a safe location.
```
$ sudo cp /proc/2134/fd/5 /var/tmp/access.log.recovered
```
Recovery via /proc works only while the owning process is running and using that descriptor; once the service exits or rotates the file, the descriptor disappears or may point to new content.
Inspect recently deleted inodes on an ext2, ext3, or ext4 volume using debugfs after confirming the device is not mounted.
```
$ sudo debugfs /dev/sda3
debugfs 1.46.5 (30-Dec-2021)
debugfs: lsdel
 Inode  Owner  Mode    Size   Blocks   Time deleted
##### snipped #####
```
The lsdel command inside debugfs lists inodes that were recently removed and may still have recoverable data blocks.
Dump a chosen deleted inode from within debugfs into a new file on another volume.
```
debugfs: dump 123456 /var/tmp/recovered-from-debugfs.bin
```
Always dump to a separate file system so the operation does not overwrite remaining recoverable data on the source device.
Restore data from a known-good backup when low-level recovery tools cannot locate the required files or the risk of further damage is too high.
```
$ rsync -av /backup/location/ /restore/location/
sending incremental file list
##### snipped #####
```
Backups created with tools such as rsync, Borg, or Restic, or with snapshot-capable file systems like btrfs and ZFS, usually provide the fastest and most reliable path back to a consistent state.
Verify recovered data by listing the recovery directory and opening critical files to confirm they are complete and readable.
```
$ ls -lh RECOVERED_FILES/home/user/Documents/
-rw-r--r-- 1 root root 120K May 13 10:20 report.odt
##### snipped #####
```

Author: Mohd Shakir Zakaria
Mohd Shakir Zakaria is a cloud architect with deep roots in software development and open-source advocacy. Certified in AWS, Red Hat, VMware, ITIL, and Linux, he specializes in designing and managing robust cloud and on-premises infrastructures.

Discuss the article:

Comment anonymously. Login not required.