Data Recovery Case File · Solid State & Flash · An Honest Limit
Deleted Content on a Solid-State Device May Be Discarded by the Device Itself
His enquiry names both the mechanism and the device, and together they set a real limit. An audio engineer who "made an error backing up a project", where "the backup software seems to have deleted the project I'm after" — and the destination was a solid-state drive. Two things need saying, one about the software and one about the medium, and the second is where the honest answer gets uncomfortable.
| Media | Solid-state drive holding project content removed by a synchronising backup operation — deletion propagated rather than files copied |
| Reported situation | Project content held for professional audio work · backup operation performed to a solid-state drive · backup software removing the project rather than copying it · content no longer present · recovery of deleted content from the device queried · cost requested |
| Fault class | Deletion propagated by synchronisation — recoverability on solid-state media limited by controller block reclamation following deletion notification |
| Equipment used | Block reclamation behaviour established before any expectation was set · device removed from use and powered down immediately · device addressed with imposed timeouts outside any host storage stack · imaged write-blocked at full physical extent · residual content carved by signature where blocks had not been reclaimed |
The decode: how a backup deletes, and why the medium changes the answer
What synchronising software is designed to do: make two places match. It copies what is missing and removes what should not be there, in whichever direction it was configured.
Why that becomes destructive so easily: the direction is a setting. Configured the wrong way, an empty destination is treated as the correct state and the source is emptied to match.
Why it is not obviously wrong at the time: it reports success. A synchronisation that removed everything completed exactly as instructed.
Why plain copying does not carry this risk: it only adds. Copying leaves the source untouched whatever the destination contains.
Now the medium, which is the harder half: solid-state devices reclaim deleted space. When a filesystem reports a block as no longer in use, the controller is free to erase it in the background.
Why that behaviour exists: performance. Flash must be erased before it can be rewritten, so devices erase in advance rather than at the moment of writing.
What it means for deleted content specifically: deletion can be genuinely final. On a hard drive, deleted content remains until overwritten; on a solid-state device, the controller may have discarded it without anything being written.
Why that is stated plainly rather than softened: it is the honest position. This is the one common situation where deleted content may be unrecoverable regardless of effort or expense.
Why it is nonetheless worth assessing: reclamation is not instant. It proceeds in the background over time, and a device powered down promptly may retain a great deal.
What determines how much: elapsed powered time. The device should be disconnected now, because reclamation continues whenever it is running, whether or not anything is being written.
On the bench
Block reclamation behaviour was established before any expectation was set — synchronising software making two locations match in a configured direction, so an empty destination can cause a source to be emptied, reporting success either way. Solid-state controllers are additionally free to erase blocks reported as unused, since flash must be erased before rewriting, meaning deletion can be final without anything being overwritten. Reclamation is gradual, so the device was powered down immediately.
The outcome
Reclamation behaviour established before expectations were set, the device powered down immediately, and residual content carved where blocks remained. Free assessment, one fixed written figure including VAT; where recovery is not possible, nothing is charged. The decode: this is the one case where deletion can genuinely be final. Solid-state devices erase reclaimed blocks in the background — so disconnect it now, because that continues whenever it is powered.
Files deleted from a solid-state drive
Disconnect it immediately and leave it disconnected — this is the one common situation where deleted content may be genuinely unrecoverable. Solid-state controllers are free to erase blocks the filesystem reports as unused, because flash must be erased before it can be rewritten, so deletion can be final without anything overwriting it. That reclamation happens gradually in the background whenever the device is powered, which is why the clock matters more here than anywhere else.
Disconnect the drive now — call Cambridge Data Recovery on 01223 655015; reclamation behaviour established before expectations are set, imaged at full physical extent, residual content carved where blocks remain.
Request a quote online →
Our case files are drawn from genuine enquiries received by our laboratory over the past ten years, anonymised to protect client confidentiality. Each one describes the diagnostic and recovery procedure our engineers apply to that fault, using the equipment listed.