Data Recovery Case File · Solid State & Flash · The Controller Is in the Way
On Flash the Structures May Be Intact and in the Wrong Place
This enquiry came from somebody helping a colleague and it reports a familiar symptom on unfamiliar hardware. A solid-state drive that "one day flicked from a normal filesystem to raw data", still visible to the system. On a mechanical drive that phrase usually means damaged structures. On flash there is a second explanation, and it changes what should and should not be attempted.
| Media | 1TB solid-state drive in an internal card format — volume presenting without an identifiable filesystem; device enumerating normally |
| Reported situation | Solid-state drive in normal service · volume ceasing to present an identifiable filesystem · device still visible to the host · no impact or interruption reported · colleague's data required |
| Fault class | Filesystem not identifiable with the device enumerating — structure damage and translation layer inconsistency both consistent; discard activity time-critical |
| Equipment used | No repair or format permitted · translation layer consistency assessed alongside filesystem structures · drive powered as little as possible to limit discard processing · imaged write-blocked · structures located by signature across the image rather than by address |
The decode: two mechanisms behind one description
What the description means: the system found a partition, went to the place its filesystem should begin, and did not recognise what was there. So it reports the volume as having no identifiable format — which is a statement about what it read, not about what exists.
The first mechanism, familiar from mechanical drives: the structures were damaged. An interrupted write, an unclean shutdown, or a region that cannot be read. The content sits untouched and its description is broken, and reconstruction from backup copies of those structures is routine.
The second mechanism, specific to flash: the controller's mapping has become inconsistent. Every read on a solid-state drive is translated — the system asks for an address and the controller decides which physical block actually holds it. If that mapping is damaged, the system asks for the start of the filesystem and receives the contents of somewhere else entirely.
Why that produces an identical symptom: the system sees data it cannot interpret, and reports exactly the same thing. But nothing is damaged — the structures are intact and the drive is returning the wrong blocks for them.
Why the distinction matters: filesystem reconstruction works in the first case and not in the second, because in the second there is nothing wrong with the filesystem. What is required instead is locating structures by their signatures across a captured image, rather than trusting the addresses the drive reports — which finds them wherever the mapping has put them.
Why the drive being visible is useful: the controller is powered, executing and presenting a device with a capacity. So any mapping fault is partial rather than total, and there is something to read.
Why this is more urgent than the same symptom on a hard drive: solid-state drives process discard instructions and run background housekeeping, clearing blocks the system has released. Every hour powered is time for the controller to tidy away blocks that a reconstruction would have used. On a mechanical drive, waiting costs nothing; here it does.
What must not happen: no format and no repair. A repair writes, and writing to a device whose mapping is inconsistent places new data at addresses nobody can predict — which can damage regions that were fine.
On the bench
No repair or format was permitted, writing to a device with inconsistent mapping placing data at unpredictable physical locations. Translation layer consistency was assessed alongside filesystem structures — a solid-state drive translating every read, so a damaged mapping returns the wrong physical blocks for correct addresses and produces an identical symptom to genuine structure damage while nothing is actually damaged. The drive was powered as little as possible to limit discard processing, and structures located by signature across the image rather than by address.
The outcome
Mapping consistency assessed alongside the structures, powered time minimised, and structures located by signature rather than by reported address. Free assessment, one fixed written figure including VAT; where a chip has to be removed, 50% of parts and labour is payable upfront with the balance only on success — otherwise no recovery, no fee. The decode: on flash there are two explanations for that symptom. The structures may be damaged, or the controller's mapping may be returning the wrong blocks for correct addresses — in which case nothing is damaged and everything is in the wrong place.
Solid-state drive whose volume lost its filesystem
Stop powering it, and don't run a repair or accept a format. Two things produce that symptom on flash and only one of them is damage. The structures may genuinely be broken, as on any drive. Or the controller's mapping may have become inconsistent — every read on a solid-state drive is translated, so if that mapping is damaged the system asks for the start of the filesystem and receives some other block entirely, while nothing is actually wrong. Repairs write, and writing to a device with unreliable mapping puts data at unpredictable locations. Time matters more here than on a hard drive, because the controller clears released blocks in the background whenever it runs.
Power it down now — call Oxford Data Recovery on 01865 593000; mapping consistency assessed alongside the structures, imaged write-blocked, structures located by signature rather than by reported address.
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.