You hit rm -rf on the wrong folder. Or you emptied the trash without thinking. Or a script you were testing wiped a directory you actually needed. If you’re reading this, you already know the sinking feeling — and you’re here because you want to know how to recover deleted files on Linux before it’s too late.
The good news is that Linux rarely destroys data the instant you delete it. Most filesystems just mark the space as “free” and move on; the actual bytes usually sit on the disk until something else overwrites them. That gap between “deleted” and “gone” is exactly what recovery tools exploit. This guide walks through real, tested methods — from simple trash-bin tricks to full block-level recovery with TestDisk and PhotoRec — across Ubuntu, Debian, Fedora, RHEL, and Arch, so you can pick the right approach for your distro and your filesystem.
Stop Right Now: The One Rule That Actually Matters
Before touching a single command, do this: stop writing to the affected drive.
Every file you save, every package you install, every log entry your system writes can overwrite the very sectors holding your deleted data. If the drive is your system disk, avoid installing recovery tools directly onto it — use a USB live environment instead, or at minimum install tools to a different partition or external drive. If it’s a secondary drive or a USB stick, unmount it immediately:
sudo umount /dev/sdX1This single habit determines whether recovery succeeds or fails more than any tool you choose afterward.
Why Deleted Files Aren’t Actually Gone (Usually)
When you delete a file on most Linux filesystems, the operating system doesn’t shred the data. It removes the file’s entry from the directory structure and marks the associated blocks as available for reuse. The content stays put — invisible to ls, but still physically present — until the system needs that space for something new.
This is true for ext4, XFS, FAT32, and exFAT in different degrees. It is not reliably true for SSDs with TRIM enabled, and it’s a different story entirely for Btrfs and ZFS, which we’ll cover separately. Understanding which filesystem you’re working with changes your entire recovery strategy, so check it first:
lsblk -for
df -ThQuick Wins Before You Reach for Recovery Tools
Not every deletion needs forensic-grade software. Check these first — they take thirty seconds and solve the problem more often than people expect.
1. Check the Trash, Not Just the Desktop Trash Can
GNOME, KDE, and most desktop environments follow the freedesktop.org Trash specification and route “deleted” files to ~/.local/share/Trash/files/ rather than actually removing them. If you deleted something through your file manager (Nautilus, Dolphin, Nemo), look here first:
ls -la ~/.local/share/Trash/files/Files deleted with rm in a terminal skip the trash entirely, which is why terminal deletions are the ones that usually send people looking for recovery tools.
2. Check for Open File Handles
If a program still has the file open when you delete it, the data often survives on disk even though the filename is gone — because Linux won’t actually free the blocks until every process closes its handle to the file. Check running processes for handles to deleted files:
lsof | grep deletedIf you find a match, you can sometimes recover the contents through /proc/<PID>/fd/<FD_NUMBER>:
cp /proc/1234/fd/5 /home/user/recovered-file.txtThis trick has saved more log files and half-written documents than any recovery suite.
3. Check for Backups You Forgot About
Sounds obvious, but check anyway:
- Timeshift snapshots (common on Ubuntu, Mint, Fedora)
- Btrfs or ZFS snapshots, if your filesystem uses either
- rsync or Borg backups, if you’ve set up scheduled jobs
- Cloud sync folders (Nextcloud, Dropbox, Google Drive clients) often keep versioned copies even after local deletion
Filesystem-Specific Recovery: Why It Matters
Not all Linux filesystems behave the same way once a file is deleted, and this is where a lot of generic advice online falls short.
Ext4 (Ubuntu, Debian, Mint, most default installs)
Ext4 is the most common filesystem for Linux desktops and servers, and it’s also the most forgiving for recovery — provided you act quickly and stop writing to the disk. Ext4 doesn’t zero out inode data on deletion by default, which is why tools like extundelete and ext4magic can often reconstruct a file’s metadata and content directly from the journal.
XFS (default on RHEL, Rocky Linux, AlmaLinux)
XFS is less forgiving. It was designed for performance on large storage arrays, not undelete-friendliness, and it aggressively reuses freed extents. There’s no mature, actively maintained undelete tool built specifically for XFS — your realistic options are xfs_undelete (works, but inconsistent) and a full carving pass with PhotoRec, which ignores the filesystem entirely and searches for file signatures directly on the raw disk.
Btrfs (openSUSE default, increasingly common on Fedora)
Btrfs changes the whole conversation. Because it’s copy-on-write, a deleted file may still exist in a previous snapshot even if the live filesystem shows nothing. If your system takes automatic snapshots (openSUSE’s Snapper does this by default), check those before running any recovery tool:
sudo snapper list
sudo snapper undochange <number>..0ZFS (common on servers, TrueNAS, some Ubuntu server setups)
Same logic as Btrfs — check for snapshots first with zfs list -t snapshot, and roll back or copy the file from a snapshot rather than reaching for a carving tool. OpenZFS’s copy-on-write design makes snapshot recovery far more reliable than block-level scanning.
SSDs and TRIM: The Bad News
If your drive is an SSD and TRIM is enabled (which it is by default on nearly every modern distro through fstrim.timer), the story changes significantly. TRIM tells the SSD’s controller to immediately erase the physical blocks belonging to deleted files, rather than waiting for new data to overwrite them. This means recovery odds on a TRIM-enabled SSD drop sharply within seconds of deletion — sometimes to zero. If you’re on an SSD, act immediately, and understand that success isn’t guaranteed the way it often is on spinning HDDs.
The Core Recovery Toolkit
Here’s the practical toolkit, in the order most people should reach for them.
TestDisk and PhotoRec (Universal, Free, Cross-Distro)
Written and maintained by Christophe Grenier, TestDisk and PhotoRec remain the gold standard for open-source data recovery, with the current stable line sitting at version 7.3. They ship in the repositories of virtually every major distro — including the Debian package archive and Fedora’s package repository — and work identically whether you’re on Ubuntu, Fedora, or Arch.
- TestDisk repairs partition tables, recovers deleted or lost partitions, and fixes boot sectors. Use it when an entire partition has vanished, not just individual files.
- PhotoRec ignores the filesystem entirely and scans the raw disk for recognizable file signatures — it currently recognizes several hundred file types. This makes it filesystem-agnostic: it works the same on ext4, XFS, FAT32, or a corrupted, unreadable filesystem.
Install and run:
# Debian/Ubuntu
sudo apt install testdisk
# Fedora/RHEL
sudo dnf install testdisk
# Arch
sudo pacman -S testdisk
# Run PhotoRec (recover to a DIFFERENT drive than the one you're scanning)
sudo photorecThe one habit that trips people up: never recover files back onto the same partition you’re scanning. Always point the output to a separate disk or USB drive.
extundelete (Ext3/Ext4 Specific)
extundelete reads the ext3/ext4 journal directly to reconstruct deleted files with their original names and directory structure intact — something PhotoRec can’t do, since PhotoRec recovers raw content but discards filenames.
sudo apt install extundelete # Debian/Ubuntu
sudo umount /dev/sdX1
sudo extundelete /dev/sdX1 --restore-allIt must run against an unmounted partition, which is why live-USB recovery is often necessary for a root filesystem.
ext4magic (More Actively Maintained Alternative)
Where extundelete has seen limited updates in recent years, ext4magic is a more actively maintained fork with better journal-parsing and the ability to target recovery by timestamp — useful if you know roughly when the file existed:
sudo apt install ext4magic
sudo ext4magic /dev/sdX1 -a "2026-08-20-00:00:00" -b "2026-08-22-12:00:00" -r -d /media/recoveryForemost and Scalpel (Signature-Based Carving)
Similar concept to PhotoRec but more configurable — you define which file signatures to search for, which speeds up scans dramatically when you know exactly what you’re looking for (say, only .docx and .jpg files):
sudo apt install foremost
sudo foremost -t jpg,docx,pdf -i /dev/sdX1 -o /media/recoveryddrescue (When the Drive Itself Is Failing)
If the deletion happened alongside a failing drive — bad sectors, clicking noises, SMART warnings — your first move isn’t recovery software, it’s imaging the drive before it degrades further using GNU ddrescue:
sudo apt install gddrescue
sudo ddrescue -d -r3 /dev/sdX /media/backup/disk_image.img /media/backup/rescue.logRun every recovery tool against the image file, not the failing physical drive. This protects you from turning a partial failure into total data loss.
Distro-by-Distro: What Actually Works Where
| Distro / Family | Default Filesystem | Best First Step | Best Recovery Tool | Notes |
|---|---|---|---|---|
| Ubuntu 26.04 LTS (“Resolute Raccoon”) / Mint | ext4 | Check ~/.local/share/Trash, then Timeshift snapshots if configured | extundelete or ext4magic, fallback to PhotoRec | Ext4 is the most recovery-friendly filesystem here |
| Debian (stable) | ext4 | Check open file handles via lsof, then unmount and run extundelete | ext4magic | Conservative package versions; may need to build from source for the newest ext4magic release |
| Fedora 44 / RHEL / Rocky / AlmaLinux | XFS (server/workstation default) | Check for LVM snapshots if using LVM-thin | PhotoRec (filesystem-agnostic carving) | XFS has weak native undelete support — carving is often the only option |
| openSUSE (Leap/Tumbleweed) | Btrfs | Check Snapper snapshots first — often instant recovery | Snapper rollback, then PhotoRec if no snapshot exists | Snapshot-based recovery beats carving tools by a wide margin here |
| Arch Linux | ext4 (user-chosen) | Depends entirely on user’s filesystem choice at install | TestDisk/PhotoRec (universal), extundelete if ext4 | Rolling release means tool versions are usually the newest available |
A Practical Walkthrough: Recovering an Accidentally Deleted Document on Ubuntu
Here’s how this plays out in practice, using a common scenario — someone runs rm important-report.docx in a terminal on Ubuntu 26.04 LTS.
- Stop working on that partition immediately. Close any unnecessary applications and avoid saving new files.
- Check for an open handle, in case the file was still open in LibreOffice or a text editor:
lsof | grep report - If nothing turns up, boot a live USB (Ubuntu’s own installer media works fine) rather than working directly on the mounted root partition.
- Identify the partition:
lsblk -f - Unmount it if it isn’t your live-boot drive:
sudo umount /dev/sda2 - Run extundelete targeting the specific file:
sudo extundelete /dev/sda2 --restore-file "home/user/Documents/important-report.docx" - If that fails, fall back to PhotoRec and filter results by
.docxextension, recovering to an external drive.
This layered approach — cheapest and fastest methods first, block-level carving as a last resort — applies almost universally, regardless of distro.
Preventing the Next Data Loss
Recovery tools are a safety net, not a strategy. A few habits make the difference between a five-minute fix and a genuine emergency:
- Use
rm -ias an alias so the shell asks for confirmation before deleting, as documented in the GNU Coreutils manual:alias rm='rm -i' - Enable Timeshift on desktop distros — it’s free, lightweight, and turns most “I deleted the wrong thing” moments into a two-minute restore.
- Set up automatic Btrfs or ZFS snapshots if your filesystem supports them; Snapper on openSUSE does this out of the box.
- Keep an off-machine backup — Borg, restic, or even a scheduled rsync to another disk — for anything you genuinely can’t afford to lose.
- Disable TRIM selectively on SSDs holding sensitive data you might need to recover, understanding the tradeoff in wear-leveling performance.
Frequently Asked Questions
Can I recover files after emptying the trash on Linux?
Yes, in many cases — emptying the trash only removes the file’s directory entry, not the underlying data, so tools like PhotoRec or extundelete can often still recover it if you act before the space is overwritten.
Does rm -rf permanently delete files instantly?
No — rm -rf unlinks the files from the filesystem immediately, but the actual data typically remains on disk until overwritten, which is why prompt recovery attempts usually succeed.
Which Linux recovery tool works best for ext4 partitions?
Extundelete and ext4magic work best on ext4 because they read the filesystem journal directly, recovering both filenames and content rather than just raw data.
Is it possible to recover deleted files from an SSD?
It’s much less reliable than on an HDD, because TRIM actively erases freed blocks on most SSDs within seconds of deletion, so success depends heavily on how quickly you act and whether TRIM was enabled.
Do I need to reinstall Linux to use recovery tools safely?
No — booting from a live USB is enough; it lets you run recovery software without writing to the affected partition, which protects the data you’re trying to save.
Can Btrfs or ZFS snapshots recover deleted files without any extra software?
Yes — if automatic snapshots were enabled (as with Snapper on openSUSE), you can often roll back to a snapshot taken before the deletion and retrieve the file directly, no carving tools needed.
Final Thoughts
Learning how to recover deleted files on Linux really comes down to two things: acting fast, and matching your recovery method to your filesystem. Ext4 users have the friendliest recovery odds thanks to journal-based tools like extundelete and ext4magic. XFS and SSD users face steeper odds and should lean on PhotoRec’s raw carving or, better yet, prevention through snapshots and backups. Btrfs and ZFS users often have the easiest path of all, provided snapshots were switched on before disaster struck.
Whatever distro you’re running, the fundamentals hold: stop writing to the drive, identify your filesystem, pick the right tool for that filesystem, and always recover to a separate disk. Handled that way, most “I just lost everything” moments turn out to be entirely recoverable.
Disclaimer: This guide is for general informational purposes only. Data recovery outcomes depend on your filesystem, drive type, and how quickly you act, and success is never guaranteed. Always test recovery commands carefully, work from a disk image or a separate drive whenever possible, and if the data is business-critical or the drive shows signs of physical failure, consult a professional data recovery service before running additional tools.
More Linux Guides Worth Reading
Continue with practical Linux installation, dual-boot, and laptop guides.
Linux Installer Shows GPT Partition Error: Causes and Fixes
Understand why GPT partition errors appear during Linux installation and how to fix boot mode, firmware, and partition table conflicts.
Read the complete guideShould You Disable Fast Startup Before Installing Linux?
Learn how Windows Fast Startup can affect Linux dual boot, NTFS partitions, shared drives, and safe Linux installation.
Read the complete guideDoes Linux Support Face Unlock on Laptops? (2026 Guide)
See how face recognition works on Linux laptops, which tools are available, and what hardware support you need in 2026.
Read the complete guide
