VOLTECHNO

ガジェットとモノづくりのニッチな部分を伝えるメディアサイト

RAID5でHDDリビルド中にHDDが2台クラッシュした時の記録

RAID5でHDDリビルド中にHDDが2台クラッシュした時の記録

年末にNASのストレージが1台Read Errorを出していたなと、年明けの三箇日にHDDを入れ替えてリビルドしていたら、RAID再構築中にHDDがクラッシュしてリビルド停止、そのままディスクアレイごとクラッシュして動作不良に至りました。

本記事はその状態からデータを退避させるまでの時系列順にした忘備録です。

NASクラッシュまでのバックグラウンド

筆者が使用しているNASは、当サイトでも何回かにわたって使用方法や拡張方法などを紹介しているSynologyのDS916+です。クラッシュ直前にはDX513を追加してストレージ拡張を行っており、最終的には3TB×7台によるRAID5(正確にはSHR)でディスクアレイを構成していました。

使用しているHDDはNAS運用を見越したWestern DigitalのWD Redで、クラッシュするまでの稼働時間は10,000h程。DS916+は風通しを良くしたクローゼット内に安置しており夏場でもHDDは最大でも40℃程。NASの中ではダウンローダーやらDockerやら常に色々走っている状態でした。

2018-12-20 不良セクタの修正ログが発生

12月の末にHDDの1つから「不良セクタが発生したが問題を修正した」というログの通知が発生。ログには問題が発生したセクタまで記録されていたものの、S.M.A.R.T上では特に問題も無く実際の使用にも問題がなかったため、替えのHDDを注文してそのまま様子見。RAID5ならHDDが万が一クラッシュしても1台くらいなら問題ないだろうと、余裕のある時にHDDを交換してリビルドする予定でした。

2019-01-03 21:29 リビルド開始

年も明けて落ち着いたころ、購入しておいたHDDに換装しようとHDDの入れ替えを開始します。以前にも同じような状態からHDDを交換してリビルドしたので、今回もHDDを交換したのちNASの自動修復を開始して完了するまでの10時間ほどを待つだけのはずでした

2019-01-03 21:37 ディスクアレイがクラッシュ

問題が発生したのはリビルドを開始してから僅か8分後、3台のディスクからリードエラーが発生し、その内のDisk[4]が連続してリードエラーを多発した直後にディスクがクラッシュしたと警告。RAID5のリビルド中にHDDが1台クラッシュしたことによってRAID5の冗長性が失われる事となり、リビルドは停止しRAIDで構成されていたボリュームも停止しました。

リビルド中のHDDを元に戻して、リビルドをクラッシュしたDisk[4]に対してやり直せば現状維持はできるのではないか?と考え、NASを一旦シャットダウンしてHDD構成を元に戻しても、既にリビルドを実行した場所に対して、元のHDDを正しく認識することもありませんでした。

ただ、再起動後には何故かクラッシュしたDisk[4]の状態が回復しており「このままもう一度リビルドできそう」ともう一度リビルドを開始するも、さっきと同じようにDisk[4]がクラッシュ。どうやらHDDは本当に破損しているでした。

ここからが問題です、本当に重要なデータのみ他のメディアにバックアップしているものの、出来る事なら可能な限りデータを吸い出したいところです。

調べてみたところ不良セクターが原因によるRAID5ディスクアレイ破損の場合、対応方法は3つほどあるようで、1つ目がデュプリケーターを使ってHDDをクローンして再ビルド、2つ目がHDD Regenerator等の不良セクタ修復ツールを使用してから再度リビルド、3つ目が復旧業者の使用、だそうです。

問題なのが、同時にDisk[2]とDisk[3]もリードエラーが発生していたこと。Disk[2][3][4]は購入時期が同じで稼働期間も同じなので、HDDを1台だけなんとかしてもリビルド中に再度別のHDDがクラッシュする可能性を考慮しなければいけませんでした。

2019-01-03 22:00頃 読み取り可能に気付く

ここから不思議な事が起こります。SynologyのFileStationを起動すると、クラッシュしたはずのRAID5ボリュームにアクセスできる状態になっていました、クラッシュ通知が来た時に共有フォルダはアンマウントされてたと思ったのですが。念のためストレージプールを確認しても、リビルド失念によるHDDが1台足りない状態でHDDが1台クラッシュで7台中5台しか稼働していないRAID5は成立しないはずなんですが、何故か読み取り専用の状態としてアクセス可能になっていました。

頭の中の疑問は消えないままでしたが、再起動すればNAS上でのクラッシュ状態は消えるため「クラッシュしても不良セクタ以外の部分は読み込める」と納得することにして、空いたストレージをかき集めて重要なデータから退避させることにしました。

2019-01-03 22:30~現在 データ退避開始

運よく、別の用途で使用する予定だったDS218+とRAID1のバックアップNASを買ったばかりだったので、そのRAIDを崩して12TBのストレージとすることでデータの退避先を確保することができました。

SMBによるネットワークアクセスも可能な状態なので、そのままネットワーク越しにデータの退避を始めました。データ読み取り中にも不良セクタはポツポツ発生しており、そのセクタのデータは読み込み不可となるため100%のデータ復旧とまではいきそうにありません。

危惧していた通り、データ退避を始めた次の日にDisk[2]もクラッシュしました。それでも尚、読み込みは可能なのでやはり「不良セクタでのクラッシュでも読める部分は読み込める」仕様になっているのかもしれません。九死に一生を得た感じですね。

現在までに退避したデータは約4割ほど、この記事が公開が公開される日にはすべてのデータ退避が完了している頃です。

結局、クラッシュの原因は何だったのか

結局、今回の不良セクタ多発によるリビルド失敗&クラッシュの裏では下のような流れがあったものと推定されます。

  1. Disk[1]で不良セクタ検知(ほぼ同時に[2][3][4]でも不良セクタが多発していたが検知せず)
  2. リビルド中に初めて他ドライブの不良セクタ領域に入り込んでNASがクラッシュと判定
  3. リビルド停止、2台以上のHDD欠損によってディスクアレイクラッシュ

リビルド中にHDDがクラッシュするという話はよく聞きますが、ほとんどの場合こんな感じで検知していなかった不良セクタをリビルド中に発見した、に起因しているのではないでしょうか。

ただ、今回の件では実際に2台以上クラッシュ扱いになっても読み込みはできていましたし、ほとんどのデータ退避には成功していたので実害と言えば新しく購入したHDD代と復旧に要した時間くらいでした。データの被害はほとんどなかったのが幸いです。

今回の不良セクタ多発の原因については少し考えるだけでも下のような原因が思い浮かびます。

  • 同じロットのHDDを買ったから同じ時期に壊れた
  • NANの管理方法が悪かった
  • DX513増設時のストレージ拡張に失敗していた

WD Redにした割には10,000h程度で立て続けに不良セクタ多発に至ったのには運用的な問題点があったのかもしれませんし、RAIDを構成する上で避けねばならない「同一ロットのHDDを購入しない」と言うルールを破ってHDDを購入していたのでHDDが壊れる時期が近くなってしまったのかもしれません。

NASの管理方法については、3Dプリンタのや定置型工具の近くにNASを設置していたのでそういう微振動も影響したのかなと推測されます、過去に見た動画では、ディスクアレイに大声で叫ぶとディスクのレイテンシが悪くなるという検証動画があるくらいなので、その辺なども考えればきりがありません。

DX513のストレージ拡張時には問題がなかったため、少なくともストレージ拡張時点まではHDDは健康だったものと推定されます。結局、原因は多肢に渡り、分からずじまいではありますが、振動を中心に再発防止のために何らかの対策はしなければいけません。

今回の件でのデータにアクセスできなかった時間自体はほんの僅かでした。痛感したのは、RAIDはあくまでもデータに対してインシデント発生時の保守性や可用性を確保するためのもので、バックアップとしてはあまり過度の期待をしてはいけないものだな。と

今回のような同時多発的なクラッシュはなかなか無いパターンだとは思いますが、HDDが破損させやすい条件さえ揃ってしまえば簡単に起きうる事態だと思います。今後も最悪の事態に至る前に、データ保管の方法を考え直す必要がありそうです。

Return Top