Data Recovery Case File · Solid State & Flash · The Battery He Pulled

On a solid-state drive, the janitor works after hours: the reimaged SSD decoded honestly — what the quick format left, what the background clean-up had begun to take, and why cutting all power was the best decision available

The enquiry came from an institution's IT support team, and it read like the incident report it was. A user's laptop, due for an operating-system upgrade, "although told it was going to be wiped, was not fully backed up prior to being reimaged." The process, described with the precision that shapes this whole page: "a simple format — partition table wipe, not securely wiped — then the OS image added" via their standard deployment. Then the discovery: "we were consequently told that there was critical data which was only stored on that laptop." And then the response that decided the case: "At that point the laptop was powered down, mains power removed and battery removed." The drive: a 128GB SSD in a compact business laptop — the small-form module kind, as he correctly distinguished, not M.2. Two questions closed the enquiry: a quote, and whether payment could run "via purchase order." Yes to the second, answered properly below; the first got the honest structure it deserved — because on solid-state media, this genre's truths need saying plainly, and his battery-pull is the reason there was good news to ledger at all.

The decode: why SSDs delete actively, what the reimage wrote, and what the battery-pull froze

The janitor, introduced: on a spinning drive, deleted data lies where it fell until something new happens to land on it — deletion is passive, and time is on recovery's side. A solid-state drive is different by design: told that space is free, its controller schedules that space for active erasure, tidying in the background — after the format, after the deployment, whenever the drive has power and idle moments. Deletion on an SSD is a process, not an event. Which transforms the meaning of his response: powering down, pulling the mains, removing the battery — every path to power cut — didn't just stop the users. It stopped the janitor mid-shift. Whatever the background clean-up had not yet reached was frozen in place from that moment. In this genre, no better move exists.

The reimage, sized honestly: his distinction — quick format, not a secure wipe — was exactly the right one to make. The format itself discarded the map rather than the territory; the OS deployment then wrote a fresh system into part of that territory. On a 128GB module, a standard deployment claims a real but bounded share, and it lands where deployments land — not aimed at the user's corners. So the honest pre-assessment picture had three regions: ground the new system had overwritten (gone, plainly); ground the background clean-up had processed before the power died (gone, just as plainly); and ground neither had reached — where a user profile's documents, mail archives and working files had every chance of sitting intact. The proportions were unknowable from outside; stating that, rather than promising, is what the free assessment was for.

The institutional questions, answered as asked: purchase-order payment — yes: organisations are invoiced against their PO in the ordinary way, with the fixed written figure, including VAT, quoted first so the paperwork and the promise match. And the report was written for its two audiences from the start: technical detail for the team, plain findings for the user whose data it was.

The recovery: imaged cold, ledgered warm

The module was imaged under controlled power on native connections — first contact managed so the drive's housekeeping gained no second shift — and all analysis ran on the copy. The deployment's footprint was mapped; the surviving expanse beyond it was worked with deep-structure recovery aimed at the user's world: profile areas, document stores, mail data, application working files. Every candidate was opened and tested, not counted and hoped. The result went into the ledger this genre demands: recovered and verified in one column — the substantial majority of the user's critical working data, caught beyond the deployment's reach and ahead of the janitor's — and named but claimed in the other, listed plainly where overwrite or clean-up had already passed.

The outcome

The critical data delivered itemised and verified, invoiced against the institution's purchase order exactly as requested, with the two-column ledger leaving nothing ambiguous for either audience. Free assessment, one fixed written figure including VAT, no recovery, no fee. And the incident's real lesson travelled back with the report, addressed to process rather than people: on solid-state fleets, "told it was backed up" deserves verification before the reimage — because afterwards, the drive itself joins the far side of the race.

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.