Quick answer: When you delete a file on a hard drive, the data stays physically on the disk until it is overwritten, which is why recovery software works. On an SSD it is the opposite: after a delete the operating system tells the controller which blocks are free with the TRIM command, and the controller physically erases those blocks during garbage collection. On a healthy internal SSD with TRIM enabled this process usually runs within seconds to minutes, and the deleted data is destroyed irreversibly. So the first rule for a deleted file on an SSD is to stop using the device immediately, because garbage collection runs even while the disk is idle. Data can still be recovered in these cases: if TRIM is disabled (some USB enclosures, bridges and RAID configurations do not pass TRIM), if TRIM has not yet been processed, or if the fault is a physical controller problem.

As SSDs replaced hard drives, the expectation of getting deleted files back was left behind too. A file accidentally deleted on an SSD usually does not come back with classic recovery software, and the reason is the SSD's internal architecture. This guide explains, at an expert level, why and when the flash translation layer, wear leveling, TRIM and garbage collection destroy deleted data, in which narrow window recovery is possible, and which physical failure scenarios still carry hope.

Why NAND flash writes differently

A hard drive can write new data directly over a sector. NAND flash cannot. In flash memory data is written in pages, but erasing can only be done in much larger blocks. To update a page, its content is first moved elsewhere, then the whole block is erased. Also, each NAND cell survives a limited number of program and erase cycles.

These two constraints require a translation layer between the logical address the SSD shows the user and the physical location where the data actually sits.

The flash translation layer (FTL) and wear leveling

The flash translation layer (FTL) is the map, running inside the controller, that maps logical block addresses (what the operating system sees) to physical NAND locations. When you update a file, the FTL usually does not write the data to its old place; it writes to a new, empty page and updates the map. The old page is now marked invalid.

Wear leveling continuously moves data physically to balance cell wear. So a heavily written block does not tire out, the controller cycles lightly used blocks too. As a result, the data at the same logical address may sit in different physical cells over time, and this movement is entirely under controller control.

This architecture has two important consequences for recovery. First, reaching the physical location from the logical address requires knowing the FTL map; without the map, raw NAND reads are scattered and meaningless. Second, because the SSD moves and erases data in the background on its own decision, deleted data can disappear even if the user does nothing.

TRIM: the command that destroys deleted data

TRIM is the mechanism at the heart of SSD recovery. When you delete a file, the file system marks the blocks that file occupied as free. The TRIM command reports the list of these free blocks to the SSD controller: there is no longer valid data at these logical addresses, you may clean them whenever you want.

When the controller receives this information it marks the corresponding physical pages invalid and erases them during garbage collection. Many SSDs return a fixed value (usually zero) when those addresses are read after TRIM; this is called deterministic read after TRIM (DRAT or DZAT). So the data is not only physically erased, it also becomes logically unreadable.

This is the fundamental difference between SSD and HDD. On an HDD deleted data sits passively until it is overwritten. On an SSD, TRIM turns a delete into an active and fast destruction. We also covered the endurance and behavior dimension of this difference in our HDD and SSD lifespan comparison article.

Garbage collection: why the window closes fast

Garbage collection is the background process where the controller cleans blocks full of invalid pages and makes them reusable. If a block still has valid data mixed with invalid data, the controller gathers the valid pages, moves them to another block, then fully erases the old block.

The critical point is this: garbage collection runs as long as the computer is on and the SSD is powered, even if the user does nothing. So after an accidental delete on an SSD, the recovery window is not hours but often seconds or minutes. The chance of recovering deleted data depends on powering the device off before garbage collection erases those blocks.

Situation HDD TRIM enabled SSD
File deleted data stays in the sector TRIM marks it free
Until overwritten recoverable garbage collection destroys it
While the user sits idle data stays erased in the background
Recovery window long (until overwrite) very short (seconds-minutes)

When data is still recoverable

Although the table looks bleak, recovery on an SSD is not always impossible. There is hope in these cases. If TRIM is disabled: some USB disk enclosures and bridges do not pass the TRIM command, some old operating system or file system configurations do not use TRIM, and on external USB SSDs TRIM often does not work. In that case deleted data behaves like on an HDD and recovery software may work. If TRIM has not yet been processed: if the device was powered off in the short window between delete and garbage collection, the data may still be physically present. If it is inside a hardware RAID: some RAID controllers do not pass TRIM to the underlying disks. If there is a physical fault rather than a software delete: if the controller failed, the data actually sits on the NAND and the problem is reaching it. We also covered format scenarios in our recovering data from a formatted disk article.

Physical failure: a separate world, independent of TRIM

Accidental deletion and a controller fault are two entirely different scenarios and must not be confused. If an SSD is suddenly not recognized, shows the wrong capacity, or does not respond at all, this is usually not because data was deleted but because the controller or power circuit failed. In that case the data is still on the NAND chips; the problem is reaching it.

In this scenario recovery requires repairing the controller or removing and reading the NAND chips (chip off). But there are two big difficulties here. First, even if the raw NAND is read, making the data meaningful requires solving the controller specific FTL map, the scrambling and the error correction code (ECC) scheme. Second, if the disk is self encrypting (SED) the bits read are encrypted and cannot be solved without the key; we covered this limit in our SED and TCG Opal recovery article. We detailed controller and NAND recovery in our NVMe M.2 SSD recovery article and the chip off technique in our NAND extraction article. We examined a brand based SSD recovery approach in our Samsung SSD recovery article.

An honest expectation

It is necessary to be clear here. On a healthy internal SSD with TRIM enabled, accidentally deleted or formatted data is in most cases permanently lost within a short time, and no software can bring it back. Tools that promise you guaranteed deleted file recovery from every SSD are either generalizing the special cases where TRIM does not work or are not realistic. The best defense is not recovery but prevention: backing up important data regularly and on a different medium. The physical failure scenario is separate and can often be recovered in an expert lab. We covered choosing the right recovery software in our best data recovery programs comparison article; but no software can bring back data physically erased by TRIM.

The DSET approach

At DSET we run SSD recoveries in our lab at Ankara Hacettepe Teknokent by diagnosing the scenario correctly up front. We determine whether it is an accidental delete, a format, or a physical controller fault, because these require different methods and have different chances of success. In a delete scenario we assess whether TRIM has been processed and whether the recovery window is still open, and we image the device immediately if possible. In a physical fault we apply controller repair, FTL analysis and, if needed, chip off. In no case do we promise a guaranteed result; we share the probability honestly. If you have deleted data from an SSD, power the device off immediately because the recovery window closes fast, and contact DSET.

Frequently asked questions

Can I bring back a file I deleted on an SSD with recovery software? Usually no. On a healthy internal SSD with TRIM enabled, garbage collection physically cleans the blocks within seconds to minutes after a delete, and the data does not come back. Recovery software can only work in the special cases where TRIM does not run (some USB enclosures, bridges, old configurations) or if the device was powered off very quickly. The safest move is to power the device off the moment you notice the deletion.

Do I have a better chance on an external USB SSD? In some cases yes. Many USB disk enclosures and bridges do not pass the TRIM command to the underlying SSD. In that case deleted data, like on an HDD, can stay physically present until it is overwritten, and the recovery chance rises. It is still not certain; if the device supports TRIM and the command passes through, the data is lost fast anyway. If you are unsure, stop using the device and have it assessed.

My SSD is suddenly not recognized, could the data have been deleted? Most likely no, this is a different scenario. On a suddenly unrecognized SSD the problem is usually not deletion but a controller or power circuit fault. In that case the data is still on the NAND and can often be recovered in a lab with controller repair or chip off. If the disk is not self encrypting the chance of success is higher; if it is encrypted, the key is required.

Sources