Skip to main contentSkip to navigation
Rossmann Repair Group logo - data recovery and MacBook repair
SSD Data Recovery

Can You Recover Data After TRIM? The Honest Answer

Quick Answer

If TRIM has been executed and garbage collection has physically erased the NAND cells, recovery is not possible. If the physical erase never happened (older BOT-protocol external USB SSDs, RAID 1/5/10 arrays, drives pulled before idle garbage collection ran), professional hardware and file-carving tools can still help.

If you deleted files from an SSD and your operating system sent a TRIM command, we have to be honest: in most cases, that data is gone. TRIM tells the SSD controller to logically unmap the data, scheduling the underlying NAND blocks for physical erasure by the background Garbage Collection process. Once erased, there is no residual data to recover. This is fundamentally different from HDD deletion, where data persists until physically overwritten. Any software that claims to recover TRIM-wiped SSD data is misleading you.

There are scenarios where TRIM has not run and recovery remains possible. This page explains which those are, why the dead-controller scenario is counterintuitive, and why the software industry has an incentive not to tell you this.

Louis Rossmann
Written by
Louis Rossmann
Founder & Chief Technician
Updated 2025-01-15

What TRIM Actually Does

When you delete a file on a TRIM-enabled SSD, the process runs in three stages. Understanding each stage explains why the outcome differs from deleting a file on a hard drive.

Stage 1: LBA Deallocation

The operating system notifies the SSD which logical block addresses (LBAs) held the deleted file. This is the TRIM command, defined in the ATA standard as the DATA SET MANAGEMENT command with the Trim attribute set. The controller receives a list of LBA ranges and marks them as no longer in use in the flash translation layer (FTL). At this point the data is still physically present in NAND, but the FTL considers those pages invalid.

Stage 2: Garbage Collection

SSDs cannot overwrite existing data in place. To write new data to a NAND block, the controller must first erase the entire block (typically 256KB to 4MB), then write. Garbage collection consolidates valid pages from partially-filled blocks, freeing entire blocks for erasure. TRIM-marked pages are flagged invalid and skipped during consolidation; they do not need to migrate to the new block before erasure.

Stage 3: Physical NAND Erase

When a NAND block contains only invalid pages, the controller issues an erase command to the flash chip. This sets every bit in the block to 1 (the erased state). The operation is irreversible. After erasure, the cells do not retain a weaker charge signature of the previous data. Unlike hard drives, where deleted data persists as magnetic flux until overwritten, erased NAND cells hold no recoverable information.

The key distinction from HDDs: On a hard drive, "deleted" means the directory entry is removed but the sectors still hold the original data until new writes physically overwrite them. On a TRIM-enabled SSD, the controller actively erases those cells during garbage collection. The data does not survive; it was intentionally destroyed by the drive as a write-performance optimization.

When TRIM Has Not Run: Your Data May Survive

Recovery is possible when TRIM either was never sent to the drive or when the garbage collection that would have physically erased the data did not yet complete. These are specific, identifiable scenarios.

External USB SSDs

Older USB-to-SATA and USB-to-NVMe bridge chips using the legacy Bulk-Only Transport (BOT) protocol do not pass the TRIM command. The OS issues TRIM to the bridge; the bridge discards it. The SSD never receives the erase instruction. Data deleted from a BOT-based external USB SSD may be recoverable with the same file-carving techniques used on hard drives. Note that modern UASP bridges do pass TRIM.

SanDisk Extreme recovery details →

RAID Arrays

While modern controllers often pass TRIM commands to RAID 0 arrays, hardware and software RAID controllers typically block TRIM for parity (RAID 5) or mirrored (RAID 1/10) volumes. An SSD in a RAID 1, 5, or 10 array receives no TRIM commands regardless of OS settings. Deleted data on these RAID-member SSDs has the same recovery probability as HDDs in the same configuration.

Drive Pulled Before Idle GC

TRIM marks data as invalid, but garbage collection runs later, often during idle periods. If the drive was powered down immediately after deletion, or never had an opportunity to run GC, the NAND cells may still hold the original data. The window between TRIM issuance and physical erasure varies by drive and workload.

TRIM Disabled in OS

On Windows, TRIM can be disabled via fsutil behavior set disabledeletenotify 1. On Linux, some configurations mount file systems without the discard flag and skip periodic fstrim runs. If TRIM was not active, the drive never received the erase instruction.

Dead Controller: TRIM Never Ran

This is the counterintuitive scenario. When an SSD controller fails completely, it loses the ability to execute TRIM or garbage collection. Any data scheduled for erasure but not yet physically erased remains intact on the NAND.

Consider the sequence: you delete files, the OS issues a TRIM command, the controller marks those LBA ranges as invalid in the FTL, and then the controller fails (firmware corruption, power surge, controller chip failure) before it runs garbage collection on those blocks. The NAND cells still hold the original data. The controller can no longer read or erase them through normal operation, but the data is physically present.

The recovery path: The PC-3000 SSD utility can bypass a failed controller and access raw NAND directly, or reload controller firmware to restore FTL access without triggering garbage collection. Data flagged by TRIM but not yet erased can often be imaged and returned. This is not possible with any consumer software.

The practical implication: if your SSD failed and you had recently deleted files you now need back, the failure may have inadvertently preserved them. A working SSD with TRIM enabled would have erased those files during its next garbage collection cycle. A dead SSD cannot execute that erase.

How Wear-Leveling Complicates Data Recovery

Wear-leveling is a third background process running on every SSD alongside TRIM and garbage collection. The controller continuously redistributes data across the NAND array to prevent any single block from being erased more often than its neighbors. Without wear-leveling, blocks holding frequently updated data (OS swap files, database journals) would reach their endurance limit and fail while the rest of the drive remained healthy.

This has a direct consequence for data recovery: a file's logical address in the file system does not correspond to its physical location on the NAND. The controller's flash translation layer (FTL) maintains the mapping between logical and physical locations. When reconstructing data from raw NAND in a chip-off scenario on an unencrypted drive, the wear-leveling map must be reversed. Without the controller's FTL, the data appears scrambled across the array with no obvious ordering.

For controller-based recovery using PC-3000, wear-leveling is transparent. The controller handles the logical-to-physical mapping internally. Recovery tools communicate through the controller, which resolves wear-leveling automatically. The problem arises only when the controller is dead and chip-off is the only option.

How Different Operating Systems Handle TRIM

TRIM behavior varies by operating system and file system. Some combinations issue TRIM immediately on deletion; others batch it or skip it entirely. This determines the recovery window after file deletion.

OSFile SystemTRIM BehaviorRecovery Impact
Windows 10/11NTFSImmediate, automatic, aggressiveNear-zero recovery window after deletion
Windows 10/11exFATSupported but less aggressiveNarrow recovery window may exist
macOSAPFSImmediate, automaticNear-zero recovery window after deletion
macOSHFS+ (external)TRIM not issued on external drives by defaultRecovery often possible
Linuxext4Depends on mount option (discard or fstrim)Varies; check mount configuration
Any OSFAT32TRIM support varies by OS and driverRecovery more likely than NTFS/APFS

Why Software Vendors Lie About This

Software companies need you to buy their product. A marketing page that says "TRIM-erased data is permanently gone and our software cannot help" does not drive sales. So the messaging is carefully worded to imply recovery is possible without confirming it.

The claim "recover deleted files from SSD" is technically true in edge cases: legacy BOT-based external USB SSDs without TRIM passthrough or SSDs with TRIM disabled. The software can recover files in those scenarios. However, if a drive has received a TRIM command but not yet completed garbage collection, standard software cannot recover files because Deterministic Read Zero After TRIM (DZAT) instantly feeds zeros to the OS. The problem is that the disclaimers are buried or absent, and the same interface is shown to users with TRIM-wiped drives as to users with actually recoverable drives. The software scans, finds nothing, and you paid for it anyway.

Data recovery software operates at the file system layer using standard OS APIs. Because of DZAT, the SSD controller synthesizes and returns zeros for unmapped LBAs instantly, even before the cells are physically erased. Disk Drill, Recuva, R-Studio: all hit this same firmware mask. None of them can interrogate raw NAND below the block device abstraction to bypass it.

If a software product claims to recover TRIM-erased SSD data: either the drive had TRIM disabled or lacked TRIM passthrough (edge cases where free tools would also work), or the claim is false. Free tools cannot recover data from incomplete garbage collection due to DZAT. NAND cells after a physical erase command hold no data.

Frequently Asked Questions

Can data be recovered after TRIM?

Usually not. TRIM tells the SSD controller to logically unmap deleted files and schedule them for physical erasure by Garbage Collection. Once physically erased, those cells contain no residual data. The exception is when physical erasure never happened: older BOT-based external USB SSDs often do not receive TRIM commands, drives pulled immediately after deletion may not have completed garbage collection, and a controller that failed before issuing the erase left the NAND physically intact. In those cases, professional tools like PC-3000 can sometimes recover data.

Does Disk Drill work on a TRIMmed SSD?

No. Once a TRIM command is issued, the SSD uses Deterministic Read Zero After TRIM (DZAT) to guarantee standard OS reads return zeros, even before physical erasure occurs. Disk Drill and similar tools rely on these standard APIs. Because of DZAT, those sectors return zeros instantly. There is nothing for the software to find.

Does wear-leveling affect data recovery?

Wear-leveling redistributes data across the NAND array to prevent cell exhaustion. For controller-based recovery using PC-3000, wear-leveling is transparent because the controller resolves the logical-to-physical mapping internally. For chip-off recovery on unencrypted drives, the wear-leveling map must be reverse-engineered from raw NAND dumps, adding reconstruction complexity.

Deleted files from an SSD?

We evaluate whether TRIM ran and whether recovery is possible. Free assessment, no obligation.