What Is SSD Garbage Collection?
SSD garbage collection (GC) is an automated background process run by the SSD's internal controller. It consolidates valid data from fragmented NAND blocks into clean blocks, then physically erases the old blocks so they can accept new writes. GC is the step that permanently destroys deleted data on an SSD.
When you delete a file, the operating system sends a TRIM command to the SSD. TRIM marks the file's logical addresses as invalid in the controller's Flash Translation Layer (FTL). TRIM does not erase anything. The controller queues those blocks for garbage collection, which runs during idle time and applies the erase voltage that resets the NAND cells to their unprogrammed state.
This two-step process is what makes SSD data recovery different from hard drive recovery. On a hard drive, deleted files stay on the magnetic platters until new data overwrites the same sectors. On an SSD, the controller actively hunts for stale blocks and erases them in the background, regardless of whether new data needs that space.
What Is DZAT (Deterministic Read Zero After TRIM)?
DZAT is a SATA specification feature where the SSD controller guarantees that any read request targeting a TRIMmed logical block address returns all zeroes. This happens immediately after TRIM processing, before garbage collection physically erases the NAND cells. The NVMe equivalent is DLFEAT=001b (Deallocate Logical Block Features).
- DZAT (Deterministic Read Zero After TRIM)
- The strictest SATA TRIM implementation. The controller intercepts all read commands to TRIMmed LBAs and returns a payload of all zeroes. The physical NAND may still hold the original charge states, but no software can reach them through the standard interface. Most modern SATA SSDs implement DZAT.
- DRAT (Deterministic Read After TRIM)
- A less strict implementation where the controller returns a consistent, deterministic value for TRIMmed LBAs. The value is usually zeroes but the specification allows other fixed patterns. Less common in modern drives.
- DLFEAT=001b (NVMe Deallocate Features)
- The NVMe equivalent of DZAT. When a drive sets DLFEAT to 001b in its namespace metadata, reading a deallocated logical block returns all zeroes. Most modern NVMe drives enforce this behavior for predictable latency and RAID parity consistency.
DZAT creates a critical problem for data recovery. The controller lies to the operating system. It reports that TRIMmed blocks contain nothing but zeroes, even while the original data still exists as electrical charges on the NAND cells. This is not a software limitation. It is a protocol-level enforcement built into the drive's firmware.
Why Does Recovery Software Fail on Modern SSDs?
Recovery software operates at the logical layer above the SSD controller. It sends standard read commands through the OS storage driver. When the controller has DZAT enabled, every read to a TRIMmed block returns zeroes. The software sees empty space and reports the data as unrecoverable.
| Layer | What Happens | Data Accessible? |
|---|---|---|
| File system (OS level) | OS sends TRIM after file deletion; marks LBAs invalid | No; file metadata removed |
| Controller logical interface | DZAT returns zeroes for all TRIMmed LBAs | No; software sees empty space |
| FTL mapping table | LBA-to-PBA mapping dropped; pages marked invalid | Not through standard commands |
| Physical NAND cells | Charge states may still hold original data until GC erases | Yes, via PC-3000 SSD raw NAND access |
Tools like Disk Drill, EaseUS, Recuva, and R-Studio all operate at the top two layers. They cannot bypass the controller's DZAT enforcement, and they cannot access raw NAND pages below the FTL. When these tools report zero recoverable files from a TRIMmed SSD, the data may still exist physically on the NAND. It requires hardware that communicates with the controller at the diagnostic level, not through the standard storage protocol.
SSD Data Recovery Pricing
Five published tiers from From $200 to $1,200–$1,500. NVMe SSD recovery ranges from From $200 to $1,200–$2,500. Free evaluation, firm quote before any paid work. No data, no recovery fee. +$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.
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.
How the SSD Controller Manages Garbage Collection
NAND flash cannot overwrite data in place. The SSD must erase an entire block (128 to 256 pages, typically 256KB to 4MB) before writing new data to any page within that block. Garbage collection exists to prepare erased blocks for future writes by reclaiming blocks that contain a mix of valid and invalid pages.
Page-Level Writes, Block-Level Erases
Pages (4KB to 16KB) are the smallest unit the controller can read or write. Blocks (groups of 128 to 256 pages) are the smallest unit the controller can erase. When the OS modifies a file, the controller writes updated data to a new, clean page and marks the old page as invalid in the FTL. This out-of-place write model means blocks gradually accumulate invalid pages alongside valid ones.
The GC Cycle
- Identification: The controller selects a block with a high ratio of invalid pages. Controllers track valid/invalid ratios for every block on the drive.
- Valid page migration: The controller reads the remaining valid pages from the target block and writes them to a clean, pre-erased block.
- Block erase: The controller applies erase voltage to the entire target block, resetting all cells (both previously valid and invalid) to the unprogrammed state (0xFF). This step permanently destroys the deleted data.
Background GC vs. Foreground GC
Background GC runs during idle periods without interrupting host I/O. The controller uses dedicated processing cores (Phison controllers use "CoX processors" for this) to clean blocks quietly. Foreground GC triggers when the pool of free blocks drops too low to handle incoming writes. The controller pauses host operations to erase blocks in real time, causing the latency spikes known as the "performance cliff." From a recovery perspective, foreground GC is the worst scenario: it erases TRIMmed blocks immediately to free space for new data.
Over-Provisioning and GC Timing
Over-provisioning (OP) is a reserve of NAND blocks hidden from the user. A drive with 10% OP always has a buffer of free blocks available for writes while background GC processes dirty blocks at its own pace. More OP means the controller can defer physical erasure for longer periods. A nearly full drive with minimal free space triggers aggressive foreground GC, erasing stale blocks within seconds of a TRIM command. Enterprise SSDs with 28% or more OP tend to have the most relaxed GC scheduling; consumer drives with 7% OP erase more aggressively.
Which Controllers Implement DZAT?
Every major SSD controller family implements DZAT or its NVMe equivalent (DLFEAT=001b). The differences that matter for data recovery are in GC timing: how quickly the controller physically erases TRIMmed blocks after the DZAT logical mask is in place.
Samsung Controllers (MKX, Elpis, Pascal)
Samsung designs controllers in-house: the MKX for the SATA 870 EVO, Elpis for the NVMe 980 PRO, and Pascal for the 990 PRO. Samsung firmware prioritizes aggressive GC for NAND endurance optimization. Background GC begins within seconds of idle time after receiving TRIM. If a Samsung drive stays powered on and idle for more than 30 seconds after file deletion, the NAND blocks have likely been physically erased. Samsung's aggressive GC benefits drive longevity but creates the shortest recovery window of any controller family.
Phison Controllers (PS3111-S11, PS5012-E12, PS5018-E18)
Phison controllers power drives from Corsair, Kingston, Seagate, and Sabrent. Newer Gen4/Gen5 controllers (like the E18 and E26) use dedicated CoX processors for background GC, separating GC from host I/O processing. Older controllers like the PS3111-S11 have a documented firmware failure mode where GC operations cause the FTL to panic and throw the drive into SATAFIRM S11 safe mode. When this happens, GC freezes mid-cycle. The interrupted GC preserves NAND data that would otherwise have been erased, making PC-3000 recovery viable.
Silicon Motion Controllers (SM2258XT, SM2259XT, SM2262EN)
Silicon Motion controllers are used by Crucial, ADATA, and many OEM drives. The SM2259XT (a DRAM-less SATA controller) shows a favorable behavior for recovery: on a quick format, the controller erases the primary FTL translator but does not trigger a mass-GC cycle across the NAND array. The physical data persists on the memory cells. PC-3000 can access historical translator backups stored in the NAND service area and reconstruct the original directory structure. This makes Silicon Motion drives among the more recoverable after format events.
Marvell, Realtek, and Intel/Solidigm
Marvell controllers (enterprise-grade) follow strict DZAT compliance with steady, predictable GC timing. Realtek controllers appear in budget NVMe drives and can delay GC under heavy thermal throttling. Intel/Solidigm controllers enforce RZAT (Read Zero After TRIM) in enterprise environments where RAID parity consistency requires deterministic behavior across all drives in the array.
How Powering Off Preserves Data Before GC Completes
The gap between TRIM marking blocks as invalid and GC physically erasing those blocks is the only recovery window. Powering off the SSD immediately after data loss freezes the controller state and prevents GC from running.
- Power off the drive immediately. Disconnect the SSD from the system. Do not shut down the OS normally if you can avoid it; a normal shutdown gives the controller idle time to run GC before power is removed.
- Do not reconnect to a running OS. Plugging the SSD back into a running system sends queued TRIM commands and gives the controller idle time to resume GC. Even mounting the drive as read-only may trigger controller activity.
- Do not run recovery software. Consumer recovery tools send read commands through the standard interface. On a DZAT drive, these reads return zeroes (giving you no useful data). Worse, the drive is powered on and idle between read commands, allowing background GC to execute.
- Ship the drive powered off to a lab with PC-3000 SSD. The PC-3000 forces the controller into a diagnostic state that disables all background processes, including GC, before reading raw NAND.
If the SSD suffered a power loss or firmware failure before GC ran, the data is likely intact on the NAND. Firmware failures freeze the controller mid-operation, preventing all background tasks including GC. Drives stuck in safe mode (SATAFIRM S11, BSY state, 0-byte capacity) have not run GC since the failure occurred.
How PC-3000 SSD Reads Invalid NAND Pages
PC-3000 SSD bypasses the controller's standard SATA/NVMe interface entirely. Instead of asking the controller for logical data (which triggers DZAT zeroes), it communicates with the controller at the diagnostic level to access raw physical NAND pages that the FTL has marked as invalid but GC has not yet erased.
Safe Mode Entry and Loader Upload
The first step is preventing the controller from executing its standard firmware (and with it, background GC). Engineers use hardware techniques to force the controller into Safe Mode. With the primary firmware suspended, PC-3000 uploads a custom microcode loader directly into the controller's RAM. This loader grants access to Techno Mode.
Techno Mode: Freezing the Drive State
In Techno Mode, the SSD operates in a restricted, single-channel state. All background firmware tasks are disabled: no garbage collection, no wear leveling, no TRIM processing. The drive's forensic state is frozen. PC-3000 can now read raw Physical Block Addresses (PBAs) directly, bypassing the FTL mapping table and the DZAT logical mask.
FTL Translator Reconstruction
Raw NAND reads return fragmented data mixed with ECC parity bits and out-of-order blocks from wear leveling. To reconstruct usable files, the FTL translator must be rebuilt. Advanced SSD controllers (Silicon Motion SM2259XT, Phison E12) create backup copies of the FTL translator in the NAND service area as a safeguard against power loss. PC-3000 Data Extractor scans the raw NAND architecture for these historical translator backups, reverts the logical mapping to a version that existed before the deletion event, and rebuilds the original file system and directory structure.
This procedure depends on one condition: the physical NAND cells must still hold the original charge states. If GC has already erased the target blocks, the cells are reset to 0xFF and the data is gone. This is why immediate power-off is critical. For drives where the controller is dead beyond repair, chip-off NAND extraction desolders the NAND chips from the PCB for direct reading, but AES-256 encryption on most modern controllers means chip-off yields only ciphertext without the original controller to decrypt.
SSD Garbage Collection Recovery FAQ
Can you recover data from an SSD after garbage collection?
Why does my data recovery software show zeroes on my SSD?
How long does garbage collection take to erase deleted SSD data?
What is the difference between TRIM and garbage collection?
What does DZAT mean for SSD data recovery?
Should I power off my SSD immediately after losing data?
Can PC-3000 SSD bypass DZAT and read the raw NAND?
Does over-provisioning affect how fast garbage collection erases data?
SSD Not Responding? Get a Free Evaluation.
Garbage collection may not have erased your data yet. Power off the drive and ship it to our Austin lab. SATA SSD recovery starts at $200; NVMe starts at $200. No data, no charge.