HDD故障時のRAID5復旧手順と体験談 – トラブルから学ぶストレージ管理

システム管理者にとって、ストレージ障害は最も恐れる事態の一つです。今回は、私が経験したRAID5システムでのディスク故障と復旧の詳細について共有したいと思います。この記事を通じて、同様の状況に直面する方々に実践的な知見を提供できればと思います。

ディスク故障の発生と初期対応

Kubernetesクラスターで運営しているWebサイトで、突然サービスが応答しなくなりました。原因を調査したところ、RAID5構成の4台のディスクのうち1台に障害が発生していることが判明しました。

初期対応の課題

復旧作業を行うにも、予備ディスクがなく近隣にパーツショップも無いため、楽天のツクモで注文したところ、注文後も発送連絡が全く来ない状況が続き、復旧まで何日もかかってしまいました。詳しくは、先日の投稿に記載しています。

1. 予備ディスクの不足
2. 代替パーツの調達の遅延
3. 復旧作業の長期化

ストレージ戦略の変更

復旧作業が進めない状況に陥ってしまったため、改善しないといけないと考えていたストレージ環境について、いい機会と捉え対応する事にしました。

1. ストレージプロビジョナーの移行
2. NVMeストレージへの移行
3. rsyncによる定期的なバックアップ
4. 将来的なファイルシステムの検討（BTRFS）

RAID5復旧の実際の手順

さて、本題のRAID5におけるディスク破損からの復旧ですが、ディスクを搭載したRAIDは最近話題のNASではなく、Raspberry Piがベースとなっているシステムを利用しています。そのため、復旧に関しては、特にGUIやツールがある訳ではなく、コマンドラインでの操作一択という状況でした。

また、ホットスワップに対応した機器でもないため、一旦電源を落としてからディスク交換を実施しました。

環境構成

• ハードウェア：Raspberry Pi
• RAID構成：ソフトウェアRAID（mdadm）
• ディスク構成：4TBディスク × 4台

復旧手順

構成はソフトウェアRAIDのため、「mdadm」というコマンドを使用して設定していきます。私の環境では/dev/md127がRAID設定されていましたが、お使いの環境に応じて書き換えてください。

故障のディスクは、物理的に抜く前にRAIDアレイから削除しなければいけなかったのですが、抜いた後でも削除ができました。

1. RAIDの状態確認

sudo mdadm --detail --scan --verbose

2. RAIDの停止

sudo mdadm --stop /dev/md127

3. 故障ディスクをRAIDアレイから削除

sudo mdadm /dev/md127 -r /dev/sda

4. 新規ディスクをRAIDアレイに追加

sudo mdadm /dev/md127 -a /dev/sda

5. ファイルシステムの修復

sudo fsck.jfs -f /dev/md127

4TBのディスク4台でしたが、実際の使用量は1TB未満だったので、修復にかかった時間は1晩といったところでした。

教訓と今後の対策

今回のディスク障害は、ストレージ管理の重要性を改めて認識する機会となりました。適切な準備と迅速な対応が、システムの可用性を維持する鍵となります。

1. 予備ディスクの常備
2. 定期的なバックアップ
3. ストレージ構成の継続的な見直し
4. 障害対応マニュアルの整備

補足情報

• 復旧時間：約1晩
• 実際の使用容量：1TB未満
• 使用ツール：mdadm、fsck.jfs

免責事項：本記事の手順は筆者の経験に基づくものであり、環境によって異なる場合があります。必ず事前に十分な検証とbackupを行ってください。

関連記事:

NFSサブディレクトリプロビジョナーからCSIドライバーへの切り替え Kubernetes障害の発生と復旧まで Kubernetesって知っていますか？