How to Recover a Deleted Directory or Folder in Linux: Trash, extundelete, ext4magic and PhotoRec

Updated: 9 October 2026 · Applies to: Debian 13 and Ubuntu 26.04 (extundelete 0.2.4, ext4magic 0.3.2, PhotoRec 7.2, trash-cli 0.24), AlmaLinux 10 with EPEL (PhotoRec 7.2), the same steps on Rocky Linux; ext3, ext4 and XFS

A folder removed with rm -r or rm -rf does not go to a trash folder: Linux marks its space as free straight away. You can often still recover a deleted directory, but only until that space is reused. Work through these steps in order:

1. Stop writing to that disk.
2. Look in the desktop Trash.
3. Copy files that a running program still has open.
4. Restore from a backup or snapshot.
5. On ext3 or ext4, run extundelete or ext4magic on the unmounted partition (keeps names and folders).
6. On any file system, including XFS, carve the files out with PhotoRec (contents only, no names or folders).

1. Stop writing to the disk

Every new file can overwrite the deleted data. Find out which partition held the folder:

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

• If it is a separate data partition, stop the services that write to it and unmount it: sudo umount /dev/sdb1 (or sudo mount -o remount,ro /data if it cannot be unmounted).
• If it is the root partition, as on most VPS, you cannot unmount it while the server runs. Stop busy services, save recovered files to another disk, and if possible copy the partition to another disk first and work on the copy (see how to create a disk image with dd).
• On SSDs and many virtual disks a weekly fstrim job tells the drive which space is free, after which the old data may be discarded for good. The timer is enabled by default on Debian 13 and Ubuntu 26.04 and in the default presets of AlmaLinux 10. Pause it with sudo systemctl stop fstrim.timer until you are done.

2. Check the Trash (desktop)

A folder deleted in a file manager is moved to ~/.local/share/Trash/files/, with a matching file in ~/.local/share/Trash/info/ that remembers where it came from:

$ cat ~/.local/share/Trash/info/project.trashinfo
[Trash Info]
Path=/root/Documents/project
DeletionDate=2026-10-09T17:43:42

Restore it from the Trash in the file manager, or move it back with mv. On servers, the trash-cli package gives the same safety net on the command line: trash-put folder instead of rm -r, then trash-list and trash-restore. In our test trash-restore put /root/work/site back in place.

3. Rescue files a program still has open

If a running program (a web server writing a log, a database, a script) still has a deleted file open, the data stays on disk until the program closes it, and you can copy it back through /proc:

$ sudo lsof +L1
COMMAND PID USER FD   TYPE DEVICE SIZE/OFF NLINK    NODE NAME
tail    778 root 3r   REG   0,51       65     0 1572990 /srv/site/logs/orders.log (deleted)
$ sudo cp /proc/778/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 of the deleted log. Do this before you restart the program. It works for open files only, not for the directory itself.

4. Restore from a backup or snapshot

The fastest and most complete recovery is a backup: restore only the deleted folder from the latest copy. On cPanel hosting, see how to restore your files from backups; for code kept in Git, see how to recover deleted files in Git. Btrfs and LVM snapshots work the same way: mount the snapshot and copy the folder out (create and mount Btrfs snapshots).

5. ext4 and ext3: extundelete or ext4magic

According to the ext4magic manual, ext3 and ext4 wipe the block list of a deleted file, so extundelete and ext4magic rebuild files from older copies of that information in the file system journal. They can restore whole directory trees with their names, but only while those journal entries still exist, so run them as soon as possible. Both are in Debian and Ubuntu, but not in AlmaLinux or EPEL.

1. Install the tools: sudo apt install extundelete ext4magic
2. Unmount the partition (step 1), or work on a dd copy of it.
3. Go to a folder on a different disk, because the tools write the recovered files to the current directory: cd /mnt/usb
4. Restore the folder. The path is relative to the root of that partition, without a leading slash: if /dev/sdb1 is mounted on /home, /home/alice/project becomes alice/project.

   sudo extundelete /dev/sdb1 --restore-directory alice/project
   # result: ./RECOVERED_FILES/alice/project

5. If that finds nothing, try ext4magic. Its -m option is meant for recovering after a recursive delete:

   sudo ext4magic /dev/sdb1 -r -f alice/project -d /mnt/usb/recovered
   sudo ext4magic /dev/sdb1 -m -d /mnt/usb/recovered     # all deleted files

   According to its manual, ext4magic looks at the last 24 hours by default; set the window with -a (after) and -b (before) in seconds since 1970, for example -a $(date -d "-2 hours" +%s).

extundelete --restore-all tries to restore everything, and --after takes the same kind of timestamp as ext4magic's -a.

The older ext3grep tool is still packaged (0.10.2 in Debian 13 and Ubuntu 26.04), but it only understands ext3. On our ext4 test file system it stopped with an assertion failure and a core dump, so use the tools above instead.

6. Any file system, including XFS: PhotoRec

According to CGSecurity, PhotoRec (package testdisk) ignores the file system and goes after the underlying data, so it also works on XFS, the default file system of RHEL, AlmaLinux and Rocky Linux, where PhotoRec comes from EPEL:

sudo apt install testdisk                               # Debian, Ubuntu
sudo dnf install epel-release && sudo dnf install testdisk   # AlmaLinux, Rocky Linux

Run sudo photorec /dev/sdb1, choose the partition and file system type, choose to search only the free (unallocated) space, and pick an output folder on another disk. A non-interactive run on a disk image looks like this (create the output folder first; PhotoRec stopped with "Cannot create file" when it was missing):

mkdir -p /mnt/usb/recup
sudo photorec /log /d /mnt/usb/recup/ /cmd disk.img partition_none,options,mode_ext2,fileopt,everything,enable,search
ls /mnt/usb/recup/recup_dir.1/

We deleted a folder with four files from an ext4 test image and ran exactly that. PhotoRec returned:

f0008836.txt     the CSV file, byte for byte identical
f0008886.sh      the shell script, identical
f0008888.tar.gz  the archive, padded to 57,344 bytes, but gzip -t and tar listing OK
(the 78-byte PNG was not found)

It also produced 811 junk files (named *.dovecot) from empty file system blocks. The original names and the folder structure are lost, so sort the results by type and search them by content, for example grep -rl "invoice" /mnt/usb/recup/. Limiting the file types (the fileopt menu) reduces the junk, but in our test that run guessed a different block size and cut the CSV short, so if the results look damaged, run it again with all file types.

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.
• Use trash-put instead of rm -r for folders you might need again.
• To find out who or what deletes files, see how to use auditd to find out who deleted a file.

For a single file see how to recover a deleted file in Linux. 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 and ext4magic manual pages; PhotoRec documentation on cgsecurity.org.