mdadmソフトウェアRAIDが縮退したときの復旧フロー｜障害ディスクの交換からアレイ再構築と整合性確認まで

RAIDの縮退（デグレード）とは何か

ソフトウェアRAIDを構成する複数のディスクのうち、1本以上が脱落または故障した状態を「縮退（デグレード）」と呼びます。RAID 1やRAID 5・6では冗長性の設計上、一定本数の故障まではデータの読み書きを継続できますが、その間はアレイは無防備な状態にあります。RAID 5なら1本の故障で縮退、RAID 6なら2本目の故障まで動作を継続しますが、さらに1本が抜けた瞬間にアレイ全体がクラッシュしてデータは失われます。

現場では「ディスクエラーのアラートが来たのに、サービスが落ちていないからしばらく放置」というケースが散見されます。しかし縮退時間が長引くほど、残存ディスクへの読み取り負荷が集中してセカンダリ障害が起きるリスクが高まります。縮退を検知したら、できるだけ速やかに対処するのが鉄則です。

障害ディスクの特定と縮退状態の確認

まずアレイの現在の状態を把握します。mdadmで管理されているアレイは /proc/mdstat を参照するのが最も手軽です。

cat /proc/mdstat

出力中に [UU_] のように _（アンダースコア）が含まれている場合、その位置のデバイスが脱落していることを示します。より詳細な情報はmdadmコマンドで確認します。

sudo mdadm --detail /dev/md0

出力の State 行が clean, degraded となっていれば縮退状態です。Failed Devices の数値と、各デバイスの行に表示される faulty フラグで障害ディスクを特定します。物理的なディスクとの対応は lsblk や smartctl で確認します。

sudo smartctl -H /dev/sdb

SMARTのヘルスステータスが PASSED でなければ、そのディスクは交換対象と判断します。なお、カーネルのリードエラーにより論理的に障害扱いになっていても、SMARTが正常を示すケースがあります。その場合はディスク自体の物理障害か、ケーブル・コントローラ側の問題かを切り分ける必要があります。

障害ディスクの取り外しとアレイからの除外

ホットスワップ対応の環境であれば、アレイを停止せずにディスクを交換できます。まずmdadmでアレイから対象デバイスを明示的に除外します。すでに faulty 状態になっていればこの手順は省略できる場合もありますが、確実を期すために実行しておきます。

sudo mdadm /dev/md0 --fail /dev/sdb
sudo mdadm /dev/md0 --remove /dev/sdb

コマンド実行後、再度 --detail で sdb がアレイのメンバーから外れていることを確認してから物理的にディスクを抜きます。ホットスワップ非対応のサーバの場合はシャットダウンが必要です。その際、rootパーティションがRAID上にある構成では initramfs の設定が正しく行われているかを事前に確認しておかないと、縮退状態でのブートに失敗するケースがあります。

新しいディスクを取り付けたら、パーティションテーブルを既存の正常ディスクからコピーします。GPTパーティションの場合は sgdisk を使います。

sudo sgdisk /dev/sdc -R /dev/sdb
sudo sgdisk -G /dev/sdb

MBRの場合は sfdisk でパーティションテーブルを複製します。パーティションタイプをLinux RAID（fd）に設定し忘れると、再追加時にエラーになることがあるため注意が必要です。

アレイへの再追加と再構築の開始

新しいディスク（またはパーティション）をアレイに追加します。

sudo mdadm /dev/md0 --add /dev/sdb1

追加が成功すると、即座に再構築（リビルド）が始まります。進捗は /proc/mdstat をリアルタイムで確認できます。

watch -n 5 cat /proc/mdstat

出力例として recovery = 23.4% (23456789/100000000) finish=45.2min speed=87654K/sec のような表示が出ます。完了するまでの時間はアレイのサイズとディスク速度に依存し、数テラバイト規模では数時間に及ぶこともあります。再構築中もアレイは読み書き可能ですが、I/O負荷が上がるため業務影響が懸念される場合は、再構築の速度を絞ることができます。

# 最大速度を一時的に制限する（単位: KB/s）
echo 20000 | sudo tee /proc/sys/dev/raid/speed_limit_max

この値はシステム再起動で元に戻ります。永続化する場合は /etc/sysctl.d/ に設定を追記します。

再構築完了後の整合性確認

再構築が完了したら、アレイの状態が clean に戻ったことを確認します。

sudo mdadm --detail /dev/md0

State : clean、Active Devices と Working Devices の数が一致し、Failed Devices : 0 になっていれば再構築は正常完了です。続いて整合性チェック（scrub）を実施します。再構築によってデータはディスクに書き込まれていますが、ビット化けや潜在的な不整合が残っている可能性を排除するための手順です。

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

進捗は /proc/mdstat または以下で確認できます。

cat /sys/block/md0/md/sync_completed

チェック完了後、/sys/block/md0/md/mismatch_cnt の値を確認します。ゼロであれば問題なし、非ゼロの場合は不整合ブロックが存在します。RAID 5/6では自動修復オプション（repair）で修正できますが、RAID 1では2本のうちどちらが正しいかをmdadmが判断できないため、修復前にデータの確認が推奨されます。

整合性確認を定期的に自動実行する仕組みとして、多くのディストリビューションでは mdadm パッケージインストール時にsystemdのタイマーユニットが導入されます。Ubuntu 22.04/24.04ではsystemdのサービスとして管理されているため、以下で状態を確認できます。

systemctl status mdmonitor.service
systemctl list-timers | grep md

2026年現行環境での注意点と切り戻し

2025〜2026年時点で主流となっているUbuntu 24.04（Noble）やDebian 12（Bookworm）、RHEL 9系では、以前は /etc/mdadm/mdadm.conf の手動編集が必要だった設定の多くがsystemdのユニットや mdadm --scan の自動検出で処理されます。ただし、新しいディスクをアレイに追加した後、設定ファイルの更新は依然として必要なケースがあります。

sudo mdadm --detail --scan | sudo tee -a /etc/mdadm/mdadm.conf

重複エントリを追記しないよう、実行前に既存の ARRAY 行を確認・削除してから実行するのが安全です。initramfsの更新も忘れずに行います。

# Debian/Ubuntu系
sudo update-initramfs -u

# RHEL/AlmaLinux/Rocky系
sudo dracut --force

切り戻しが必要になる状況として、「交換したディスクも不良品だった」「再構築中に別のディスクが故障した」ケースがあります。RAID 5環境で再構築中に追加障害が発生するとアレイはクラッシュします。この状況を防ぐには、再構築前に既存の正常ディスク全本のSMARTデータを取得しておき、再構築時間と照らし合わせてリスク評価することが重要です。特に運用年数が長い環境では、縮退検知を機に全ディスクの一斉交換を検討する現場も増えています。

アレイがクラッシュした場合に備えたバックアップは、mdadm運用の前提条件です。RAIDはバックアップの代替ではなく、あくまでもディスク障害に対する可用性向上の手段であることを、運用設計の段階から明確にしておく必要があります。定期的な mdadm --examine によるスーパーブロックの確認と、scrubの実施ログ保管を組み合わせることで、障害時の対応速度と根拠の明確さが格段に向上します。