なぜRAIDアレイは停電後に非アクティブになるのですか？

電源喪失後、RAIDアレイはメタデータが検出されたものの、システムが利用可能なメンバーと状態で安全に起動できなかったために非アクティブのままになることがあります。

「非アクティブ」という用語は主にLinuxのmdアレイを指しますが、他のストレージスタックでも同様のインポートや起動失敗が起こります。強制起動を試みる前に、デバイスの検出、メンバーメタデータ、ダーティまたは劣化状態、起動設定、電源経路の障害を確認してください。

Linux RAIDにおける「非アクティブ」の意味を理解する

非アクティブなmdアレイは、デバイスや一部の設定が接続されていても通常のI/Oを拒否します。これは単にマウントされていない健全なアレイとは異なり、マウントコマンドで欠落した起動ステップを修復することはできません。

非アクティブなアレイ状態とは、設定はされているがアクティブでなく、I/Oがエラーを返す状態です。この状態により、システムはアレイが準備完了であるふりをせずにメンバーの検出や再構成を続けられます。

状態を変更する前に、/proc/mdstat、アレイの詳細、各メンバーのスーパーブロックを調査してください。目的は起動が停止した理由を知ることであり、メンバーセットを確認せずに「非アクティブ」を「アクティブ」に変えることではありません。

1つ以上のメンバーが再認識されていない可能性がある

突然の停電は、電源ケーブル、バックプレーン、SATAケーブル、コントローラーポート、ドライブのいずれかが次回起動時に初期化に失敗することを露呈させます。その結果、アレイはメタデータが示すよりも少ないメンバーしか認識しません。

mdadmは通常、起動前に利用可能な非スペアデバイスと期待されるアクティブ数を比較します。期待されるデバイスが欠落している場合でも、十分なメタデータがあればmdデバイスエントリを作成し、アレイは部分的に組み立てられたままになることがあります。

ハードウェアの検査が必要な場合は安全に電源を切り、コネクタ、スピンアップ、コントローラ検出、シリアル番号、SMARTデータを確認してください。劣化起動を選択する前に接続を復元してください。なぜなら、一時的な経路障害の方がアレイの再構築よりも簡単かつ安全に修復できる場合があるからです。

不適切なシャットダウンはアレイをダーティ状態にすることがある

電源喪失は、すべてのメンバーとパリティブロックが一貫した状態に達する前に書き込みを中断させることがあります。その場合、アレイのメタデータは次回起動時に再同期、ビットマップ再生、ジャーナル再生、またはその他の整合性処理が必要であることを記録します。

Linux mdは予期しないシャットダウン後に、完全再同期、書き込み意図ビットマップ、ジャーナル、部分的パリティログなど異なる整合性ポリシーをサポートしています。整合性ポリシーは、冗長性を再び信頼できるようになるまでに必要な作業量を決定します。

ダーティだが完全なアレイは正常に起動して再同期することがあります。ダーティかつ劣化したアレイは、欠落データや不確かなパリティにより信頼できる再構築に必要な情報が失われる可能性があるため、より慎重な対応が必要です。

ダーティかつ劣化したパリティは安全上の起動拒否を引き起こすことがある

RAID 5またはRAID 6は、ダーティかつメンバーが欠落している場合、起動時に拒否されることがあります。この拒否は、パリティが古くなっている可能性があり、欠落したデータを他のコピーと照合できない状態を防ぐためのものです。

ダーティかつ劣化した状態での起動拒否は、強制起動が検出不能な破損を生む可能性があるため存在します。したがって、強制劣化起動は通常の起動動作ではなく、明示的な管理者の判断によるものです。

欠落メンバー、バックアップ状況、書き込み履歴が理解されるまではこの保護を迂回しないでください。まずデバイスパスを復元するか故障メンバーをクローンし、回復を続ける場合は書き込みを最小限に抑え、回復したファイルを独立して検証してください。

起動時の検出と設定が不完全なことがある

すべてのディスクが正常でも、デバイス検出が組み立て試行後に完了したり、設定にアレイの識別情報が欠けていたり、initramfsに古いRAID設定が含まれているために起動時にアレイが見つからないことがあります。

RAID設定ファイルは、起動ツールがスキャンおよび組み立てるデバイスとアレイを記述します。正確なアレイ設定記録は、自動検出が意図したセットを確実に推測できない場合に特に重要です。

実際のメンバーUUIDとインストール済み設定および起動環境を比較してください。実際のアレイ識別を確認した後にのみ古い設定を修正してください。不完全なメンバーセットから新しい設定を生成すると、次回起動が一貫して誤ったものになる可能性があります。

外部メタデータはユーザースペースの管理者を必要とする場合がある

一部のアレイはカーネルだけでなくユーザースペースで管理される外部メタデータ形式を使用しています。突然の障害後、コンテナやモニタープロセスがメンバー状態変更に必要な確認応答を完了していないことがあります。

外部管理メタデータは、ユーザースペースがイベントを確認するまで活動を保留することがあります。したがって、非アクティブなコンポーネントセットは、データディスクの故障ではなく管理ステップの欠落を反映している可能性があります。

一般的なmdコマンドを適用する前にメタデータ形式を特定してください。ファームウェア支援やコンテナ形式は、適切なモニター、コントローラユーティリティ、またはNAS回復ワークフローを必要とし、メタデータ更新が正しい順序で行われるようにします。

リスクの低い順に回復を進める

まず読み取り専用の証拠から始めます：安定したIDでブロックデバイスを一覧表示し、シリアル番号をスロットにマッピングし、メンバーメタデータを調べ、前回の起動ログを確認し、すべての期待されるディスクが存在するかをチェックします。新しいアレイを作成したりスーパーブロックをゼロクリアしたりしないでください。

接続と設定が修正された後にプラットフォームの通常の組み立てを試みてください。サポートされていれば読み取り専用または読み取り自動モードを使用し、正確な欠落メンバーと整合性リスクが理解されている場合にのみ劣化動作や強制オプションを使用してください。

回復後は再同期やスクラブを完了し、バックアップを確認し、障害経路を調査してください。UPS、信頼できる電源と配線、最新のRAID設定、安定したデバイスID、アラート機能は、次回の電源イベントで同じ非アクティブ状態が発生する可能性を減らします。