Data Recovery Case File · NAS & Network Storage · Case 1,700 · The Tools That Let You Look

A Configuration Utility Has No Read-Only Mode

The seventeen-hundredth file in this archive is about a moment its owner describes with unusual honesty. An old server running a parity array across three discs with a spare held in reserve, where "during a period of ill health with mind fog, I inadvertently entered the array configuration utility. Got out quick, but too late." The utilities that let you look at an array are the utilities that let you change it — there is no safe, read-only way in — and the moment he most needed careful judgement was, by his own account, the moment he had least of it.

The decode: four things this case teaches, at the end of a site

The first — the tools that let you look are the tools that let you change. He entered a configuration utility, not a viewer. Array configuration tools have no read-only mode — they exist to define arrays, and looking at the settings and altering them happen through the same screens, so entering at all placed him one confirmation away from a change. This is the recurring shape of the hardest cases in this archive: the instrument of inspection and the instrument of damage are the same instrument.

The second — the moment you most need judgement is often the moment you have least. He tells us plainly: illness, mind fog. Every made-it-worse case in this archive shares that shape — panic, exhaustion, a deadline, or illness — the destructive action taken not by the careless but by the capable at their least capable. The value in his honesty is that it names the real risk factor, which is not ignorance but impairment, and impairment is not something competence protects against.

The third — the decision worth making in advance is the decision to stop. The judgement that would have helped him was not technical knowledge, which he plainly has. It was a rule decided beforehand: I will do nothing irreversible until I have asked someone. A rule like that works in every state — clear-headed or foggy, calm or panicking — precisely because it does not depend on being in a condition to reason well. It is the one decision that survives the loss of the faculties needed to make every other decision.

The fourth, and the technical heart — the most dangerous writes are the ones nobody initiated. He correctly reports no user-initiated writes since the problem arose, and that is exactly the right thing to have preserved. But a hot spare is present — and the whole purpose of a spare is that the controller can bring it into the array and rebuild onto it automatically, without anyone asking. So the first question is not what he did; it is whether the controller, seeing an array it now considered degraded, started a rebuild of its own. A rebuild is not a user-initiated write, and it writes across a member.

Why the symptom change is the key evidence: the fault moved from the system reaching the kernel and stalling, to the loader being reported missing after the partition table and boot sector are read. That change is diagnostic — the array is assembling, and assembling further than before, but presenting different content. Members are coming together in an order or with parameters that differ from the original, so the volume appears but what it contains is misaligned. The data is there; the arrangement reading it is wrong.

What that means for the approach: the altered configuration cannot be trusted, so the original parameters are derived from the members themselves rather than read from the utility that was changed. Each member is imaged individually and the array assembled offline from the images, with candidate parameters tested against the symptom — the correct arrangement is the one that resolves the loader and presents a consistent volume. Nothing is done to the original members, and no rebuild is permitted on them.

Why imaging every member first is not optional here: if a rebuild did begin, one member may already be partially overwritten, and the others hold the original data. Capturing all of them before anything else preserves every version there is, so the assembly can be worked out from the most complete set rather than from whatever the controller has most recently changed.

What must not happen — and it is what the controller offers: no allowing a rebuild to run or complete, no re-entering the configuration utility to try to correct the settings, and no accepting any prompt to repair or reinitialise the array. Every one of those is the same category of action that caused the fault: a change made through the only tools available, which have no read-only mode. The array is read, not corrected in place.

On the bench

Whether the controller began an automatic rebuild was established before anything else — a hot spare existing precisely so the controller can rebuild onto it without a user request, so a rebuild is not a user-initiated write yet writes across a member, making the controller's own action the first thing to determine. Each member was imaged individually write-blocked, original array parameters derived from the members rather than the altered configuration, and the array assembled offline from images with parameters verified against the symptom change — the shift to a missing loader indicating an array assembling with altered order or parameters so that the volume presents but its content is misaligned.

The outcome

The controller's rebuild state established first, every member imaged individually, the original parameters derived from the members, and the array assembled offline with no rebuild permitted on the originals. Free assessment, one fixed written figure including VAT, charged per drive, with 50% of parts and labour payable upfront and the balance only on a successful recovery. The decode, for the seventeen-hundredth file: the tools that let you look are the tools that let you change, and there is no read-only way in. The judgement you most need is the one you have least of when unwell — so the decision worth making in advance is the decision to stop. And the most dangerous write is the one nobody initiated: a hot spare lets the controller rebuild on its own, so the first question is not what you did, but what the array did after you left.

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.