Recovering Deleted Files on Linux With TestDisk and PhotoRec

Recovering Deleted Files on Linux With TestDisk and PhotoRec

You ran rm on the wrong directory, formatted the wrong USB stick, or a partition table vanished. Before anything else, read the first section; what you do in the next few minutes matters more than which tool you use.

The honest summary: recovery is sometimes possible, never guaranteed, and much harder on SSDs. Backups are the real fix, and we will come back to that.

The first five minutes

Deleted data usually still sits on the disk until something overwrites it. So:

  1. Stop writing to the affected drive. Do not install recovery tools onto it, download to it, or keep using it
  2. If it is your system drive, shut down (a clean shutdown writes logs; pulling the power writes nothing, though it has its own risks) and boot from a live USB
  3. If it is another drive, unmount it now:
sudo umount /dev/sdb1
  1. Image the drive first if the data matters. Work on the image, not the original:
sudo apt install gddrescue
sudo ddrescue -d /dev/sdb /mnt/backup/sdb.img /mnt/backup/sdb.map

ddrescue copies what it can, skips bad areas and comes back to them, which makes it the right tool for failing drives too. Our dd guide explains the plain-dd equivalent for healthy drives.

Install TestDisk and PhotoRec

Both come in one package:

sudo apt install testdisk     # Debian / Ubuntu
sudo dnf install testdisk     # Fedora
sudo pacman -S testdisk       # Arch

Most live USB rescue systems, such as SystemRescue, include them already.

TestDisk: partitions and undelete

TestDisk works with filesystem structures. It is the tool for:

  • Lost or deleted partitions: scanning the disk for partition signatures and rewriting the partition table
  • Damaged boot sectors on FAT and NTFS
  • Undeleting files on filesystems that keep enough metadata: FAT, exFAT, and NTFS (and ext2)
sudo testdisk /dev/sdb          # or the image: testdisk sdb.img

It is a text menu. The typical path:

  1. Create a log, select the disk, and confirm the partition table type (usually EFI GPT or Intel/MBR)
  2. Analyse to search for partitions. Quick Search first, Deeper Search if needed
  3. For lost partitions: check that the found partitions look right (TestDisk can list their files), then Write the new table
  4. For deleted files: choose Advanced, select the partition, then Undelete, mark files, and copy them to a different drive

Our partitioning guide helps make sense of what TestDisk shows you.

PhotoRec: carving files from raw data

PhotoRec ignores the filesystem entirely. It scans the raw bytes for file signatures, the recognisable headers at the start of JPEGs, PDFs, ZIP-based documents, videos, and hundreds of other formats, and extracts what follows.

That makes it work where TestDisk cannot: reformatted drives, corrupted filesystems, and ext4. The price is that file names and folder structure are lost; you get files named like f1234567.jpg sorted into numbered directories.

sudo photorec /dev/sdb          # or photorec sdb.img
  1. Select the disk or partition
  2. Choose the filesystem type (ext2/3/4 or Other for FAT/NTFS/exFAT)
  3. Choose Free (unallocated space only, for deleted files) or Whole
  4. Pick a destination on a different drive
  5. Under File Opt, you can restrict to the types you need, which speeds things up and reduces junk

Afterwards, find what you need by type and size, or search contents:

find recup_dir.* -name '*.pdf' -size +100k
grep -rl "Quarterly report" recup_dir.*

Our find guide and grep guide help sort through thousands of recovered files.

Why some recoveries fail

SSDs and TRIM

On SSDs, deleting a file triggers TRIM: the operating system tells the drive those blocks are free, and the drive erases them internally, often within seconds or minutes. Once trimmed, the data is gone, and no software can bring it back. Most distributions trim continuously or weekly (fstrim.timer).

Recovery from an SSD is realistic only if you act immediately, and even then it often fails.

ext4

When ext4 deletes a file, it clears the inode’s pointers to the file’s data blocks, so tools have little metadata to follow. PhotoRec still works for many file types; ext4magic can sometimes reconstruct recently deleted files from the journal. Our inodes and the page cache guide explains what is lost.

Btrfs and ZFS

Copy-on-write filesystems make recovery from raw data harder, but they offer something better: snapshots. If you had snapshots enabled, recover from those instead. See Btrfs snapshots with Timeshift and ZFS basics.

A failing drive is different

If the drive is clicking, disappearing, or logging I/O errors, do not run recovery tools on it directly. Every read stresses it further. Image it with ddrescue first, check its health with smartctl, and for irreplaceable data on a mechanically failing drive, consider a professional recovery service.

Prevention beats recovery

Recovery tools are a last resort. What actually protects you:

  • Backups, automated and tested: automated backups and restic vs borg
  • Snapshots on Btrfs or ZFS
  • A trash for the command line: gio trash file or the trash-cli package moves files to the desktop trash instead of deleting them
  • Care with destructive commands; our rm guide covers the habits that prevent these accidents

Frequently Asked Questions

What should I do immediately after deleting a file by mistake?

Stop writing to that drive. Every new write can overwrite the deleted data. If it was on your system drive, shut down and work from a live USB. If it was on another drive, unmount it, and ideally make an image of it with ddrescue before attempting recovery.

What is the difference between TestDisk and PhotoRec?

TestDisk works with filesystem structures: it repairs partition tables, rebuilds boot sectors, and can undelete files on filesystems that keep enough metadata, such as FAT, exFAT, and NTFS. PhotoRec ignores the filesystem and scans raw data for known file signatures, recovering file contents even from badly damaged or reformatted drives, but without original names or folders.

Can I recover deleted files from ext4?

It is hard. When ext4 deletes a file, it clears the information linking the inode to the file’s data blocks, so undelete tools have little to work with. PhotoRec can still carve many file types from raw data, and tools like ext4magic can sometimes use the journal, but results are partial.

Why can I not recover files from an SSD?

Because of TRIM. When a file is deleted, the operating system tells the SSD which blocks are free, and the drive erases them, often within seconds or minutes. Once trimmed, the data is gone. Recovery from SSDs is only realistic very soon after deletion, and often not at all.

Where should recovered files be saved?

Always to a different drive than the one you are recovering from. Writing recovered files to the source drive can overwrite the very data you are still trying to recover.

What about deleting with rm?

rm removes the directory entry and frees the data blocks; there is no recycle bin. The data stays on a hard drive until overwritten, so recovery tools may find it, but on SSDs and ext4 the chances are poor. Backups are the only reliable protection against rm mistakes.