← All posts

Deleted Files on an SSD: What TRIM Changes, and What It Doesn't

September 2, 2026 · DiskRescue Blog

You deleted something you needed, or a folder went missing, and the first ten search results all say the same reassuring thing: the file isn't really gone, Windows only marked the space as free, so stop writing to the drive and run a recovery scan.

That accurately describes a mechanical hard drive. If the files were on an SSD — the drive inside nearly every laptop sold in the last several years — the sentence quietly stops being true, and following it costs you the only window you had.

Quick answer: Look in the Recycle Bin first, because a file sitting in it has not been deleted yet and no TRIM has gone out. Past that point, deleting a file on an SSD normally sends a TRIM command telling the controller those blocks are dead, after which most drives return zeros for those addresses regardless of what is still in the NAND. TRIM only fires when a file system deletes something, so a lost partition, a RAW volume, or a drive asking to be initialized leaves SSD data about as recoverable as on a hard drive. If a delete or a format was involved, cut the power first.

The standard advice describes a chain that SSDs break

On NTFS, deleting a file is bookkeeping. The Master File Table record gets flagged unused, the clusters return to the free pool, and the bytes go untouched. Recovery software rebuilds the file from that leftover structure, or carves it out of raw sectors by its header once the structure is gone. Both rest on one assumption: ask the drive for a sector, and it hands back whatever was last written there.

SSDs break that assumption deliberately. Deleting a file on an SSD also issues a TRIM command, called Deallocate on NVMe drives, naming the logical blocks that no longer hold anything valid. The controller marks them dead in its mapping table and erases them at its own convenience during background housekeeping.

Here is the part most guides get wrong. The damage isn't the erase. It's the map. Once a block is trimmed, most drives report that address as holding nothing and return zeros for it immediately, before a single cell has been wiped. The ATA command set names the behavior: Deterministic Read After Trim, which promises a consistent answer (in practice, zeros), and the stricter Deterministic Zeroes After Trim, which promises zeros outright. Most current SSDs, NVMe models especially, support at least the first, while older and cheaper SATA drives often leave it undefined. Your file can therefore sit physically intact on the flash chips and be unreachable by any program on your computer. Recovery software asks for logical blocks, and the controller has already decided the answer is zero.

Work out whether a delete notification reached your drive

"SSD or HDD" is the wrong question. The useful one is whether anything told this particular controller the blocks were free, which depends on whether the delete actually happened, and on how the drive is attached.

Start with the obvious one. If the file is still in the Recycle Bin, nothing has been deleted yet and no TRIM has been issued: restore it from there and stop reading. TRIM fires when the bin is emptied, or on a Shift+Delete. It is worth knowing which files skip the bin and take that treatment immediately, because the list is longer than most people expect: anything deleted from a USB stick or a memory card, anything on a network share, anything removed by an installer or a cleanup tool that deletes outright, and any file too large for the bin's size limit on that drive.

Check the file system before the hardware. Windows issues delete notifications on NTFS and ReFS. Most external drives and sticks ship formatted exFAT, where nothing is sent at all, and the storage vendors' own documentation says as much. Right-click the drive in Explorer, open Properties, and read the File system line. exFAT or FAT32 puts you back in classic hard-drive territory whatever the hardware underneath happens to be.

Internal SATA or NVMe SSD. Assume TRIM fired. Windows sends it by default on NTFS volumes, though not on an exFAT or FAT32 one.

External SSD in a USB enclosure. On an NTFS-formatted external SSD it comes down to the bridge chip. Over USB the command travels as SCSI UNMAP and has to survive translation inside the enclosure. Plenty of bridges drop it, and a UASP badge on the box is no assurance that UNMAP reaches the drive. For any particular enclosure you find out by scanning.

USB flash drive, SD or microSD card. These are flash too, yet the problem largely passes them by. Storage vendors' compatibility notes list TRIM support for sticks and memory cards as plainly no, so deletions there follow the classic hard-drive model, which is much of why card recoveries so often work.

One caution about the usual check. fsutil behavior query DisableDeleteNotify, in an elevated prompt, returns a line each for NTFS and ReFS, where 0 means delete notifications are permitted. That is an operating-system setting. It tells you Windows is willing to send TRIM; whether your drive received it, acted on it, and included the blocks holding your file are three further questions it says nothing about. Treat a 0 as grounds for lower expectations, then scan anyway.

Plenty of SSD losses never involved TRIM at all

TRIM is issued when a file system deletes a file, and its scope is that file's blocks. A whole category of disasters therefore leaves SSD data as intact as it would be on a spinning disk, because nothing was deleted at all:

• The partition vanished and the drive shows as unallocated
• The volume opens as RAW, or Windows offers to format it
• The disk asks to be initialized
• The file system was wrecked by a power cut or an unsafe unplug

In each of these the map was damaged, not the files. No delete notification ever went out, so the blocks are still mapped to their contents. Scan them.

Two cases run the other way.

Quick format. On a hard drive a quick format is famously survivable: it rewrites the file system metadata and leaves the data sitting behind it. On an SSD, Windows issues TRIM across the volume as part of the same operation, handing the lot to the controller as dead space. Never format an SSD to make it mountable and plan on recovering afterwards.

Windows.old. If the files vanished during a Windows upgrade, or a Reset that offered to keep your files, open C:\Windows.old\Users\ before running anything else. It is a plain copy of the previous installation's user folders, indifferent to everything above, and Windows deletes most of it automatically about ten days after the upgrade. The fix here is dragging a folder.

The first fifteen minutes

1. Cut the power now, before you read any further. Here hard-drive advice actively misleads. On an HDD a powered idle drive is a safe drive, while an SSD controller does its garbage collection precisely when it has power and nothing else to do. Forensic researchers documented this in 2010: once a volume had been quick-formatted, the drive went on purging the invalidated blocks by itself, with no further instruction from the host, and their paper describes such devices as operating "under their own volition, in the absence of computer instructions." Shut the machine down and read the rest on your phone. The urgency belongs to deletes and formats, where a notification has already gone out and background housekeeping has something to act on. A missing partition or a RAW volume marked nothing as free, so shut down anyway, but the clock there is not running the same way.

2. Don't install recovery software onto the affected drive, and don't recover onto it either. Install to a second drive, or pull the SSD and attach it to another machine.

3. Image first if the drive is misbehaving. Dropping off the bus, throwing read errors, going read-only by itself: each means every powered minute carries risk. DiskRescue's safe path reads the original once, sector by sector, into an image file on a healthy disk, then scans that copy. It guards against a drive that is deteriorating; a trimmed block still images as zeros.

4. Then scan read-only, using both methods. DiskRescue runs both. Parsing the NTFS records returns files with their original names and folder paths. Signature carving finds them by their raw headers when metadata is gone — it survives a destroyed file system, at the cost of generated file names.

And skip the maintenance that feels productive: Optimize Drives runs a retrim pass, chkdsk /f writes to the volume, and a secure erase does what its name says.

SSDs fail silently, and that isn't a software problem

A dying hard drive announces itself: clicking, grinding, a spin-up that never completes. SSDs offer none of that. They disappear from the BIOS mid-session, reappear with the wrong capacity or an odd model name, or fall permanently into read-only once the spare block pool runs out.

When a controller or its power circuitry dies, no scan reaches the flash, because nothing is translating addresses any more. That is lab work, and many modern SSDs encrypt everything with an internal key by default, so even chip-level recovery can return ciphertext. If the drive isn't detected at all, stop powering it and get a quote.

What the free trial settles in one scan

No article can tell you whether your particular blocks still return data. On an SSD that is the whole question.

The DiskRescue trial runs the full scan, read-only, without writing a byte to the source drive, and on an SSD the result doubles as a diagnosis. Read it in two parts. Deleted-file names are reconstructed from the MFT, which is why a file can still be listed with its size and its original folder path long after its contents stopped being readable. The signature-carving pass is the tell: a carve across trimmed space has no headers left to find, so a list that ought to run to hundreds of entries comes back with a handful. Where the loss was a partition, a RAW volume, or a corrupted file system, the same scan usually returns the tree with names and folders intact.

Then settle it by restoring. The trial restores 20 files at no cost, any size, no account, no social share, which is enough to pull the few that actually matter and open them. Files whose blocks were trimmed arrive at the right size and full of zeros. Anything that survived opens the way it always did.

The answer comes out of a scan. Run one from a second drive, read-only, before anything else touches the disk.

How DiskRescue Compares

On a lifetime license, DiskRescue costs about 1/5 what the big-name recovery suites below charge — paid once and used for life, with no auto-renewal.

Prices, features, and free-tier limits checked on each official site (Windows editions) on July 14, 2026 — they may change with sales or updates. The price comparison uses DiskRescue's launch price ($29.99). EaseUS free recovery is 500 MB by default, expanding to 2 GB after a social-media share (kb.easeus.com); Disk Drill's official free limit is 100 MB (cleverfiles.com).

Further reading

• "The Disk Is Write Protected" on Windows: Clear the Flag Without Losing Data
• Recover Files After a Windows Crash Without Making It Worse
• Handling Clicking Noises from Your External Hard Drive