Data Recovery Case File · Desktop Externals & Aging Drives · The Record Existed
Bad Block Errors Logged for Two Weeks Describe a Failure That Was Never Sudden
His enquiry contains something most do not: a timeline. A 6TB drive no longer recognised at all, where "checking event logs it looks like it has been experiencing bad block errors for around two weeks." The disappearance was abrupt and the failure was not — the system had been recording the decline throughout, in a place nobody has reason to look until something goes wrong.
| Media | 6TB hard drive no longer enumerating — host event log recording bad block errors across approximately two weeks preceding the failure |
| Reported situation | Hard drive no longer recognised by the host at all · host event log examined by the owner · bad block errors recorded for approximately two weeks prior · no symptoms noticed during that period · recovery sought and quotation requested |
| Fault class | Progressive surface degradation preceding loss of enumeration — reallocation exhausted or firmware-stage failure following sustained error accumulation |
| Equipment used | Logged error history used to establish the failure as progressive rather than sudden · current draw measured across the start-up cycle on a controlled bench supply · service area and reallocation records read under strict timeouts · imaged write-blocked with healthy regions taken first and marginal regions revisited across passes · recovered content validated by opening |
The decode: what the logs recorded, and what the drive was doing meanwhile
What a bad block error in a log represents: a read the drive could not complete. The host asked for data, the drive failed to return it, and the operating system recorded the event — one line per occurrence.
Why he saw nothing at the time: the drive was handling them. Drives detect failing sectors, retry them, and relocate their contents to spare capacity held in reserve — a process designed to be invisible.
Why that invisibility is the point and also the problem: the reallocation is silent by design, so nothing surfaces while it works. The user experience of a drive quietly consuming its spare capacity is no experience at all.
What two weeks of entries therefore indicates: a sustained rate of failure. Occasional errors are normal across a drive's life; a fortnight of them is a surface degrading faster than the drive can keep up with.
Why the drive then disappeared entirely: two likely paths. Either the reserved capacity was exhausted, or the degradation reached the drive's own configuration region — and a drive that cannot read its own configuration cannot announce itself.
Why the second is the commoner ending: the configuration area is a small region like any other and is not immune. Once it fails, everything stops regardless of how much of the surface remains readable.
Why that is the encouraging reading: a drive lost to a configuration failure may have most of its content intact. The failure that ended enumeration is separate from the extent of surface damage, and the two are not proportional.
What is worth saying for anyone reading rather than for him: the drive's own health reporting would have shown this. Reallocated sector counts rising over days are visible to anyone who checks, and a rising count is the clearest early warning storage gives.
Why that is not a reproach: nobody checks a drive that is working. The information existed and there was no reason to look at it — which is exactly why it is worth mentioning now.
What must not happen: no repeated connection attempts. A drive with a degrading surface and a failing configuration region is spending reads on the same failing area every time it is powered.
On the bench
Logged error history was used to establish the failure as progressive rather than sudden — a bad block entry recording a read the drive could not complete, while drives detect failing sectors, retry and relocate their contents to reserved capacity in a process designed to be invisible. Sustained entries across a fortnight indicate degradation outpacing that mechanism, ending either in exhausted reserve or in failure of the configuration region, which prevents enumeration irrespective of surviving surface. Reallocation records were read under strict timeouts.
The outcome
The logged history used to establish progression, reallocation records read under strict timeouts, and healthy regions captured first. 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 disappearance was sudden and the failure was not. Your drive was relocating failing sectors silently for a fortnight — and what finally stopped it may be a small configuration region rather than the extent of the damage.
What the logs would have told you
Stop reconnecting it now, since each attempt spends reads on the same failing area. For anything still working, the useful habit is checking a drive's own health reporting occasionally: a rising reallocated sector count is the clearest early warning storage gives, and it's visible days or weeks before anything surfaces to you. Drives detect failing sectors, retry them and move their contents to reserved capacity silently by design — so nothing appears wrong until the reserve is exhausted or the degradation reaches the drive's configuration region.
Stop reconnecting it — call Manchester Data Recovery on 0161 871 0788; logged history used to establish progression, reallocation records read under strict timeouts, healthy regions captured first.
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.