Data Recovery Case File · Cameras, Drones & Cards · Verified Is Not Copied
Checking That the Files Are There Is Not the Same as Having Them Somewhere Else
His enquiry describes a week that closed a window. A card checked over after a job, where "all the video files were there. This morning when I went to back it up, I can't get the card to show up on any device — it's not even showing in disk utility to mount." Verifying content and copying it are different acts, and the interval between them is exposure — a card that reads today is not a card that will read next week.
| Media | Memory card holding professional video footage — verified readable the previous week, subsequently not enumerating on any device or presenting for mounting |
| Reported situation | Card holding commissioned video work · contents checked and confirmed present the previous week · card not appearing on any device when backup was attempted · not presenting in the system's disk utility for mounting · no copy held elsewhere · contents required |
| Fault class | Controller failure between verification and copying — card not completing enumeration; memory not implicated by controller state |
| Equipment used | Absence from the mounting utility distinguished from a filesystem fault · card addressed through hardware with imposed timeouts rather than the host stack · controller state assessed in vendor technological modes · chip-level read past the controller with translation layer reconstructed in software · video streams reassembled and validated by playback |
The decode: what the mounting utility not seeing it means, and the wider lesson
What the system's disk utility would normally show: every storage device present, whether or not its contents can be read. A card with a damaged filesystem still appears there, listed but unmountable — that is precisely the case the tool exists for.
Why its complete absence is more significant: the card is not being presented at all. That places the fault before any filesystem question — the card is not announcing itself, so there is nothing for the utility to list, mountable or otherwise.
What that narrows it to: the controller. A card must complete an introduction before any system can list it, and a controller that cannot finish its own start-up never reaches that point — which is why nothing appears on any device he has tried.
Why that is better news than a filesystem fault sounds: the memory holding the footage is a separate component. It retains what was written to it and is not implicated by a controller that cannot start, so the material is very likely present behind the failure.
Why professional video cards fail this way: they are written to heavily and filled repeatedly. A card that has been through many full cycles is working its controller hard, and controller failure without warning is characteristic of flash media generally.
Why the footage is favourable material: video occupies long continuous regions rather than being scattered in small pieces. Sustained runs reassemble reliably once the memory is read and the distribution pattern rebuilt.
What the week between checking and copying actually was: the entire window. He verified the files existed and then relied on that verification for a week — and in that interval the card failed, so the check turned out to describe a state that no longer held.
Why this is the most useful thing in his account for anyone else: checking is not protecting. Confirming that footage is on a card gives real reassurance and changes nothing about its safety — the material remains in exactly one place, on a device that can fail without warning, and the reassurance can delay the copy.
What the practice worth adopting is: a card is copied at the first opportunity, and verified after the copy exists rather than instead of it. Verification belongs at the destination.
What must not happen: no formatting when a device offers it, no repair utilities, and no further insertion attempts. A controller stuck at start-up stays stuck, and the offer to make the card usable targets what a recovery reads.
On the bench
Absence from the mounting utility was distinguished from a filesystem fault — such a utility listing every present device including those with damaged filesystems, so complete absence indicates the card is not completing enumeration and the fault precedes any filesystem question. The card was addressed through hardware with imposed timeouts rather than the host stack, with chip-level reading performed past the controller, the memory retaining content written before the failure, and video streams reassembled and validated by playback.
The outcome
The absence distinguished from a filesystem fault, the card addressed through hardware, and the memory read past the controller. Free assessment, one fixed written figure including VAT; on cards where content has been deleted or overwritten, the figure is payable upfront. The decode: not appearing in the mounting utility at all is more informative than appearing unmountable — the card is not announcing itself, which is the controller rather than the filesystem, and your footage sits behind it.
Checking a card and copying it are different jobs
Copy first and verify at the destination — confirming footage is present gives real reassurance while changing nothing about its safety, and that reassurance is what delays the copy. The gap between checking and backing up is pure exposure, since a card that reads today can fail without warning. If a card doesn't appear in your system's disk utility at all, that's actually more informative than appearing unmountable: it means the card isn't announcing itself, so the fault is the controller rather than the filesystem, and the memory holding your work is a separate component. Don't format it or run repair tools.
Don't format it — call Easy Data Recovery on 028 9002 0144; absence from the mounting utility distinguished from a filesystem fault, addressed through hardware, memory read past the controller.
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.