SSD Data Recovery

Can You Recover Data After TRIM?
The Honest Answer

After TRIM, SSD recovery depends on whether garbage collection physically erased the NAND. If erasure completed, no software or lab can recover the deleted files. If the erase never ran because the drive lost power, used a legacy USB bridge, sat in RAID, or suffered controller failure, Rossmann evaluates the media in the Austin lab with no diagnostic fee. Our SSD data recovery service is available for drives where TRIM has not yet completed erasure.

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.

Author01/01

Written by

Louis Rossmann

Founder & Chief Technician

Updated 2026-05-23

What TRIM Actually Does

TRIM tells the SSD controller to logically unmap deleted data, marking the corresponding NAND pages as invalid. The controller's autonomous Garbage Collection process later erases the physical NAND blocks containing those invalid pages. Once erased, no residual data remains. The exception is when physical erasure never completed before the drive lost power or the controller failed.

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.

NAND Erase Physics & Write Amplification

NAND flash cannot overwrite data in place. A block must be erased before new pages can be written, and that erase applies +15-20 volts via Fowler-Nordheim tunneling to reset all bits to 1. This is the physical reason garbage collection exists.

The Write Amplification Factor measures data written to flash versus data written by the host. Without TRIM, the controller must migrate stale data during garbage collection, and WAF can exceed 3 on heavily written drives. TRIM reduces WAF by flagging pages as invalid so they can be erased without migration.

Garbage collection timing is autonomous. It may run seconds after deletion or during idle periods. If power is removed before the erase voltage is applied, the original data remains physically intact on the NAND.

Write Amplification Factor (WAF): The ratio of data written to the NAND flash versus data written by the host. Without TRIM, WAF can exceed 3 on heavily written drives because the controller must migrate stale data during garbage collection. TRIM reduces WAF by allowing invalid pages to be erased without migration.

Quick Format vs. Individual File Deletion

Deleting a single file sends targeted TRIM commands for specific LBA ranges. The OS tells the SSD exactly which blocks that file occupied, often just 4KB to 128KB clusters. The controller marks only those ranges invalid in the FTL.

A quick format behaves differently. It issues TRIM or Deallocate across the entire partition volume, not just the blocks that held files. The primary FTL mapping table is wiped. However, many controllers keep redundant historical copies of the translator metadata in the NAND service area. Those older copies may survive the format if garbage collection hasn't yet erased the service area blocks that contain them.

PC-3000 SSD can enter Technological Mode and scan raw NAND for surviving historical translator copies. If an earlier FTL version is found prior to the format, engineers reconstruct the virtual file-to-zone mapping in PC-3000 RAM. This isn't guaranteed; if the controller's garbage collection already swept the service area, the historical copies are gone.

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.

Garbage Collection Timing by Controller Manufacturer

Garbage collection speed varies by SSD controller manufacturer. Samsung controllers often erase TRIMmed blocks within seconds of idle time. Silicon Motion controllers frequently defer GC until the reserve of free blocks drops below a firmware threshold. The recovery window after deletion isn't uniform; it depends on the specific controller algorithm.

Not all SSDs erase deleted data at the same speed. The controller's firmware decides when to run garbage collection, & different vendors use different strategies.

Samsung Controllers: Samsung controllers tend to be aggressive. Samsung Elpis (980 Pro) and Pascal (990 Pro) queue and execute erase within seconds of idle. Rossmann does not currently offer in-lab recovery for Samsung Elpis or Pascal controllers. If you deleted files & left the drive powered on, garbage collection may have already run before you finished reading this sentence.
Silicon Motion (SMI) Controllers: SMI controllers, including the SM2258XT & SM2259XT families found in many budget SATA SSDs, often take a lazier approach. They defer garbage collection until the reserve pool of free blocks drops below a firmware-defined threshold. On lightly used drives, data may sit for hours. This creates a longer recovery window, but only if the drive hasn't been written to heavily.
Phison Controllers: Phison behavior varies by firmware revision & product line. The PS3111-S11 (Kingston A400, PNY CS900) batches GC operations; the window varies by firmware revision. Some firmware revisions run GC promptly during idle periods, while others batch operations. The PS3111-S11 (SATAFIRM S11) & E12 families show different GC scheduling patterns.
Marvell Controllers: The 88SS1074 & 88SS1093 families power many WD Blue and SanDisk Ultra 3D SSDs. Marvell garbage collection tends to be threshold-triggered, not aggressively idle-triggered. The controller waits until the reserve pool of free blocks falls below a firmware-defined percentage before erasing invalid pages. On a lightly used drive, deleted data may remain intact for minutes to hours.
Realtek Controllers: Realtek RTS5735 & RTS5765DL controllers appear in budget SATA & NVMe drives. Rossmann does not currently offer in-lab recovery for Realtek controllers. We lack bench data on whether their GC is idle-triggered or threshold-triggered.
Innogrit Controllers: Innogrit Shasta+ & Rainier power enterprise & consumer NVMe SSDs. Rossmann does not currently offer in-lab recovery for Innogrit controllers. Public documentation on their GC timing is limited.
Maxio Controllers: Maxio MAS0902 appears in ADATA & Lexar SATA SSDs with PC-3000 SSD support. MAS1102 is under deep development at ACELab with support limited to 240 GB configurations. Rossmann does not currently offer in-lab recovery for Maxio MAS1102. On MAS0902, garbage collection is typically deferred until the free-block reserve drops below threshold, similar to Silicon Motion.

Background Maintenance: Phison SmartRefresh and DEBM

Modern controllers run background maintenance that intersects with data retention. Phison PS5012-E12 and PS5013-E13T controllers employ SmartRefresh, which uses Dynamic Error Bit Monitoring to evaluate block health continuously. If error bits cross a threshold before the ECC engine fails, the controller initiates an Idle-Time Media Scan and performs a Read Retry using shifted threshold voltages.

The valid data is then rewritten to a healthy block. This is beneficial for drive longevity, but it means a powered-on SSD is a hostile environment for deleted data. Even if garbage collection hasn't erased your TRIMmed files yet, background media scans can move or refresh surrounding blocks, reducing the chance that an older historical translator copy survives in the NAND service area.

The practical takeaway: you can't predict the recovery window from the drive's brand name alone. The controller firmware algorithm determines whether your deleted files survive for minutes, hours, or not at all. A powered-on drive left idle is actively maintaining itself; every second of power increases the probability that background processes erase or relocate data.

What Are the Different SSD Unmap Protocols?

TRIM, Deallocate, & UNMAP are three protocols that tell an SSD controller to mark data blocks as invalid. ATA TRIM runs on SATA, NVMe Deallocate operates over PCIe, & SCSI UNMAP handles enterprise SAS & SAN traffic; all three trigger the same logical unmapping & subsequent garbage collection, but they travel through different command sets.

The ATA TRIM command was introduced in ATA8-ACS2, yet the word TRIM is used as a catch-all for three distinct protocols. The actual command depends on the bus & protocol.

ATA TRIM: The SATA DATA SET MANAGEMENT command with the Trim attribute set. Introduced in ATA8-ACS2 & extended in SATA 3.1 with Queued TRIM. The operating system sends a list of logical block addresses to the SSD controller, which marks them invalid in the FTL.
NVMe Deallocate: The Dataset Management command in the NVMe command set, present in NVMe 1.2 & refined in NVMe 2.0 TP4040. It functions identically to TRIM but operates over the PCIe bus. Most M.2 and U.2 SSDs use this protocol.
SCSI UNMAP: The enterprise command used in SAS drives, SAN arrays, & VMware environments. Consumer USB-NVMe enclosures with UASP can translate UNMAP into NVMe Deallocate, but legacy BOT bridges drop the command entirely.

When Has TRIM Not Erased Deleted SSD Data?

Deleted SSD files remain recoverable only when the drive never received TRIM or never completed the later NAND erase. Legacy BOT USB bridges, some RAID sets, disabled operating system TRIM, and immediate power loss after deletion create the main recovery windows.

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.

External SSD recovery details →

RAID Arrays

Many hardware RAID controllers block TRIM for parity (RAID 5) or mirrored (RAID 1/10) volumes to preserve parity integrity. Software RAID implementations such as Linux mdadm and Windows Storage Spaces typically pass TRIM to member SSDs. An SSD in a hardware RAID 1, 5, or 6 array may receive no TRIM commands depending on the controller firmware. Deleted data on RAID-member SSDs where TRIM is blocked has the same recovery probability as HDDs in the same configuration.

Hardware RAID IR Mode Exception

Hardware RAID controllers in IR (Integrated RAID) mode, including LSI MegaRAID and Dell PERC H730P / H740P, block TRIM to preserve parity integrity across RAID 5 and RAID 6 arrays. The controller intercepts TRIM commands and drops them before they reach member SSDs. Cross-flashed IT mode firmware or HBA passthrough configurations pass TRIM straight through. A RAID set in IR mode creates a recoverable exception where deleted SSD data behaves like HDD data.

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.

When Is SSD Data Recovery Actually Possible After Deletion?

Recovery after deletion depends on whether the TRIM command reached the drive & whether garbage collection physically erased the NAND. A dead controller, legacy USB bridge, disabled TRIM, or immediate power loss can preserve data that a healthy drive with active TRIM would erase within minutes.

The table below maps common scenarios to their recovery outcomes. SATA SSD recovery at Rossmann starts at From $200 with no diagnostic fee. If we can't recover your data, you don't pay.

Scenario	TRIM / Deallocate Executed?	GC Erased NAND?	Software Possible?	PC-3000 Possible?
Accidental deletion (Windows NTFS internal SSD)	Yes	Usually within minutes	No (controller returns zeroes)	No (physically erased)
Accidental deletion (legacy USB BOT enclosure)	No (blocked by bridge)	No	Yes	Yes
Quick-format in hardware RAID	No (blocked by controller)	No	Yes	Yes
Controller dies immediately after deletion	Yes (logically unmapped)	No (controller failed before GC)	No (drive doesn't mount)	Yes (Safe Mode / Techno Mode)
TRIM disabled in OS	No	No	Yes	Yes
Power loss immediately after deletion	Yes (logically unmapped)	No (GC never ran)	No (controller returns zeroes)	Yes (if GC had not started)

NVMe SSD recovery starts at From $200. Every evaluation is free, and we only bill if we return your data.

Can a Dead SSD Controller Preserve Deleted Data?

A failed SSD controller can preserve deleted data when the controller dies after TRIM marks blocks invalid but before garbage collection erases the NAND. PC-3000 SSD workflows can restore firmware access or image raw NAND without letting the failed controller finish the erase.

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.

Why Does Simply Connecting a Dead SSD Risk Further Data Loss?

A standard write-blocker prevents host writes, but it still allows the controller to boot normally. If the controller initializes successfully, it may run background garbage collection within minutes and erase NAND blocks that were scheduled for deletion.

To freeze the NAND state, the drive must be held in a diagnostic state such as Techno Mode, Safe Mode, or ROM Mode. PC-3000 SSD enters these states by uploading an LDR loader to SRAM or by shorting diagnostic pins during power-on. This halts the FTL and stops background tasks before they can erase data.

Standard forensic write-blockers were designed for hard drives. They intercept ATA commands from the host & prevent write operations, but they don't stop the SSD's internal controller from booting its own firmware. A powered-on SSD with a healthy controller can execute autonomous garbage collection even when every host write is blocked. The controller doesn't need new host commands to erase blocks it already marked for deletion.

The only way to freeze NAND state is to prevent the controller from initializing normally. PC-3000 SSD uploads an LDR loader to SRAM through the diagnostic interface, or the technician shorts ROM_CS or UART pins during power-on to force Safe Mode. This severs the controller's access to NAND before background GC starts. The NAND state is frozen at the moment of power-on, preserving data that TRIM flagged but GC hasn't erased.

Phison SATAFIRM S11 ROM Mode

The PS3111-S11 controller powers the Kingston A400, PNY CS900, and Patriot Burst series SSDs. When firmware validation fails, it enters ROM mode and reports SATAFIRM S11 with 0 bytes capacity.

PC-3000 Phison utility uploads an LDR loader to SRAM, bypasses corrupted SMART tables, and rebuilds the virtual FTL from raw NAND page metadata. Files deleted immediately prior to the crash that were logically unmapped by TRIM but not yet physically erased become accessible because the loader ignores the firmware zero-return mask.

Silicon Motion BSY State

SM2258XT and SM2259XT are DRAM-less controllers found in many budget SATA SSDs. During initialization, corrupted system blocks cause an infinite loop that holds the ATA BSY bit high and freezes the host.

The PC-3000 operator shorts ROM_CS or UART_TX pins during power-on to break the BSY loop and force ROM mode. The compatible PC-3000 SSD Silicon Motion utility uploads a loader to SRAM, and the translator is rebuilt manually or automatically.

PC-3000 SSD Workflow for Controller Failures

Identify controller family (Phison, Silicon Motion, Marvell) and check the PC-3000 SSD support matrix.
If the drive does not enter ROM mode automatically, short diagnostic test points (such as ROM_CS pads) with tweezers during power-on.
PC-3000 uploads a matching LDR microprogram to controller SRAM.
The loader bypasses the corrupted FTL and disables background tasks including garbage collection, wear-leveling, and the firmware zero-return mask.
The technician scans raw NAND pages to rebuild a virtual FTL from surviving page metadata.
PC-3000 scans Out-of-Band spare-area metadata on every physical NAND page, harvesting LBA tags, wear-level counters, and chronological sequence numbers. It mathematically rebuilds the historical Logical-to-Physical mapping table in workstation RAM. Files that were TRIMmed but not yet erased become accessible through this reconstruction.
The logical file system is extracted sector-by-sector and returned to the customer.

All work is performed in-house at our Austin, TX lab, founded in 2008. We do not outsource controller-level recovery to third parties.

Why Chip-Off Fails on Encrypted SSDs

Many modern NVMe and high-end SATA SSDs implement hardware AES-256 encryption bound to the controller silicon. Budget SATA DRAM-less controllers typically use deterministic XOR scrambling rather than full AES-256. If the controller dies, removing the NAND chips and reading them independently yields scrambled or encrypted noise. The encryption key or scrambling seed never leaves the controller.

The only recovery path is board-level microsoldering to repair the original PCB and revive the controller, preserving the encryption keys. We locate failed components using FLIR thermal imaging, replace shorted PMICs or voltage regulators with a Hakko FM-2032 on an FM-203 base station, and perform BGA rework on the controller IC with a Zhuo Mao precision BGA rework station when necessary.

When the original controller boots, the encryption keys are intact and your data is accessible. Board repair is not a separate service from data recovery; for encrypted SSDs, it is data recovery.

How Does Wear-Leveling Complicate SSD Recovery?

Wear-leveling separates a file's logical address from its physical NAND location. Controller-based recovery uses the flash translation layer to resolve that map, but chip-off recovery must rebuild page order, block rotation, XOR patterns, and metadata from raw NAND dumps.

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 Do Operating Systems Handle SSD TRIM?

Operating systems handle TRIM differently by file system, storage driver, and drive connection. Windows NTFS and macOS APFS usually issue TRIM quickly on internal SSDs, while Linux depends on discard or fstrim settings and external drives depend on bridge-chip passthrough.

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.

OS	File System	TRIM Behavior	Recovery Impact
Windows 10/11	NTFS	Immediate, automatic, aggressive	TRIM is issued immediately; actual block erasure depends on SSD garbage collection timing, but the window is short
Windows 10/11	exFAT	Supported natively since Windows 8, but most exFAT volumes use external USB or SD bridges that block TRIM	Recovery likely on external drives with BOT bridges; internal exFAT may still receive TRIM
Windows Server	ReFS	Native TRIM and UNMAP support built into the file system; automatic space reclamation on deletion	Near-zero recovery window; ReFS is aggressive about space reclamation on Server-grade NVMe arrays
macOS	APFS	Immediate, automatic	Near-zero recovery window after deletion
macOS	HFS+ (external)	TRIM not issued on external drives by default	Recovery often possible
Linux	ext4	Depends on mount option (discard or fstrim)	Varies; check mount configuration
Any OS	FAT32	TRIM support varies by OS and driver	Recovery more likely than NTFS/APFS

Internal vs. External TRIM Behavior

Internal PCIe and SATA connections pass TRIM commands immediately and aggressively. External USB enclosures using the legacy Bulk-Only Transport (BOT) protocol, common on chips manufactured before 2015, block TRIM entirely, creating a recovery window that does not exist on internal drives. Modern UASP bridges, standardized in 2015, do pass TRIM, so the enclosure model matters.

On Linux, the discard mount option triggers immediate TRIM on every deletion. Without discard, and without periodic fstrim runs, the operating system may skip TRIM entirely. macOS 10.6.8 and later enable TRIM on internal SSDs by default, while HFS+ on external drives does not send TRIM by default, leaving deleted data recoverable.

Connection	TRIM Passthrough	Typical Speed	Recovery Window
Internal PCIe NVMe (M.2)	Immediate, aggressive	Seconds to minutes	Near-zero
Internal SATA	Immediate	Minutes	Short
External USB 3.0 UASP	Passed through	Minutes	Short
External USB 2.0/3.0 BOT	Blocked entirely	Hours	Same as HDD
Thunderbolt NVMe	Passed through	Seconds	Near-zero
USB-C with UASP	Passed through	Minutes	Short

Windows NTFS TRIM: Internal PCIe/SATA vs. External USB

Windows issues TRIM automatically the moment a file is deleted from NTFS, including when the Recycle Bin is emptied. Internal PCIe NVMe and SATA connections pass TRIM immediately. External USB enclosures behave differently: legacy BOT bridges manufactured before 2015 drop TRIM entirely, while modern UASP bridges pass it through. The actual physical erase still depends on the SSD controller's garbage collection algorithm, not just the OS command.

The fsutil behavior query DisableDeleteNotify command shows the OS-side TRIM setting, not the controller's erase schedule. A return value of 0 means Windows will send TRIM on future deletions. It does not tell you whether garbage collection has already erased the NAND blocks for files you deleted yesterday.

Disabling TRIM after deletion via fsutil behavior set DisableDeleteNotify 1 does not reverse TRIM commands already sent. It only stops future deletions from triggering TRIM. If garbage collection hasn't run yet, powering down immediately preserves data. Changing an OS setting while the drive is idle just gives the controller more time to erase.

Linux fstrim.timer vs. Continuous discard

Linux distributions that mount ext4 with the discard option send TRIM immediately on every deletion, matching Windows NTFS behavior. Distributions that don't use discard typically run fstrim.timer, a systemd service that issues TRIM weekly by default. Files deleted between weekly fstrim runs haven't been TRIMmed yet, so they remain recoverable.

Without discard and without fstrim.timer running, the SSD never receives TRIM commands at all. Files deleted in this configuration remain recoverable with the same probability as on a hard drive until the next manual fstrim runs. Check your mount options with findmnt -o TARGET,OPTIONS / to see whether discard is active.

macOS trimforce for Third-Party SSDs

macOS enables TRIM on internal Apple SSDs by default starting with 10.6.8. Third-party aftermarket SSDs installed in Macs have TRIM disabled by default unless the user runs trimforce enable, introduced in OS X 10.10.4. If you installed a non-Apple SSD & never enabled TRIM, deleted files remain recoverable with the same probability as on a hard drive.

macOS T2 & Apple Silicon: Encryption Combined with TRIM

T2 and M-series Macs combine APFS TRIM with hardware-level AES-256 encryption managed by the Secure Enclave. On deletion, the system destroys the cryptographic key for that file's data blocks in addition to issuing TRIM. Even if garbage collection were somehow halted, the encrypted ciphertext lacks the key. Data becomes mathematically unrecoverable almost instantly.

We do not bypass, crack, or defeat T2/M-series security. Recovery on these systems requires board-level repair of the original logic board so the Secure Enclave functions normally. Board repair is data recovery for Apple Silicon SSDs.

Virtual Machine TRIM Passthrough

VM hypervisors handle TRIM differently depending on storage configuration. In some setups, the guest OS issues a TRIM command, the hypervisor intercepts it, & the underlying host SSD never receives a physical Deallocate command. The guest sees a TRIM success, but nothing happens to the physical NAND.

In other configurations, the hypervisor passes TRIM straight through to the host, which then processes it normally. VMware ESXi with thin-provisioned VMDKs often translates guest TRIM into UNMAP on the datastore. VirtualBox with raw disk passthrough also passes TRIM to the host SSD. Hyper-V behavior varies by virtual disk format & host OS version.

The result is unpredictable without checking the specific hypervisor, virtual disk type, & storage backend. A TRIMmed file inside a VM may or may not be erased on the physical SSD underneath.

Hyper-V VHDX and Generation 2 VMs

Hyper-V on Windows Server allows TRIM and UNMAP passthrough to virtual hard disks (VHDX) when the guest is a Generation 2 VM running Windows Server 2012 or later. The host Cluster Shared Volume must be formatted as NTFS or ReFS with thin provisioning enabled. If the CSV uses a fixed-size VHDX or an older Generation 1 VM BIOS, the hypervisor drops TRIM commands before they reach the physical SSD.

Files deleted inside a Hyper-V guest on a fixed VHDX may survive on the physical host SSD because the hypervisor never forwards the Deallocate command. On a dynamically expanding VHDX with passthrough enabled, the physical SSD receives the same TRIM or UNMAP command the guest issued, & garbage collection erases the NAND normally.

How Do You Check if TRIM Is Enabled on Your SSD?

Windows, macOS, and Linux each provide a built-in command or system report to verify whether TRIM is active on your SSD. Checking TRIM status takes 10 seconds and prevents wasted software scans; if TRIM is enabled, consumer tools like Disk Drill can't recover deleted files. The controller returns zeroes for unmapped blocks.

Knowing whether TRIM is active helps you decide whether software recovery is worth trying. If TRIM is on, consumer tools will see only zeroes.

Windows: Open an elevated command prompt and run fsutil behavior query DisableDeleteNotify. A return value of 0 means TRIM is enabled; 1 means it is disabled.
macOS: Open System Information and navigate to SATA/SATA Express or NVMExpress. Look for "TRIM Support: Yes." Third-party SSDs installed in Macs require trimforce enable to activate TRIM.
Linux: Run lsblk -D to see DISC-GRAN and DISC-MAX columns; non-zero values indicate TRIM support. You can also test with fstrim -v / to see how many bytes would be trimmed.

If TRIM is active, recovery software is futile. The controller returns DZAT or DLFEAT zeroes instantly. Only lab-level tools that bypass the firmware mask can access raw NAND, and only if garbage collection has not yet erased the cells.

What Should You Do After Deleting Files from an SSD?

Power the SSD down, stop scans, and do not install recovery software on the same computer. Every minute of idle power gives the controller more opportunity to run garbage collection. A laboratory diagnostic evaluation can determine whether the media falls into a recoverable edge case or whether physical erasure has already completed.

Shut the computer down instead of restarting or running file recovery scans.
Disconnect external SSDs after safe shutdown so background garbage collection stops. Sleep mode is insufficient; the controller remains powered and can run garbage collection or Idle-Time Media Scan while the system sleeps.
Do not clone the SSD through normal OS tools when the drive still mounts.
Document the operating system, file system, enclosure model, and time since deletion.
Use mail-in data recovery when the drive needs lab evaluation without a local storefront visit.

Why abrupt disconnect can be safer than graceful shutdown: A graceful shutdown gives the controller time to flush caches, update SMART tables, and potentially trigger idle-time garbage collection before power is removed. If the drive has TRIMmed blocks that haven't been erased yet, a normal shutdown sequence may trigger the very erase you're trying to prevent. For an external SSD with a known BOT bridge that blocks TRIM, the risk is low. For an internal NVMe drive, the safest action is to pull power immediately rather than letting the OS run its shutdown routine.

Why Can SSD Recovery Software Mislead Users?

SSD recovery software can mislead users because it scans through standard operating system reads. After TRIM, Deterministic Read Zero After TRIM makes those reads return zeros for unmapped sectors, so software cannot see NAND cells that hardware-level SSD tools must access below the file system.

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 the controller's firmware mask 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 (SATA) or DLFEAT zero-return (NVMe), 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 because the controller synthesizes zeroes. NAND cells after a physical erase command hold no data.

Some software vendors market TRIM recovery as possible if you "act fast" and disable TRIM. EaseUS, Wondershare, and iMyFone advertise features that imply deleted SSD files are recoverable after TRIM. This contradicts the engineering reality. DZAT (SATA Word 69 bit 5) makes the controller return zeroes instantly for unmapped LBAs. There is no window for software to act.

Disabling TRIM after deletion does not reverse TRIM commands already issued by the OS. The OS already told the controller which blocks to unmap. The controller's firmware mask is already active. Changing the OS setting only prevents future deletions from triggering TRIM. It can't restore data the controller has already masked.

Why Do Recovery Tools Find 0-Byte Files After TRIM?

Modern SATA SSDs use Deterministic Read Zero After TRIM (DZAT), while NVMe SSDs enforce equivalent zero-return behavior through Deallocate Logical Block Features (DLFEAT). The controller intercepts read requests for unmapped logical blocks and instantly returns zeroes to the operating system. This happens before physical NAND erasure completes, so software scanning the drive sees synthetic zeroes instead of the original data.

Early SSDs implemented non-deterministic TRIM, where reads might return stale data, zeroes, or random values. Modern drives use a firmware mask that guarantees consistent behavior.

Non-Deterministic TRIM: Early SSDs. Reads after TRIM may return stale data, zeroes, or random values depending on the controller state.
DRAT (Deterministic Read After TRIM): Reads return a consistent value after TRIM, though not necessarily zeroes. The controller guarantees predictability but may return a fixed non-zero pattern.
DZAT (SATA) / DLFEAT Zero-Return (NVMe): On SATA SSDs, DZAT guarantees zeroes after TRIM. On NVMe SSDs, the Deallocate Logical Block Features (DLFEAT=001b) field provides the equivalent zero-return behavior. The controller synthesizes and returns zeroes instantly. Software reads zeroes even if the physical NAND has not yet been erased.

SATA IDENTIFY DEVICE Word 69 & NVMe Identify Namespace DLFEAT

SATA DZAT is defined in IDENTIFY DEVICE Word 69, bit 5. DRAT occupies Word 69, bit 14. Basic TRIM support (Data Set Management) is reported in Word 169, bit 0. If this bit is set but Word 69 bits 5 and 14 are cleared, the drive has non-deterministic TRIM. A drive that sets bit 5 guarantees zeroes for all LBAs unmapped by TRIM.

NVMe DLFEAT lives in byte 33, bits 2:0 of the Identify Namespace metadata. A value of 001b means read deallocated block returns zeroes. You can verify this on Linux with nvme id-ns /dev/nvme0n1 -H | grep -A 4 "dlfeat".

In both SATA and NVMe, standard OS reads return whatever the controller's firmware mask promises. Software can't override the mask; only hardware-level bypass through PC-3000 SSD Safe Mode or Techno Mode can read raw NAND below it.

Specific controller families implement DZAT and DLFEAT zero-return with different strictness. The Phison PS5018-E18 and E21 controllers set DLFEAT=001b on most retail firmware revisions, enforcing immediate zero-return for deallocated LBAs. Silicon Motion SM2262EN and SM2258XT families return zeroes for deallocated LBAs through firmware-level masks. Samsung Elpis (980 Pro) and Pascal (990 Pro) enforce DLFEAT zero-return strictly. Rossmann does not currently offer in-lab recovery for Samsung Elpis or Pascal controllers.

Verifying DZAT and DLFEAT from the Command Line

On Linux, you can query the controller's post-TRIM behavior directly without third-party tools. For SATA SSDs, run hdparm -I /dev/sda | grep -A 2 "Trim" to see whether the drive reports "Deterministic read ZEROs after TRIM." For a more verbose output, smartctl -x /dev/sda prints the IDENTIFY DEVICE word map including Word 69 and Word 169.

For NVMe SSDs, run nvme id-ns /dev/nvme0n1 -H | grep -A 4 "dlfeat". A DLFEAT value of 001b confirms the drive returns zeroes for deallocated ranges. Some drives report DLFEAT values other than 001b, indicating multiple LBA formats or vendor-specific behavior. In every case, standard OS reads return whatever the controller's DLFEAT field promises; software can't bypass it.

Windows users can check TRIM support via fsutil behavior query DisableDeleteNotify, but that only reports the OS-side setting. It does not reveal the controller's DZAT or DLFEAT mask. The Linux commands above interrogate the controller firmware directly.

This is why Disk Drill, EaseUS, & R-Studio often recover files that are 0 bytes or filled with zeroes. The software is not broken. The SSD controller is feeding it synthetic zeroes through the firmware mask.

When Is Recovery Mathematically Impossible?

SSD data recovery is mathematically impossible when NAND blocks have been physically erased by garbage collection, when DZAT/DLFEAT zero-return is active on a healthy controller, or when a modern Samsung or WD NVMe drive has been idle for hours after deletion. These aren't limitations of Rossmann's lab; they're certainties of NAND flash physics.

We don't sugarcoat this. If the NAND blocks that held your files have been erased by garbage collection, no lab on earth can recover them. The erase command applies +15-20 volts via Fowler-Nordheim tunneling to reset every bit to 1. There's no residual magnetic signature like on a hard drive. Erased NAND cells hold no recoverable information.

If DZAT (SATA) or DLFEAT zero-return (NVMe) is active & the controller is healthy, software can't bypass the firmware mask. The controller synthesizes zeroes instantly for unmapped LBAs. Standard OS reads return whatever the controller promises; no software can override it.

If your drive was idle for hours after deletion on a modern Samsung or WD NVMe SSD, the data is gone. Samsung controllers often run garbage collection within seconds of idle time. A powered-on drive left overnight has completed physical erasure. This isn't a failure of our equipment; PC-3000 SSD, Hakko FM-2032, & FLIR thermal cameras can't reverse a +15-20 volt NAND erase. No tool can.

The erase applies +15-20 volts to the P-well substrate while holding control gates at ground. Fowler-Nordheim tunneling forces trapped electrons through the oxide barrier. Once complete, every cell reads 0xFF. There is no residual charge pattern, no sub-threshold margin, and no forensic technique to recover it.

Hard drives retain deleted data as magnetic flux until overwritten. Magnetic remanence allows forensic recovery of overwritten sectors in some cases. SSDs have no equivalent physical mechanism. After garbage collection erases a NAND block, the electrons are physically gone.

Samsung Elpis (980 Pro) and Pascal (990 Pro) controllers often begin garbage collection within seconds of idle time. Rossmann does not currently offer in-lab recovery for these controllers. If the drive was idle for hours after deletion on a modern Samsung NVMe SSD, the data is gone. No lab on earth can reverse a +15-20 volt NAND erase.

Frequently Asked Questions

Users frequently ask whether TRIM makes SSD recovery impossible, how long the garbage collection window lasts, why recovery software shows zero-byte files, and whether disabling TRIM after deletion helps. The short answers: recovery is usually impossible once TRIM runs and GC erases NAND, the window depends on the controller, zero-byte files result from DZAT/DLFEAT firmware masks, and disabling TRIM after the fact does not reverse commands already sent.

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 or Deallocate command is issued, the SSD controller guarantees standard OS reads return zeros, even before physical erasure occurs. SATA SSDs use Deterministic Read Zero After TRIM (DZAT); NVMe SSDs enforce the same behavior through Deallocate Logical Block Features (DLFEAT). Disk Drill and similar tools rely on these standard APIs. Because the controller synthesizes zeroes, 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.

Why does recovery software find my files but they are 0 bytes?

Modern SATA SSDs use Deterministic Read Zero After TRIM (DZAT), while NVMe SSDs enforce equivalent zero-return behavior via Deallocate Logical Block Features (DLFEAT). The controller intercepts read requests for unmapped blocks and instantly returns zeroes to the operating system. Software tools like Disk Drill, EaseUS, and R-Studio scan through standard OS reads, so they see synthetic zeroes even if the physical NAND has not yet been erased. The software is not broken; the SSD controller is feeding it a firmware mask of zeroes.

Does formatting an SSD erase data permanently?

A quick format on a modern SSD issues a massive TRIM or Deallocate command across the entire partition. Because of DZAT (SATA) or DLFEAT zero-return (NVMe), the controller immediately returns zeroes for all unmapped sectors. The data appears erased instantly to software. Physical NAND erasure by garbage collection follows shortly after. Recovery is only possible if the format was performed on a drive that does not support TRIM, uses a legacy USB bridge that blocks the command, or if the controller failed before garbage collection ran.

What is the difference between TRIM, UNMAP, and Deallocate?

ATA TRIM is the SATA command set for marking blocks invalid. NVMe Deallocate is the equivalent command in the NVMe protocol over PCIe. SCSI UNMAP is the enterprise command used in SAS and SAN environments. All three perform the same logical function, telling the controller which blocks are no longer needed so it can schedule them for physical erasure during garbage collection.

Can a dead SSD controller actually help recover deleted files?

Yes, paradoxically. A dead controller cannot execute garbage collection. If the controller fails after marking blocks invalid via TRIM but before physically erasing them, the NAND retains the original data. PC-3000 SSD can access the raw NAND in Safe Mode or Techno Mode, bypass the corrupted FTL, and ignore logical TRIM flags. Files that would have been erased on a healthy drive may still be recoverable in this specific scenario.

Why does recovery software show my file names but the files are 0 bytes?

Recovery software scans the Master File Table (MFT) on NTFS or the file system catalog on APFS. Deleting a file unlinks the MFT pointer but triggers TRIM on the underlying data blocks. The MFT entry itself survives, so software like EaseUS, Disk Drill, or Stellar recovers the file name & size metadata. When the software reads the actual data, the SSD controller returns DZAT zeroes for those LBAs. The result is a file that appears correct in the directory listing but contains no data.

Can a quick-formatted SSD be recovered?

A quick format issues TRIM or Deallocate across the entire partition, destroying the primary FTL mapping table. However, many controllers keep redundant historical copies of the translator metadata in the NAND service area. If garbage collection hasn't yet erased those service area blocks, PC-3000 SSD can reconstruct the translator from the surviving copies and recover the data. If GC has already run, the data is gone.

Does TRIM run on external USB SSDs?

It depends on the USB bridge chip. Legacy Bulk-Only Transport (BOT) bridges, common on enclosures manufactured before 2015, block TRIM entirely. The OS issues the command to the bridge, & the bridge discards it. Modern UASP bridges, standardized in 2015, do pass TRIM through to the SSD. Check your enclosure model; if it uses BOT, deleted files may still be recoverable.

How long do I have before garbage collection erases my deleted files?

The window varies by SSD controller manufacturer. Samsung controllers often begin erasing TRIMmed blocks within seconds of idle time. Silicon Motion controllers frequently defer garbage collection until the reserve pool of free blocks drops below a firmware-defined threshold, potentially leaving data intact for minutes to hours if the drive isn't heavily written. Phison behavior varies by firmware revision. There's no universal answer; the controller's algorithm decides.

How do I check if TRIM is enabled on my SSD?

On Windows, open an elevated command prompt and run fsutil behavior query DisableDeleteNotify. A return value of 0 means TRIM is enabled; 1 means it is disabled. On macOS, open System Information and navigate to SATA/SATA Express or NVMExpress; look for 'TRIM Support: Yes.' Third-party SSDs in Macs require trimforce enable to activate TRIM. On Linux, run lsblk -D to see DISC-GRAN and DISC-MAX columns; non-zero values indicate TRIM support. You can also test with fstrim -v / to see how many bytes would be trimmed.

Can disabling TRIM after deletion recover lost data?

No for data already TRIMmed. Disabling TRIM after deletion does not reverse TRIM commands the operating system already sent. If garbage collection has not yet erased the NAND, disabling TRIM can prevent new TRIM commands from wiping additional recoverable fragments. The correct action is to power down the drive immediately rather than spending time changing OS settings. Every second of idle power gives the controller more opportunity to run garbage collection.

Can forensic tools recover TRIMmed SSD data?

Standard forensic imaging tools (dd, FTK Imager, EnCase) read through the same OS block-device APIs as consumer software. After TRIM, DZAT/DLFEAT guarantees the controller returns zeroes for unmapped LBAs. Forensic tools see the same synthetic zeroes. The only forensic path is hardware-level bypass: PC-3000 SSD in Safe Mode or Techno Mode, which reads raw NAND below the firmware mask. This requires the controller to be supported by PC-3000 and the NAND to not yet be erased by garbage collection.