Deleted files from an SSD: what TRIM changes.

Why SSD deletion is different

On a traditional hard disk, deleting a file usually removes or changes the records that point to its space. Until those magnetic sectors are overwritten, much of the old content may still be readable.

An SSD has another layer. Its controller translates the logical addresses seen by the computer into locations in flash memory. It moves data internally, spreads writes and erases flash in larger units. The operating system cannot infer which physical cells correspond to a deleted file.

TRIM exists to bridge that gap.

Microsoft describes TRIM as a hint that tells storage which ranges are no longer needed. NTFS can send that instruction during normal file deletion. It helps the SSD manage free space and future writes; it also changes the recovery problem.

Delete, TRIM and erase are three different events

It helps to separate the sequence:

1. Delete: the file system marks the file’s space as available and updates its metadata.
2. TRIM or deallocate: the operating system tells the storage device that the corresponding logical blocks are no longer required.
3. Internal handling: the SSD controller updates its maps and may erase or recycle flash later.

The confusion comes from treating all three as one instant physical erase.

A controller does not have to wipe every flash cell at the moment the user empties the Recycle Bin. Yet after deallocation, the old bytes may no longer be available through normal reads. For recovery purposes, “still somewhere in a NAND cell” is not the same as “addressable and reconstructable as the original file”.

The current NVM Express specification formalises this at the interface level. A deallocated logical block can be handled according to controller capabilities, including returning defined values or an error rather than the previous user data.

Why there is no honest universal percentage

The outcome depends on a chain of facts.

Did the operating system send the instruction?

Modern operating systems commonly support TRIM, but the exact behaviour depends on the file system, mount state, operation and configuration. A deletion that happened while the device was connected read-only is not the same as one performed normally on the active system disk.

Did the instruction reach the SSD?

Internal SATA and NVMe devices have a direct route. External USB bridges, older enclosures, RAID controllers, virtual disks and some adapters can change whether deallocation passes through.

This is why the make and model of the enclosure matter. It is also why removing an SSD from an external case before recording how it was connected can discard useful context.

What did the controller do with it?

Controllers differ. Firmware version, encryption, garbage collection, power state and flash translation behaviour all affect what remains accessible. The elapsed time alone cannot answer the question.

Was the file partly overwritten anyway?

The computer continues writing logs, browser data, updates, caches and temporary files. Installing recovery software onto the affected system is itself a write. Saving recovered files back to the same SSD can overwrite other candidates.

This ordinary activity is separate from TRIM and is a reason to stop even when deallocation behaviour is uncertain.

What you should do now

If the missing data is valuable:

1. Stop using the device.
2. Shut it down rather than leaving it at the login screen.
3. Do not run Windows “Optimize Drives”, a secure erase, reset or reinstall.
4. Do not install a recovery utility onto the affected SSD.
5. Record the device model, computer model, operating system and how the loss happened.
6. Check independent copies before paying for recovery.

Independent copies include cloud version history, email attachments, another computer, a camera card, a phone, a collaborator’s copy and an actual backup. Check the contents, not only whether the backup application reports success.

If the SSD is an external device, retain the enclosure, cable and power adapter. If it came from a NAS or RAID set, preserve every member and its slot order.

Can a laboratory bypass TRIM?

The precise answer is: sometimes a different access route exists for a supported device, but “bypass TRIM” is not a universal service.

Professional tools may communicate with a controller below the normal file-system layer. ACE Lab’s 2025 PC-3000 catalogue advertises TRIM-bypassing and deleted-file access for supported SSDs. The words for supported SSDs carry most of the meaning.

Success can depend on:

• the exact controller and firmware;
• whether the tool supports that family;
• whether the relevant flash pages still exist;
• how the controller maps or encrypts them;
• whether enough metadata survives to reconstruct the file;
• what happened after deletion.

This is why a reputable lab asks for the precise device and event history before offering a prognosis. A claim that every trimmed SSD is recoverable is not credible. A claim that every deleted SSD file vanished at the same instant is too broad.

Software scans can produce misleading hope

A scan may still list a filename after its content has become unavailable. Directory records and file data are different things.

You may see:

• the original name but a zero-byte file;
• a preview generated from a surviving thumbnail;
• a file with the correct size but unreadable content;
• a photograph reconstructed partly from cached data;
• old metadata that points to deallocated blocks.

Finding the name is not proof that the original file body survives.

Run self-service software only when the source is known to be healthy, you understand the write risk and the data is not valuable enough to justify preserving the original first. The safer professional pattern is to acquire the source to separate storage and analyse the copy.

TRIM is not secure sanitisation

Deletion and deallocation are designed for storage management, not as a complete policy for disposing of confidential media.

NIST SP 800-88 Revision 2 defines sanitisation as making access to target data infeasible for a stated level of effort. Organisations disposing of SSDs should follow an approved clear, purge or destroy process and verify its result. Emptying the Recycle Bin is not a sanitisation record.

That distinction works both ways:

• a deleted file is not guaranteed recoverable;
• a deleted file is not proof that the whole device was securely sanitised.

The most useful information for a diagnosis

Before contacting a laboratory, write down:

• SSD make, model and capacity;
• computer, NAS or enclosure model;
• Windows, macOS, Linux or another system;
• internal NVMe, internal SATA, USB, Thunderbolt or RAID connection;
• what was deleted, formatted, reset or reinstalled;
• whether the SSD stayed powered afterwards;
• every recovery tool or repair action already attempted;
• the folders or file types that matter most.

Those facts are more useful than the number of hours since deletion. They help distinguish a straightforward logical deletion, a likely deallocation case, a failed controller and a storage path where TRIM may not have passed through.

If this is the only copy, request an SSD data recovery diagnosis before experimenting. The answer may still be that the deleted ranges are no longer accessible. An early, evidence-based answer is better than losing the remaining possibilities to one more scan.