How to undo rm in Linux? [100% Working]

Deleting the wrong file with rm or rm -rf is one of the most common—and most stressful— mistakes on the Linux command line. Unlike a desktop file manager, rm does not move files to a Trash folder, and there is no Ctrl+Z to bring them back. This guide answers whether you can undo rm, tells you exactly what to do in the first few minutes, walks through the practical recovery methods, and shows how to protect yourself from the next accident.

Can you undo rm or rm -rf in Linux?

No. Linux rm does not have a built-in undo feature, and files deleted with rm or rm -rf are not moved to Trash by default—the command unlinks them immediately. Recovery may be possible, but it is never guaranteed.

Whether you can get a file back depends on several things:

• the filesystem type (ext4, XFS, Btrfs, ZFS, and so on)
• how much disk activity happened after the deletion
• whether you have backups or snapshots
• whether the file is still held open by a running process
• whether the freed disk blocks have already been overwritten

The single most important factor is disk activity after deletion. When you delete a file, the data usually still sits on disk until something else writes over those blocks. Every write to the affected filesystem can destroy what you are trying to recover, so your first job is to stop writing to that disk—covered next.

What to do immediately after rm or rm -rf

If the deleted files matter, stop using the affected filesystem immediately. Do not copy files onto it, install packages, or write recovery-tool output to the same partition. What you do in the first few minutes usually decides whether recovery succeeds.

• Stop writing to the disk. Close applications that write to it and avoid running unnecessary commands against that filesystem. For a busy system disk, consider stopping non-essential services.
• Remount the filesystem read-only if possible. For a non-root partition: mount -o remount,ro /mountpoint. This blocks new writes from overwriting recoverable blocks.
• Do not install recovery tools on the same partition. Install them on a different disk, or boot from a live USB or rescue environment.
• Check whether the deleted file is still open by a process. If a running program still has the file open, you can often copy it straight back from /proc (Method 2).
• Restore from backup or snapshot first if available. Backups and LVM snapshots are faster and preserve original filenames, paths, and permissions—see Method 1 and the routing table below.

If the data is critical and the filesystem cannot be unmounted (for example, it is the root filesystem), the safest option is to power the system down and image the disk from a rescue environment before attempting any recovery. If the data sits on LVM and the volume group still has free space, an LVM snapshot taken right after the mistake can freeze a copy of the volume for safer file recovery than carving a live root filesystem.

Which recovery method should you use?

Read this table first, then jump to the matching method. Try methods in this order when more than one might apply—earlier rows are usually faster and preserve filenames better.

Not doable with plain rm: there is no undo button. Method 7 does not help after rm unless you had already aliased deletes to Trash.

The step-by-step /tmp examples under Method 2, Method 6, and Method 7 were run on a Linux system with bash; your paths and device names will differ.

Methods to recover deleted files after rm

Each section below starts with When to use and then the commands.

Method 1: Restore from backup or snapshot

When to use: You have any recent backup or snapshot of the affected data—always try this before carving tools. This is the only approach that reliably keeps original paths, names, ownership, and permissions.

Use this first if you have it. Restoring from a backup or snapshot is the most reliable recovery method, and the only one that dependably preserves filenames, ownership, and permissions. Check for:

• system or application backups (rsync, Borg, restic, and similar); for partition-level copies see how to backup or clone a Linux partition
• LVM snapshots — create before risky work, or mount an existing snapshot to copy files back
• Btrfs snapshots (btrfs subvolume snapshot, or tools like Snapper/Timeshift)
• ZFS snapshots (zfs rollback, zfs clone)
• cloud-provider volume snapshots

If a recent snapshot exists, mount it or roll back to it instead of carving the raw disk. For LVM, our LVM snapshot backup and restore tutorial covers lvcreate --snapshot, checking snapshot status, and merge/remove.

Method 2: Recover through /proc when a process still has the file open

When to use: The delete was recent and sudo lsof | grep deleted shows the file still held open by a daemon or your shell. Works on a live, mounted filesystem—including /—and is often the fastest recovery when it applies.

On Linux, a file's data is not released while a process still has it open—even after rm. If the deletion was recent and a service still holds the file, you can copy the bytes back out through /proc/<pid>/fd/<number>.

List deleted-but-still-open files (you usually need root to see every process):

sudo lsof | grep deleted

A line like this tells you process 1234 still has the file open on file descriptor 5:

nginx   1234   root   5w   REG   8,1   10485760   98765   /var/log/app.log (deleted)

Copy the data back out:

sudo cp /proc/1234/fd/5 /recovered/app.log

That pattern is what saves log files and database files when a daemon never closed the handle. It does nothing for a file that no process had open.

Practice on a throwaway directory under /tmp

You can see the same behavior without risking real data. Use a fresh directory from mktemp each time so you never collide with another test.

We will create a small file and list it. Pick a temporary directory and write two lines into secret.txt:

DEMO=$(mktemp -d)
printf 'recovery-demo-secret-content\nline2\n' > "$DEMO/secret.txt"
ls -la "$DEMO/"

You should see secret.txt with non-zero size.

Next, keep the inode open on file descriptor 4, then delete the name. The exec 4<>file syntax opens the file for read and write in the current shell; rm removes the directory entry but the kernel keeps the inode until you close that descriptor:

exec 4<>"$DEMO/secret.txt"
rm -v "$DEMO/secret.txt"

Typical output:

$ rm -v "$DEMO/secret.txt"
removed '/tmp/tmp.wdvCABchUm/secret.txt'

Verify the file name is gone. ls should show an empty directory (only . and ..):

$ ls -la "$DEMO/"
total 0
drwx------  2 golinuxcloud golinuxcloud  40 Jun 22 19:41 .
drwxrwxrwt 17 root         root         420 Jun 22 19:41 ..

Confirm the kernel still sees the inode as (deleted). Filter lsof for your current shell PID ($$):

lsof -p $$ | grep deleted

Example line:

$ lsof -p $$ | grep deleted
bash    95710 golinuxcloud   4u   REG               0,42       35    2137 /tmp/tmp.wdvCABchUm/secret.txt (deleted)

Copy the live inode out through /proc/self/fd/4, then read it back:

cp /proc/self/fd/4 "$DEMO/restored-secret.txt"
cat "$DEMO/restored-secret.txt"

You should see the original two lines. On a real incident you would use the PID and fd number from sudo lsof | grep deleted, not self, and you would write the copy to another filesystem.

Clean up when you are done practicing:

exec 4>&-
rm -rf "$DEMO"

When rm -rf removed a whole directory

rm -rf removes directory entries, but any file still referenced by an open descriptor keeps its data until that descriptor closes. So you only get back the files something still had open—nothing else.

Build a tiny tree so you have two files under one project folder:

DEMO=$(mktemp -d)
mkdir -p "$DEMO/project/src" "$DEMO/project/docs"
printf 'main()\n' > "$DEMO/project/src/main.c"
printf 'README\n' > "$DEMO/project/docs/README.txt"
find "$DEMO" -type f | sort

Open only main.c on fd 3, then delete the entire tree:

exec 3<"$DEMO/project/src/main.c"
rm -rf "$DEMO"

Check that the top-level directory is gone (expected):

test -d "$DEMO" && echo still there || echo gone

List the deleted inode again:

lsof -p $$ | grep deleted

Example:

bash    95756 golinuxcloud   3r   REG               0,42        7    2145 /tmp/tmp.ioqGW5QlsR/project/src/main.c (deleted)

Recover that one file to a safe output directory, read it, then close the fd:

mkdir -p /tmp/recovered-out
cp /proc/self/fd/3 /tmp/recovered-out/main.c
cat /tmp/recovered-out/main.c
exec 3>&-
rm -rf /tmp/recovered-out

Here the recovered content is simply main() on one line. README.txt is not coming back from this trick unless another process had it open too.

Method 3: Recover with Foremost (file carving)

When to use: Backups, /proc, and extundelete are not options; you can work from an unmounted partition or a disk image; you know the file type (for example -t pdf); you accept lost filenames and offset-based names in the output directory.

When directory entries are gone but you still have raw access to the partition (or a disk image), Foremost scans for known file signatures and pulls out what it can. You lose original paths and names—recovered files are named by offset—but you sometimes get usable content back.

Foremost is a data recovery program for Linux used to recover files using their headers, footers and data structures through a process known as file carving. It is available for free and can be used as a general data recovery tool.

According to the Linux distribution you are using, you can find the installation step below:

For Debian Based OS(Ubuntu, Mint, Pardus etc):

sudo apt install foremost -y

For Arch Based OS(Archman Linux, Arch Linux, Manjaro etc):

sudo pacman -S foremost

For Redhat-based OS(Centos, Fedora, AlmaLinux, Rocky Linux etc), the forensics repository is added first, then the package is installed:

sudo dnf install https://forensics.cert.org/cert-forensics-tools-release-el9.rpm
sudo dnf --enablerepo=forensics install foremost 

The default usage of the foremost command is:

foremost [-h] [-V] [-d] [-vqwQT] [-b <blocksize>] [-o <dir>] [-t <type>] [-s <num>] [-i <file>]

You can search by giving the file(jpg, gif, png, exe, mov,pdf, doc, zip, rar, htm, mp4 etc) parameter with the -t parameter. The -i parameter is used as the file input file. If no input file is specified or the input file cannot be read, stdin is used.Files recovered with the -o parameter are written to the specified directory. If no value is entered, the output is taken to the "output" directory.

An example for foremost:

foc@linux:~$ sudo foremost -t pdf -i /dev/vda3
Processing: /dev/vda3
|**************************************************************************************************************************

The output directory and the pdf files found are as follows:

foc@linux:~$ sudo tree output
output
├── audit.txt
└── pdf
    ├── 00472288.pdf
    ├── 09197568.pdf
    ├── 09198264.pdf
    ├── 09204608.pdf
    ├── 09208560.pdf
    ├── 09212840.pdf
    ├── 09296680.pdf
    ├── 10765320.pdf
    ├── 11036672.pdf
    ├── 13143040.pdf
    ├── 13143320.pdf
    ├── 13143664.pdf
    ├── 13150208.pdf
    ├── 13150488.pdf
    ├── 13150848.pdf
    ├── 13284784.pdf
    ├── 13389464.pdf
    ├── 13395368.pdf
    ├── 13412800.pdf
    └── 13862912.pdf

1 directory, 21 files

All formats are searched by giving the value "all" to the -t parameter:

foc@linux:~$ sudo foremost -t all -i /dev/vda3

foc@linux:~$ sudo ls -l output/
total 92
-rw-r--r-- 1 root root 44568 Nov 13 07:44 audit.txt
drwxr-xr-- 2 root root  4096 Nov 13 07:41 bmp
drwxr-xr-- 2 root root  4096 Nov 13 07:41 exe
drwxr-xr-- 2 root root  4096 Nov 13 07:41 gif
drwxr-xr-- 2 root root 12288 Nov 13 07:41 htm
drwxr-xr-- 2 root root  4096 Nov 13 07:41 jpg
drwxr-xr-- 2 root root  4096 Nov 13 07:41 pdf
drwxr-xr-- 2 root root 12288 Nov 13 07:41 png
drwxr-xr-- 2 root root  4096 Nov 13 07:41 zip

The file formats found are in their named directory. Because carving recovers by content, the recovered files are renamed by block offset rather than their original names.

Method 4: Recover with Scalpel (file carving)

When to use: Same cases as Method 3, but you want configurable header/footer rules in /etc/scalpel/scalpel.conf and often faster multi-threaded carving on large devices. Still loses original paths and names.

Scalpel is a fast file carver that reads a database of header and footer definitions and extracts matching files from a set of image files or raw device files. Scalpel is independent on used file-system and will carve files from FATx, NTFS, ext2/3, or raw partitions. It is useful for both digital forensics investigation and file recovery. You choose which signatures stay active inside /etc/scalpel.conf (or /etc/scalpel/scalpel.conf on some distributions); expect the same trade-off as Foremost—recovered content often comes back without the original path or filename.

Follow the steps below to install on your system.For Debian Based OS(Ubuntu, Mint, Pardus etc):

sudo apt install scalpel -y

For Arch Based OS(Archman Linux, Arch Linux, Manjaro etc):

sudo pacman -S scalpel

For Redhat based operating systems (Centos, Fedora, AlmaLinux, Rocky Linux etc.), the EPEL repository is added first and the "tre" package is installed:

sudo dnf install epel-release -y
sudo dnf install tre -y

Then the forensics repository is added, then the "scalpel" package is installed:

sudo dnf install https://forensics.cert.org/cert-forensics-tools-release-el9.rpm
sudo dnf --enablerepo=forensics install scalpel -y

The scalpel configuration file is located("/etc/scalpel/scalpel.conf" for Debian based OS) at /etc/scalpel.conf. File formats are in this file, a new file type definition or wanted/unwanted formats are defined in this file:

nano /etc/scalpel.conf

#---------------------------------------------------------------------
# ADOBE PDF
#---------------------------------------------------------------------

        pdf        y        5000000        %PDF  %EOF\x0d        REVERSE
        pdf        y        5000000        %PDF  %EOF\x0a        REVERSE

# MICROSOFT OFFICE
#---------------------------------------------------------------------

# Word documents

        doc        y        10000000  \xd0\xcf\x11\xe0\xa1\xb1\x1a\xe1\x00\x00 \xd0\xcf\x11\xe0\xa1\xb1\x1a\xe1\x00\x00 NEXT
        doc        y        10000000  \xd0\xcf\x11\xe0\xa1\xb1

# MISCELLANEOUS
#---------------------------------------------------------------------

        zip        y        10000000        PK\x03\x04        \x3c\xac
        rar     y       10000000        Rar!
        java        y        1000000        \xca\xfe\xba\xbe

# GRAPHICS FILES
#---------------------------------------------------------------------

# AOL ART files
        art        y        150000        \x4a\x47\x04\x0e        \xcf\xc7\xcb
        art        y         150000        \x4a\x47\x03\x0e        \xd0\xcb\x00\x00

# GIF and JPG files (very common)
        gif        y        5000000                \x47\x49\x46\x38\x37\x61        \x00\x3b
        gif        y         5000000                \x47\x49\x46\x38\x39\x61        \x00\x00\x3b
        jpg        y        200000000        \xff\xd8\xff\xe0\x00\x10        \xff\xd9
        jpg     y       200000000       \xff\xd8\xff\xe1                \xff\xd9

You must prefix the file format you want to exclude with a # character. Then start a sample search:

[root@fedora faruk]# scalpel -c /etc/scalpel.conf -o files_found /dev/nvme0n1p2
Scalpel version 2.1
Written by Golden G. Richard III and Lodovico Marziale.
Multi-core CPU threading model enabled.
Initializing thread group data structures.
Creating threads...
Thread creation completed.

Opening target "/dev/nvme0n1p2"

Image file pass 1/2.
/dev/nvme0n1p2: 72.3% |********************************* | 335.8 GB 01:57 ETA/dev/nvme0n1p2: 100.0% |**********************************************| 464.8 GB 00:00 ETAAllocating work queues...
Work queues allocation complete. Building work queues...
Adding files_found/pdf-0-0/00000000.pdf to queue
...
Adding files_found/pdf-1-0/00000875.pdf to queue
Adding files_found/pdf-1-0/00000876.pdf to queue
Adding files_found/pdf-1-0/00000877.pdf to queue
Adding files_found/pdf-1-0/00000878.pdf to queue
Work queues built. Workload:
pdf with header "%PDF" and footer "%EOF\x0d" --> 113 files
pdf with header "%PDF" and footer "%EOF\x0a" --> 766 files
Carving files from image.
Image file pass 2/2.
/dev/nvme0n1p2: 100.0% |**********************************************| 464.8 GB 00:00 ETAProcessing of image file complete. Cleaning up...
Done.
Scalpel is done, files carved = 879, elapsed = 400 secs.

When the search is complete, you can access the data in the directory specified with the -o parameter:

[root@fedora faruk]# tree files_found/
files_found/
├── audit.txt
├── pdf-0-0
│ ├── 00000000.pdf
...
├── 00000877.pdf
└── 00000878.pdf

2 directories, 880 files

Before starting the scan, make sure that the directory you specify with -o has enough space. Otherwise, you may encounter an insufficient disk space warning.

Method 5: Filesystem-level tools (extundelete, XFS, Btrfs)

When to use: You know the filesystem type; you can unmount the target (or mount read-only from rescue); the delete was recent on ext3/ext4 so the journal may still list inodes. Prefer this over raw carving (Methods 3–6) when metadata might still be intact.

These tools talk to the filesystem or journal instead of guessing file types from raw bytes. They are powerful, but you normally unmount the target first (or mount it read-only from rescue mode) and you always write recovered data to another disk. The commands below are the shape of the workflow—run them only after you read the tool manual for your exact filesystem version.

For ext3/ext4, extundelete can restore recently deleted files from the journal:

sudo umount /dev/sdb1
sudo extundelete /dev/sdb1 --restore-all

Recovered files land under RECOVERED_FILES/ in your current directory. On XFS, look at xfs_undelete (and upstream docs for your kernel). On Btrfs, investigate btrfs restore against an unmounted filesystem. None of these steps were executed on the machine that hosts this article, because running them against a live root disk would be unsafe to demonstrate in place.

Method 6: TestDisk and PhotoRec (signature carving)

When to use: Methods 1, 2, and 5 did not apply or failed; the filesystem is unmounted (or you are scanning a disk image / LVM LV offline); you need content by file signature (PNG, PDF, zip, …) and can write output to another disk. Not a reliable quick fix for a file deleted on live, mounted / that you cannot unmount—see the routing table above.

Install the suite (Debian/Ubuntu):

sudo apt install testdisk -y

TestDisk prints partition layout (testdisk /list). PhotoRec scans that same block device for file signatures and writes recovered content to a directory you choose. It does not bring back the original filename or path. PhotoRec needs a block device—not the path /root/file.txt after rm.

Delete a file, then recover it (verified on Ubuntu, TestDisk/PhotoRec 7.2)

The commands below create an 8 MiB ext4 volume, delete one PNG, unmount it, then recover the bytes with TestDisk + PhotoRec. On a real incident, replace /tmp/photorec-demo.img with the device from findmnt (for LVM: /dev/mapper/vg-lv or /dev/vg/lv) and unmount that filesystem before step 3. In production, point /d at a directory on another disk, not the volume you are scanning.

1. Put a file on the volume, delete it, unmount:

IMG=/tmp/photorec-demo.img
MNT=$(mktemp -d)
sudo dd if=/dev/zero of="$IMG" bs=1M count=8 status=none
LOOP=$(sudo losetup -f --show "$IMG")
sudo mkfs.ext4 -F -L DEMOVOL "$LOOP"
sudo mount "$LOOP" "$MNT"
sudo cp /usr/share/pixmaps/debian-logo.png "$MNT/deleted-demo.png"
sync
sudo rm -f "$MNT/deleted-demo.png"
sync
sudo umount "$MNT"
sudo losetup -d "$LOOP"
rmdir "$MNT"

2. Inspect layout with TestDisk:

sudo testdisk /list "$IMG"

3. Run PhotoRec (mode_ext2 is the correct /cmd keyword for ext4):

sudo mkdir -p /var/tmp/photorec-out
cd /var/tmp
sudo photorec /debug /log /d photorec-out \
  /cmd "$IMG" partition_i386,1,options,mode_ext2,fileopt,png,enable,search

4. Verify the carved file:

find /var/tmp/photorec-out* -name '*.png' -exec file {} \;
sha256sum /usr/share/pixmaps/debian-logo.png /var/tmp/photorec-out.1/f0009552.png

Output from the test run:

$ sudo testdisk /list /tmp/photorec-demo.img
Disk /tmp/photorec-demo.img - 8388 KB / 8192 KiB - CHS 2 255 63
Sector size:512
     Partition			Start        End    Size in sectors
   P ext4                     0   0  1     1   5  4      16384 [DEMOVOL]
     ext4 blocksize=4096 Large_file Sparse_SB

$ file /var/tmp/photorec-out.1/f0009552.png
/var/tmp/photorec-out.1/f0009552.png: PNG image data, 48 x 48, 8-bit/color RGBA, non-interlaced

The SHA-256 of the recovered PNG matched the deleted file; only the name changed (PhotoRec uses the disk offset, for example f0009552.png).

5. Map to your disk or LVM:

findmnt -n -o SOURCE,TARGET,FSTYPE /path/where/file/lived
sudo testdisk /list /dev/mapper/your--vg-your--lv

Use that device in step 3 instead of "$IMG". Do not scan individual PV disks (/dev/sdb) when the file lived on a logical volume—scan the LV that holds ext4. See overview of LVM in Linux if PV versus LV naming is unclear.

Menu-driven run (same choices): sudo photorec → select the device → File Opt → set destination. For a screenshot-based PhotoRec walkthrough, see recover lost files in Linux with PhotoRec. Scripted keyword reference: PhotoRec scripted run.

Method 7: Restore from trash-cli

When to use: You (or a script) deleted with trash, trash-put, or an rm alias to Trash—not plain rm. Does nothing for a normal rm delete unless Trash was already in place before the mistake.

Install the tools once (Debian/Ubuntu shown; use dnf, pacman, or zypper on other families):

sudo apt install trash-cli -y

Create a throwaway directory and a small file so you are not practicing on real data:

DEMO=$(mktemp -d)
cd "$DEMO"
printf 'restore me\n' > doc.txt
ls -la

You should see doc.txt in the listing.

Move the file into Trash instead of unlinking it:

trash-put doc.txt
ls -la

The directory should look empty except for . and ...

List what landed in Trash and filter to your temp path so the list stays short:

trash-list | grep "$DEMO" || trash-list

Example line:

2026-06-22 19:42:32 /tmp/tmp.Ux2Y49n9GR/doc.txt

Bring the file back. trash-restore is interactive: it prints numbered choices. When only one row matches, you can answer 0 from the keyboard, or pipe it for a script:

printf '0\n' | trash-restore

Typical interaction:

$ printf '0\n' | trash-restore
   0 2026-06-22 19:42:32 /tmp/tmp.Ux2Y49n9GR/doc.txt
What file to restore [0..0]:

Confirm the file is back and readable:

ls -la
cat doc.txt

You should see restore me again. Tear down the temp directory when you are finished:

cd /
rm -rf "$DEMO"

If trash-list shows several paths, read the menu carefully before you pipe the index—pick the number that matches the file you want.

If you are not already using trash-cli day to day, the next section shows how to wire it into your shell so the safety net exists before you need it.

How to prevent accidental rm in future

You cannot undo a plain rm after the fact, but you can make future deletions far safer.

• Use trash-cli instead of rm. Install it and delete with trash-put, which moves files to Trash so you can restore them later:

  text Copy

  sudo apt install trash-cli -y      # Debian/Ubuntu
  sudo dnf install trash-cli -y      # RHEL/Fedora/Rocky/Alma
  sudo pacman -S trash-cli           # Arch/Manjaro
  sudo zypper install trash-cli      # openSUSE

  Restore with trash-restore, list with trash-list, and empty with trash-empty.

• Alias rm to trash-put if you want CLI Trash behavior. Add this to ~/.bashrc:

  text Copy

  alias rm='trash-put'

  Then source ~/.bashrc. Now rm sends files to Trash instead of unlinking them.

• Use rm -i or rm -I for confirmation. rm -i prompts on every file; rm -I prompts once when removing many files or recursively:

  text Copy

  alias rm='rm -I'

• Use safe-rm or shell functions for protected paths. Tools like safe-rm block deletion of critical directories (such as /, /etc, /usr) even if a command or script targets them.

• Keep backups and snapshots for important directories. Regular backups, LVM snapshots, Btrfs/ZFS snapshots, or cloud volume snapshots turn a disaster into a quick restore.

Summary

Linux rm has no undo and does not use Trash by default, so deleted files are unlinked immediately. Recovery is sometimes possible but never guaranteed, and it depends almost entirely on stopping writes to the affected filesystem right away. If files are deleted, remount the filesystem read-only (or shut down and image the disk), then try recovery in order of reliability: backups and snapshots first, then open file descriptors via /proc, then carving with Foremost or Scalpel when you can work from a copy of the disk, then filesystem tools such as extundelete, then TestDisk and PhotoRec together (Method 6: testdisk /list, interactive PhotoRec, or a /cmd scripted run), and finally trash-cli (Method 7) when you had been using Trash all along. Going forward, use trash-cli, sensible aliases in interactive shells, and regular backups so the next accidental deletion is a quick restore rather than a forensic project.

For more information, you can get help from the application's manual pages:

man foremost
man scalpel
man testdisk
man photorec
man trash

Related guides on GoLinuxCloud

• Linux LVM snapshot backup and restore tutorial — create, extend, merge, and remove snapshots; useful before upgrades and after accidental deletes on LVM
• How to clone or backup a Linux partition using fsarchiver — full partition backup before maintenance
• Overview of LVM in Linux — PV, VG, and LV layout when choosing what block device to scan
• PROPERLY recover lost files Linux — PhotoRec walkthrough with screenshots
• Repair ext4 filesystem in rescue mode — unmount and check ext4 safely before extundelete or carving

References

• undo Linux's rm?
• Undo the Linux trash command
• linux terminal undo rm 'somefile'