What Happens to SSD Data After You Delete a File?
Deleting a file on an SSD triggers a three-step chain. The operating system removes the file from its directory, sends a TRIM command to the SSD controller, and the controller queues those blocks for garbage collection. Each step moves the data closer to permanent destruction.
- OS deletion. The file system (NTFS, APFS, ext4) removes the file's directory entry. The file's logical block addresses are marked as free in the file system metadata. At this point, the data still exists on the NAND.
- TRIM command sent. The OS sends a TRIM command (DATA SET MANAGEMENT for SATA, DEALLOCATE for NVMe) to the SSD controller. This tells the controller which logical addresses no longer contain valid data. TRIM does not erase anything; it informs the controller that it can erase those blocks when ready.
- Garbage collection erases the NAND. The controller's background process reads valid pages out of mixed blocks, copies them to clean blocks, and applies an erase voltage to the old blocks. The erase voltage resets every cell in the block to its unprogrammed state. The data is physically gone.
The gap between step 2 and step 3 is the only recovery window. If the drive loses power, suffers a firmware crash, or stays busy with other I/O before GC runs, the data may survive on the physical NAND. Once GC applies the erase voltage, no recovery method exists.
Why Can't Any Lab Recover Physically Erased NAND?
NAND flash stores data as electrical charges trapped in floating gate transistors. Each cell holds a specific charge level that represents one or more bits. When garbage collection erases a block, it applies a high voltage (15-20V) that drains every floating gate in the block through Fowler-Nordheim tunneling. The charge that represented your data no longer exists.
This is different from a hard drive. On a magnetic hard drive, deleting a file only removes the directory pointer. The magnetic orientation on the platter stays until new data writes over the same physical location. The data waits to be overwritten. On an SSD, the controller actively hunts for stale blocks and erases them in the background.
An erased NAND cell reads as 0xFF (for SLC) or the lowest threshold voltage state (for TLC/QLC). There is no residual charge pattern, no magnetic remnant, no partial signal to reconstruct. The physics are binary: either the floating gate holds a charge or it doesn't. After the erase voltage, it doesn't. Any company that claims to recover data from physically erased NAND cells is charging you for work that is physically impossible.
Why Does Recovery Software Show All Zeroes on Your SSD?
Modern SSDs implement DZAT (Deterministic Read Zero After TRIM). After the controller processes a TRIM command, it returns all zeroes for any read to those addresses, even if the physical NAND cells still hold the original data. Recovery software reads through the controller's standard interface, receives zeroes, and reports the files as unrecoverable.
- DZAT (Deterministic Read Zero After TRIM)
- SATA specification behavior. The controller intercepts all read commands to TRIMmed logical block addresses and returns a payload of all zeroes. Enforced at the firmware level before the read reaches the physical NAND. Most modern SATA SSDs implement DZAT.
- DLFEAT=001b (NVMe Deallocate Features)
- The NVMe equivalent of DZAT. When set in the namespace metadata, reads to deallocated blocks return all zeroes. Most modern NVMe controllers enforce this for predictable latency and RAID parity consistency.
- DRAT (Deterministic Read After TRIM)
- Older, less strict implementation. The controller returns a consistent value for TRIMmed addresses, but that value isn't guaranteed to be zeroes. Rarely seen in drives manufactured after 2018.
DZAT is the reason recovery software fails on modern SSDs. The controller lies to the operating system. It reports empty space where data may still physically exist on the NAND. This isn't a software bug. It's a protocol-level design decision built into the drive's firmware.
How We Diagnose Whether Your Data Survived
We connect your SSD to PC-3000 SSD and force the controller into a diagnostic state that disables DZAT, garbage collection, and wear leveling. Then we read the raw physical NAND pages to determine whether the data still exists at the cell level. If GC has already erased those blocks, we tell you. No charge.
- Controller identification. We identify the controller family (Samsung, Phison, Silicon Motion, Marvell) and select the correct PC-3000 SSD utility module. Each controller has a different diagnostic mode entry procedure.
- Diagnostic mode entry. PC-3000 SSD forces the controller into Safe Mode or Techno Mode depending on the controller family. In this state, the controller stops processing TRIM, GC, and normal read/write operations.
- FTL mapping table analysis. We read the Flash Translation Layer to identify which physical NAND blocks correspond to the deleted file's logical addresses. The FTL shows whether those blocks were marked as invalid (TRIMmed) and whether they appear in the GC erase queue.
- Raw NAND page read. We read the target physical blocks directly. If the cells still hold charge states above the read threshold, the data exists. If they read as 0xFF (erased state), GC has already run and the data is gone.
- Honest assessment. If the NAND is erased, we tell you and return the drive. You pay nothing. If the data survives, we quote recovery based on complexity. SATA SSD recovery: $200–$1,500. NVMe: $200–$2,500.
We don't charge diagnostic fees. We don't charge “attempt fees.” If TRIM and GC have already erased your data, the honest answer costs you nothing. Call (512) 212-9111 or ship the drive for a free evaluation.
DZAT and DLFEAT: Which SSDs Erase Data Fastest After TRIM?
All modern SSDs implement deterministic post-TRIM behavior (DZAT on SATA, DLFEAT on NVMe), but the aggressiveness of garbage collection varies by controller family. Samsung controllers erase TRIMmed blocks within seconds. Silicon Motion controllers may defer GC for hours on a lightly used drive.
| Controller Family | Interface / Post-TRIM Behavior | GC Timing | Recovery Window |
|---|---|---|---|
| Samsung (Elpis, Pascal, Phoenix) | NVMe / DLFEAT=001b | Seconds after idle | Very short |
| Phison PS3111 (SATA) | SATA / DZAT | Batched during idle | Minutes |
| Phison PS5012, PS5018 (NVMe) | NVMe / DLFEAT=001b | Batched during idle | Minutes |
| Silicon Motion SM2258, SM2259 (SATA) | SATA / DZAT | Deferred until low free blocks | Minutes to hours |
| Silicon Motion SM2262, SM2263 (NVMe) | NVMe / DLFEAT=001b | Deferred until low free blocks | Minutes to hours |
| Marvell 88SS1074 (SATA) | SATA / DZAT | Firmware-dependent | Minutes |
DZAT (SATA) and DLFEAT (NVMe) hide the data from software immediately. GC destroys it physically. Both happen automatically. The only variable is how fast GC runs after TRIM, and that depends on the controller, the drive's free space, and how long the drive stays powered on.
How Much Does SSD Data Recovery Cost?
SATA SSD recovery ranges from $200–$1,500. NVMe SSD recovery ranges from $200–$2,500. The price depends on the failure type, not on whether TRIM was involved. If we determine that garbage collection has already erased your data, the evaluation costs nothing. +$100 rush fee to move to the front of the queue.
Simple Copy
Low complexityYour drive works, you just need the data moved off it
$200
3-5 business days
Functional drive; data transfer to new media
Rush available: +$100
File System Recovery
Low complexityYour drive isn't showing up, but it's not physically damaged
From $250
2-4 weeks
File system corruption. Visible to recovery software but not to OS
Starting price; final depends on complexity
Circuit Board Repair
Medium complexityYour drive won't power on or has shorted components
$450–$600
3-6 weeks
PCB issues: failed voltage regulators, dead PMICs, shorted capacitors
May require a donor drive (additional cost)
Firmware Recovery
Medium complexityMost CommonYour drive is detected but shows the wrong name, wrong size, or no data
$600–$900
3-6 weeks
Firmware corruption: ROM, modules, or system files corrupted
Price depends on extent of bad areas in NAND
PCB / NAND Swap
High complexityYour drive's circuit board is severely damaged and requires NAND chip transplant to a donor PCB
$1,200–$1,500
4-8 weeks
NAND swap onto donor PCB. Precision microsoldering and BGA rework required
50% deposit required; donor drive cost additional
50% deposit required
Hardware Repair vs. Software Locks
Our "no data, no fee" policy applies to hardware recovery. We do not bill for unsuccessful physical repairs. If we replace a hard drive read/write head assembly or repair a liquid-damaged logic board to a bootable state, the hardware repair is complete and standard rates apply. If data remains inaccessible due to user-configured software locks, a forgotten passcode, or a remote wipe command, the physical repair is still billable. We cannot bypass user encryption or activation locks.
No data, no fee. Free evaluation and firm quote before any paid work. Full guarantee details. NAND swap requires a 50% deposit because donor parts are consumed in the attempt.
Rush fee: +$100 rush fee to move to the front of the queue.
Donor drives: A donor drive is a matching SSD used for its circuit board. Typical donor cost: $40–$100 for common models, $150–$300 for discontinued or rare controllers.
Target drive: The destination drive we copy recovered data onto. You can supply your own or we provide one at cost plus a small markup. All prices are plus applicable tax.
How Does NAND Block Erasure Work at the Cell Level?
NAND flash stores data as charge trapped in a floating gate transistor. The floating gate sits between the control gate and the silicon channel, electrically isolated by thin oxide layers. Programming (writing data) uses Fowler-Nordheim tunneling to push electrons onto the floating gate. Erasing uses Fowler-Nordheim tunneling in the reverse direction to pull electrons off.
Page-Level Writes, Block-Level Erases
NAND can write individual pages (4KB-16KB) but can only erase entire blocks (typically 256KB-4MB containing 64-256 pages). This asymmetry is why garbage collection exists. The controller can't erase a single deleted file's pages without erasing every page in that block. GC reads the still-valid pages out of a mixed block, copies them to a clean block, then erases the entire old block at once.
Erase Voltage and Fowler-Nordheim Tunneling
During block erasure, the controller applies 15-20V to the substrate while grounding the control gate. This voltage differential creates an electric field across the tunnel oxide that pulls electrons off the floating gate through quantum mechanical tunneling. The process takes 3-10 milliseconds per block and resets every cell in the block to the erased threshold voltage.
For SLC NAND, the erased state is a single threshold: 0xFF. For TLC NAND, which stores 3 bits per cell across 8 voltage levels, the erase resets all cells to the lowest threshold. For QLC (4 bits, 16 levels), the same principle applies but with tighter voltage margins. After erasure, there is no intermediate charge state that preserves the original data. The floating gate is either charged or discharged. An erased cell carries no recoverable information about what it previously stored.
Why Partial Erasure Doesn't Help
If power is lost mid-erase, some cells in the block may be partially drained while others retain their original charge. PC-3000 SSD can read pages from partially erased blocks and recover data from cells where the charge state is still above the read threshold. But this only applies to interrupted GC operations. A completed block erase is total. Every floating gate in the block has been fully discharged.
PC-3000 SSD Diagnostic Workflow for TRIM State Analysis
PC-3000 SSD communicates with the SSD controller at the vendor command level, below the standard SATA or NVMe protocol. This access level allows direct inspection of the FTL state, TRIM status flags, and raw NAND page contents. The diagnostic workflow depends on the controller family.
Samsung Controller Diagnostic (Phoenix, Pablo)
PC-3000 SSD's Samsung utility enters Techno Mode through vendor-specific command sequences. In Techno Mode, the controller halts all background operations including GC, wear leveling, and TRIM processing. The utility reads the FTL mapping tables from the controller's DRAM or NAND-backed metadata area and maps logical addresses to physical NAND block/page coordinates. Reading the raw pages at those coordinates shows whether the cells are erased or still hold data. Modern Samsung NVMe controllers (Elpis in the 980 Pro, Pascal in the 990 Pro) have limited PC-3000 firmware support; recovery on these models relies on board-level hardware repair rather than diagnostic mode data extraction.
Phison Controller Diagnostic (PS3111, PS5012)
Phison controllers enter diagnostic mode through UART or vendor-specific command interfaces depending on the generation. PC-3000 SSD's Phison utility reads the block status table to identify which blocks are marked as invalid (TRIMmed but not yet erased) vs. erased (GC completed). Blocks in the “invalid but not erased” state still contain recoverable data. The utility reads those pages directly, past the FTL's logical-to-physical translation.
Silicon Motion Controller Diagnostic (SM2258, SM2262, SM2263)
Silicon Motion controllers maintain a detailed block status map in their system area. PC-3000 SSD's SM utility reads this map to distinguish between active blocks (data in use), dirty blocks (TRIMmed, pending GC), and free blocks (already erased). Dirty blocks are the recovery targets. The utility dumps the raw NAND pages from dirty blocks and reconstructs the file system from the physical data, ignoring the FTL's logical view.
What Does the FTL Mapping Table Reveal About TRIM Status?
The Flash Translation Layer (FTL) is the controller's internal database that maps logical block addresses (what the OS sees) to physical NAND locations (where data is stored on the chips). When TRIM invalidates a logical address, the FTL updates its mapping to reflect that the physical block is a candidate for erasure.
PC-3000 SSD reads the FTL directly from the controller's DRAM cache or from NAND-backed metadata pages. The FTL contains three categories of entries that matter for TRIM recovery:
- Active mappings. Logical addresses pointing to physical pages with valid data. These are not affected by TRIM.
- Invalid mappings (TRIMmed, pending GC). Logical addresses where the FTL records that TRIM was received but GC has not yet erased the physical block. The data is still on the NAND. This is the recovery target.
- Free/erased blocks. Physical blocks that GC has already erased. The cells read as 0xFF. The data is permanently gone.
The ratio of “TRIMmed but not erased” blocks to “already erased” blocks determines how much of the deleted data can be recovered. A drive that lost power shortly after deletion will have most TRIMmed blocks still intact. A drive that ran for hours in idle will have most blocks erased by GC.
When Is Recovery Possible After TRIM?
Recovery is possible when the physical NAND cells still hold their original charge states. Recovery is impossible when garbage collection has applied the erase voltage to those blocks. No exceptions. No amount of lab equipment changes this.
| Scenario | NAND State | Recoverable? |
|---|---|---|
| Power loss before GC | Cells hold original charge | Yes |
| Firmware crash froze controller | GC never ran; cells intact | Yes |
| USB bridge blocked TRIM | Controller never received TRIM | Yes |
| TRIM disabled in OS | No TRIM sent; data persists | Yes |
| GC interrupted mid-erase (power loss during erase) | Some pages partially erased | Partial; depends on cell states |
| GC completed; blocks erased | Cells at 0xFF (fully erased) | No |
| Secure Erase executed | All cells reset across entire drive | No |
The single most important action after accidental deletion on an SSD: power off the drive immediately. Do not reconnect it to a running system. Do not run recovery software (it triggers controller activity and may start GC). Ship the drive powered off. We'll determine the NAND state in our SSD data recovery evaluation. If GC has already run, we tell you and return the drive at no cost.
How TRIM Command Processing Differs Across Controller Families
SSD controllers don't all handle TRIM the same way. The controller-family timing table above shows when GC runs; this section covers what happens inside the controller between receiving the TRIM command and beginning the physical erase. That internal pipeline determines how long your data survives after deletion.
Every controller processes TRIM through at least three internal stages: command parsing, FTL invalidation, and GC scheduling. The differences are in how aggressively each stage executes and whether the controller couples FTL unmapping with immediate block erasure or defers it.
ATA DATA SET MANAGEMENT and NVMe Dataset Management: The Wire Protocol
Before the controller can parse, invalidate, or schedule anything, the unmap request has to cross the host-device interface. The wire format differs between SATA and NVMe, but both protocols carry the same underlying information: a list of LBA ranges the host no longer considers valid. The controller receives that payload, acknowledges the command, and then decides on its own schedule when to perform the physical erase.
SATA (ACS-4 DATA SET MANAGEMENT). The DATA SET MANAGEMENT command uses opcode 06h. TRIM is signaled by setting bit 0 of the Feature field (the TRIM attribute). The host transfers a 512-byte payload buffer containing up to 64 LBA Range Entries. Each entry is 8 bytes wide: a 48-bit starting LBA followed by a 16-bit block count. A block count of zero means the entry is unused. Multi-sector payloads are permitted, so a single DSM command can carry thousands of range entries if the file system deletes many fragments at once. The controller parses the payload, walks the FTL, and marks each listed LBA as unmapped.
NVMe (NVMe 2.0 Dataset Management). The Dataset Management command uses opcode 09h. The Deallocate attribute (AD, bit 2 of Command Dword 11) tells the controller to treat each Range entry as an unmap request. The payload is a buffer of 16-byte Range descriptors: a 32-bit context attribute field, a 32-bit length in logical blocks, and a 64-bit starting LBA. Up to 256 ranges may be sent in a single Dataset Management command. Deallocate remains an attribute of DSM; controllers advertise deterministic post-deallocate read behavior through the DLFEAT field at byte offset 33 of the Identify Namespace structure.
The wire protocol carries the unmap payload, nothing more. The controller's response to the host is “received”, not “erased.” Physical erasure happens later, when the controller's internal GC scheduler decides to reclaim the affected blocks. The gap between the command completion and the physical erase is the recovery window. The next four subsections describe how each major controller family uses that gap.
- Samsung (Elpis, Pascal, Phoenix): Immediate FTL Unmap + Aggressive Foreground GC
- Samsung controllers unmap the logical-to-physical translation entry in the FTL the moment the TRIM command completes. The controller doesn't wait for idle time. Within seconds of completing the FTL unmap, both foreground and background GC threads begin consolidating valid pages and erasing invalidated blocks. On a Samsung 980 Pro (Elpis controller), TRIMmed blocks can be physically erased before the OS even confirms the delete operation to the user. The recovery window on Samsung drives is measured in single-digit seconds of idle time after the delete.
- Silicon Motion (SM2258XT, SM2259XT, SM2262EN, SM2263XT): Deferred Lazy GC with Erasure Area Pointers
- Silicon Motion controllers take a different approach. On receiving TRIM, the controller marks affected entries in the FTL as obsolete and adds them to an internal erasure area pointer list. Physical erasure doesn't begin until the free block pool drops below a firmware-defined threshold, typically 10-15% of total NAND capacity. On a lightly used drive with plenty of free space, TRIMmed pages can persist on the NAND for hours because the controller has no pressure to reclaim those blocks. This deferred GC architecture is why SM-based drives (Kingston A400, Crucial MX500, Crucial BX500) often yield better post-TRIM recovery outcomes than Samsung drives of the same age.
- Phison (PS3111-S11, PS5012-E12, PS5018-E18): Batched Idle GC with Firmware-Defined Latency
- Phison controllers queue TRIM invalidations and execute GC in timed batch cycles during idle periods. The firmware defines a minimum latency interval (typically minutes, not seconds) between batch erase operations. The PS3111-S11 SATA controller has a known firmware defect where GC operations cause FTL corruption, throwing the drive into SATAFIRM S11 safe mode. When this happens, the controller halts all background operations, including GC, and the NAND data freezes in whatever state it was in at the moment of the firmware panic. Drives stuck in SATAFIRM S11 mode often have TRIMmed blocks that were never physically erased because GC was interrupted by the crash.
- Marvell 88SS1074: OEM-Customized Firmware Behavior
- The Marvell 88SS1074 controller ships with a reference firmware that OEM partners (Lite-On, Plextor) customize for their own drives. GC aggressiveness varies across these customizations. Plextor's M8V firmware and Lite-On's implementations differ in how aggressively they schedule background erase operations on the same silicon. PC-3000 SSD's Marvell utility accounts for these OEM firmware variants, but the recovery window prediction depends on identifying the specific OEM firmware version during diagnostic mode entry.
The practical difference between these architectures: a deleted file on a Samsung 970 Evo Plus (Phoenix controller) may be physically gone seconds after the OS confirms deletion. That same file on a Kingston A400 (SM2258XT) with significant free space could survive much longer because the controller has no pressure to reclaim those blocks. Controller architecture, not drive brand, determines the recovery window.
How Do Operating Systems Schedule TRIM Commands?
The operating system decides when to send TRIM commands to the SSD controller. Windows, macOS, and Linux each schedule TRIM differently, and that scheduling directly affects how fast your data reaches the controller's GC queue. The race between OS-issued TRIM and controller-side GC determines the total recovery window.
Windows: Near-Instant TRIM on Delete
Windows (7 and later) sends TRIM to the SSD controller almost immediately after a file is permanently deleted. Shift+Delete bypasses the Recycle Bin and issues TRIM within milliseconds. Emptying the Recycle Bin triggers TRIM for every file in the bin. Windows also runs a weekly “Optimize Drives” task (formerly Defragment) that reissues TRIM for all free space on the volume, catching any blocks the real-time TRIM missed.
Check TRIM status on Windows: open Command Prompt as administrator and run fsutil behavior query disabledeletenotify. A result of 0 means TRIM is enabled. Result of 1 means TRIM is disabled and deleted blocks are not sent to the controller.
macOS: Millisecond TRIM on APFS
APFS (the default file system since macOS 10.13) issues TRIM within milliseconds of file deletion on Apple-supplied NVMe SSDs. Third-party SATA SSDs installed in older MacBooks require sudo trimforce enable to activate TRIM support. One exception worth noting: macOS's native software RAID driver does not pass TRIM commands through to the underlying drives, so SSDs in an Apple Software RAID array retain deleted data until overwritten by new writes.
Linux: Weekly Batched TRIM by Default
Most modern Linux distributions (Ubuntu 20.04+, Fedora 33+, Debian 11+) ship with fstrim.timer, a systemd timer that runs fstrim once per week. Between runs, deleted blocks are not sent to the controller. This weekly batch creates the largest default recovery window of any major OS: up to 7 days where deleted files exist on the NAND without the controller even knowing they're available for GC.
Adding discard to the mount options in /etc/fstab enables continuous real-time TRIM, which behaves like Windows: TRIM fires on every delete. Continuous discard shrinks the recovery window to match the controller's GC speed.
Over-Provisioning Pressure and Forced GC
A nearly full SSD creates GC urgency that overrides the controller's normal scheduling. When free block reserves drop below the over-provisioning threshold (typically 7-28% of NAND capacity depending on controller firmware), the controller switches from background GC to foreground GC. Foreground GC runs in the critical write path: the controller must erase TRIMmed blocks immediately to serve incoming writes. A 1TB SSD with 950GB used has almost no free block buffer, forcing the controller to erase stale blocks within seconds of receiving TRIM. The same 1TB drive at 500GB used has hundreds of gigabytes of free block reserves and can defer GC for hours.
If you've deleted files from a nearly full SSD, assume the recovery window is short regardless of the controller family or OS. If the drive had significant free space, the window may be longer, but still power down the drive immediately.
How PC-3000 SSD Halts Garbage Collection Before Erasure Completes
The diagnostic workflow described earlier in this page covers identifying TRIM state. This section covers the specific technique of freezing GC execution so the controller can't continue erasing blocks while we extract data. PC-3000 SSD achieves this by intercepting the controller's boot sequence and loading a restricted-operation microcode environment.
Safe Mode: ROM Pin Shorting on SM, Phison, and Marvell Controllers
For Silicon Motion, Phison, and Marvell controllers, GC freezing requires a hardware-level boot interrupt. During power-on, we short specific diagnostic test points on the PCB (often labeled ROM_CS or UART_TX on the controller's reference design). This grounds the boot ROM chip-select line and forces the controller to halt at Stage 3 of its boot sequence: Service Area Access. The main firmware never loads from NAND into the controller's SRAM.
With the main firmware stopped, GC, wear leveling, and TRIM processing cannot initiate. PC-3000 SSD uploads a custom microcode loader into the controller's internal RAM. This loader provides raw NAND page read capability without any of the controller's normal translation, filtering, or DZAT enforcement. Every physical page is accessible, including pages the FTL had marked as invalid.
Techno Mode: Vendor Command Suspension on Samsung Controllers
Samsung controllers don't require pin shorting. PC-3000 SSD's Samsung utility sends a vendor-specific ATA or NVMe command sequence that places the controller into Techno Mode. In this state, the controller suspends all autonomous operations: GC stops, wear leveling stops, DLFEAT enforcement is disabled, and the TRIM processing queue pauses. The controller remains powered and responsive but executes only the commands PC-3000 issues directly.
FTL Backup Recovery: Reverting to a Pre-TRIM Mapping State
After freezing GC, the next step is locating usable FTL mapping data. Advanced controllers (SM2259XT, Phison PS5012-E12, Samsung Phoenix) periodically flush backup copies of the FTL mapping table to a reserved NAND service area. These backups capture the logical-to-physical address map at a specific point in time.
PC-3000 Data Extractor scans the NAND service area for historical FTL backups. If a backup predates the TRIM operation, it contains valid logical-to-physical mappings for the deleted files. Loading this pre-TRIM backup effectively reverts the controller's address translation to a state where the deleted files still have valid physical page assignments. The extractor then reads those physical pages using the restored mapping table and reconstructs the original file system.
Forensic Write Blockers Don't Stop GC
Standard forensic write blockers prevent host-initiated writes. They do not prevent controller-initiated GC. A write blocker supplies power to the SSD, and power is all the controller needs to run autonomous background operations. Connecting an SSD to a write blocker after accidental deletion gives the controller the power it needs to continue erasing TRIMmed blocks.
The correct protocol for preserving SSD data after accidental deletion: cut power completely. Remove the drive from the system. Do not connect it to any interface, including write blockers, USB docks, or diagnostic stations. Ship it unpowered. PC-3000 SSD's diagnostic mode entry procedure is specifically designed to interrupt the boot sequence before GC can initialize.
Why Do Some TRIMmed Pages Survive in the Over-Provisioned Area?
A consumer SSD hides part of its raw NAND in an over-provisioned (OP) pool the controller uses for wear leveling, bad block replacement, and GC scratch space. Factory OP ranges from about 7% on budget SATA drives to 28% on enterprise NVMe models. The OP pool holds the second recovery window: stale page copies that can persist even after GC has cycled through the active pool.
How Data Migrates Between the Active Pool and the OP Pool
Wear leveling and write amplification constantly shuffle data between the active user-visible pool and the OP reserve. When the controller picks a source block for GC consolidation, it reads the still-valid pages, writes them to a clean block pulled from the free pool (often an OP block), and then schedules the original block for erasure. The old physical page in the source block is marked invalid in the FTL, but the electrical charge on those floating gates persists until the containing block reaches the front of the erase queue. On a lightly used drive with abundant free space, that queue can move slowly.
The consequence: when the FTL unmaps a logical address in response to TRIM, the physical page that held the original data is not the only copy the drive may have written during that data's lifetime. Every time wear leveling relocated the page from one physical block to another, it left the previous copy as a stale page in what is now an OP reserve block. Those stale copies are still charge-intact until the controller selects their containing block for erasure. A single deleted file may have multiple stale copies scattered across OP blocks that the drive simply hasn't gotten around to reclaiming.
Why Chip-Off NAND Recovery Reaches Pages the Controller Considers Invalid
The controller's FTL is a bookkeeping layer; it does not correspond to the physical state of the NAND. When the FTL marks a logical address invalid, the underlying physical page is not erased. It simply becomes unreferenced. Reading through the controller's standard interface returns DZAT zeroes because the FTL refuses to translate a request to an unmapped LBA. Reading through PC-3000 SSD in diagnostic mode bypasses the FTL enforcement but still depends on the original controller being alive and capable of communicating with the NAND bus.
Chip-off NAND recovery goes further. The NAND packages are desoldered from the PCB and read directly on a programmer that addresses each die, plane, block, and page by its native coordinates. At that level the FTL, the DZAT enforcement layer, and the GC scheduler are all bypassed because the controller is out of the path entirely. Every page that has not yet received the erase voltage reads its actual charge state, including stale copies sitting in OP reserve blocks that the controller's FTL marked invalid long ago. The data is only gone if the specific physical block containing a given copy has already been erased. Other copies, in blocks the controller hasn't reclaimed yet, remain readable.
This is why chip-off is worth attempting on lightly-used drives even after GC has clearly run on the active pool. A drive at 30% full has a deep OP reserve that rotates slowly. Stale copies of deleted files can persist in that reserve for hours, days, or in some cases longer, depending on controller firmware, wear leveling strategy, and host I/O pressure. The tradeoff: chip-off requires a donor PCB or full FTL reconstruction from the raw dumps, and it cannot defeat the controller's AES-256 encryption on self-encrypting drives. For encrypted NVMe SSDs, reviving the original controller through board repair remains the only path to plaintext data.
When OP Survivability Matters for Recovery Strategy
OP reserve survivability is a secondary recovery window, not a substitute for the primary power-off protocol. The controller still erases OP blocks eventually. On heavily written drives, the OP pool cycles rapidly and stale copies are short-lived. On nearly-full drives, the OP pool is the only free-block buffer and gets erased aggressively to serve incoming writes. The survivability benefit is greatest on lightly-used drives that were powered down soon after the delete event and shipped to the lab without further writes.
The PC-3000 SSD diagnostic still runs first. If the FTL backup scan or the raw NAND read inside the active pool recovers the target files, there is no need to escalate to chip-off. If the active pool has been erased but controller analysis indicates the drive has substantial free OP reserve and low write amplification over the period since the delete, chip-off becomes the next step. NAND swap pricing for this tier of work is listed at $1,200–$1,500 for SATA and $1,200–$2,500 for NVMe, with a donor PCB or raw NAND reconstruction required.
How Write Amplification Multiplies NAND Damage During Recovery Software Scans
Write amplification factor (WAF) is the ratio between physical NAND program operations the controller actually performs and the host writes the operating system issued. The formula is simple; the consequences are not.
| Variable | Definition |
|---|---|
| WAF | NAND program operations ÷ host write operations |
| Pages per block | Typically 64-256 pages (4KB-16KB each) per erase block |
| Valid page ratio | Fraction of pages in the GC source block that still hold live data |
| Free-block pool depth | Count of fully erased blocks the controller can hand to incoming writes |
Page-Program vs Block-Erase Asymmetry Drives the Multiplier
NAND programs at page granularity but erases at block granularity. To rewrite a 4KB host page that lives in a partially-invalid block, the controller must read every still-valid page in that block, program those valid pages into a clean block, then erase the entire source block. Each host write therefore translates into at least one page program for the new data plus one page program for every valid page the GC pass had to relocate. As block fragmentation increases, WAF rises in a near-linear fashion.
Worked Example: Recovery Software on a Fragmented SSD
Consider a 256-page erase block where 8 pages still hold valid live data and 248 pages were marked invalid by TRIM but have not yet received the erase voltage. A single 4KB host write that the controller routes through this block triggers the following NAND traffic during GC:
- 1 page program for the host write itself (written to a clean block).
- 8 page programs to relocate the still-valid pages out of the source block into the clean block.
- 1 block erase applied to the source block. The 15-20V Fowler-Nordheim erase pulse resets every floating gate in that block, including the 248 pages that still held charge-intact copies of TRIMmed user data.
Effective WAF for this single host write is 9 (9 NAND program operations per 1 host write), and the byproduct is 248 invalidated pages crossed off the recovery list in one erase pulse. Multiply that across the thousands of small reads, metadata updates, and journal flushes that consumer recovery software issues during a scan and the destruction is not theoretical; it is mechanical.
Why the Same Math Doesn't Apply When PC-3000 SSD Drives the Bus
PC-3000 SSD enters the controller through vendor-specific commands that suspend the GC scheduler, the wear-leveling thread, and the TRIM-processing queue before any reads are issued. In that diagnostic state, controller-side activity does not consume free blocks and does not advance the FTL invalidation pipeline. Reads target the raw physical NAND coordinates the FTL backup or reconstructed mapping points to. WAF during diagnostic reads is effectively zero because no programs and no erases are issued by the read path.
Consumer recovery software cannot reach this state because the standard SATA and NVMe command sets do not expose the vendor commands required to suspend background NAND activity. Disk Drill, EaseUS, R-Studio, and PhotoRec all run inside the host operating system and issue reads through the controller's public interface. Each of those reads keeps the controller awake, refreshes thermal and wear-leveling metadata, and gives the GC scheduler another opportunity to advance its erase queue.
The Consequence Chain in One Pass
- Host issues read or write through the controller's standard interface.
- Controller wakes the GC scheduler and the wear-leveling thread to service the request and refresh internal metadata.
- GC selects the next source block from the invalidated-block queue. Source blocks rich in TRIMmed-but-not-yet-erased pages sit at the front of that queue because they free the most space per erase pulse.
- Valid pages are programmed into a clean target block (WAF multiplier kicks in).
- Source block receives the 15-20V erase pulse. Floating gates discharge through Fowler-Nordheim tunneling. The recoverable charge state is gone.
- Recovery software reports zeroes for the affected LBAs because DZAT enforcement returns 0x00 for any TRIMmed range and the underlying NAND is now physically erased anyway.
This chain is why the ssd data recovery protocol starts with a power-disconnect order and not a software scan. Evaluation on PC-3000 SSD is free; SATA recovery starts at $200 and NVMe at $200. NAND-level work where the controller is suspended and pages are read at physical coordinates falls in the $450–$600 range for SATA and $600–$900 for NVMe. Rush availability: +$100 rush fee to move to the front of the queue. An SSD that arrived powered off has a real recovery window. An SSD that ran recovery software for an hour before shipping often does not.
Why Does Every Hour of Power-On Time Reduce SSD Recovery Odds?
An SSD controller is autonomous. It doesn't need instructions from the operating system to erase data. Once TRIM marks blocks as invalid, the controller schedules those blocks for physical erasure on its own timeline. Every second the drive stays powered on and idle gives the controller another GC cycle to erase blocks you need.
The controller-family GC timing differences described earlier in this page translate directly into real recovery windows. The table below maps controller architecture to approximate time-to-erasure under normal idle conditions:
| Controller | Typical Time to Physical Erasure (Idle) | Action Required |
|---|---|---|
| Samsung (Elpis, Pascal, Phoenix) | Seconds | Immediate power disconnect |
| Phison PS3111-S11, PS5012, PS5018 | Minutes | Power off within 60 seconds |
| Silicon Motion SM2258, SM2259 | Minutes to hours (capacity dependent) | Power off as soon as possible |
| Marvell 88SS1074 | Minutes (firmware variant dependent) | Power off within 60 seconds |
What Not to Do After Accidental SSD Deletion
- Don't run recovery software. Disk Drill, EaseUS, R-Studio, and PhotoRec all work through the controller's standard interface. They trigger controller activity, wake GC, and receive zeroes from DZAT enforcement. The software can't see past the controller, and running it gives the controller time to continue erasing.
- Don't connect a write blocker. Write blockers supply power. The controller boots, initializes GC, and continues erasing TRIMmed blocks. A write blocker protects against host writes but not against the controller's own autonomous erase operations.
- Don't boot the operating system. Booting generates I/O activity that triggers additional TRIM commands for temporary files, swap space, and file system journal entries. Each new TRIM command adds more blocks to the GC queue.
- Do disconnect power immediately. Pull the SATA data and power cable. Remove the M.2 SSD from the slot. For a laptop, shut down (don't sleep/hibernate) and remove the drive if possible. Ship the drive unpowered to the lab.
A free evaluation on PC-3000 SSD determines whether GC has already destroyed your data. SATA SSD recovery starts at $200; NVMe starts at $200. If GC finished erasing the target blocks, we return the drive and charge nothing. Call (512) 212-9111 or start a free evaluation.
TRIM & Garbage Collection Recovery FAQ
Can data be recovered from an SSD after TRIM?
What does DZAT mean for SSD data recovery?
How does garbage collection permanently erase SSD data?
Why do data recovery companies charge for drives where TRIM already erased the data?
Is TRIM the same as Secure Erase on an SSD?
How long after deletion does garbage collection erase SSD data?
Can PC-3000 SSD read past DZAT to access raw NAND data?
Why does running recovery software on a powered SSD destroy data faster than leaving it idle?
Does TRIM work on external USB SSDs?
Need Recovery for Other Devices?
The recovery window between TRIM and garbage collection. Controller-specific GC timing, how to disable TRIM, and when professional recovery is still possible.
How GC consolidates valid pages, erases stale blocks, and why DZAT blocks software recovery before GC finishes the physical erase.
SATAFIRM S11, 0GB capacity, BSY state. When the controller firmware crashes, GC stops and TRIMmed data may survive on the NAND.
Full SSD data recovery service. SATA from From $200, NVMe from From $200. Free evaluation, no data = no fee.
Deleted Files on Your SSD? Find Out If They Survived.
TRIM may not have finished the job. Power off the drive and ship it to our Austin lab. We check the raw NAND state for free. SATA SSD recovery starts at $200; NVMe starts at $200. No data, no charge.