Data Recovery Case File · Case 1550 · A Copy Is Not Always a Working Copy

They Have Every Byte and the Machine Still Will Not Cut

This enquiry came from a timber factory and it is the first in this archive where recovering the data would not solve the problem. A drive failure on the computer that controls a cutting machine, running an operating system two decades old: "we have a clone hard drive, but the issue is the software that controls the machine is now looking for a licence key which we don't have, as this key was most probably tied to the exact sector on the original drive." They already have the data. What they do not have is the thing the software checks for — and that was designed not to survive copying.

The decode: what the software is looking for, and why a clone cannot have it

What they did right, before anything else: they had a clone. A factory running production equipment on an ageing computer, and somebody had made a copy of its drive — which is more foresight than most organisations running critical machinery on legacy controllers manage at all.

Why the clone starts and the software refuses: the operating system, the application and every file are present and correct. The check that fails is not looking at files. It is looking at the medium.

How protection of that era worked: software licensed to a machine was frequently bound to a physical characteristic of the disk it was installed on. A deliberately-created unreadable sector at a known position. A track written outside the normal format. Timing behaviour that only the original medium reproduces. The application checks for that characteristic at start-up, and if it is absent, it concludes it is running on a copy.

Why a clone cannot reproduce it, and this is the heart of it: cloning copies data. You cannot copy an error. A sector-by-sector duplication reads each sector and writes it to the destination — and a sector that reads as a failure becomes, on the destination, a sector that reads perfectly well. The copy is more correct than the original, which is exactly the wrong answer.

So the clone is a faithful copy of the data and an unfaithful copy of the disk, and the difference between those two things is the entire case.

The doctrine of case 1550: recovering the data is not always the job

Every other case in this archive assumes the same thing: that what has been lost is data, and that returning it solves the problem. Here it does not. They could be handed every byte from that drive, verified and complete, and the saw would still not cut timber.

Because what they actually need is a machine that runs, and the data is one component of that. The others are a licence, an operating system old enough that nothing supports it, an application nobody sells any more, and a binding between the software and a specific piece of hardware. Storage is the part that failed and it is not the whole system.

Which generalises, and this is the thing worth taking from it: the dependency you cannot see is the one that strands you. A controller running obsolete software with a media-bound licence is a single point of failure with no replacement path — and the moment you discover that is the moment the drive fails, which is the worst possible moment to find out.

What actually helps here, cheapest first — and the cheapest is a telephone call. Contact the machine's manufacturer. Licence reissue for industrial equipment is routine; vendors of long-lived machinery expect controllers to fail and generally have a process for it. Twenty-year-old equipment usually still has a support route, because the machines are still in factories. That may resolve the entire matter for nothing, and almost nobody tries it before commissioning a recovery.

If that fails, the technical route: the original is read at flux level rather than logically, capturing the raw magnetic behaviour including the regions that fail to read — which preserves the characteristic a logical clone discards. Alongside that, the licence configuration itself is extracted from the original once it is readable, since the key is generally recorded somewhere in the installed software's own settings.

Why the original must be preserved unaltered: it is the only object that carries the physical characteristic. A repair that makes it readable in the ordinary sense could destroy exactly what the software is checking for.

The audit worth doing on any machine you cannot afford to lose: what does this depend on that is not on the disk? A licence, a dongle, a network service, a vendor still trading, an operating system that still installs. Every one of those is a dependency, and a copy of the drive covers none of them.

On the bench

The vendor licence reissue route was established before any technical work — industrial equipment manufacturers expecting controller failure and generally maintaining a reissue process, which frequently resolves the matter at no cost. The original was imaged at flux level preserving read-failure behaviour, since logical duplication reads each sector and writes a readable result, converting a deliberately unreadable region into a readable one and destroying the very characteristic being verified. The protected region was characterised against the software's verification routine, licence configuration extracted from the original once readable, and the original retained unaltered throughout.

The outcome

The vendor route established before any technical work, the original imaged at flux level with read-failure behaviour preserved, and the licence configuration extracted from the original itself. Free assessment, one fixed written figure including VAT, 50% of parts and labour upfront with the balance only on successful recovery. The decode, and the doctrine of case 1550: you cannot copy an error. A clone reads each sector and writes a readable result, so a deliberately unreadable region becomes readable — which is precisely what the licence check is looking for the absence of. And more than that: recovering the data is not always the job. What you need is a machine that runs, and the drive is one dependency among several. Ask of anything you cannot afford to lose: what does this depend on that is not on the disk?

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.