Can a Deleted File Be Recovered After TRIM?

Sometimes, but TRIM turns recovery from a filesystem problem into a race against the storage device. If you deleted a file from an SSD, the filename disappearing is only the first event. The filesystem may still know which blocks belonged to it, the operating system may have queued a discard, and the drive may later erase or rearrange those blocks internally.

That means the useful answer is not "run undelete". It is: stop writing to the device, find out whether TRIM was issued, and treat every further boot or mount as potentially making recovery worse.

Deletion and TRIM are different events

Deleting a file normally removes directory metadata and marks its data blocks as available. Until those blocks are reused, recovery software may be able to reconstruct some or all of the content. Deleting a name does not immediately mean that every data byte has vanished.

TRIM, usually exposed on Linux as discard, tells an SSD which logical block ranges are no longer needed. The drive can then stop preserving those ranges during garbage collection. It is an instruction about future storage behaviour, not a secure erase command with a predictable instant of completion.

Linux filesystems can issue discard when blocks are freed if the relevant mount option is enabled. The separate fstrim utility can also discard unused blocks across a mounted filesystem. The fstrim manual recommends that most systems trim periodically rather than continuously.

Quick detour: this is why copying a disk image after deletion is not automatically a safe rescue. Reading the device can preserve a snapshot of what is still readable, but the image cannot bring back blocks that the controller has already discarded or returned as zeroes.

Why SSD recovery is less predictable than hard-disk recovery

Hard disks expose magnetic sectors more directly. An SSD has a flash translation layer between logical block addresses and physical NAND pages. The controller moves data during wear levelling and garbage collection, and it may process discarded ranges later, in batches or opportunistically.

There is no reliable countdown from TRIM to physical erasure. A trimmed range might remain readable briefly, return zeroes, or become unavailable after background work. The result depends on the drive, firmware, spare capacity, workload, power state and filesystem.

Some SSDs return deterministic zeroes for trimmed blocks. That can look reassuring, but it means the device is answering the read rather than revealing recoverable old contents. A successful read is not evidence that the old file survived.

TRIM is also not the same thing as overwriting every physical flash cell. The controller may have several physical copies, stale pages or spare areas that are invisible through the normal block interface. That is one reason storage sanitisation guidance treats flash differently from magnetic disks. NIST SP 800-88 Rev. 2 discusses sanitisation as a process tied to the media and the required level of assurance.

First response: make the device boring

If the data matters, stop using the original device immediately. Do not install recovery software on it, boot from it repeatedly, run a filesystem repair, or save recovered output back to the same disk.

1. Power the machine down cleanly if doing so will not trigger encryption or other access problems. If the device is already unmounted, leave it that way.
2. Attach the storage to a separate recovery system, ideally through hardware that does not issue discard commands.
3. Create a read-only forensic image or clone to different storage. Keep the original untouched and work from the copy.
4. Record the device identity, filesystem, deletion time, mount options and anything that may have written to it since deletion.

For a valuable case, a professional examiner may use a write blocker and specialised imaging hardware. Consumer USB enclosures can complicate matters by translating commands, hiding health data, or handling discard differently from the original controller path.

Do not run a new trim command while investigating an old deletion. It may discard every currently unused range, including the blocks you are hoping still contain recoverable data.

Check whether discard was likely to happen

On Linux, continuous discard can be configured as a mount option. Periodic discard is commonly performed by a systemd timer. The exact setup varies, so inspect the machine rather than guessing.

findmnt -no SOURCE,FSTYPE,OPTIONS /path/to/mountpoint
systemctl status fstrim.timer
journalctl -u fstrim.service --since "24 hours ago"
lsblk --discard

The first command shows filesystem mount options. The timer and journal indicate whether periodic trimming ran. lsblk --discard shows whether the device reports discard capabilities, but it does not prove that this particular file's blocks were trimmed.

Absence of a discard record is not proof of survival. A filesystem, hypervisor, RAID layer or SSD controller may have handled the operation somewhere else. Conversely, seeing a discard-capable device does not tell you when a deleted file's ranges were submitted.

What recovery software can and cannot do

Recovery tools work best when filesystem metadata or data blocks remain available. They may search directory structures, inode records, journals, allocation maps and file signatures. Their success depends on the filesystem and on how much information remains coherent.

• On ext4, journal and inode information can sometimes help, but journalling is not a backup of file contents.
• On XFS, metadata allocation and delayed work make simplistic undelete expectations unsafe.
• On copy-on-write filesystems such as Btrfs, snapshots and reflinks may preserve another reference to the data, but ordinary deletion does not guarantee a recoverable copy.
• On encrypted volumes, recovery still needs the encryption keys and a usable view of the filesystem or raw blocks.

File carving can recover recognisable formats without filenames or directory structure. It is useful for some photographs and documents, but fragmented files, compressed data and encrypted containers are much harder. A carved result with the right extension is not automatically a complete or authentic file.

Recovery software cannot negotiate with an SSD controller. If the logical blocks now read as zeroes or as unrelated data, a normal undelete tool cannot ask the drive to reveal an earlier mapping.

Snapshots and backups beat undelete

Before scanning raw flash, look for another legitimate copy. Filesystem snapshots, application exports, synchronisation targets, email attachments, build artefacts and backups often preserve more context than a recovery tool can reconstruct.

A snapshot is only useful if it existed before deletion and its blocks were not also discarded. Check the snapshot's retention and storage location. A snapshot on the same SSD may share the same physical blocks, while a backup on separate storage has a much better chance of being independent.

Do not forget copies created by applications. Editors may keep recovery files, databases may have write-ahead logs, and build systems may have cached the source. Those are not guaranteed, but searching them is usually safer than experimenting with the original disk.

What secure deletion has to do with this

TRIM is not a user-facing guarantee that a deleted file is unrecoverable at a particular moment. It helps an SSD manage unused flash, and it can make recovery less likely, but it is not a substitute for a documented sanitisation process.

For deliberate sanitisation, use the storage vendor's supported secure-erase or sanitize mechanism where appropriate, and consider the threat model. Full-disk encryption also changes the problem: destroying the relevant key can make old ciphertext impractical to use, although key handling and copies of the plaintext still matter.

NIST describes cryptographic erase as removing the keys used to protect stored data, rather than trying to overwrite every physical storage location. Whether that gives enough assurance depends on how the encryption was implemented and managed. It is a sanitisation decision, not a recovery trick.

The practical answer

If the file was deleted from a hard disk and the disk has seen little activity, recovery may be reasonably hopeful. If it was deleted from an SSD with active discard, the odds are unknowable until examination, and every write can reduce them.

So the rule is simple: stop writing, image first, investigate discard, and search for backups before attempting repair. If the file is valuable enough that guessing would hurt, stop experimenting with the original device. Flash storage is very good at hiding the evidence, and it does not provide a progress bar.