Data Recovery Case File · Trust, Practice & Honest Limits · Case 1,800 · What the Device Was Holding
Sometimes the Machine Is the Thing You Need, and You Find Out Too Late
The eighteen hundredth file in this archive opens a new question, and it does so by contradicting the last one. A laptop that "got (a little) water on it and now won't boot", whose owner adds something that changes the whole job: "my phone also recently crashed, so I am worried that I won't be able to get back into any services that need a second factor. Getting the data off the laptop would certainly be nice, but if it can be made to run again so I can get back into my account, that would be ideal." He does not primarily want his files. He wants a credential — and that is a different piece of work.
| Media | Laptop of approximately six years, running a Linux-based system — liquid exposure followed by failure to start; second-factor authentication material held on the device; owner's phone separately non-functional |
| Reported situation | Laptop approximately six years old · limited liquid exposure · machine no longer starting · owner's phone separately having crashed · concern regarding access to services requiring a second authentication factor · stored data desired · restoration of the machine to working order preferred if achievable |
| Fault class | Liquid ingress with progressive corrosion — storage not implicated by board-level damage; authentication material recoverable from the filesystem where board restoration is not achievable |
| Equipment used | Required outcome established as credential access before technical approach was chosen · powering stopped and board cleaned before any assessment · drive removed and imaged write-blocked independently of the machine · authentication and configuration material located within the filesystem · board repair pursued in parallel where restoration was viable |
The decode: four things this case opens, at the start of a site
The first — the question to answer before any technical one is what you actually need. Almost every enquiry in this archive wants files. His does not, quite. He needs to prove to a service that he is who he says he is, and the laptop happens to be the thing that can do it. Establishing that before choosing an approach is the difference between a job that solves his problem and one that merely succeeds — because handing him a drive full of recovered files would leave him exactly as locked out as he is now.
Why this inverts what usually holds: the ordinary advice is that the device does not matter and the data does. Here the device may be the point — not because the machine is precious, but because what it holds is not a document but an ability. That is worth stating plainly at the opening of a site: the useful question is not "what is stored on it" but "what depends on it".
The second — a second factor is a dependency you cannot see until both halves fail. The design is deliberate: two independent things, so that losing one is survivable. He lost both — a phone that crashed and a laptop that got wet, unrelated events days apart. Either alone would have been an inconvenience, because each could have authorised the replacement of the other.
Why that shape recurs throughout this archive: it is the same failure as a mirrored pair whose drives were bought together and aged identically, and the same as a folder deleted from a computer and from the backup drive holding it. Redundancy protects against the failures it anticipated, and the ones that take both copies are the ones nobody planned for.
The third — the audit worth doing is of dependencies, not contents. People know roughly what files they hold. Almost nobody can list what would become unreachable if a particular device stopped working — authenticator entries, saved sessions, keys, a password vault, recovery codes stored on the thing they protect. Those are not documents; they are the device's role rather than its contents, and the moment you discover the list is the moment you can no longer ask it.
What that suggests concretely: backup codes printed and kept away from both devices, a second factor registered on something that will not fail alongside the first, and a recovery address that does not itself require the factor being recovered.
The fourth, and the technical heart — the goal decides the method, and here the two goals converge. If he needed files, the answer is simple and the laptop is irrelevant: remove the drive, image it, done. Because he needs a credential, restoring the machine becomes a legitimate objective rather than a distraction — and water damage is the fault where that is most often achievable, since corrosion is board-level, the storage is rarely implicated, and cleaning with component-level repair frequently returns a machine that would not start.
Why the drive should be imaged first regardless: on a Linux system the material that authenticates him is held in files. Authenticator seeds, keys and session state live in the filesystem, so recovering the drive may resolve the credential problem without the laptop ever running again — which means the two objectives are not alternatives, and the safe one comes first.
What should happen in parallel and costs nothing: the account's own recovery routes. Backup codes, a registered recovery address, an identity verification process — all faster and cheaper than any of this, and worth exhausting before the outcome depends on hardware.
What must not happen — and this is the urgent part: no charging it, no attempts to switch it on. Corrosion needs moisture, contaminants and an electrical potential; the water supplied the first two and every connection supplies the third. A device left unpowered corrodes slowly, and one being tested corrodes fast.
On the bench
The required outcome was established as credential access before the technical approach was chosen — recovered files not resolving a lockout, so the objective governs the method rather than following from it. Powering was stopped and the board cleaned before any assessment, corrosion requiring moisture, contaminants and an electrical potential, of which the last is supplied by every connection. The drive was removed and imaged write-blocked independently of the machine, and authentication and configuration material located within the filesystem, such material being held in files on a Linux system, with board repair pursued in parallel where restoration was viable.
The outcome
The required outcome established before the approach was chosen, powering stopped and the board cleaned, the drive imaged independently, and board repair pursued in parallel. 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, for the eighteen hundredth file: you have told us the most important thing, which is that files alone would not solve your problem. What you need is an ability rather than a document — and because your authentication material lives in the filesystem, reading the drive may return it without the laptop starting again.
When a device holds your way back into everything else
Unplug it and stop trying to power it, because corrosion needs moisture, contaminants and a voltage — the water supplied two and every charging attempt supplies the third. Then say what you actually need, since recovered files won't resolve a lockout and the objective should decide the method rather than the other way round. Exhaust the account's own recovery routes in parallel: backup codes, a registered recovery address, identity verification. And afterwards, audit dependencies rather than contents — the useful question isn't what's stored on a device but what becomes unreachable without it, which is a list nobody can compile once it has failed.
Stop powering it — call Easy Data Recovery on 028 9002 0144; required outcome established before the approach is chosen, board cleaned before assessment, drive imaged independently with authentication material located in the filesystem.
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.