Data Recovery Case File · NAS & Network Storage · A Copy Inside a Wrapper
A Mirror Member Holds Everything and Still Needs the Layers Above It
His enquiry describes a reasonable expectation that did not hold. Two disks from a failed network unit configured as a mirrored pair, where he is "trying to access the data on the drives but it's not as simple as I had hoped" after fitting a third-party filesystem driver. Each disk does hold a complete copy — and between that copy and the filesystem sit layers the driver knows nothing about.
| Media | Two 2TB drives from a network unit configured as a mirrored pair — unit failed; drives connected directly with a third-party filesystem driver unsuccessful |
| Reported situation | Network unit with two drives configured as a mirrored pair · unit suffering a failure · drives connected directly for access · third-party filesystem driver installed · content not accessible · assistance sought regarding the unit's volume arrangement |
| Fault class | Mirror members intact with volume management layers unrecognised — filesystem driver insufficient without array and logical volume assembly |
| Equipment used | Layer structure identified before any driver approach was pursued · each member imaged individually write-blocked · array membership and logical volume structure derived from the members themselves · filesystem interpreted from the assembled image · content delivered to supplied destination media |
The decode: what sits between the disk and the files
Why his expectation was reasonable: a mirrored pair keeps identical content on both disks. Each member is a complete copy rather than a fragment, so reading one directly ought to be possible — and it is, once the layers are handled.
What the first layer is: array membership. The unit writes its own metadata onto each disk recording that it belongs to a mirrored set, and a host that does not recognise that metadata sees a disk it cannot place.
What the second layer is, and this is the one the driver could not help with: logical volume management. Most units place a volume manager between the array and the filesystem, so the filesystem does not sit directly on the disk — it sits on a logical volume assembled from it.
Why a filesystem driver alone therefore fails: it looks for a filesystem at the start of what it is given. It finds array metadata and volume manager structures instead, and reports nothing usable — which is what he encountered.
Why that is not a fault in the driver: it does the job it was built for. The mismatch is that two layers have to be assembled before a filesystem is exposed for it to read, and neither is its responsibility.
Why a mirror is nonetheless the favourable configuration: there is no striping to reconstruct and no parity to calculate. Once the layers are assembled, either member yields the whole volume — and if one member is degraded, the other frequently is not.
Why both members are imaged rather than one: mirrored disks age together and are rarely equally healthy. Regions unreadable on one are often readable on the other, and combining them produces a more complete image than either alone.
Why the unit's failure does not have to be diagnosed: the objective is the content, not the appliance. Whether the enclosure, its supply or its software failed is irrelevant once the disks are read directly.
Why nothing is attempted on the original disks: the layers are assembled offline from images, with parameters derived from the members themselves. Any attempt to reassemble the array in a host risks writing new metadata, which is the one action that would matter.
What must not happen: no accepting an offer to initialise either disk, and no returning them to a unit that may attempt a rebuild. A machine shown these disks will not recognise them and will propose preparing them.
On the bench
The layer structure was identified before any driver approach was pursued — a mirrored pair holding identical complete content on each member, above which sit array metadata recording set membership and, in most units, a logical volume manager, so the filesystem does not sit directly on the disk. A filesystem driver looking for a filesystem at the start of the device finds those structures instead. Each member was imaged individually, with array and volume structure derived from the members themselves.
The outcome
The layer structure identified first, each member imaged individually, and the filesystem interpreted from the assembled image. 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: each disk does hold a complete copy, which is why your expectation was reasonable. Between that copy and the files sit array metadata and a volume manager — and a filesystem driver looks past neither.
Reading a mirrored disk from a failed unit directly
Refuse any offer to initialise either disk, and don't return them to a unit that might attempt a rebuild. Your expectation is sound — a mirror keeps identical complete content on each member, so one disk should be readable on its own. What stops a filesystem driver is that two layers sit above the filesystem: metadata recording that the disk belongs to an array, and in most units a logical volume manager. The driver looks for a filesystem at the start of the device and finds those instead. Have both members imaged rather than one, since mirrored disks age together and rarely fail identically.
Don't initialise them — call Manchester Data Recovery on 0161 871 0788; layer structure identified before any driver approach, each member imaged individually, array and volume structure derived from the members.
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.