Unknown RAID geometry

When RAID metadata is missing, stripe size is only one part of the geometry that must be reconstructed correctly.

A controller replacement, erased configuration, disk migration, or failed NAS can leave all member disks present without a usable virtual disk. RAID level, member order, data offset, stripe size, parity rotation, and delayed parity may all be unknown.

Understand the symptom

Correct geometry aligns filesystem structures across member boundaries.

WHY

What is happening

Candidate layouts are tested against partition starts, filesystem superblocks, directory structures, virtual-disk headers, parity consistency, and repeated data patterns. Several wrong layouts can produce isolated readable fragments, so validation must extend beyond opening one file or seeing a recognizable signature.

What you may see

Symptoms that change the recovery path.

01

Controller sees foreign or unconfigured disks

Member identity remains but the virtual-disk definition is unavailable.

02

Array imports with wrong capacity

Member count, offset, sector size, or RAID level may be incorrect.

03

Filesystem signature appears but will not mount

Some geometry fields align while later stripes do not.

04

Files open with periodic corruption

A wrong stripe size or order can damage data at repeating intervals.

Protect the source

Actions that can make the situation worse.

01

New array metadata overwrites originals

Controller initialization can replace signatures and event context.

02

Trial mounts may write journals

A partially coherent layout can invite filesystem changes to the wrong assembly.

03

Single-file success is misleading

Small files may sit within one member segment and not validate the full geometry.

Do this now

Safe steps before evaluation.

01

Inventory every member

Record serial, model, capacity, sector format, bay, role, and health.

02

Preserve controller evidence

Keep configuration backups, logs, screenshots, cache, firmware, and the original chassis.

03

Stop import and initialization attempts

Do not clear foreign state or create a replacement virtual disk.

04

Image before experimenting

Perform geometry analysis against protected member copies.

NEPFOSYS process

How a data-first evaluation proceeds.

01

Metadata and pattern analysis

NEPFOSYS reviews surviving RAID records and cross-disk structures.

02

Geometry candidate testing

Order, offset, stripe size, rotation, and level are evaluated without source writes.

03

Filesystem-wide validation

The chosen layout is checked across directories, large files, databases, and requested data.

A clear next step

Preserve the original device before another repair or recovery attempt.

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 review

Questions, answered

What customers ask before starting.

Can stripe size be guessed from disk count?

No. Disk count does not determine stripe size, order, offsets, or parity rotation.

What if the controller configuration was deleted?

Surviving disk metadata and logical patterns may still support reconstruction, but do not recreate the array first.

Why test large files?

They cross more stripe boundaries and expose geometry errors that small files may not reveal.

DFW local · Nationwide mail-in

Protect the device. Start with the facts.

Start my recovery case