Does data recovery work the same on an SSD as it does on a regular hard drive? I accidentally deleted a project folder from my SSD and stopped using the drive right away. I have recovered deleted files from a hard drive before, but does an SSD require a different process?
Deleted files are sometimes recovered, if you stop using the drive immediately. I would not count on recovering them from an SSD after the computer has continued running.
Crucially, deletion only removes the OS’s record of the file, and marks the space it occupied as available for new data. The data itself remains until it is overwritten, usually far later than you expect, so recovery is only guaranteed to work before the space is reused.
This is why it’s important to not continue using the computer, in particular not browsing the web or downloading files. It is perfectly possible for the operating system to write log files anywhere, including places you have no idea about. If the drive with deleted files on it was your system drive, you might want to turn off the computer and recover files from another system, which will involve mounting the drive as a secondary drive. I have personally witnessed users attempt to recover files with recovery software installed on the same partition they were trying to recover, ruining any chance of data recovery.
Software designed to recover deleted data works by scanning for any files that were not properly deleted, including, if deletion was recent and the drive was not heavily used in the meantime, files with intact filenames and folder structure. If filenames are not intact, you’ll have to deal with generic names, and potentially, files that were partially overwritten and are now unreadable. It is important to remember that SSDs will often delete files faster than magnetic drives due to TRIM, potentially to the point of making recovery impossible within a day after deletion. USB flash sticks and memory cards generally behave like older hard drives, meaning that a photo deleted from a camera might be recoverable weeks after deletion, while a similar photo on an SSD laptop might be unrecoverable after less than 24 hours.
In short, I would not rely on recovery software to save me if I accidentally delete a file, but rather prefer conventional backups that allow for far more predictable recovery. I would only consider recovery software a viable option if filenames are intact, and I know that the drive was not heavily used and TRIM was disabled shortly after deletion.
15 Likes
Realistically, the odds are worse on an SSD, but “SSD means impossible” is too absolute. It depends on whether TRIM was enabled and actually reached the drive. Don’t boot from it or install recovery software on it. Make a sector-by-sector image from another system, then scan the image. If the project matters enough to pay for professional recovery, stop before trying several tools, since repeated DIY attempts rarely improve the result.
Check the easy copies before doing a raw recovery scan: Recycle Bin, cloud-sync trash, File History or Time Machine, your IDE’s local history, and any Git remote. For a project folder, those often produce a cleaner recovery than carving files from storage, especially when filenames and directory structure matter.
No, SSD recovery does not work quite the same way as hard-drive recovery. On a hard drive, deleted data may remain readable until another write replaces it. An SSD can receive a TRIM command and discard those blocks internally, so recovery software may find directory entries but get empty or unusable file contents. Full-disk encryption and the SSD controller’s internal block mapping can complicate matters further.
Stopping use was the right move. If none of the backup or version-history options has the folder, keep the SSD powered off and decide whether the project justifies professional recovery. A DIY scan is less risky when performed on an image from another computer, but with a TRIMmed SSD, several different programs usually cannot recover data that the drive has already cleared.
A sector image can create false confidence: it preserves only what the SSD controller still exposes, not blocks already cleared after TRIM. So image first if doing DIY, but don’t expect imaging to improve the odds the way it often does with a damaged hard drive.
A project folder is a particularly awkward recovery target because getting the bytes back is only half the job. Source trees depend on filenames, directory layout, configuration files, and lots of tiny related files. A recovery program might find readable text while losing the paths and names, leaving you with hundreds of generic files that are technically “recovered” but painful to turn back into a working project.
That difference matters more on an SSD because TRIM may leave the old directory metadata visible while the actual file contents read as zeros. If that has happened, switching recovery programs will not fix it. The program is asking the SSD for data that its controller no longer returns.
If a scan does find fragments, don’t judge the result only by whether it recreates the whole folder. Search the recovered material for distinctive class names, function names, comments, error messages, or strings unique to your project. Salvaging the files you spent the most time writing may be realistic even when recreating the exact tree is not. Generated files, source maps, package caches, build directories, and compiled binaries can sometimes help reconstruct pieces too, although decompiling a binary will not restore comments or clean original source.
I’d keep the drive off until deciding what the project is worth. For casual DIY, work from an image and save every recovered file somewhere else. For valuable client or work code, talk to a recovery lab before powering it up repeatedly, but ask them specifically about deleted data from a TRIM-capable SSD. “We recover SSDs” can mean hardware failures, which is a different problem from blocks discarded after deletion.
So no, it does not work the same as recovery from a regular hard drive. Stopping immediately gives you the best remaining chance, but with an SSD the outcome may already have been decided by TRIM before you shut it down.
If the SSD was connected through a USB enclosure or an older storage controller, the outlook may be different because some connection paths do not pass TRIM commands to the drive. In that case, deletion can behave more like it does on a hard drive: the blocks remain readable until reused. Internal NVMe and SATA system drives usually give you much less room for optimism because TRIM commonly reaches them immediately.
Do not reconnect the SSD just to check whether TRIM was enabled. That test cannot undo anything, and powering the drive gives its controller time to process deletion commands it has already received. The useful details to record while the machine is off are the operating system, whether the SSD was internal or external, the type of enclosure or adapter, and whether disk encryption was active.
This connection-path caveat is why I would not treat “SSD” as the whole diagnosis. @hyperlogic is right that imaging is the proper DIY starting point, but the image should be made read-only from another system and stored on a different drive. If it contains zeros where the files were, recovery software has nothing meaningful to work with. If TRIM never reached the SSD, the image may still contain recoverable content.
For an important project, tell a recovery lab that this is a deletion case rather than a failed-drive case, and give them the connection details. Those two jobs require different techniques. The SSD may be perfectly healthy while the deleted data is permanently unavailable, or it may still expose the old blocks because the setup never supported TRIM properly.
TRIM firing doesn’t automatically mean your data is gone the same instant the blocks get flagged. There’s a gap between the OS sending the command and the controller actually wiping the cells during garbage collection, and how the drive answers a read of a trimmed block varies by model. Some return zeros immediately, some return the old contents until the physical erase happens, and a few are non-deterministic about it. So ‘gone within minutes’ is the safe assumption, but it isn’t a law. @lena_codes describing metadata surviving while contents read as zeros is exactly the deterministic-wipe case, and yeah, no amount of tool-swapping fixes that.
Where I’d push back a little is the heavy focus on imaging as the correct DIY start. It’s the right move for a failing drive, but for a plain deletion on a healthy SSD you’re mostly just spending effort to freeze a snapshot that may already be blank. @alphabyte nailed why. If the drive is fine and the data is fine, you don’t need an image. If TRIM already cleared it, the image gives you a perfect copy of nothing. Imaging earns its keep when the hardware is dying and you want to stop stressing it, which isn’t your situation.
Honestly, before any of the recovery talk, I’d spend two minutes on the boring question: was this folder ever touched by anything that keeps history? Editor autosaves, a synced drive, an old commit sitting on a remote you forgot about. Those beat carved fragments every time because you get real filenames back. If none of that exists and the code genuinely matters, keep the drive off and treat it as a deletion case with a lab, not a repair job. Two different problems, two different price tags.
Do not run CHKDSK, fsck, “repair,” or defrag on the SSD. Those tools can change filesystem metadata and will not undo deletion. SSD recovery is less predictable than hard-drive recovery because TRIM may have already made the deleted blocks unreadable.