Data Recovery Case File · Second Fixes & Trade Handoffs · The Promise Nobody Can Make
"They Require All the Data and Cannot Afford to Lose Any"
This enquiry came from an IT provider on behalf of a client, and it contained a sentence that appears in a great many enquiries and deserves addressing directly. A laptop SSD that "is not visible and the OS will not load. The SSD is not available in BIOS, and when it's removed and placed in a USB enclosure the drive fails to initialize. They require all the data on the drive and cannot afford to lose any." The technical elimination is thorough. The last sentence is the difficult one — not because it is unreasonable, but because no bench can promise completeness, and a provider who relays that requirement without a conversation about it is carrying a risk that belongs to nobody in particular.
| Media | Client-owned laptop solid-state drive — absent from system firmware and failing to initialise in an external enclosure; complete recovery stated as a requirement |
| Reported situation | Machine not booting · drive not enumerated by firmware · drive failing to initialise when removed and connected externally · enquiry made by the client's IT provider · complete recovery specified as a requirement |
| Fault class | Controller-level failure with no enumeration — vendor-mode access the realistic route; completeness not determinable in advance |
| Equipment used | Vendor technological and safe-mode access (PC-3000 portfolio, SSD support) · firmware area and translation-layer assessment · imaging on restored access · findings and completeness reported per file, in writing suitable for onward supply |
The decode: the technical position, then the expectation
What the elimination establishes: a drive absent from system firmware and failing to initialise in an enclosure has been tested at the two levels that matter, and neither sees it. That rules out the operating system, drivers, the enclosure's bridge and the host machine, and places the fault at the drive's own controller. On solid-state storage that is the characteristic failure rather than an unusual one — the controller holds the address mapping and often the encryption, so when it fails the drive presents nothing at all.
What the realistic route is: vendor technological and safe modes, which allow a drive whose normal start-up fails to be addressed anyway, its firmware area assessed and repaired, and the drive imaged. That works often enough to be well worth attempting. The honest counterpart, stated before rather than after: where the failure lies in the memory itself rather than the controller's firmware state, reading the packages directly is not the dependable fallback it is on cards and sticks, because the mapping and keys live in the controller.
Now the sentence that matters. "Cannot afford to lose any" describes a consequence, not a capability — it tells you what failure would cost the client, and it is genuinely useful information because it justifies effort and expense. What it cannot do is change what a drive will yield. No firm can promise a complete recovery on a drive it has not opened, and any firm that responds to that sentence by agreeing to it is either misunderstanding or overpromising. The right response is not to flinch from it but to convert it into a plan.
How to convert it: three practical steps a provider can take. Establish a priority order with the client now — if everything cannot come back, what must? That single conversation, held before the work, is worth more than any assurance afterwards, and it lets imaging be sequenced accordingly. Establish what exists elsewhere: cloud accounts, mail archives, server-stored profiles, a backup regime that covered more than anyone remembers. And agree how partial results will be reported — per file rather than as a percentage — so a partial outcome is a document rather than an argument.
Why this protects the provider: because they will be in the room when the result is delivered. A client told in advance that completeness cannot be promised, and asked what matters most, receives a partial recovery as a partial success. A client who was told it would all come back receives the same result as a failure.
On the bench
Access was attempted through the PC-3000 portfolio's SSD support in the drive's vendor technological modes, with the firmware area and translation layer assessed for the corruption that typically prevents start-up. The honest limits were set out in writing before commitment, so that the provider had something to put in front of their client rather than a verbal impression. Where access was restored the drive was imaged immediately and sequenced by the priority order agreed in advance, and the findings — what was recovered, what was not, and where the losses fell, per file — were written for onward supply to someone who had not attended.
The outcome
The drive accessed at controller level where possible, imaged in the client's priority order, and the completeness reported per file in writing. 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 anyone relaying an absolute requirement: "cannot afford to lose any" describes the consequence of failure rather than a capability anyone can supply, and a firm that simply agrees to it is overpromising; convert it instead — agree a priority order with the client before the work, so imaging can be sequenced; establish what already exists in cloud accounts, mail and backups; and agree that partial results will be reported per file rather than as a percentage, so an incomplete outcome arrives as a document rather than a dispute.
When a client says they cannot lose any of it
Have the conversation before the work rather than after the result. Nobody can promise a complete recovery on a drive that hasn't been opened, so a firm that agrees to that requirement is either misunderstanding it or overselling — and you'll be the one in the room when the outcome is delivered. Convert the requirement into a plan instead. Ask the client, now, what must come back if everything cannot: that priority order lets imaging be sequenced to capture the critical material first, while the drive is at its most cooperative. Check what already exists elsewhere — cloud accounts, mail archives, server-stored profiles, backup regimes that covered more than anyone remembers — because that often shrinks the problem substantially. And agree upfront that any losses will be reported file by file rather than as a percentage, so a partial result arrives as a document you can hand over.
Turn it into a priority order — call Glasgow Data Recovery on 0141 404 0294; honest limits in writing before commitment, imaging sequenced to your client's priorities, losses reported per file.
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.