Data Recovery Case File · NAS & Network Storage · Members Without a Membership
Healthy Drives and No Access Means the Unit Has Lost Its Own Configuration
His enquiry separates two things most people would report as one. A four-bay unit holding two drives in a mirrored pair, where after unplugging and reconnecting "the address has changed and it no longer recognises the drives properly — it tells me they are functional, but no access to the files." The unit can see its drives and cannot see its array, which is a configuration loss rather than a storage failure.
| Media | Four-bay network unit containing two drives in a mirrored configuration — members reported functional by the unit; array not recognised and content not accessible |
| Reported situation | Network unit holding two drives in a mirrored configuration · unit disconnected from power and reconnected · unit's network address changing on reconnection · unit no longer recognising the array · drives reported as functional by the unit · no access to stored content · photographic content required |
| Fault class | Array configuration lost with members healthy — unit unable to assemble a set whose drives it can otherwise read; content retained on both members |
| Equipment used | Member health separated from array recognition before any rebuild was considered · no initialisation or array recreation permitted on the unit · each member imaged individually write-blocked · array membership and volume structure derived from the members themselves · filesystem interpreted from the assembled image |
The decode: what the unit lost, and why the drives are fine
What a unit needs to present an array: two separate things. Working drives, and a record of how those drives were joined together — the second held in the unit's own configuration and mirrored in metadata on the members.
Why his report separates them so usefully: the unit says the drives are functional. That is the first requirement satisfied and reported by the device itself, which is genuine information.
What it therefore lacks: the second. Without a valid record of the array, it has two drives it can read and no instruction on how to combine them, so it presents nothing.
Why a power interruption can cause this: configuration is held in the unit's own system area, and an abrupt loss during a write leaves it inconsistent. A unit that cannot parse its own configuration falls back to treating the drives as unassigned.
Why the address changing is a separate symptom of the same event: the unit's network settings live in the same configuration. Both the address and the array definition were lost together, which is consistent with one cause rather than two.
Why the mirrored configuration is the favourable one here: each member holds a complete copy. There is no striping to reconstruct and no parity to compute — once the layers are handled, either drive yields the whole volume.
Why the unit must not be allowed to fix it: the obvious next step is to create the array again. Recreating an array writes fresh metadata and, on most units, initialises the members — which is the one action that would destroy what is currently intact.
Why the offer is so dangerous in this specific state: the unit reports healthy drives and no array, so creating one looks like the correct remedy. Everything about the interface encourages it.
What is done instead: each member imaged individually, and the array membership and volume structure derived from the members themselves rather than from the unit. The information the unit lost is still present on the drives, in the metadata each member carries.
Why that usually succeeds: array metadata written to members is designed to survive exactly this. It exists so that a set can be reassembled after a controller is replaced, and reading it offline is straightforward.
On the bench
Member health was separated from array recognition before any rebuild was considered — a unit requiring both working drives and a record of how they were joined, the latter held in its own configuration and mirrored in member metadata, so drives reported functional with no array indicates the second having been lost. Abrupt power loss during a configuration write leaves it inconsistent, explaining both the array loss and the changed network address. Array membership was derived from the members themselves.
The outcome
Member health separated from array recognition, no recreation permitted on the unit, and membership derived from the members themselves. Free assessment, one fixed written figure including VAT, charged per drive, with 50% of parts and labour upfront and the balance only on successful recovery. The decode: your unit has healthy drives and no record of how they were joined. That record still exists in metadata on the drives themselves — which is why recreating the array is the one thing that would destroy it.
A unit reporting healthy drives and no array
Do not let it create the array again, however plainly that looks like the remedy — recreating writes fresh metadata and on most units initialises the members, destroying what's currently intact. Read the two halves separately: a unit needs working drives and a record of how they were joined, and yours is reporting the first while having lost the second, most likely to a power interruption during a configuration write. The address changing at the same time fits one cause rather than two. That joining record still exists in metadata on the drives themselves.
Don't recreate it — call Manchester Data Recovery on 0161 871 0788; member health separated from array recognition, members imaged individually, membership derived from the drives themselves.
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.