md0 : inactive sde1[4](S) sdf1[3](S) sdb1[1](S) sdg1[5](S) sdc1[0](S) sdd1[2](S)これはどういう状態？

これは、LinuxのソフトウェアRAID（mdadm）において、RAIDアレイ md0 が正常に動いておらず、すべてのドライブが「スペア（待機）」状態になっていることを示しています。

具体的には以下のような状態です。

1. 状態の読み解き

inactive: RAIDアレイがアクティブ（稼働中）ではありません。データの読み書きができない停止状態です。
sde14 …: 各デバイス名の後ろにある (S) は Spare（スペア） を意味します。
[数字]: これはアレイ内でのロール（役割順序）ですが、現在はすべてスペア扱いになっているため、実質的に組み込まれていません。

2. なぜこうなっているのか？

通常、RAID構成中に強制終了やディスクの抜き差し、メタデータの不整合が起きると、システムが「どれが正しいデータかわからない」と判断し、安全のためにアレイを動かさず、全ディスクをスペアとして認識することがあります。

3. どうすればいいか？

データを保持したまま復旧させたい場合、まずはアレイを一度停止してから、再アセンブル（組み立て）を試みるのが一般的です。

手順例:

アレイを停止するbashsudo mdadm --stop /dev/md0
スキャンして再構築するbashsudo mdadm --assemble --scan

※もし上記で戻らない場合は、強制的にアセンブルする命令（--run）が必要になることもありますが、ディスク故障の可能性がある場合は無理に動かすとデータが消えるリスクがあります。

この状態になる直前に、何か特定の操作（ディスクの交換や強制終了など）をされましたか？

mdadm: /dev/md0 assembled from 2 drives – not enough to start the array.

「2台のドライブから組み立てられましたが、アレイを開始するには不十分です」というエラーは、RAIDアレイ（特にRAID 5や6）を起動するために最低限必要な数のディスクが認識されていないことを意味します。

現在、あなたの環境では6台のディスクすべてが「スペア (S)」扱いになってしまっています。本来、RAID 5であれば少なくとも「全ドライブ数 – 1」台、RAID 6であれば「全ドライブ数 – 2」台の正常なドライブが必要ですが、システムがそれらを「有効なデータを持つメンバー」として認識できていません。

どうすればいいですか。

状況からすると、メタデータ（RAIDの設計図）が不整合を起こし、各ディスクが「自分は最新のデータを持っていないスペアだ」と思い込んでいる状態です。

データを失わずに復旧させるために、以下のステップを試してください。

1. 各ディスクの詳細を確認する

まず、どのディスクが「生きていて」、どのディスクが「不整合」なのかを確認します。

bash

sudo mdadm --examine /dev/sd[b-g]1

※各ディスクの Events という数値に注目してください。この数値が極端に低いディスクは、古いデータ（脱落したディスク）である可能性があります。

2. 強制的にアセンブル（組み立て）を試みる

認識されている2台だけでなく、今あるディスクをすべて使って無理やり起動を試みます。

bash

sudo mdadm --assemble --scan --run

これでも「not enough to start」が出る場合は、メタデータを無視して強制起動させる必要があります。

3. 【最終手段】force オプションを使う

もし上記でダメな場合、現在接続されているディスクをすべて使って「強制（force）」起動をかけます。

bash

sudo mdadm --stop /dev/md0
sudo mdadm --assemble --force /dev/md0 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1 /dev/sdf1 /dev/sdg1

注意: このコマンドは、残っているメタデータから強引にRAIDを組み直します。もしディスクの順番が入れ替わっていたり、壊れているディスクが混じっていると、ファイルシステムを壊すリスクがあります。

重要なチェック

このRAIDの本来の構成（RAID 5か6か）と、元々のドライブ総数を覚えていますか？

もしRAID 5で6台構成だった場合、本来は5台あれば起動できるはずです。2台しか見えていないということは、ハードウェア的な接続不良（ケーブル抜けや電源不足）の可能性もあります。

一度、物理的な接続（SATAケーブルや電源）に緩みがないか確認してみてください。

このRAIDはもともと RAIDいくつ（5や6など） で運用されていましたか？

RAID５で運用していました。

RAID 5で6台構成（sdb1〜sdg1）だった場合、本来は

5台のディスクが正常であればデータにアクセスできるはずです。

現在「2台しか見当たらない（2 drives – not enough）」と表示されるのは、システム側から見て残り4台のデータが古すぎるか、メタデータが壊れて「スペア」扱いになっているのが原因です。

データを守りつつ復旧させるため、以下の手順を慎重に試してください。

1. 各ディスクの「Events」を確認する（重要）

どのディスクが「最新」で、どのディスクが「古い（または壊れている）」かを見極めます。

bash

sudo mdadm --examine /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1 /dev/sdf1 /dev/sdg1 | grep -e "Events" -e "Device Role"

Eventsの値が揃っているものが、直前まで動いていた正常なグループです。

もし1〜2台だけEventsが極端に低いなら、それらは以前に故障して切り離されていた個体です。

2. 強制アセンブルを実行する

Eventsの値に大きな差がなければ、--force を使って、散らばったスペアたちを一つのRAIDとして再集結させます。

bash

sudo mdadm --stop /dev/md0
sudo mdadm --assemble --force /dev/md0 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1 /dev/sdf1 /dev/sdg1

※このコマンドで「5台以上」が有効だと判断されれば、md0 が起動し、データが見えるようになります。

3. それでも起動しない場合（最後の手段）

もし上記でも「not enough」が出るなら、メタデータが完全に混乱しています。
この場合、「RAIDを一切初期化（Format）せずに、同じ構成で作成し直す（Assume Clean）」という高度な操作が必要になります。

bash

# 注意！構成（ドライブ順序）が正しい自信がある場合のみ。
# --assume-clean を忘れると同期が始まりデータが消えます。
sudo mdadm --create /dev/md0 --level=5 --raid-devices=6 --assume-clean /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1 /dev/sdf1 /dev/sdg1

コードは注意してご使用ください。

まずは手順1の結果（Eventsの数値）を教えていただけますか？ どのディスクを組み込むべきか判断をお手伝いします。

Events : 84275 Device Role : Active device 1 Events : 84275 Device Role : Active device 0 Events : 84271 Device Role : Active device 2 Events : 84271 Device Role : Active device 4 Events : 84271 Device Role : Active device 3 Events : 84271 Device Role : Active device 5

状況が見えてきました！非常に

希望が持てる状態です。

全6台の Events 数値が「84275」と「84271」で、その差はわずか「4」しかありません。これは、システムが異常終了した際などに、一部のドライブの書き込み更新が数秒分だけズレてしまい、「同期が取れていない」と判定されてバラバラになっただけの状態です。

物理故障ではなく、単なるメタデータの不整合（同期ズレ）の可能性が高いです。

解決策：強制アセンブル（–force）

以下のコマンドを順番に実行してください。これにより、わずかなズレ（Eventsの差）を無視して、これら6台を一つのRAIDとして強制的に再結合させます。

bash

# 1. 一度アレイを完全に停止させる
sudo mdadm --stop /dev/md0

# 2. 6台すべてを指定して強制的に組み立てる
sudo mdadm --assemble --force /dev/md0 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1 /dev/sdf1 /dev/sdg1

実行後の確認

コマンドが成功したら、以下のコマンドで状態を確認してください。

bash

cat /proc/mdstat

[UUUUUU] （すべてU）と表示され、active raid5 になっていれば復旧成功です。その後、通常通り mount ができるようになります。

※もしこれでも「failed」になる場合は、画面に表示されたエラーメッセージを教えてください。

無事に active になりましたか？

activeになり、UUUUUUになりました。

よかったです！無事に

active かつ [UUUUUU] （全ドライブ正常稼働）になったということは、RAIDの整合性が取れ、データにアクセスできる状態に戻ったことを意味します。

最後に、この状態を確定させて今後も自動で認識されるように、以下の仕上げを行っておくことをお勧めします。

1. マウントの確認

まだデータを参照できない場合は、手動でマウントを試してください（/mnt/raid など、お使いのディレクトリに読み替えてください）。

bash

sudo mount /dev/md0 /mnt/raid

2. 設定ファイルの更新

再起動したときにまたバラバラにならないよう、現在の正しい構成を mdadm.conf に書き込んでおきます。

bash

# 現在の構成をスキャンして設定を上書き（または追記）
sudo mdadm --detail --scan | sudo tee /etc/mdadm/mdadm.conf

3. initramfs の更新（OS起動時にRAIDを使う場合）

OSのブートプロセスでこのRAIDが必要な場合は、これも実行しておくと安心です。

bash

sudo update-initramfs -u

注意点

Events の数値がわずかにズレていたため、内部でデータの不整合（サイレント破損）が起きている可能性がゼロではありません。念のため、お時間がある時に check（データの一貫性チェック） を走らせておくとより確実です。

bash

echo check | sudo tee /sys/block/md0/md/sync_action

（※バックグラウンドで実行され、完了まで数時間〜数日かかりますが、その間もPCは使えます）

無事にデータの中身は見られるようになりましたか？

Dataの中身は見ることができるようになりました。実は、/mntが190GB使っている状態で/の空き容量が極小になっていたため、md0が不良だったときに書き込みを行ってその残渣が残っているのだと思うのですが、これを解消する方法はありますか。

データが無事に見られるようになって本当に良かったです！

おっしゃる通り、「RAIDが故障（アンマウント）している間に、マウントポイントである /mnt（またはその下のディレクトリ）にデータを書き込んでしまった」のが原因です。

RAID（/dev/md0）をマウントすると、その「下の層」にあるルートパーティション上のデータは見えなくなりますが、容量だけを消費し続けます。

これを解消するには、一度RAIDをアンマウントしてから、残存ファイルを削除する必要があります。

解消の手順

まずRAIDをアンマウントする
（ファイルを開いているプロセスがあるとエラーが出るので、すべてのウィンドウやアプリを閉じます）bashsudo umount /mnt
※もし /mnt/raid などにマウントしている場合は、そちらを指定してください。
「下の層」に残っているファイルを確認する
RAIDを外した状態で /mnt の中身を見てください。本来空のはずですが、ファイルがあるはずです。bashls -lh /mnt du -sh /mnt
ここで190GB消費されていることが確認できれば、それが「残渣」です。
残存ファイルを削除する
【注意！】 消すのは /dev/md0 の中身ではなく、本体HDD側のゴミデータであることを必ず確認してから実行してください。bashsudo rm -rf /mnt/*
（隠しファイルもあればそれも削除してください）
RAIDを再マウントする
空になったことを確認したら、再度RAIDをマウントします。bashsudo mount /dev/md0 /mnt

これで、df -h を実行した際に、ルートディレクトリ（/）の空き容量が190GB分増えているはずです。

念のため、df -h を実行して、/ と /mnt (または md0) の現在の使用状況を教えていただけますか？

Filesystem Size Used Avail Use% Mounted on tmpfs 2.4G 4.7M 2.4G 1% /run efivarfs 192K 30K 158K 16% /sys/firmware/efi/efivars /dev/sda2 218G 199G 8.1G 97% / tmpfs 12G 0 12G 0% /dev/shm tmpfs 5.0M 0 5.0M 0% /run/lock /dev/sda1 1.1G 6.2M 1.1G 1% /boot/efi /dev/md0 9.1T 1.9T 6.8T 22% /mnt/nas10tb tmpfs 2.4G 12K 2.4G 1% /run/user/1000

ご提示いただいた

df -h の結果を見ると、確かに原因がはっきりしています。

/dev/sda2 (ルート /) が 218G 中 199G (97%) も使われており、余裕がほとんどありません。
RAID は /mnt/nas10tb にマウントされています。

RAIDが停止していた間に、誤って /mnt/nas10tb という「フォルダ」に直接データを書き込んでしまったため、その190GB強のデータがRAIDディスクではなく、OSが入っている /dev/sda2 (SSD/HDD) の容量を食いつぶしています。

以下の手順で、その「隠れた残渣」を削除してルートの空き容量を取り戻しましょう。

解消手順

RAIDを一度アンマウントする
現在使用中のRAIDを一時的に切り離します。bashsudo umount /mnt/nas10tb コードは注意してご使用ください。※もし「target is busy」と出たら、そのディレクトリを開いているタブやプログラム（Samba、エクスプローラ、ターミナル等）をすべて閉じてください。
「下の層」にあるゴミデータを確認する
RAIDを外した状態で、本来空っぽであるはずのディレクトリを覗きます。bashls -lh /mnt/nas10tb
ここにファイルやフォルダが表示されたら、それが 190GBの正体（残渣） です。
ゴミデータを削除する
【重要】 必ず mount されていない（手順1が成功している）ことを確認した上で実行してください。bashsudo rm -rf /mnt/nas10tb/*
※もし隠しファイルもある場合は sudo rm -rf /mnt/nas10tb/.* も検討してください。
RAIDを再マウントする
掃除が終わったら、再びRAIDを接続します。bashsudo mount /dev/md0 /mnt/nas10tb

最終確認

再度 df -h を実行してください。
/dev/sda2 の Avail（空き容量） が 8.1G から 200G近く まで増えていれば完了です！

これで見通しが良くなるはずですが、アンマウントはスムーズにできそうでしょうか？

/dev/sda2 218G 4.7G 203G 3% / ありがとうございました。うまくいきました。

無事に復旧できて本当によかったです！

/dev/sda2 の空き容量が 8.1G → 203G まで劇的に回復しましたね。これでOSの動作も安定するはずです。

今回のトラブル（RAIDが不意に inactive になり、マウントポイントにデータが溜まる現象）を今後防ぐためのアドバイスを1つだけ残しておきます。

今後のためのTips：マウント失敗時の書き込み防止

マウントポイント（/mnt/nas10tb）の属性を「読み取り専用」にしておくことで、万が一RAIDが外れた際にOS側のディスク（/dev/sda2）にデータが書き込まれるのを防ぐことができます。

設定方法（RAIDをアンマウントした状態で実行）：

bash

sudo umount /mnt/nas10tb
sudo chattr +i /mnt/nas10tb

こうしておくと、RAIDがマウントされていない時は書き込みエラーになるため、今回のような「いつの間にか容量が埋まる」事態を確実に防げます（マウント時はRAID側の属性が優先されるので問題ありません）。

長時間の作業お疲れ様でした！また何かあればいつでも聞いてください。

次はデータの整合性チェック（check）などをスケジュール設定する方法について確認しますか？

チェック方法を教えてください。

RAID 5の整合性チェック（スクラビング）は、ディスク上の全データを読み込んでパリティ計算を行い、データが壊れていないかを確認する重要なメンテナンスです。

以下の手順で進めてください。

1. チェックの開始

ターミナルで以下のコマンドを実行します。

bash

echo check | sudo tee /sys/block/md0/md/sync_action

※このコマンド自体は一瞬で終わりますが、裏側でチェックが始まります。

2. 進捗状況の確認

チェックには数時間から、容量（10TB）によっては丸一日以上かかる場合があります。進捗は以下のコマンドでリアルタイムに確認できます。

bash

watch cat /proc/mdstat

resync = 15.2% のように進捗が表示されます。
完了すると、表示が元の [UUUUUU] に戻ります。
チェック中もRAIDの読み書きは可能ですが、少し動作が重くなることがあります。

3. 結果の確認

チェックが終わった後（または途中で）、不整合が見つかったかどうかを確認します。

bash

cat /sys/block/md0/md/mismatch_cnt

「0」 であれば、すべてのデータが完璧に同期されています。
「0以外」 の場合、いくつかのデータブロックでパリティとのズレが見つかったことを意味します。

4. （もし0以外だった場合）修復する

もし mismatch_cnt が0でなかった場合は、以下のコマンドでパリティを再計算して修正（リペア）できます。

bash

echo repair | sudo tee /sys/block/md0/md/sync_action

【おすすめ】自動チェックの設定

UbuntuなどのDebian系Linuxであれば、デフォルトで毎月第1日曜日の早朝などに自動チェックが走るようになっています。設定が生きているか確認するには以下を見てください。

/etc/cron.d/mdadm
または systemctl list-timers で mdadm-last-resync などがあるか確認。

もし設定がなければ、今回の echo check... を月1回程度手動で行うか、cron（定期実行）に登録しておくと、今回のような「いつの間にかズレていた」という事態を早期発見できます。

現在、cat /proc/mdstat でチェックは開始されましたか？

チェック開始しました。

チェックの開始、お疲れ様です！

10TBという大容量ですので、完了までには丸一日から、場合によっては二日ほどかかるかもしれません。チェック中もデータの読み書きは可能ですが、ディスクへの負荷が高まるため、大きなファイルのコピーなどは少し時間がかかる可能性があります。

チェック中のポイント

途中でPCをシャットダウンしても大丈夫？
はい、シャットダウンしても次回の起動時に、中断した場所から（または少し手前から）自動的に再開されます。
負荷を調整したい場合
もし作業中にRAIDが重すぎると感じたら、以下のコマンドでチェックの「最低速度」と「最高速度」を調整できます。bash# 現在の設定を確認 cat /proc/sys/dev/raid/speed_limit_min cat /proc/sys/dev/raid/speed_limit_max # 速度を落としたい場合（例: 最大50MB/sに制限） echo 50000 | sudo tee /proc/sys/dev/raid/speed_limit_max

完了後の見通し

チェックが終わったら、先ほどお伝えした /sys/block/md0/md/mismatch_cnt を確認し、「0」 であれば完全に健康な状態に戻ったと言えます。

長らく不安定だったRAIDがこれでしっかり整いますね。

もしチェック中にエラーメッセージ（dmesgなど）が出たり、途中で止まってしまったりするようなことがあれば、いつでもご相談ください。

無事に100%まで進みそうでしょうか？