Data Recovery Case File · NAS & Network Storage · Copy First, Diagnose After
The Diagnostic Step Spent the Working Window
His enquiry contains a sentence worth reading twice. A network drive that had given up, where "technical support got me to plug it into the PC. It was working, now all it does is spin up and then about 10 seconds later goes off." It worked, once, during a support call. That was the window and it was spent on a diagnosis — which is nobody's fault and is worth understanding, because support scripts are written to identify a fault rather than to preserve access, and those are not the same objective.
| Media | Network storage drive removed from its appliance and connected directly to a computer during a support call — reading on that occasion; subsequently spinning up and powering down after a short interval |
| Reported situation | Appliance no longer functioning · manufacturer support directing the drive to be connected directly to a computer · drive reading successfully on that occasion · drive subsequently spinning up and powering off after approximately ten seconds · support advising inspection of the board |
| Fault class | Progressive readiness failure with a working access period expended on diagnosis — firmware-initiated shutdown following incomplete start-up |
| Equipment used | No further power-up · spin-down timing observed on a controlled supply · readiness sequence read directly under strict timeouts · PC-3000 Express technological-mode service-area assessment · imaging on restored addressing in priority order |
The decode: two different objectives, and what the shutdown means
What support was doing, fairly: answering the question it was asked. A caller reports an appliance that has stopped working, and the correct diagnostic step is to establish whether the fault lies in the appliance or the drive inside it — which means connecting the drive directly and seeing whether it reads. That is good procedure and it produced a real answer.
Why it cost him: because the question that mattered was not "what is wrong" but "how do I get my files". When a device is failing intermittently, every successful access is a resource, and there is no way to know how many remain. Spending one on a diagnosis produces information; spending it on a copy produces data. Diagnosis is the right goal when a device is stable and the wrong goal when access is finite.
What he could not reasonably have known: that the drive was on its last accesses. Nothing announced it, the drive read normally when connected, and the sensible-sounding step was the one suggested by the people who made the device. The lesson is not that he was misled — it is that the caller is the only person who knows the data is irreplaceable, and saying so changes what should happen next.
What to say instead, and it is a single sentence: that the data is not backed up and that copying it takes priority over identifying the fault. Any competent support conversation will accommodate that, and it reorders the steps — connect, copy everything, then diagnose whatever remains.
What the current behaviour means: spinning up and powering off after about ten seconds is a firmware-initiated shutdown. The drive is starting, attempting its readiness sequence, failing to complete it, and switching itself off deliberately rather than continuing. That is the electronics reaching a conclusion, which places the fault at the configuration or positioning stage rather than in the motor — the mechanism is clearly capable of spinning.
Why that is a reasonable place to be: the reserved region a drive reads on every start-up is separate from where user data lives, so a drive unable to read its own configuration still holds everything. It is addressed in the drive's technological modes, after which it images conventionally.
What must stop: further power-up attempts. Each is another failed start on a drive that has already demonstrated it cannot complete one.
On the bench
No further power-up was attempted, each being another failed start on a drive that already cannot complete one. Spin-down timing was observed on a controlled supply — a shutdown after a consistent interval indicating a firmware-initiated abort rather than a motor unable to turn, which places the fault above the mechanism. The readiness sequence was read directly under strict timeouts, with PC-3000 Express technological-mode service area assessment, and imaging on restored addressing performed in priority order.
The outcome
The shutdown characterised on a controlled supply, the service area repaired and the contents imaged in priority order. 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, and it is worth carrying into any support call: diagnosis and preservation are different goals. When a device is failing intermittently every successful access is finite, so a working moment spent identifying the fault is a working moment not spent copying. Say the data is irreplaceable, and ask to copy first.
Device that worked once during a support call
Tell support at the start that the data isn't backed up and that copying it comes before identifying the fault — that single sentence reorders everything. Support procedures are written to diagnose, which is the right goal when a device is stable and the wrong one when access is finite. Connecting a drive directly to see whether it reads is genuinely good procedure and it produces a real answer; it just spends a working access on information rather than on your files. You're the only person in that conversation who knows the data is irreplaceable, and any competent support line will accommodate it: connect, copy everything, then diagnose whatever's left. Meanwhile stop powering it up — a drive that shuts itself off after a few seconds has already concluded it can't start.
Stop powering it — call Guildford Data Recovery on 01483 901310; shutdown timing characterised on a controlled supply, service area repaired in technological mode, imaged in priority order.
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.