Controller metadata, foreign configurations, and missing virtual disks.

Section 1

How controllers identify and assemble an array

A controller must decide which devices belong to the set, how they are ordered, and how their blocks form the logical volume. Depending on the platform, that decision can use configuration stored on member disks, controller-held configuration, enclosure or slot information, and the state reported by each member.

• Member identity: serial numbers, WWNs, device identifiers, and controller records help distinguish the intended drives from replacements or unrelated media.
• Layout information: RAID level, member count, stripe geometry, offsets, parity behavior, and logical capacity define how blocks relate.
• Configuration agreement: the controller evaluates whether the available records describe one usable array state.
• Physical status is only one layer: a drive can respond normally while the controller cannot place it confidently in the expected virtual disk.

Section 2

Why a foreign configuration appears

A foreign-configuration message generally means the controller found RAID configuration information that is not part of the configuration it currently expects. The correct response depends on how the system reached that state.

• A controller was replaced or reset.
• Drives were moved, reseated, or connected through different slots or paths.
• A member or replacement contains configuration from another array.
• Power loss or an interrupted operation left the controller and member set presenting different states.
• More than one candidate configuration is present.

Importing may be appropriate in a documented migration. It is not a safe diagnostic experiment when the member set, order, history, or proposed configuration is uncertain.

Section 3

Why a virtual disk may not be presented

A missing virtual disk does not by itself establish that the data is gone. It establishes that the controller is not presenting the expected logical device. Possible causes include incomplete membership, lost or conflicting configuration, controller or enclosure changes, unreadable regions, and an array state that the firmware will not assemble automatically.

• Record whether all expected physical members are detected.
• Compare the reported logical capacity and RAID level with the known configuration.
• Preserve any foreign, unconfigured, offline, or failed labels.
• Do not create a new logical drive with the old capacity as a test.

Section 4

Why a rebuild may not start or continue

A rebuild depends on sustained access to the surviving members and a sufficiently coherent source state. It may be blocked or may stop because the controller cannot accept the replacement, another member becomes unreadable, configuration conflicts remain, or the source set cannot supply the blocks needed to continue.

• Record the exact starting and stopping percentage.
• Preserve the original member and the partial rebuild target.
• Capture which member was being rebuilt and every associated error.
• Do not assume that repeating the same rebuild leaves the remaining members unchanged.

Section 5

Power loss, cache, and incomplete writes

A power event can interrupt ordinary application writes, filesystem updates, RAID metadata changes, or cached controller operations. The result may be a consistent older state, an incomplete newer state, or damage at more than one layer. The controller display alone cannot determine which layer contains the first inconsistency.

• Preserve controller cache and battery or capacitor status when available.
• Record whether the system restarted automatically and whether a rebuild, patrol read, or consistency operation began.
• Distinguish a missing array from an array that mounts but contains filesystem or database damage.
• Protect the storage state before repair tools introduce additional writes.

Section 6

Member order, identity, and migration conflicts

Some platforms can identify members independently of physical bay order; others also rely on enclosure and slot mappings. In either case, the original arrangement remains valuable evidence and should be recorded rather than deliberately changed during diagnosis.

• Map each original bay to the drive serial number or WWN.
• Keep removed, replacement, and suspected members separately labeled.
• Record controller, enclosure, cable, and expander changes.
• Do not “try every order” on hardware that may write configuration or begin background work.

Section 7

Controlled triage before import, clear, rebuild, or repair

1. Stop unnecessary writes. Do not initialize, recreate, clear, import, rebuild, repair, or force-mount solely to see what happens.
2. Document the system. Capture controller and enclosure models, firmware, screens, logs, physical status, logical status, and event history.
3. Identify every member. Record bay, serial number, WWN, capacity, sector size when relevant, and whether the member is original or a replacement.
4. Evaluate source stability. Determine which members can sustain reads and which require controlled imaging or specialist work.
5. Protect sources. When imaging is required, use separate destination storage and retain error maps and verification records.
6. Determine the layout from protected access. Establish membership, order, offsets, stripe geometry, parity behavior, and the best available write state.
7. Reconstruct and validate away from the sources. Test the logical volume, filesystem, databases, and priority files before accepting a recovery result.