Linux software RAID recovery
Linux software RAID records array identity and member history in md metadata. After a power loss, disk dropout, migration, or controller event, an array may appear inactive, degraded, or unable to assemble even though useful data remains on its members.
Understand the symptom
mdadm compares array UUIDs, roles, metadata versions, event counters, and device states when assembling an array. A stale member may contain older but internally consistent data, while a recent member may have participated in an incomplete reshape or rebuild. Correct recovery depends on the failure timeline, RAID level, chunk layout, bitmap, and filesystem above the array.
What you may see
The md device exists but is not running or does not expose the expected filesystem.
The active member count is below the level required for normal assembly.
Some disks stopped receiving writes earlier than others or were attached during different states.
Layout or parity may be partially transformed across the member set.
Protect the source
Recreating an array can replace roles, UUIDs, offsets, and other assembly evidence.
Starting with the wrong members may write parity or filesystem changes over the best source.
A resync is not a data-recovery scan; it can propagate an incorrect state across disks.
Do this now
Prevent automatic assembly, mounts, LVM activation, containers, and applications from changing the set.
Record mdadm examine output, UUIDs, roles, event counts, offsets, chunk size, bitmap, and array state.
Keep bay positions, serial numbers, controller connections, removed disks, and replacements documented.
Save mdadm.conf, logs, kernel messages, backup files, and the exact commands already attempted.
NEPFOSYS process
NEPFOSYS correlates superblocks, counters, RAID geometry, disk health, and the incident sequence.
Readable members are imaged before any array-level assembly or filesystem repair.
Candidate member sets are tested away from the originals and validated against priority data.
A clear next step
Start a case with the exact symptoms, incident timeline, prior attempts, encryption details, and the files that matter most. NEPFOSYS will route the case to the appropriate DFW intake or nationwide mail-in path.
Start with a case reviewQuestions, answered
Only after the member history is understood and protected copies exist. Force assembly can activate a stale or incomplete set and permit writes.
Not when the data is the priority and member state is uncertain. A rebuild writes broadly and may use the wrong source.
Array UUID, RAID level, member roles, event counters, metadata version, chunk size, offsets, bitmap state, and the failure timeline all influence reconstruction.
DFW local · Nationwide mail-in