Data Recovery Case File · Formatted & Logical Faults · The Check Assumes Healthy Hardware
A Consistency Check Cannot Tell a Bad Read From a Bad File
His enquiry describes a reasonable action taken on an unreasonable drive. An 8TB drive that "has started to read the data intermittently and then not read when it feels like it", followed by running a check utility that "identified some corrupt files." A consistency check is built on the assumption that the hardware beneath it works. On a drive that reads intermittently, what it reports is unreliable — and what it offers to repair is worse than unreliable.
| Media | 8TB hard drive — intermittent read success across the volume; consistency check run against it reporting corrupt files; music library held |
| Reported situation | Drive reading intermittently and inconsistently · consistency check run by the owner · check reporting corrupt files · origin of the reported corruption unknown to the owner · repair of the reported files queried · full content to be moved to replacement media |
| Fault class | Intermittent read failure with a check utility run over it — reported corruption not distinguishable from failed reads; repair operations writing to degrading media |
| Equipment used | Check findings treated as unreliable given intermittent reads · no further repair operations permitted · drive removed from service before capture · imaged write-blocked under strict per-sector timeouts with multiple passes over marginal regions · files validated by opening rather than by reported status |
The decode: why the check's findings and its repairs are both a problem
What a consistency check is designed to do: compare the filesystem's records against what is actually stored, and correct records that do not agree. It assumes that when it reads something and gets an answer, the answer is true — which is entirely reasonable on healthy hardware.
Why that assumption fails here: the drive reads intermittently. A read that fails once and succeeds later returns different answers at different times, so the check may compare a record against data it simply could not retrieve at that moment.
What the check therefore cannot distinguish: a file that is genuinely damaged from a file it could not read on that attempt. Both present to it as content that does not match its record, and it reports both as corruption — which is why the findings say as much about the drive's mood as about the files.
So the honest answer to how the files became corrupted: many of them very likely did not. They were unreadable when asked, on a drive that reads intermittently, and files reported as corrupt on hardware in this state are frequently intact.
Why the repair function is the real danger: correcting a filesystem means writing to it. A check that concludes a record points at nothing may remove the record — and if the data was merely unreadable at that moment rather than absent, the reference to intact content has been deleted.
Why that is worse than the original fault: an intermittently readable file is recoverable by reading it repeatedly until it returns. A file whose directory entry has been removed by a repair has lost the thing that says where it is, and reconstruction becomes substantially harder.
Why running the check also cost reads: a consistency check on a large volume examines a great deal of the drive. On a drive with limited working life that is a large expenditure of retries spent on verification rather than on copying.
What to do instead, in order: the drive comes out of service, is imaged under capped timeouts so no single region absorbs the remaining time, and marginal regions are revisited across multiple passes. Every question about corruption is then answered against the image, where a file can be read a hundred times at no cost.
Why his instinct about replacement media is right: the content needs to end up somewhere else, and that is the correct destination for everything recovered. Nothing is written back to the original.
What must not happen: no further check runs, and nothing accepted that offers to fix or repair the volume. The tool that reports the problem is the tool that would cause the worse one.
On the bench
Check findings were treated as unreliable given intermittent reads — a consistency check comparing filesystem records against stored content on the assumption that a returned answer is truthful, which fails where reads succeed and fail inconsistently, so a file unreadable at the moment of examination is indistinguishable from a damaged one. No further repair operations were permitted, a repair removing records that appear to reference nothing and thereby discarding pointers to intact content. Imaging ran write-blocked under strict per-sector timeouts with multiple passes over marginal regions.
The outcome
The check findings set aside as unreliable, no repair permitted, and the drive imaged under capped timeouts with marginal regions revisited. 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: the check assumed your hardware was sound. On a drive that reads intermittently it cannot tell a damaged file from one it failed to read — and its repair would remove references to content that is actually intact.
Running a disk check on a drive that reads intermittently
Don't run it again, and never accept the offer to repair. A consistency check compares the filesystem's records against what's stored, assuming that anything it reads back is true — which is fine on healthy hardware and wrong on a drive that reads inconsistently. A file it couldn't retrieve at that moment looks identical to a genuinely damaged one, so much of the reported corruption is probably nothing of the sort. The repair is the real risk: it removes records that appear to point at nothing, which deletes the reference to content that was merely unreadable that time. Image the drive first and answer every question from the copy.
Don't let it repair anything — call Easy Data Recovery on 028 9002 0144; findings treated as unreliable given intermittent reads, imaged under capped timeouts with marginal regions revisited across passes.
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.