SSD Data Recovery Software
vs. TRIM & Garbage Collection

TRIM is a logical command, not a physical erase. The host operating system issues it (ATA DATA SET MANAGEMENT with the TRIM bit, or NVMe Dataset Management with the Deallocate attribute), & the SSD controller only executes the unmap. The SSD never “decides” to TRIM; the OS tells it which LBAs are dead.

When you delete a file, empty the recycle bin, or format the volume, the filesystem tells the controller those LBA ranges are free. The controller removes them from its flash translation layer, the map that turns a logical sector into a physical NAND address. From that moment the drive treats the block as invalid.

Here is the part that trips people up. The NAND cells are not wiped at TRIM time. An erase resets a whole physical block with a high-voltage tunneling cycle, & that is expensive, so the controller defers it to background garbage collection on its own schedule. The original charge sits in the cells until that runs.

So the data is physically present but logically unreachable. On a drive that advertises RZAT (Read Zero After TRIM), the firmware intercepts any read of an unmapped LBA & synthesizes deterministic zeros, even though the cell still holds the old value. Garbage collection then erases the block later & the data is gone for good. Either way, the drive stops handing it back over its own interface.

Every “deep scan” recovery tool lives above the controller, not below it. Disk Drill, EaseUS, R-Studio, & PhotoRec run in the OS abstraction layer & send standard logical reads through the storage driver. A host read doesn’t query a NAND cell; it queries the controller’s FTL. Whatever the controller answers is what the software sees.

That is the whole problem. The software has no path to vendor-specific commands, no access to raw NAND pages, & no way to reconstruct a corrupted FTL. If the controller enforces RZAT on an unmapped LBA, it returns synthesized zeros, & the deepest scan in the world reads zeros. The marketing promise of pulling deleted files “straight off the chips” describes a thing consumer software structurally cannot do.

Read the wider software vs professional service comparison for how this same controller-abstraction limit plays out on hard drives, RAID arrays, & other media. The pattern repeats: software parses what the device hands it; hardware reaches the layer the device won’t expose.

These are capable tools, & on the right job they are the right answer. The line is simple: software works when the drive is physically healthy, enumerates cleanly to the OS, & the target data has not been TRIM-unmapped yet.

That covers real cases. You deleted files & pulled power or unplugged the drive before the controller processed the queued TRIM. You lost a partition table or a filesystem to corruption while the file data itself is still mapped. You’re working with an external SSD in an enclosure that never passed the unmap through. In those situations a logical scan reassembles the filesystem & pulls the files, & you don’t need a lab.

If that’s your situation, use the software first. It’s far cheaper than any recovery service, & most of these vendors give honest guidance about connecting the drive read-only & not writing to it. We’ll tell you the same thing on the phone, & we’ll tell you when your case is the logical-loss kind that doesn’t need us at all.

“Post-TRIM recovery is impossible” is true for a modern drive enforcing RZAT over a standard interface. It is not true in a few specific physical cases, & an honest page names them instead of pretending they don’t exist.

First, the TRIM never actually reached the drive. A non-UASP USB-to-SATA bridge silently drops the SCSI UNMAP command, so the controller never unmapped anything & the data is still mapped in the FTL. External SSDs in cheap enclosures fall into this more often than people expect.

Second, older drives don’t all enforce deterministic zeros. Pre-2015 SSDs that report non-deterministic or DRAT behavior instead of RZAT can still leak the stale block on a read after TRIM. That window closed on newer hardware, but old drives are still out there.

Third, the drive was powered down immediately & reaches a lab before garbage collection erases the block. Because the cells hold charge until that background erase runs, we can force the controller into a diagnostic mode with the PC-3000 SSD, halt garbage collection, & read the raw NAND pages that still carry the stale data. This is time-sensitive & rare, not a routine service. If the machine kept running for hours or days, the block is almost certainly already reclaimed.

Don’t confuse a TRIM’d file with a dead drive. They’re opposite problems. A TRIM’d file is gone because the controller unmapped it. A panicked controller still has your data fully mapped; it just can’t boot its own translator to serve it. That second case is one a lab recovers routinely.

The symptoms are specific. The drive reports 0 bytes, hangs the bus in a BSY state, or enumerates as a factory alias string. A Phison PS3111-S11 that fails to validate its service area drops onto the SATA bus as “SATAFIRM S11” at zero capacity. Consumer drives without power-loss protection hit this after an outage interrupts a map write & corrupts the FTL, so the controller can’t tell which metadata copy is authoritative & locks itself into a safe mode.

Recovery here is not a firmware flash. We short the correct diagnostic pins to boot a factory ROM state past the corrupted service area, use the PC-3000 SSD to inject a matched volatile microcode loader into the controller’s SRAM, & rebuild a virtual translator in workstation RAM from the raw NAND metadata. The controller then serves clean logical sectors for imaging. If the board itself is damaged, that’s microsoldering at the Hakko FM-2032 & Atten 862 stations with FLIR thermal cameras to localize a shorted rail before the drive will even power up.

One warning. The manufacturer’s factory tools (MPTool & the like) reinitialize the FTL & overwrite the service area by design, which permanently destroys the user data. They’re production tools, not recovery tools. If your drive is stuck at 0 bytes, don’t reflash it; send it in. Full detail on both problems lives on the SATA SSD recovery service &, for M.2 drives, the NVMe SSD recovery service.

If you deleted files off a healthy internal SSD & the machine has been running since, the honest answer is usually no, & no lab changes that. Once TRIM & garbage collection have done their work, the data is physically reclaimed. Any company promising a guaranteed post-TRIM deleted-file recovery on a modern drive is selling you the impossible.

So the decision is quick. TRIM’d deleted file on a drive that kept running: skip the software, skip the lab, you’re past the point either helps. Logical loss on a healthy SSD that stopped early: try the software first. Drive dead, wrong capacity, or not detected: that’s a lab job, & it’s the case where we do our best work.

When it is a lab job, our terms are published. SATA SSD recovery runs $200–$1,500 across five tiers; NVMe runs $200–$2,500. Diagnosis is free, there’s no diagnostic fee, & if we can’t recover your data you don’t pay, which is what no data, no recovery fee means in writing. We do every step in-house at one location in Austin, TX. Single location, founded in 2008, no franchises, no outsourcing.

Frequently Asked Questions