Data Recovery Case File · Cameras, Drones & Cards · Verification Is the Missing Step
They Did Everything Right and One File Slipped Through
His enquiry is unusually calm because most of the work was already safe. A card formatted after a shoot: "we've accidentally formatted a memory card, we had backed it all up but one clip is corrupt on the backup. It's not the end of the world but it would be nice to have if we could get it back. The only kicker is we would need it by midday." They backed it up, which is more than most — and one file did not survive the copy, which is the failure mode nobody plans for, because a backup that exists and a backup that was checked are not the same thing.
| Media | Memory card from a production shoot, formatted following an offload — one clip corrupt in the backup copy, making the card the sole remaining source for that file |
| Reported situation | Card offloaded to a backup after a shoot · card formatted afterwards · one clip found corrupt within the backup copy · card representing the only remaining source for that file · deadline within hours |
| Fault class | Index replacement following a verified-in-intent but unverified offload — single file targeted; content present pending overwrite |
| Equipment used | Card removed from use immediately · imaged write-blocked (DeepSpar USB Stabilizer 10Gb) · post-format write extent measured · imaging sequenced to the affected clip first · footage validated by playback against expected duration |
The decode: how a copy completes and still fails
What almost certainly happened during the offload: the copy ran, reported success, and one file arrived with bad content. That is entirely possible and it happens more than people expect. A transfer confirms that the right number of bytes moved; it does not confirm that they are the right bytes. A marginal read on the source, a transient error, or a fault in the path can produce a file of exactly the correct size containing something that will not play.
Why nothing warned them: because nothing was checking. A completed transfer and a verified transfer are different operations, and only one of them can tell you a file went wrong. Without verification, the first indication is somebody opening the file — which in production is often days later, and here was after the card had been formatted.
Why formatting the card was reasonable and became the problem: reusing media after an offload is normal practice and there was a backup. The gap is that the backup had not been confirmed good, so the format removed the only source for a file nobody knew was broken. The sequence was correct in structure and missing one step in the middle.
The step that would have caught it, and it is the whole answer: checksum verification. A fingerprint computed for every file on the card and again on the destination, then compared — identical means identical, byte for byte, and a mismatch names the specific file at the moment it goes wrong rather than weeks later. Free tools do this on every platform, and on a production offload it adds minutes. The card is then cleared knowing rather than assuming.
Why the outlook here is good: a format writes a fresh empty index and marks the space available — it does not visit the video data. So the clip is physically present unless something has been written since, and a card that came out of use immediately after the discovery is in the best condition it can be.
Why one file is a small job: the target is known, video containers carry distinctive headers, and imaging can be sequenced to reach the relevant region first — which is what makes a same-day answer realistic where a whole-card reconstruction would not be.
On the bench
The card was removed from use immediately and imaged write-blocked behind the DeepSpar USB Stabilizer 10Gb. The post-format write extent was measured, since only subsequent writes remove formatted content. Imaging was sequenced to the affected clip first against the stated deadline rather than run end to end, and footage validated by playback against expected duration rather than by file count.
The outcome
The card imaged with capture sequenced to the affected clip and validated by playback. Recovery of deleted or overwritten data from memory cards and USB sticks is charged at a flat figure, payable upfront. The decode, and the step worth adding to any offload: a completed transfer confirms the right number of bytes moved, not that they are the right bytes — so a file can arrive at the correct size containing something that will not play, and nothing tells you until somebody opens it. Compute a checksum on both sides and compare before clearing any card.
Backup that turned out to have a corrupt file in it
Verify offloads with checksums before clearing any card — that's the step that was missing, and it takes minutes. A completed transfer tells you the right number of bytes moved; it doesn't tell you they're the right bytes. A marginal read on the source or a transient error in the path can produce a file of exactly the correct size containing something that won't play, and nothing warns you because nothing is checking. The first sign is usually somebody opening it days later, by which point the card has been reused. Computing a fingerprint for every file on both sides and comparing names the specific file at the moment it goes wrong. Meanwhile, a format writes an empty index rather than erasing, so stop using the card.
Stop using the card — call Guildford Data Recovery on 01483 901310; imaged write-blocked, write extent measured, capture sequenced to the file you need and validated by playback.
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.