Data Recovery Case File · NAS & Network Storage · Where in the Sequence It Stops
Reaching the Array and Failing Afterwards Means the Array Is Not the Problem
This enquiry locates the failure to a point in the start-up sequence, which is worth more than any description of symptoms. A three-drive array on a server where a power cut outlasted the backup supply, and the machine now "loops after attempting to load the array controller, just before the system boots" — with no safe mode and no recovery environment. Where a start-up stops is a map, and this one stops after the storage has already been presented.
| Media | Three-drive array of 4TB usable capacity on a server platform — controller initialising, boot volume failing to load; abrupt power loss following exhaustion of the backup supply |
| Reported situation | Power outage exceeding the capacity of the backup supply · server powering down abruptly · machine failing to restart · start-up reaching the array controller · repeating cycle beginning immediately afterwards · recovery environment not reachable · reduced start-up mode not available |
| Fault class | Boot volume structures incomplete following abrupt power loss — array initialising normally with members intact; rebuild activity presenting the principal risk |
| Equipment used | Failure point located after array initialisation rather than within it · no rebuild, repair or initialisation permitted at the controller · each member imaged individually write-blocked before any interpretation · array geometry confirmed from member metadata and assembled offline · boot and filesystem structures interpreted with their duplicate copies |
The decode: reading the sequence, and the one action to refuse
What has already succeeded by the time the loop begins: a great deal. The controller powered up, identified its members, confirmed the array configuration and presented a volume to the system.
Why that matters more than anything else here: it clears the array. A degraded or broken array would fail at that stage and report it, and this one did not.
Where the failure therefore is: after presentation. The system received a working volume and could not start from it, which places the fault in the boot structures or the filesystem rather than in the storage.
Why an abrupt power loss produces exactly this: writes were in flight. A server shutting down without warning leaves filesystem updates half-applied, and the boot sequence is what discovers that.
Why the backup supply detail is worth noting: it explains the abruptness. A supply that runs out mid-outage produces an uncontrolled shutdown, which is exactly what an orderly one prevents.
Why no recovery environment is reachable: it lives on the same volume. The built-in recovery tools are stored on the volume that will not mount, so they are unreachable for the same reason.
Why no reduced start-up mode is available either: it needs the volume too. A minimal start-up still mounts the system volume, and the fault is in mounting it.
Now the action to refuse, and it is the one that will be offered: a rebuild. Controllers offer to rebuild or to re-initialise an array when a machine will not start, and a rebuild writes across the members.
Why that is so damaging in this particular case: the array is not the problem. Rebuilding to fix a filesystem fault performs a large write for no benefit and overwrites the state a reconstruction needs.
What is done instead: the members come out and are imaged individually. The array is assembled offline from those images and the filesystem repaired there, with the original untouched.
On the bench
The failure point was located after array initialisation rather than within it — the controller having powered up, identified its members, confirmed the configuration and presented a volume, which a degraded array would not do. The fault therefore lies in boot or filesystem structures left incomplete by writes in flight at the moment of uncontrolled shutdown. Built-in recovery and reduced start-up modes require the same volume. Each member was imaged individually and the array assembled offline.
The outcome
The failure point located after array initialisation, no rebuild permitted at the controller, and members imaged individually before offline assembly. Free assessment, one fixed written figure including VAT, charged per drive, with 50% of parts and labour upfront where a drive has to be opened. The decode: your start-up gets past the array and fails afterwards, which clears the array entirely. The power loss left filesystem writes half-applied — and a rebuild would write across members for no benefit at all.
A server looping after the array loads
Refuse any offer to rebuild or re-initialise the array — it's the option a controller presents when a machine won't start, and here it would perform a large write for no benefit while overwriting the state a reconstruction needs. Read the sequence instead: reaching the controller and failing afterwards means the array initialised, confirmed its configuration and presented a volume, so the fault is in the boot structures. That's what an uncontrolled shutdown does, leaving writes half-applied.
Refuse the rebuild — call Cambridge Data Recovery on 01223 655015; failure point located after initialisation, members imaged individually, array assembled offline and structures repaired there.
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.