How to Recover Deleted Files in Linux

Accidentally deleted an important file on Linux? Don't panic, but stop using the affected disk as soon as possible. The more data Linux writes to it, the greater the chance that your deleted files will be overwritten and become much harder or impossible to recover.

This guide walks you through the recovery process step by step, starting with the simple options like checking the Trash and file history, then moving to tools such as PhotoRec, extundelete, and ext4magic when deeper recovery is needed. You'll also learn how to identify the correct disk and filesystem, create a safe disk image before scanning, and handle LVM, LUKS, SSDs, and NVMe drives along the way. :contentReference[oaicite:0]{index=0}

Prerequisites :

Operating System        :   Ubuntu 22.04/24.04, Debian 12, Rocky Linux 8/9, RHEL 8/9
Packages and Dependencies:  testdisk (includes photorec), extundelete, ext4magic, ddrescue,
                             cryptsetup, lvm2, trash-cli
User Account            :   root user or a user account with sudo privileges
Recommended to run all administrative commands with sudo instead of logging in as root directly.

If you're not sure your account even has sudo rights yet, sort that out first, there's a walkthrough on how to configure sudo access in Linux that covers it in a few minutes.

If you're testing any of this on a fresh box before touching production data, it helps to know your way around the installer first, this Ubuntu 24.04 installation walkthrough is a decent starting point for a disposable test VM.

My Lab Setup :

Recovery Test Server:

Operating System    :   Ubuntu 24.04 LTS
Hostname            :   recovery-test
IP Address          :   192.168.1.50
Filesystem          :   ext4 (/dev/sdb1, mounted separately from root, no LVM or LUKS)

Step 1: Identify Exactly What You're Dealing With

Run this to see what's mounted where, and note the filesystem type in the third column.

df only shows you what's currently mounted. Run this next to see the full device tree, including whether the partition sits directly on disk or behind LVM.

If the affected directory sits on the same partition as your root filesystem, remounting it read only isn't always practical without booting from a live USB. If that's your situation, don't run dd or ddrescue on the running system, boot into a live USB or ISO environment first, then jump to Step 4 and image the whole disk from there instead of working on a live root partition. The same applies if root itself is LVM or LUKS backed, unlock and identify the volume from the live environment before imaging anything.

Step 2: Check the Trash Directory First

List what's sitting in your local trash before assuming the worst.

Step 3: Install Your Recovery Toolkit

On Ubuntu or Debian, install all of them in one go. Note that the ddrescue package is named gddrescue, even though the command itself is still ddrescue.

On Rocky Linux or RHEL, EPEL covers testdisk, extundelete, ddrescue, cryptsetup, and lvm2, but not ext4magic, it isn't packaged for RHEL family distros and has to be compiled from source. Some EPEL packages, ddrescue included, pull in dependencies that live in the CodeReady Linux Builder repo (called PowerTools on older Rocky releases), which is disabled by default, so enable that before installing anything.

For ext4magic on Rocky or RHEL, install the build dependencies and compile it directly from the source tarball.

Here's how the tools in this toolkit differ, so you're not guessing which one to reach for first.

Step 4: Image the Drive Before You Run Anything Else

On a healthy disk, dd works fine.

If the drive is failing, showing SMART errors, or making unusual noise, use ddrescue instead. It works through the disk in passes, skipping unreadable sectors on the first pass and retrying them separately afterward, instead of stalling the entire copy the way dd can.

Step 5: Scan the Image With PhotoRec When You Just Need the File Contents Back

Once files land in the recovery folder, sorting through hundreds of generically named files gets old fast. If you know roughly what you're looking for, the find command with a file type or size filter narrows things down quicker than scrolling through a file manager. If the filenames are generic but you don't know the type either, cd into the destination directory you gave PhotoRec, the recup_dir.1 folder referenced below sits directly inside it, and run the file command against everything there to sort by actual content type instead of guessing from extensions.

Step 6: Try extundelete or ext4magic for the Original Filenames

By default, extundelete writes recovered files into a folder called RECOVERED_FILES inside your current working directory, which is easy to miss if you forgot to cd into an external mount first. Change into your external drive and use --output-dir to be explicit about where files land.

If extundelete comes up short, ext4magic is worth a shot on the same image, it uses a slightly different syntax but the same idea, point it at the image and give it a separate output location. Unlike extundelete, ext4magic won't create the output folder for you, so create it first with mkdir -p before running the recovery command.

Whether the file even shows up in either tool comes down to what actually happens when Linux runs rm, the man page for it explains the underlying unlink behavior if you want the full picture of why this isn't always recoverable.

Building a Safety Net So You Don't Need to Recover Deleted Files in Linux Again

Once your files are back, it's worth spending twenty minutes making sure you're not back here next month. A few small habits cover most of the ways people lose data on Linux.

If you're setting up a new system or rebuilding one after this, consider btrfs or ZFS with scheduled snapshots instead of ext4. A snapshot taken every hour or so means an accidental delete is just a rollback away, no PhotoRec, no journal scanning, no imaging a drive at 2am. It's more setup work upfront than a plain ext4 install, but for anything you'd genuinely miss, it's worth it.

Install trash-cli so terminal deletions land in a recoverable trash folder instead of vanishing immediately, and get comfortable typing trash instead of rm out of habit. For anything code related, commit early and often, a git history is a far better safety net than any recovery tool. For everything else, an actual backup schedule beats hoping recovery works when you need it. A simple automated backup script paired with a scheduled job covers most home and small server setups, and if cron feels clunky for that, systemd timers are a cleaner way to run it reliably. For anything running production workloads, look into proper server backup solutions rather than relying on manual copies you'll eventually forget to run.

If your data actually lives on a remote server rather than your own machine, a good chunk of this pain goes away simply by picking hosting that handles snapshots and backups for you. When people ask me what to look at for that, I usually point them toward this Cloudways review, it's a decent rundown of whether managed hosting is worth it if you're tired of babysitting backups yourself, and it pairs well with the general advice in this Linux VPS hosting comparison if you're still shopping around.

Conclusion:

Recovery isn't guaranteed, but identifying the real device layout, encrypted or LVM or plain, imaging it first, and then working through trash, PhotoRec, extundelete, and ext4magic against that copy gives you the best realistic shot to recover deleted files in Linux without risking the original. Once you're through this, put trash-cli, snapshots, and a real backup schedule in place so the next accidental deletion is a non event instead of a panic. Drop me your feedback/comments. Feel free to share this article with others if you like it.

☕

Support My Work

Thank you for reading and for being part of this journey. If this article saved you time, consider buying me a coffee. Every contribution helps me keep producing in-depth, practical Linux content for readers like you.

Thank you for your endless support