突然アレイが inactive（非活性）になると焦りますよね。
結論から言うと、「アレイが構成情報を失って停止している」状態ですが、データが消えた（壊れた）と決まったわけではありません。
RAID5のメタデータ（管理情報）の読み込みに失敗したり、起動時にデバイスが揃わなかったりすると、このように「とりあえずデバイスは認識しているが、アレイとしては動かさない」という保護状態になります。
以下の手順で復旧を試みてください。
1. アレイを強制的に開始させる
まず、現在の構成情報を使ってアレイを再活性化（start）させます。
bash
sudo mdadm --run --assemble /dev/md0 /dev/sd[bcdefg]1
※もし mdadm.conf が正しく設定されているなら、単純に sudo mdadm --assemble --scan でも構いません。
2. それでも起動しない場合（詳細の確認）
上記でエラーが出る場合は、各ディスクのメタデータがどうなっているかを確認します。
bash
sudo mdadm --examine /dev/sd[bcdefg]1
ここで “State : clean” や “active” と表示されているか、あるいは “dirty” や “failed” になっているディスクがないかチェックしてください。
3. 注意点
--createは厳禁: 焦ってmdadm --createを実行しないでください。データが完全に消去される可能性があります。 Linux RAID Wiki（英語）などの専門サイトでも、安易な再作成は推奨されていません。- 原因の切り分け: 物理故障（ケーブル抜けやHDDの寿命）が原因で
inactiveになることが多いです。dmesgコマンドで I/Oエラーが出ていないか確認してください。
まずは --assemble を試して、その結果（エラーメッセージなど）を教えていただけますか？
どのコマンドでエラーが出ましたか？ または dmesg に何か怪しいログは残っていますか？
mdadm: –assemble would set mdadm mode to “assemble”, but it is already set to “misc”.
そのエラーは、「既に md0 という名前のデバイスが（不完全な状態で）存在しているため、新しくアセンブル（起動）モードに入れない」という mdadm の仕様によるものです。
man7.org
現在の md0 は inactive（非活性）としてシステムに掴まれているため、一度それを解放（停止）してからやり直す必要があります。
以下の手順を試してください。
1. 現在の不完全なアレイを停止する
まず、現在 inactive で残っている /dev/md0 を一度停止させます。
bash
sudo mdadm --stop /dev/md0
2. 再度アセンブルを実行する
停止できたら、改めてアレイの起動を試みます。
bash
sudo mdadm --assemble --run /dev/md0 /dev/sdf1 /dev/sdb1 /dev/sdg1 /dev/sdc1 /dev/sde1 /dev/sdd1
※ ディスクが全て揃っているはずなのに起動しない場合は、末尾に --force を付けることで、多少の情報のズレを無視して強制起動させることができます。
もし「device or resource busy」と出る場合
もし mdadm --stop でエラーが出る場合は、そのデバイスを何らかのプロセスが掴んでいます。
sudo zpool export（ZFSを使っている場合）やsudo vgchange -an（LVMを使っている場合）などで上位レイヤーを停止させてから再度試してください。
この手順で /proc/mdstat の表示は active に変わりましたか？ エラーが出る場合はその内容を教えてください。
assemble で mdadm: failed to RUN_ARRAY /dev/md0: Invalid argument と出ます。
Invalid argument
エラーは、「アセンブルしようとしているディスク間のメタデータ（Events値など）に不整合がある」か、「既に inactive 状態でカーネルに認識されている md0 が邪魔をしている」場合に発生します。
一度 md0 を完全に停止させた上で、情報のズレを無視して強制的に組み立て直す必要があります。
手順：強制アセンブルの実行
- 既存の不完全なアレイを停止する
これをしないと、リソースが使用中（busy）になり、構成のやり直しができません。bashsudo mdadm --stop /dev/md0 --forceを付けてアセンブルする
ディスクが全て揃っている（または1台欠けまで）場合、--forceを使うことで、メタデータのわずかな差異（シャットダウン時のタイミングのズレなど）を無視してアレイを強制起動させます。bashsudo mdadm --assemble --run --force /dev/md0 /dev/sd[bcdefg]1
上記で解決しない場合（情報の確認）
もしこれでも Invalid argument が出る場合は、ディスクごとのステータスを確認し、どの個体が「古い」または「異常」と判断されているか特定する必要があります。
以下のコマンドの結果を確認してください。
bash
sudo mdadm --examine /dev/sd[bcdefg]1 | grep -E 'Update Time|Events|State'
- Events の値が極端に離れているディスクはありませんか？
- State が
activeではなくfailedやfaultyになっているものはありませんか？
--force で起動に成功しましたか？ もし失敗する場合、mdadm --examine の結果に Events値の食い違い がないか教えてください。
forceでもmdadm: failed to RUN_ARRAY /dev/md0: Invalid argumentになります。 examineではState : active Events : 69683 Array State : AAAAAA (‘A’ == active, ‘.’ == missing, ‘R’ == replacing) State : active Events : 69683 Array State : AAAAAA (‘A’ == active, ‘.’ == missing, ‘R’ == replacing) State : active Events : 69683 Array State : AAAAAA (‘A’ == active, ‘.’ == missing, ‘R’ == replacing) State : active Events : 69683 Array State : AAAAAA (‘A’ == active, ‘.’ == missing, ‘R’ == replacing) State : active Events : 69683 Array State : AAAAAA (‘A’ == active, ‘.’ == missing, ‘R’ == replacing) State : active Events : 69683 Array State : AAAAAA (‘A’ == active, ‘.’ == missing, ‘R’ == replacing) となります。
examine
の結果、すべてのディスクで Events (69683) が一致し、Array State (AAAAAA) も正常であるにもかかわらず Invalid argument で失敗する場合、メタデータ自体ではなく、カーネルモジュールの不備やデバイスの重複認識が原因である可能性が高いです。
以下の3つのポイントを順に確認してください。
1. RAIDモジュールが読み込まれているか確認
カーネルが RAID5 を制御する「パーソナリティ（モジュール）」を正しく認識できていないときにこのエラーが出ることがあります。
bash
sudo modprobe raid456
を実行した後、再度 sudo mdadm --assemble --run --force /dev/md0 /dev/sd[bcdefg]1 を試してください。
2. 重複している「古い」アレイ情報を消去する
cat /proc/mdstat で md0 : inactive と表示されている場合、カーネルが古い構成情報をメモリ上に保持しており、新しい組み立て命令を拒否（Invalid argument）している状態です。
一度、確実に停止させてから再実行します。
bash
sudo mdadm --stop /dev/md0
# もし md127 など別の名前で inactive があればそれも停止
sudo mdadm --stop /dev/md127
この後、cat /proc/mdstat を見て unused devices: <none> だけになったことを確認してからアセンブルしてください。
3. Bad Block Log (BBL) の影響を確認
最近の mdadm（1.2以降のメタデータ）では、ディスク上の不良セクタ情報をメタデータに書き込みますが、これが原因で起動できない場合があります。
bash
sudo mdadm --assemble --run --update=force-no-bbl /dev/md0 /dev/sd[bcdefg]1
※これにより不良ブロックログが無視され、起動できることがあります。
4. カーネルログ (dmesg) の確認
上記でも失敗する場合、エラーの真因がカーネルログに出力されています。
bash
dmesg | tail -n 20
ここに “md: personality for level 5 is not loaded!” や “block size conflict” といった具体的な理由が出ていませんか？
modprobe 後のアセンブルで変化はありましたか？ もしダメなら dmesg の最後数行に記録されているエラーメッセージを教えてください。
modprobe後のassembleでmdadm: /dev/md0 has been started with 6 drives.と出ました。
無事にアレイが起動しましたね！お疲れ様でした。
mdadm: /dev/md0 has been started with 6 drives. という表示が出たのであれば、RAIDとしては正常に動き出しています。
念のため、以下の手順で最終確認と後処理を行ってください。
1. 状態の確認
まずは /proc/mdstat を見て、active になっていることと、リシンク（再同期）が走っていないか確認してください。
bash
cat /proc/mdstat
コードは注意してご使用ください。
md0 : active raid5 ... と表示され、末尾に [UUUUUU] とあれば完全復旧です。
2. ファイルシステムのマウント
アレイが認識されたので、次はデータを読み取れる状態にします。
bash
sudo mount /dev/md0 /mnt/your_mount_point
※ /mnt/your_mount_point はご自身の環境に合わせて読み替えてください。
3. 設定の保存（重要）
次回再起動時にまた inactive にならないよう、現在の（正常な）構成を mdadm.conf に反映させておくことを強く推奨します。
bash
# 現在の設定をスキャンして設定ファイルを更新
sudo mdadm --detail --scan | sudo tee /etc/mdadm/mdadm.conf
# 初期RAMディスクの更新（OS起動時にRAIDを正しく認識させるため）
sudo update-initramfs -u
なぜ動かなくなったのか？
今回 modprobe で解決したということは、「何らかの理由でRAID5のカーネルモジュールが自動ロードされなかった」ことが原因の可能性が高いです。OSのアップデート後や、initramfsの不整合で稀に発生します。
マウントして中のデータにはアクセスできましたか？ もしマウント時にエラーが出る場合は、ファイルシステムのチェック（fsck）が必要になるかもしれません。
resync 97.0%ですね
ほぼ完了ですね！もう少しです。
現在、RAIDが全ディスクのデータの整合性を最終チェック（再同期）している状態ですが、97.0% ということは、あとわずかな時間で完了し、冗長性が完全に確保された状態（Clean）になります。
今後の流れと注意点
- そのまま待機:
100%になるまでそのまま待ってください。watch cat /proc/mdstatと打つと、進捗をリアルタイムで監視できます。 - 負荷を避ける:
再同期中はディスクI/Oが発生しているため、大量の書き込みや重い作業は避け、完了を待つのが安全です（読み取りは可能です）。 - 完了後の表示:
完了すると、/proc/mdstatの表示が[UUUUUU]（すべてU）となり、resyncの文字が消えます。
念のためのアドバイス
今回、手動で modprobe しないと動かなかった点が気になります。前回の回答にある update-initramfs -u は、再同期が終わった後に必ず実行しておいてください。これを忘れると、次回の再起動時にまた同じ現象（inactive）が起きる可能性が高いです。
再同期が終わった後、ファイルの中身は無事に見られそうでしょうか？ df -h などのコマンドでマウント状況も確認してみてください。