Data Recovery Case File · Trust, Practice & Honest Limits · What Happens to My Files in Your Lab
"I was wondering about exposure of my files during any recovery — I'm sure that's what criminals say": the question answered properly — who sees what, under what law, held where, and deleted when — plus the stick that started it, recovered
His enquiry earned this page twice over: once for the fault, and once for the question. The fault: a Kingston 512GB USB stick that corrupted "whilst uploading two files together — something I've done many times", now refusing to open ("USB requires format"); a consumer recovery program that "identified a load of the files by their correct name — but the laptop cut the power to the USB halfway through the recovery, and the result was useless." His response since: nothing — "obviously it's best to install it as little as possible" — exactly right, and doubly so given the stakes: mid-migration between cloud services, "this is the only copy of these files in existence." And then the question, asked with a nervous joke — "I was wondering about exposure of my files during any recovery? I'm sure that's what criminals say. I can assure anyone there's nothing illegal on the stick." No assurance needed: it's the most legitimate question in this trade, everyone thinks it, almost nobody asks — and it deserves the complete answer this page gives before the recovery itself is even described.
| Media | Kingston 512GB USB flash drive — corrupted during a simultaneous two-file write; "requires formatting" on connection; sole copy of the contents, caught mid-cloud-migration |
| Reported situation | Consumer recovery run found files by name before losing power mid-recovery · owner has since minimised all connection, correctly · confidentiality of contents during recovery explicitly raised |
| Fault class | Filesystem corruption from an interrupted parallel write, compounded by an interrupted recovery pass — plus a practice question answered as policy, in writing |
| Equipment used | Confidentiality terms stated in writing first · stick imaged write-blocked (DeepSpar USB Stabilizer 10Gb) · filesystem reconstruction on the image; OSForensics validation · secure custody throughout; working copies certifiably deleted after confirmed delivery |
The decode: the confidentiality answer, then the corruption
Who sees what — the honest shape of it: the truthful answer starts by not pretending: recovering data requires looking at its structure. An engineer rebuilding a filesystem sees folder trees and filenames; verification means confirming files open. What a professional practice does is bound that necessity hard: access on a need-to-access basis only — the engineer on the case, for the purposes of the case, and no one and nothing else; no browsing beyond what the work requires, no judgement of what's found, and no discussion of contents with anyone but the client. His nervous assurance gets the reply it deserves: nobody here needed it. The files of strangers pass across this bench daily, and the professional habit is the same as a doctor's — look exactly as far as the treatment requires, and forget the rest.
Under what law, held where, deleted when: the framework isn't a promise, it's obligation: client data is handled under UK data-protection law, which binds a recovery lab as it binds anyone processing personal data — lawful purpose, minimal access, secure handling. Custody is physical and specific: the stick and every working image live on secured systems, are never uploaded to anything, never leave the lab's control, and travel back to him — original and recovered copy — by the means he approves. And the piece almost nobody thinks to ask: afterwards. Once delivery is confirmed and he's verified his files, the lab's working copies are deleted, certifiably — the recovery leaves no second archive of his life behind it. Terms to that effect go in writing with the assessment, because confidentiality you can't hold in your hand is just mood music.
The corruption itself, briefly: the fault follows patterns this archive documents deeply elsewhere: two files writing at once means interleaved filesystem updates, and the failure mid-write left the structures torn — "requires formatting" is the standard costume. The consumer tool's find-by-name success was the encouraging sign it always is (the catalogue survives; the data likely does too), and the power cut that killed it mid-run did him one accidental favour wrapped in a real risk: recovery reads shouldn't harm, but a stick losing power mid-operation is exactly the event that deepens corruption — making his stop-everything instinct, and the write-blocked image that must come next, the correct whole of the plan.
On the bench
The paperwork led: confidentiality and custody terms stated in writing alongside the assessment — the answer to his real question, signed before the technical one was touched. The stick was then imaged write-blocked behind the DeepSpar USB Stabilizer 10Gb — one complete read, its last required connection — and the torn filesystem reconstructed on the image: the interrupted parallel write's damage resolved, the catalogue his consumer tool had glimpsed rebuilt in full, and every file OSForensics-verified by opening. The sole-copy migration set came home on fresh media; the lab's working copies followed the written terms into certified deletion once his verification confirmed delivery. Need-to-access, start to finish — and then not even that.
The outcome
The stick's only-copy contents recovered, verified, and delivered — with the confidentiality question answered first, in writing, as policy rather than reassurance. Free assessment, one fixed written figure including VAT; on cards and sticks where content has been deleted or overwritten, the figure is payable upfront. And the question itself, honoured for everyone who's swallowed it: asking "who sees my files?" doesn't mark you as suspicious — it marks you as paying attention. The answers you're owed are specific: need-to-access practice, data-protection law, secure physical custody, no uploads, and certified deletion of working copies after delivery. Any lab that answers with a wink instead of terms in writing has answered a different question.
Nervous about who sees your files during recovery
Ask — it's the most legitimate question in the trade, and the answers you should insist on are concrete: access limited to the engineer on your case for the purposes of your case; handling under data-protection law; your media and its images held on secured systems, never uploaded, never leaving the lab's control; delivery by means you approve; and the lab's working copies certifiably deleted once you've confirmed your files are home — all of it in writing with the quote. No one should need your assurance that there's "nothing illegal" aboard, and no one professional will ask. If a lab can't or won't put its confidentiality practice on paper, take the question — and your drive — somewhere that will.
Terms in writing before the work begins — call Edinburgh Data Recovery on 0131 202 0491; imaged once, recovered on the copy, custody bounded, working copies certifiably deleted — one figure.
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.