Recovering Deleted Files

6 March 2023 · Updated 9 August 2026

Most write-ups on recovering deleted files were written for spinning disks and never say so. On a hard drive, deleting a file marks its space free and leaves the contents sitting there until something overwrites them, which is what makes recovery possible. On an SSD, that assumption is usually wrong, and it’s worth finding out which one you have before spending a day on it.

Check the drive first

# ROTA 1 is a spinning disk, 0 is solid state
lsblk -d -o NAME,ROTA,MODEL,SIZE

# Non-zero DISC-GRAN / DISC-MAX means the drive supports discard (TRIM)
lsblk -D

# Is the OS running TRIM on a schedule?
systemctl status fstrim.timer

When a file is deleted on an SSD with TRIM enabled, the OS tells the drive that region is no longer in use. The drive marks those pages invalid, and reads of that region stop returning the old contents. Once the drive’s garbage collection has run, recovery is somewhere between difficult and impossible depending on the firmware, and it isn’t something a better tool can solve. foremost will scan the image and find nothing, because the image itself is zeros.

There’s a short window before garbage collection where the data may still be on the flash, so acting immediately is worth something. Not much, and you can’t tell from outside how long you have.

The practical version:

• Spinning disk: carving works, and the advice below is worth following.
• SSD, TRIM enabled: assume it’s gone. Go to backups.
• SSD, TRIM disabled or an external drive over USB where discard isn’t passed through: worth trying, since the deletion may never have reached the drive as a discard.

Stop writing to it

Every write is a chance to land on the blocks you want back. Unmount the filesystem, and if the drive is still in the machine, set the block device read-only:

sudo umount /dev/sdb1
sudo blockdev --setro /dev/sdb

blockdev --setro is a software write block. It stops the kernel and anything running on the machine from writing, which covers the accident you’re most likely to have. It isn’t a hardware write blocker and shouldn’t be presented as one if the result has to stand up anywhere.

Image before you touch anything

Work on a copy. dc3dd is a fork of dd built for forensics, and the reason to use it over plain dd is that it hashes and logs while it reads:

dc3dd if=/dev/sdb of=/evidence/drive.dd \
      hash=sha256 log=/evidence/drive.log

Check if= and of= twice before pressing enter. Pointed the wrong way, this overwrites the drive you were trying to save, and there’s no undo.

Verify the copy matches the source:

sha256sum /evidence/drive.dd
# compare against the hash dc3dd wrote to drive.log

If the drive is failing rather than just missing files, ddrescue is the right tool instead. It reads what it can, skips what it can’t, and keeps a mapfile so you can come back for the bad areas:

ddrescue -d -r3 /dev/sdb /evidence/drive.dd /evidence/drive.mapfile

Run it again with the same mapfile to retry the sectors it gave up on. Every read attempt on a dying drive costs you something, so image once, properly, and work from the copy after that.

Carve the image

foremost scans for file signatures and pulls out anything it recognises, ignoring the filesystem entirely:

foremost -t jpg,png,pdf,docx -i /evidence/drive.dd -o /recovery/

Names and directory structure are gone, since those live in filesystem metadata rather than in the files. You get content with generated names.

photorec does the same job with more file types and an interactive interface, and testdisk (same package) is the one to reach for when the partition table is the problem rather than the files:

photorec /evidence/drive.dd
testdisk /evidence/drive.dd

Recover to a different drive than the one you’re reading. Writing recovered files back onto the source is a good way to overwrite the rest of what you were about to recover.

Mounting the image

If the filesystem is intact and you just want to look:

sudo mount -o ro,loop,noexec,nodev /evidence/drive.dd /mnt/evidence

Read-only matters. Mounting an evidence image read-write updates access times and journals, which changes the thing you were trying to preserve.

If it isn’t your drive

Get written authorisation before touching it, keep the original untouched and work from images, and write down what you did and when. That’s the difference between recovery and something you can’t explain later.