Data Recovery Case File · Formatted & Logical Faults · A Complete Copy of an Incomplete Read

The Clone Finished Because the Tool Stopped Asking

His enquiry describes a procedure he has performed successfully many times, failing for the first time. A machine controlling industrial equipment whose drive is producing occasional stop errors: "I used an offline cloning tool to clone its contents onto a solid-state drive, which I've done many times before, however it won't boot or repair." Every previous clone was made from a healthy drive — and cloning from a failing one is a different operation, because the tool has to decide what to write where it could not read.

The decode: what a cloning tool does with a sector it cannot read

What cloning is: reading every sector of one drive and writing it to another, in order. On a healthy source it is exact, which is why it works reliably and why he has done it many times without difficulty.

What happens when a sector will not read: the tool has to put something there, because the destination has to be the same size and the sectors after it have to land in the right places. So it writes zeros, or a pattern, or whatever it happened to have — and it carries on. Many tools do this silently, or note it in a summary nobody reads.

Why the clone therefore "completed": it did. Every sector was written. Completion measures whether the operation finished, not whether the data is correct — and a clone with ten thousand substituted sectors reports success exactly as a perfect one does.

Why it will not boot: because the sectors it could not read were not distributed at random with respect to importance. The system files and boot components are among the most-read regions of any drive, which is precisely where developing faults appear first. So a failing drive is disproportionately likely to have its unreadable areas exactly where the clone most needs them to be correct.

Why the repair also fails: a start-up repair works by reading the system files, deciding what is wrong, and fixing them. On a clone whose system files contain substituted data, there is nothing coherent to repair — the tool is not looking at damaged files, it is looking at files that were never copied.

What should have been done instead, and it is a different class of tool: imaging that logs unreadable sectors rather than silently filling them, with configurable timeouts and multiple passes over difficult regions. The value is knowing what is missing — a list of unreadable areas tells you whether the gaps matter, which a silent clone never does.

Why the original still matters most: it holds the only copy of everything the clone substituted. It should not be run again — every stop error is the drive failing under load, and the machine has presumably been restarted repeatedly.

What this means for the equipment: restoring the controller is the goal rather than the data alone, and that depends on which regions were unreadable.

On the bench

The original was retained and imaged with unreadable sectors logged rather than substituted — cloning tools writing a pattern where a source sector cannot be read, because the destination must remain positionally identical, and reporting completion regardless. Read failure distribution was mapped against system file locations, boot components being among the most-read regions and therefore where faults surface first. Imaging ran under strict per-sector timeouts with multiple passes over weak regions.

The outcome

The original imaged with failures logged rather than filled, read distribution mapped against system locations, and the clone reconciled against the logged image. 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: your clone completed and completion is not fidelity. Where a sector could not be read, the tool wrote something else and carried on — and on a failing drive the unreadable areas cluster where the system files are.

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.