Data Recovery Case File · Migrations · The Ninety-Five-Minute Alarm
Eleven times too fast: a reformat-and-return migration audited by its own clock — and a photographer's terabyte-and-a-half found where the short copy left it
The evidence in this enquiry was numerical, and she'd recorded it without knowing it was evidence. Migrating from Windows to Mac, her plan was orthodox: the 2TB external SSD — holding about 1.6TB of RAW camera files — was copied in full onto a second SSD ("which took 17.5 hours"); the original was reformatted from NTFS to a Mac-friendly format; and the data was transferred back — "which took 95 minutes." Days later, the discovery: "it did not transfer all the data. It minutely transferred some data." The two timings tell the whole story before any tool touches anything: the same collection cannot travel the same road in one-eleventh the time. Ninety-five minutes moved a fraction of 1.6TB; the rest never made the return journey — and the case turns on the question her enquiry left open: what happened, in the days since, to the intermediate drive that still held everything?
| Devices | 2TB external SSD (original — reformatted NTFS → FAT-family for Mac use) · second SSD (migration intermediate) — ~1.6TB of DSLR RAW files the cargo |
| The sequence | Full copy off: 17.5 hours → original reformatted → copy back: 95 minutes → shortfall discovered days later; original in light Mac service since; intermediate's subsequent use the case's pivotal question |
| Fault class | Silently incomplete return transfer over a freshly reformatted original — a migration failure, not a device one |
| Equipment used | Both drives imaged write-blocked · intermediate-first triage · reconciliation of the three populations (intermediate, returned set, reformat remnants) · per-file verification against the RAW collection's own numbering |
The decode: what ninety-five minutes can carry, why the copy stopped quietly — and where the archive actually was
The arithmetic first, promoted to doctrine: transfer time is a scale, and it doesn't lie — a road that took 17.5 hours outbound cannot run 1.6TB home in 95 minutes; that duration moves perhaps a tenth of the cargo, and the moment the return finished "early" was the moment to be suspicious, not relieved. (The migrator's self-check this page exists to plant: if the second journey is dramatically faster than the first, count the cargo before celebrating.) Why copies stop quietly: bulk transfers abort or skip for mundane reasons — an error mid-run ending the queue, a session interrupted, a destination format refusing what it can't hold (the FAT family's file-size ceiling is a classic silent filter, though her RAW stills would mostly duck under it; the abort pattern fits her timings better) — and operating systems are poor at announcing that a 95-minute job was supposed to be an 18-hour one. Nothing shouted. The folder looked like a folder. Where the archive was, all along: the migration's saving grace is structural — a copy-off-and-back plan means the intermediate drive held a complete copy at hour 17.5, and the shortfall's fate collapses to one question: what has the intermediate done since? Triaged first, exactly for that reason, hers returned the mixed verdict these cases usually do: the bulk of the collection still present and intact on the intermediate — never deleted, merely assumed transferred — with a portion cleared in the intervening days to make space, that cleared population now un-indexed rather than gone, and recoverable from the intermediate by the deleted-file work this archive performs daily. The reformatted original, for completeness, was examined beneath its new format for stragglers in the territory the fresh filesystem hadn't yet claimed.
The recovery — three populations, one collection
Both drives were imaged write-blocked and the collection reassembled from its three populations in order of certainty: the intermediate's intact majority extracted directly; its cleared portion recovered from un-indexed territory, the deletions recent and the drive lightly used since; and the original's pre-reformat remnants reconciled in for the margins. Verification leaned on the collection's own bookkeeping — RAW files carry sequential camera numbering and internal capture dates, so completeness was counted, not felt: the sequence walked end to end, gaps identified by number, and the honest ledger short — a small population that had been both cleared from the intermediate and overwritten by its recent use, itemised by frame number so the losses were named rather than discovered at an edit. Delivery went out on the Mac-ready storage the whole migration had been aiming at — the collection landing, at last, in the format and the place intended — plus the duplicate the delivery note refuses to omit, because a migration is precisely the moment an archive is most exposed and the second copy is the whole moral.
Outcome
The archive reassembled and counted whole but for a named handful — and the migration doctrine filed for everyone planning the same tidy loop. Verify before you reformat: the reformat is the migration's one irreversible act, and it must wait until the copy is proven — counted, sized, spot-opened — not merely finished. Run the arithmetic: journey times are a free integrity check; an implausibly fast leg is a partial leg. And honour the intermediate: the temporary drive is the migration's real safety net — keep it untouched until the destination is verified complete, because "I'll clear it for space" is how a recoverable shortfall becomes a permanent one, frame by frame. Her clocks had recorded the truth at minute ninety-five. This page is just the reading of them.
Migrations that came back light
Stop using the intermediate drive immediately — it held everything once, and its untouched portions still do; recently cleared files on it recover well if nothing new lands. Count, don't trust: compare totals and sizes between source and destination before any reformat, and treat a suspiciously quick transfer as incomplete until proven. Sequentially numbered collections (RAW photography especially) can be verified frame-by-frame — ask for the ledger by number, so any losses are named up front.
The intermediate is the case — call Belfast Data Recovery on 028 9002 0144 before anything else touches it.
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.