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.

1. 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.

2. Open a terminal with sudo privileges on a system that has direct access to the storage device that needs recovery.

   $ whoami
   root

   Use a user account that can run sudo, or switch to the root account when appropriate.

3. Inspect the per-user Trash directory for items deleted through graphical file managers.

   $ ls ~/.local/share/Trash/files/
   old-photo.jpg
   report.odt

   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.

4. Identify the block device that stores the directory where the deletion occurred.

   $ df -h /mnt/recover-lab/home/user/Documents
   Filesystem      Size  Used Avail Use% Mounted on
   /dev/loop3       56M   36K   52M   1% /mnt/recover-lab

   df maps a path like /homeuserDocuments to a device such as /dev/sda3, which is required by low-level recovery tools.

5. Unmount the file system that contains the deleted data before running tools that scan raw metadata.

   $ sudo umount /dev/loop3

   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.

6. Use extundelete on an unmounted ext3 or ext4 device to restore a specific deleted path when its original location is known.

   $ sudo extundelete /dev/loop3 --restore-file home/user/Documents/report.odt
   NOTICE: Extended attributes are not restored.
   Loading filesystem metadata ... 1 groups loaded.
   Loading journal descriptors ... 6 descriptors loaded.
   Failed to restore file home/user/Documents/report.odt
   Could not find correct inode number past inode 14.
   Try altering the filename to one of the entries listed below.
   extundelete: Operation not permitted while restoring file.
   extundelete: Operation not permitted when trying to examine filesystem
   File name                                       | Inode number | Deleted status

   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.

7. Recover all recently deleted entries from the same device when exact file names are unknown.

   $ sudo extundelete /dev/loop3 --restore-all
   NOTICE: Extended attributes are not restored.
   Loading filesystem metadata ... 1 groups loaded.
   Loading journal descriptors ... 6 descriptors loaded.
   Searching for recoverable inodes in directory / ... 
   0 recoverable inodes found.
   Looking through the directory structure for deleted files ... 
   0 recoverable inodes still lost.
   No files were undeleted.

   Restoring all inodes can produce many files; ensure there is enough free space on the destination volume before running this operation.

8. Run testdisk to scan the disk or partition for lost partitions and undeleted files using its interactive menu.

   $ sudo testdisk /version
   TestDisk 7.1, Data Recovery Utility, July 2019
   Christophe GRENIER <grenier@cgsecurity.org>
   https://www.cgsecurity.org
   
   Version: 7.1
   Compiler: GCC 13.2
   ext2fs lib: 1.47.0, ntfs lib: libntfs-3g, reiserfs lib: none, ewf lib: none, curses lib: ncurses 6.4
   OS: Linux, kernel 6.12.54-linuxkit (#1 SMP Tue Nov  4 21:21:47 UTC 2025) aarch64

   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.

9. Use photorec to carve files of known types from a device or disk image when file-system metadata is badly damaged.

   $ sudo photorec /version
   PhotoRec 7.1, Data Recovery Utility, July 2019
   Christophe GRENIER <grenier@cgsecurity.org>
   https://www.cgsecurity.org
   
   Version: 7.1
   Compiler: GCC 13.2
   ext2fs lib: 1.47.0, ntfs lib: libntfs-3g, ewf lib: none, libjpeg: libjpeg-turbo-2.1.5, curses lib: ncurses 6.4, zlib: 1.3
   OS: Linux, kernel 6.12.54-linuxkit (#1 SMP Tue Nov  4 21:21:47 UTC 2025) aarch64

   Configure photorec to save files onto a different volume than the one being scanned to avoid overwriting blocks that may still contain recoverable data.

10. 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
    python3   27842                             root    3w      REG               0,64       11     382872 /var/log/recover-demo/access.log (deleted)

    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.

11. 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/27842/fd/3 /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.

12. Inspect recently deleted inodes on an ext2, ext3, or ext4 volume using debugfs after confirming the device is not mounted.

    $ sudo debugfs -R "lsdel" /dev/loop3
    debugfs 1.47.0 (5-Feb-2023)
     Inode  Owner  Mode    Size      Blocks   Time deleted
    0 deleted inodes found.

    The lsdel command inside debugfs lists inodes that were recently removed and may still have recoverable data blocks.

13. Dump a chosen deleted inode from within debugfs into a new file on another volume.

    $ sudo debugfs -R "dump /home/user/Documents/report.odt /var/tmp/recovered-from-debugfs.bin" /dev/loop3
    debugfs 1.47.0 (5-Feb-2023)
    /home/user/Documents/report.odt: File not found by ext2_lookup

    Always dump to a separate file system so the operation does not overwrite remaining recoverable data on the source device.

14. 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 /root/sg-work/recover-lab/backup/ /root/sg-work/recover-lab/restore/
    sending incremental file list
    report.odt
    
    sent 130 bytes  received 35 bytes  330.00 bytes/sec
    total size is 7  speedup is 0.04

    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.

15. Verify recovered data by listing the recovery directory and opening critical files to confirm they are complete and readable.

    $ ls -lh /root/sg-work/recover-lab/RECOVERED_FILES/home/user/Documents/
    ls: cannot access '/root/sg-work/recover-lab/RECOVERED_FILES/home/user/Documents/': No such file or directory