Data Recovery Case File · NAS & Network Storage · The Duration Was the Signal
A Rebuild That Barely Finished
His enquiry contains a number that should have raised an alarm at the time. An appliance running faultlessly for eight years: "one of the drives suddenly was red. I got a new drive and replaced it. It seemed to have rebuilt itself after about 8 days. But it has been in a loop ever since — it is recognised for a few minutes on the dashboard, but the loop includes a power down so it never fully mounts." He has since tried a replacement power supply. Eight days is the important figure, because a rebuild of that length is not a rebuild that succeeded comfortably — it is one the array barely survived.
| Media | Five-bay network storage appliance in continuous service for approximately eight years — one member replaced following failure, reconstruction taking approximately eight days, unit subsequently cycling without completing a mount |
| Reported situation | Appliance in service approximately eight years · one member reporting failure · member replaced and reconstruction performed over approximately eight days · unit subsequently entering a repeating cycle · recognised briefly then powering down · replacement power supply tried without change · no separate backup held |
| Fault class | Post-rebuild instability on contemporaneous ageing members — proprietary array layout requiring format-specific reconstruction |
| Equipment used | No further rebuild attempted · all members removed and labelled by bay · each imaged individually write-blocked (Atola TaskForce 2) · vendor-specific array layout interpreted rather than assumed standard · volume assembled offline from images |
The decode: what eight days means, and why the disks cannot go in a PC
What a rebuild actually does: reconstructs the replaced member by reading every sector of every remaining disk and computing what the missing one held. It is by a wide margin the heaviest load an array ever experiences, and it happens at the exact moment there is no redundancy left to absorb another problem.
Why the duration matters so much: a healthy set rebuilds at close to the disks' sustained read speed. Eight days means it was not doing that. Something was slowing it dramatically — remaining members returning errors and forcing retries, sectors taking many attempts, or the appliance throttling around difficulties. A rebuild that takes a week is the array telling you the surviving disks are struggling, and "it seemed to have rebuilt itself" is doing considerable work in that sentence. It completed, under duress, on disks that were already failing to keep up.
Why eight years matters alongside it: the members are contemporaries. Bought together, powered together, given identical workloads for eight years, they arrive at the end of their lives together. The first red drive was not an isolated event but the first of a set reaching the same point.
What the loop is: the unit powering up, initialising, attempting to bring the volume online, encountering something it cannot get past, and shutting down deliberately rather than continuing. His replacement power supply was the right thing to eliminate and it has ruled out the commonest external cause — so what remains is the unit or the members. Given the rebuild history, a member failing during the mount attempt is the likeliest explanation.
The point specific to this class of appliance, and it matters: some network units do not use a standard array layout. They use a vendor-specific arrangement that distributes data in a way generic tools cannot interpret, and which cannot be assembled by connecting the disks to a computer and using ordinary software. So the disks must not be put into a PC to see what is on them — nothing will read them, a host will offer to initialise them, and accepting destroys the layout metadata. Reconstruction requires the format to be interpreted specifically.
What must not happen: no further rebuild. Repeating an eight-day maximum-load read across disks that are visibly at the end of their service life is the single most likely way to lose the set entirely.
On the bench
No further rebuild was attempted, since repeating a maximum-load read across contemporaneous disks that had already struggled through one is the likeliest way to lose the set. All members were removed and labelled by bay, then imaged individually write-blocked on the Atola TaskForce 2 — capturing each while it still cooperated rather than asking the array to work again. The vendor-specific layout was interpreted rather than assumed standard, since generic array tools cannot read this arrangement, and the volume was assembled offline from the images.
The outcome
Every member imaged individually before further load, the vendor layout interpreted specifically and the volume assembled offline. 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 whose array took days to rebuild: that duration was the warning. A healthy set rebuilds at close to full read speed, so a week means the remaining disks were erroring and retrying throughout — it completed under duress. And on appliances using a vendor-specific layout, the disks cannot be read by putting them in a computer; a host will offer to initialise them and accepting destroys the arrangement.
Array that rebuilt very slowly and has been unstable since
Don't let it rebuild again, and don't put the disks into a PC to see what's on them. The rebuild duration was the real warning: a healthy set reconstructs at close to the disks' full read speed, so one that takes days means the remaining members were returning errors and forcing retries the whole way through. It finished under duress, on disks that were already struggling — and after eight years of identical workload they're all contemporaries reaching the same point together. Repeating that maximum-load read is the likeliest way to lose everything. Many network appliances also use a vendor-specific layout that ordinary software can't interpret, so connecting the disks to a computer achieves nothing except an offer to initialise them, which destroys the arrangement.
Don't rebuild again — call Newcastle Data Recovery on 0191 406 1051; every member imaged write-blocked before further load, vendor layout interpreted specifically, 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.