Data Recovery Case File · NAS & Network Storage · Degraded Is Not Working
Running Without the Safety Net
Her enquiry describes a decision that seemed to solve the problem and removed the protection instead. A network unit where "one of the drives started getting noisy some time ago and showed an error message. He took the faulty drive out and left the rest running. Unfortunately it now looks like the whole thing may not be working, as I've been trying to access our family photos." Removing the noisy drive stopped the error and the unit carried on serving files, which felt like a fix. What it actually did was silence a warning while running the array with nothing left in reserve — and the outcome that followed was the expected one, not bad luck.
| Media | Multi-bay network storage unit — one member removed following noise and an error message, array run in a degraded state for an extended period, volume now inaccessible; family photographs held |
| Reported situation | One member developing noise and reporting an error · member removed by the owner · unit left running with remaining members · array operating degraded for an extended period · volume now inaccessible · removed drive retained or otherwise to be established |
| Fault class | Second failure in an array already running without redundancy — reconstruction dependent on all members including the removed one |
| Equipment used | Removed member located and treated as a required component · no rebuild attempted · all members imaged individually write-blocked (Atola TaskForce 2) · failure sequence established from member metadata · volume assembled offline from images |
The decode: what degraded means, and where the removed drive is
What redundancy actually buys: an array with parity can lose one member and continue, reconstructing the missing data from the others as it goes. That is the whole protection. It is not a permanent condition — it is a grace period, designed to keep the system running long enough for a replacement to be fitted and the array rebuilt.
What removing the drive did: exactly what the design intends in the short term. The noisy member came out, the error stopped, and the unit continued serving files from the remaining disks. Everything looked normal. But from that moment the array had no redundancy at all, and any subsequent problem on any remaining member could not be recovered from. It ran with the safety net removed, silently, for months.
Why it felt like a fix, and this is the trap: a degraded array behaves identically to a healthy one from the outside. Files open, folders browse, nothing is slow. The only difference is invisible: the margin is gone. So there is no feedback to prompt anybody to finish the job, and "I'll get a replacement drive at some point" becomes months. A degraded array is a warning that has been silenced rather than answered.
What has probably happened now: a second member has developed a problem, and with no redundancy the volume can no longer be assembled. Disks bought together and run together age together, so a second failure some months after the first is the expected pattern rather than an unlucky coincidence.
The question that matters most, and it should be answered today: where is the drive that was removed? It may be needed. If the second member has failed badly and the first was merely noisy, the removed drive may be in better condition than the one that failed later — and either way, the more members available, the more routes there are to a reconstruction. A drive taken out months ago and put in a drawer, a box, or a bin is a real variable. It should be found before anything else.
What must not happen: no rebuild. If the unit can be persuaded to come up degraded, it will offer to reconstruct onto a replacement — reading every remaining member end to end for hours, at maximum load, on disks that have already demonstrated they are at the end of their lives.
On the bench
The removed member was located and treated as a required component rather than as a discarded faulty part — a drive taken out while merely noisy may be in better condition than one that failed later, and more available members means more routes to a reconstruction. No rebuild was attempted. All members were imaged individually write-blocked on the Atola TaskForce 2, the failure sequence established from member metadata so that stale data could be excluded, and the volume assembled offline from the images.
The outcome
The removed drive recovered into the set, every member imaged individually and the volume assembled offline from the copies. 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, for anyone running an array with a member removed: redundancy is a grace period, not a state you can stay in. Taking the failed drive out stops the error and the unit behaves exactly as before, which is the trap — there is no outward sign that the margin has gone. Find the drive you removed, because it may be needed, and never let the unit rebuild.
Array running with a failed drive taken out
Find the drive you removed — it may well be needed, and drives taken out months ago end up in drawers, boxes and bins. If the first one was only noisy and a later one has failed properly, the one you removed could be in better condition. Then understand what removing it did: an array with parity can lose one member and keep going, but that's a grace period designed to keep you running until a replacement is fitted, not a state to remain in. From the moment you pulled the drive there was no margin left, and nothing about the system's behaviour would tell you — a degraded array opens files and browses folders exactly like a healthy one. That's why this happens so often. Don't let the unit rebuild onto a replacement now.
Find the drive you took out — call Newcastle Data Recovery on 0191 406 1051; every member imaged write-blocked, failure sequence established from metadata, volume assembled offline.
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.