Data Recovery Case File · Portable Drives · Copy Everything Else First
The Good Files Are at Risk While You Retry the Bad Ones
Her enquiry has a deadline in it and an instinct that needs redirecting. A drive that stopped being read by her Mac: "I've plugged it into my husband's Windows machine and it has found all of the files, but when I try to transfer the editing files it says 'cyclic redundancy check' error and won't copy them. I need the data pretty urgently as it is work meant to go out to clients this week." Everything she needs to know is in the fact that the other machine listed all the files — and the most urgent thing she can do is not what she is currently doing.
| Media | External hard drive holding professional editing work — filesystem intact and fully listed on a second machine; specific files failing to copy with checksum errors; client deadline in force |
| Reported situation | Drive no longer read by the owner's machine · fully listed on a second machine with all files visible · specific files failing to copy with cyclic redundancy check errors · client work due within the week |
| Fault class | Localised physical read failure over an intact filesystem — remaining content readable and at risk while retries continue |
| Equipment used | Readable content copied and verified before any further attempts on failing files · imaged write-blocked under per-sector timeouts with weak regions revisited · client-deliverable material prioritised · losses mapped per file |
The decode: what the error means, and the order to work in
What a cyclic redundancy check error actually is: the most honest error a drive produces. Every sector is stored with a checksum, and when the drive reads one it recalculates and compares. A mismatch means the data came back wrong — so the drive refuses to hand it over rather than passing bad data silently. It is not a filesystem problem and not a software problem; it is the drive reporting that a specific physical region could not be read correctly, and it deserves to be believed.
What her second machine established: a great deal. Listing all the files means the filesystem is intact — the structures describing where everything lives are readable and complete. So this is not corruption or a damaged index. It is localised physical read failure in the regions where certain files sit, with the rest of the drive fine.
Now the instruction, and it is the whole point. Copy everything that does copy, right now, before returning to the files that do not. The natural response is to focus on the failing files — they are the ones that matter, the deadline is on them, and retrying feels like progress. But every retry is sustained reading of a drive that has already demonstrated it is degrading, and the material that would copy is still sitting on that drive while it happens. People routinely lose a healthy majority while fighting for a broken minority.
Why retrying does not work anyway: a checksum failure means the region could not be read correctly. Asking again immediately usually produces the same result, because the drive has already exhausted its internal retries before reporting the error. What does help is a strict per-sector time budget with the region revisited on later passes, where a sector that failed several attempts sometimes succeeds — but that is imaging, not copying, and it should happen after the readable material is safe.
What that means for the deadline: the sequence works in her favour. Securing everything readable takes an hour or two and may well include most of what the client needs. What remains can then be attacked properly, with a known list of exactly which files are affected rather than a general anxiety.
What not to do: not run a repair utility, which writes conclusions back, and not run the disk-checking tool that will offer to fix bad sectors — that marks them unusable and can move data around, which on a drive under deadline is exactly the wrong risk.
On the bench
Readable content was copied and verified before any further attempts on the failing files — since a drive reporting checksum errors is degrading, and the material that still copies remains at risk for as long as retries continue on the material that does not. The drive was then imaged write-blocked under per-sector timeouts with weak regions revisited on later passes, client-deliverable material prioritised against the deadline, and unreadable areas resolved to the individual files they affected.
The outcome
The readable majority secured first, the drive imaged under timeout control and the losses reported file by file. Free assessment, one fixed written figure including VAT; where a drive has to be opened, 50% of parts and labour is payable upfront with the balance only on success — otherwise no recovery, no fee. The decode, for anyone getting checksum errors on files they need: copy everything that does copy first. That error is the drive honestly reporting that a physical region could not be read correctly — and while you retry those files, the healthy majority is still sitting on a degrading drive. Retrying immediately rarely helps, because the drive already exhausted its own retries before reporting.
Files that won't copy with a checksum error
Copy everything else first — right now, before you go back to the files you actually need. That's counterintuitive and it's the most useful thing you can do. A cyclic redundancy check error is the drive reading a sector, recalculating its checksum, finding a mismatch, and honestly refusing to hand over bad data. It means a specific physical region can't be read, so the drive is degrading — and while you retry the broken files, everything that would still copy is sitting on that same drive. People lose a healthy majority fighting for a broken minority. Retrying immediately rarely helps anyway, since the drive exhausted its own internal retries before reporting the error. And don't run a disk-checking tool that offers to fix bad sectors.
Secure everything else first — then call Newcastle Data Recovery on 0191 406 1051; readable content verified before further attempts, imaged under per-sector timeouts, deliverables prioritised.
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.