How TRIM Affects SSD Data Recovery

TRIM is an ATA command (DATA SET MANAGEMENT for SATA, DEALLOCATE for NVMe) that the operating system sends to the SSD controller when files are deleted. It identifies which logical block addresses no longer contain valid data so the controller can erase the underlying NAND cells during idle time.

TRIM (ATA Data Set Management)

The SATA protocol command that tells the SSD controller which LBAs are no longer in use. Supported on all modern SATA SSDs and enabled by default in Windows 7+, macOS 10.10.4+, and Linux kernel 2.6.33+.

UNMAP (SCSI/NVMe Deallocate)

The equivalent command for NVMe and SCSI-attached SSDs. Functionally identical to TRIM: it notifies the controller that specific blocks can be erased. NVMe Deallocate is part of the Dataset Management command set.

Garbage Collection (GC)

The controller's internal background process that physically erases NAND blocks marked as invalid by TRIM. GC consolidates valid pages into clean blocks and erases the stale ones. This is the step that actually destroys data; TRIM only marks it for destruction.

DisableDeleteNotify

The Windows registry flag that controls whether the OS sends TRIM commands to the drive. Setting DisableDeleteNotify = 1 via fsutil prevents the OS from issuing TRIM, preserving deleted data on the NAND until the blocks are overwritten by new writes.

SSDs need TRIM because of how NAND flash works. Unlike magnetic hard drives, an SSD cannot overwrite a cell in place. It must erase an entire block (typically 256KB to 4MB) before writing new data to any page within that block. Without TRIM, the controller does not know which pages contain deleted data, so it must read-modify-write entire blocks when new data arrives. TRIM lets the controller pre-erase blocks during idle time, which maintains write performance over the life of the drive.

TRIM and garbage collection are separate operations. TRIM marks blocks as invalid; GC erases them. If anything interrupts that sequence, the data may survive on the NAND.

1. 01

   Power loss before garbage collection

   If the SSD loses power after TRIM was issued but before GC erased the blocks, the data is physically intact. The controller marked the blocks as stale in its FTL, but the NAND cells still hold the original charge states. PC-3000 can read raw NAND pages and recover data from blocks that the controller considers invalid.

2. 02

   Firmware failure freezing the controller

   When SSD firmware corrupts, the controller stops processing commands, including garbage collection. A drive stuck in firmware safe mode (SATAFIRM S11, BSY state, or 0 bytes capacity) has not run GC since the failure. TRIMmed blocks that the OS deleted before the firmware crashed may still contain data.

3. 03

   USB enclosures blocking TRIM passthrough

   Many older USB-to-SATA bridge chips (such as the JMicron JMS539 or early ASMedia ASM1051) do not pass TRIM commands through to the drive. If the SSD was used in an external enclosure that blocks TRIM, deleted files remain on the NAND indefinitely. The controller never received the invalidation command, and standard recovery tools may work in this scenario.

4. 04

   TRIM disabled in the operating system

   If DisableDeleteNotify was set to 1 on Windows, or the discard mount option was not enabled on Linux, TRIM was never sent. Deleted data persists on the NAND until the controller overwrites those blocks with new data during normal write operations.

Disabling TRIM prevents the OS from telling the SSD to erase deleted blocks. This preserves deleted data on the NAND until the controller reuses those blocks for new writes. Disable TRIM before deleting files if you anticipate needing recovery later.

1. Open an elevated Command Prompt or Terminal (right-click Start, select "Terminal (Admin)").
2. Check current TRIM status: fsutil behavior query DisableDeleteNotify
3. If DisableDeleteNotify = 0, TRIM is enabled. Disable it: fsutil behavior set DisableDeleteNotify 1
4. For NVMe drives, also run: fsutil behavior set DisableDeleteNotify NTFS 1
5. Verify: fsutil behavior query DisableDeleteNotify should now show 1.

On macOS, TRIM is enabled by default for Apple-branded SSDs and can be enabled for third-party drives via trimforce enable. There is no supported method to disable TRIM on macOS without disabling SIP. On Linux, TRIM runs only if the file system is mounted with the discard option or if fstrim is scheduled via cron/systemd timer.

The SSD controller doesn't erase NAND cells the instant it receives a TRIM command. TRIM updates the FTL mapping table & adds affected blocks to a garbage collection queue. The controller's firmware scheduler decides when to physically erase those blocks based on idle time, free block availability, & SLC cache pressure.

Background GC vs. Foreground GC

Background garbage collection runs during idle periods when the host isn't sending I/O commands. The controller picks stale blocks, moves valid pages to clean blocks, & erases the originals. This is the normal mode: quiet, deferred, & often delayed by seconds to hours depending on workload.

Foreground GC is different. It triggers when the controller's free block pool drops below a firmware-defined threshold. The controller must reclaim blocks immediately to satisfy incoming writes, and it does so on the critical I/O path. This is the performance cliff users notice when an SSD slows down during large file copies. For recovery, foreground GC is worse: it erases TRIMmed blocks immediately because the controller needs that NAND space right now. SATA SSD firmware recovery runs $600–$900.

SLC Cache Exhaustion & Forced Migration

Most consumer SSDs use pseudo-SLC (pSLC) caching: the controller writes incoming data to TLC or QLC cells in SLC mode (1 bit per cell) for speed, then migrates that data to full TLC/QLC density during idle time. A 1TB QLC SSD might have 12-48GB of pSLC cache. When sustained writes fill that cache, the controller must flush pSLC pages to their native TLC/QLC format.

This flush operation triggers aggressive garbage collection. The controller needs free TLC/QLC blocks to receive the migrated data, so it erases every stale block it can find, including TRIMmed blocks that might still contain recoverable data. A nearly full SSD under heavy writes can erase TRIMmed blocks within seconds of the pSLC cache filling. A half-empty SSD with a Phison PS5012-E12 controller and plenty of free blocks might defer that erasure for hours.

Over-Provisioning & Free Block Reserves

Over-provisioning (OP) is the portion of physical NAND reserved for controller operations beyond the user-addressable namespace. Consumer SSDs typically ship with roughly 7% factory OP (for example, 512 GiB of raw NAND exposed as a 500 GB / ~465 GiB namespace). Enterprise drives ship with 28% or more. The base-10 vs base-2 capacity difference (1 TB marketed = ~931 GiB reported by Windows) is a unit conversion artifact, not OP. More OP means a larger free block pool, which means the controller has less urgency to run GC on TRIMmed blocks.

Drive fill level matters too. A nearly full consumer SSD leaves the controller with a small free-block pool, so it runs GC aggressively to maintain write performance. The same drive at half capacity has a much larger pool of available blocks. GC pressure is low, TRIMmed blocks sit in the queue longer, & the recovery window extends from minutes to hours.

Background GC

Runs during idle time. Erases stale blocks at the controller's leisure. Deferred by seconds (Samsung) to hours (Silicon Motion on lightly used drives). The recovery window depends on how quickly the SSD reaches idle after TRIM.

Foreground GC

Triggers when free blocks drop below firmware threshold. Runs on the I/O critical path. Erases TRIMmed blocks immediately. The performance cliff (write speeds dropping from 500MB/s to 50MB/s on SATA) is the observable symptom.

pSLC Cache Flush

When the pseudo-SLC write cache fills (typically 12-48GB on a 1TB QLC SSD), the controller migrates cached pages to TLC/QLC blocks. This migration triggers block erasure to free space, which can include TRIMmed blocks that still held recoverable data.

NVMe APST & Garbage Collection Scheduling

NVMe drives support Autonomous Power State Transition (APST), which lets the host OS dictate how quickly the drive enters low-power states during idle. NVMe drives define multiple power states: PS0 (active, ~8W) down to PS3 or PS4 (deep sleep, ~0.009W). When the drive enters a non-operational power state, the NVMe specification allows it to temporarily exceed that state's power limit for background processing, including garbage collection.

NOPPME (Non-Operational Power State Permissive Mode Enable) controls this behavior. If NOPPME is disabled, the drive must respect the strict power limit of the current sleep state & defer GC until the host wakes it back to an operational state. On a laptop that pushes the NVMe drive into PS4 deep sleep within 100ms of idle, the drive can't run GC because the power budget is too low. This inadvertently extends the recovery window: the drive goes to sleep before the controller has time to erase TRIMmed blocks.

Enterprise & data center NVMe SSDs disable APST entirely (0ms transition latency). The drive stays in PS0 at full power, ready for the next I/O command with zero latency. That means the controller runs GC without any power-state constraints, erasing TRIMmed blocks as soon as idle time appears. Consumer NVMe drives with aggressive host-configured APST profiles can preserve TRIMmed data longer if the system transitions the drive into non-operational states before GC completes. NVMe SSD firmware recovery runs $900–$1,200.

APST (Autonomous Power State Transition)

NVMe power management feature that transitions the drive between power states based on idle time. Each state has defined entry/exit latencies & power limits. PS0 is full active; PS3/PS4 are deep sleep. The host OS configures APST thresholds via the NVMe Set Features command.

NOPPME (Non-Operational Power State Permissive Mode Enable)

NVMe controller feature bit. When enabled, the controller can temporarily exceed a non-operational power state's power limit for background maintenance (GC, wear leveling). When disabled, GC is blocked until the host transitions the drive back to an operational power state.

DRAT, DZAT, & NVMe DLFEAT define what the SSD controller returns when software reads a TRIMmed LBA. Modern SSDs enforce deterministic behavior: they intercept host reads to TRIMmed addresses & return zeros, even if the physical NAND cells haven't been erased yet. PC-3000 SSD bypasses this by entering vendor-specific diagnostic mode to read raw NAND pages directly.

Older budget SATA SSDs used non-deterministic TRIM. The controller returned unpredictable data for TRIMmed LBAs: sometimes the original data, sometimes zeros, sometimes garbage from a different page. This inconsistency occasionally allowed recovery software to read surviving data before GC ran. Non-deterministic TRIM appeared on early SM2246EN & JMicron JMF670H controllers and is rare in drives manufactured after 2016.

Current drives enforce DRAT at minimum. DRAT is identified by SATA Word 69, Bit 14 in the drive's IDENTIFY DEVICE response. DZAT (Bit 5 of the same word) is stricter & required for RAID-capable enterprise SATA SSDs because array controllers need consistent parity calculations across members. A DZAT drive returns the same value for every read to every TRIMmed LBA: absolute zeros, no exceptions.

The practical result: on any SSD manufactured after 2016, recovery software sees only zeros or a fixed pattern for deleted blocks. Disk Drill, R-Studio, & PhotoRec all read through the host interface. The controller intercepts their read commands & returns deterministic data instead of what's physically stored on the NAND. The original charge states may still exist in the floating gate transistors, but the controller's protocol layer refuses to expose them.

PC-3000 SSD bypasses this protocol layer entirely. In vendor-specific diagnostic mode, the tool sends raw NAND page read commands that skip the controller's LBA translation & deterministic-zero interception logic. If GC hasn't physically erased the cells, the original page data is readable at the hardware level. Firmware recovery for SATA SSDs runs $600–$900; NVMe runs $900–$1,200.

DRAT (Deterministic Read After TRIM)

SATA specification behavior (Word 69, Bit 14). The controller returns a single, consistent value for all host reads to TRIMmed LBAs. The specific value varies by implementation but is always the same for every TRIMmed block on that drive.

DZAT (Deterministic Zeroes After TRIM)

SATA specification behavior (Word 69, Bit 5). Stricter than DRAT: the controller returns absolute zeros for any TRIMmed LBA. Required for enterprise RAID arrays where parity calculations depend on consistent zero-fill across degraded members.

DLFEAT (Deallocate Logical Block Features)

NVMe Identify Namespace byte 33, bits 2:0. 001b means reads to deallocated (TRIMmed) LBAs return all 00h bytes (the NVMe equivalent of SATA DZAT). 010b means reads return all FFh bytes. 000b means the behavior is not reported. Modern NVMe controllers (Samsung Elpis, Phison PS5018-E18, Silicon Motion SM2264) enforce one of the deterministic encodings, typically 001b.

PC-3000 SSD puts the controller into a vendor-specific diagnostic mode before the firmware's garbage collection routine initializes. In diagnostic mode, the controller accepts raw NAND read commands without executing any background operations. TRIMmed blocks that haven't been erased yet are readable at the physical page level.

Why Normal Power-On Destroys TRIM-Pending Data

Powering a TRIMmed SSD normally is the single worst thing you can do. The controller boots its firmware, checks the FTL for pending operations, & resumes garbage collection on every block marked as invalid. Aggressive Samsung firmware can erase significant portions of stale blocks in the seconds following power-on. By the time the drive appears in BIOS, the data may already be gone.

This is why consumer recovery software can't help with TRIM scenarios even if the NAND cells still hold data. Connecting the drive to your computer boots the controller normally, which triggers GC before any software can intervene. SATA SSD firmware recovery runs $600–$900; NVMe runs $900–$1,200.

Vendor-Specific Diagnostic Mode Entry

Each controller family has a different procedure for entering diagnostic mode. PC-3000 SSD includes dedicated utilities for Samsung, Phison, & Silicon Motion controllers. The utility sends a vendor-specific command sequence over the SATA or NVMe interface that forces the controller into a low-level service mode. In this mode, the firmware's background task scheduler is disabled.

GC does not run. TRIM queues are not processed. The controller accepts direct NAND page read commands & returns raw cell data without filtering through the FTL's validity markings. Pages that TRIM marked as "invalid" still contain their original charge states because the erase operation never executed.

Raw NAND Page Reading & FTL Reconstruction

Once in diagnostic mode, PC-3000 reads physical NAND pages directly. This bypasses the controller's LBA-to-PBA mapping. The tool reads every page in every block, including blocks the controller considers invalid. Each page contains the original data plus ECC (error correction code) metadata that the tool uses to verify data integrity.

After the raw read, PC-3000 reconstructs the Flash Translation Layer mapping table to reassemble files from the physical page data. The FTL maps logical block addresses to physical NAND pages. Without this reconstruction, the raw page dump is just a stream of unordered 4KB-16KB fragments. The PC-3000's controller-specific algorithms know each family's FTL structure & can rebuild the mapping even when the controller's own FTL copy is corrupted or incomplete.

For encrypted SSDs (most NVMe drives & SATA drives with TCG Opal), the raw NAND pages are AES-256 ciphertext. Reading them without the controller's decryption key produces unreadable data. In those cases, the only path is reviving the original controller through board-level repair so it can decrypt the NAND contents with its own key material. Chip-off NAND extraction on an encrypted SSD yields only ciphertext.

A graceful OS shutdown (Start > Shut Down) takes 10-30 seconds while flushing caches, closing processes, & writing final log entries. The SSD stays fully powered during this window. The controller uses every microsecond of idle time to run garbage collection on TRIMmed blocks. Pulling the power cable is the only response that stops GC before it erases your data.

Windows shutdown writes to the registry hive, flushes NTFS journal entries, & signals each running service to stop. macOS writes to the Unified Log & flushes APFS metadata. These write bursts are separated by micro-idle gaps while the OS waits for services to acknowledge the shutdown signal. Aggressive Samsung firmware reclaims stale blocks during those idle gaps. A normal 10-30 second shutdown provides ample background time for the controller to irreversibly erase significant portions of TRIMmed data.

Immediate Power Isolation Procedure

On a desktop: hold the power button for 5 seconds or pull the ATX power cable from the back of the PSU. On a laptop: hold power for 5 seconds, then disconnect the battery if it's removable. For an NVMe M.2 drive: shut down via forced power-off, then physically remove the M.2 drive from the motherboard before shipping. For a SATA SSD: disconnect both the SATA data cable & SATA power connector.

Removing power deprives the controller of the ~20V erase voltage it needs to apply Fowler-Nordheim tunneling pulses to the NAND floating gates. Without that voltage, the controller can't erase a single cell. The drive freezes in its current state. Ship it to our Austin, TX lab without reconnecting it to any system. SATA SSD evaluation is free; recovery starts at $200. NVMe recovery starts at $200.

Enterprise SSDs & Power Loss Protection

Enterprise SSDs include PLP (Power Loss Protection) capacitors on the PCB. These tantalum or ceramic capacitors store enough charge to keep the controller alive for 20-50ms after external power disappears. That's enough time for the controller to flush its DRAM write cache & complete any in-progress page writes to the NAND.

PLP is good for data integrity during unexpected power outages. It's bad for TRIM recovery. When you pull the power cable from an enterprise Samsung PM9A3 or Intel DC P4610, the PLP capacitors keep the controller running long enough to process pending TRIM queue entries & erase stale blocks. Consumer SSDs like the Samsung 870 EVO or WD Blue SN580 lack PLP capacitors. Pulling the cable cuts power instantly, which can leave TRIMmed blocks intact because the controller lost its erase voltage mid-operation.

The over-provisioned (OP) area holds physical NAND blocks that the controller keeps outside the user-addressable LBA range. These blocks serve garbage collection, wear leveling, and bad-block replacement. After a TRIM command, stale copies of deleted pages can end up inside the OP pool if the wear-leveling routine migrated them before erase. The pages remain readable through direct NAND access until the controller selects those OP blocks for its next erase cycle.

Factory OP, Dynamic OP, & User OP

Consumer SATA and NVMe SSDs typically ship with roughly 7% factory OP, often derived from the binary-to-decimal capacity difference (for example, 512 GiB of raw NAND exposed as a 500 GB / ~465 GiB LBA namespace). Enterprise drives ship with 28% or more, reserved to sustain steady-state random write performance under constant garbage collection pressure. Dynamic OP expands the pool whenever free-block counts fall below the controller threshold, temporarily borrowing user-addressable blocks. User OP is the portion the administrator leaves unpartitioned; the controller treats unmapped LBAs as extra free blocks.

Wear-Leveling Migration of Stale Pages

Before a block is erased, the controller copies its valid pages to a new free block so the original can be released. Static wear leveling extends this behavior to rarely-updated data: the controller periodically moves cold pages into blocks with higher erase counts to equalize wear. When TRIM marks pages invalid shortly after a wear-leveling migration, the original source block may sit in the OP pool with its contents intact until the block allocator reaches it. A page that was logically deleted from the user LBA space can therefore persist physically inside the OP area for minutes to hours, depending on write pressure and block allocation order.

Chip-Off NAND Reachability of OP Blocks

The OP area is a controller-firmware abstraction. At the NAND die level, every block carries the same physical address regardless of whether the FTL maps it into user LBA space or reserves it for OP. Powering a NAND die on an external programmer after chip-off extraction exposes every physical page, including pages the controller considered OP reserve. The FTL metadata is needed to reassemble logical files, and on self-encrypting drives the raw pages are AES-256 ciphertext that cannot be decrypted without the controller's key material.

Conditions Under Which OP Survivability Matters

OP-area survivability is load-bearing only when the drive is isolated from power before the controller completes its queued erases. Immediate power disconnection after deletion halts GC mid-sequence and freezes the OP pool in whatever state the controller left it. Firmware failure that hangs the GC scheduler produces the same freeze. Queued TRIM commands that the host sent but the controller never acknowledged (for example, pending DSM operations in the SATA NCQ queue at the moment of a hard power cut on a consumer SSD without PLP) leave the FTL in an intermediate state where the affected ranges have not yet been flagged invalid. Enterprise drives with Power Loss Protection capacitors flush pending TRIMs during an outage, which is good for data integrity and bad for recovery. Any recovery path that depends on OP survival requires the drive to arrive at the lab without a second power-on.