RAID5 リビルド中に崩壊の悪夢

先日、ワタシの書斎で起こった悪夢について記録する。冗長性を持ったRAID5のストレージがリビルド中に崩壊するという悪夢。
なお、念のため先に書いておきますがワタシはG-Technologyアンバサダーで同社から一定の機材協力を得ています。今回のトラブルはPROMISE社のPegasusで起こったものですが、プロミス社を非難したり信頼性が低いというものではありません。
機械はいつか壊れるモノであり今回のRAIDは購入４年目になっていて、ハードディスク機器としては順当な寿命だったとも思っています（ただし、今回のドライブのロットは・・・後述）。
どのメーカーの機材であっても起こりうる「今そこにある危機（機器）」としてお読み頂けると幸いです。

DAY-1
発端はここ数日、Mac Proが不安定だったこと。データの保存中にアプリケーションが応答しなくなったり、iPhoneの同期が終わらないままiTunesが落ちたり、さらにはMac Proを終了しようとしても正常に終了プロセスが走らなかったりした。
うちでは、G-TechnologyのG-SPEED Shuttle XL（RAID5運用）に写真や動画を、PROMISE社のPegasus R6（RAID5運用）に一般的な書類データや音楽を保存、運用している。

挙動から、データ保存ストレージのPegasusが怪しいかなあと、PROMISEユーティリティでダッシュボードをみる（左）も異常なく、念のためG-Speedユーティリティ（右）もチェックするも問題なし。
今思えば、このとき、もっと踏み込んで調べるべきだった。

DAY-2　朝
不安定な挙動が解消されない。

ので気になってアラートの出ていないPROMISE Pegasus R6のNVRAM Enentsを確認すると、Minor エラーでBad sector is found on physical diskがずらりと並んでた。
G-Technologyアンバサダーになる前、2012年の１２月に購入した6発RAID、もう4年目になるのでドライブ自体が壊れるのは仕方ないし、織り込み済み。
Pegasus R6はRAID5で運用中ゆえ今すぐデータが失われるモノではないが、早晩深刻なエラーに転じるのは想像に難くないので、交換用ディスクを発注。バックアップは取っているが、別のストレージにもう１組、バックアップ作成を仕掛け、外出。

DAY-2　夜
帰宅すると交換用のドライブが届いていた。
Seagate Barracuda 3TB ST3000DM001

そして、同時にMajor エラーで赤ランプ点灯、マイナーエラーを出していたドライブが死んでいた。

ベイ１のドライブ。このPegasus R6は保証期間内に１度、保証期間外に１度、都合２回、ドライブエラーでドライブを交換している。
これで３度目（もちろん、壊れるディスクは異なっている）なので、搭載ドライブの半数が入れ替わることになる（と、この時思ったのは甘かったとあとで思い知るのだが）。

DAY-2 深夜（正しくはDAY-3 になっていたが）
ドライブを交換。リビルドに入る。これまでの経験だと、約12時間で復旧予定
　ここまでは想定通りで事故をアンダーコントロールで進行していたはず。

DAY-3 夕方
そろそろRAID再構築も終わってるはずとバックグラウンドアクティビティをみると、まだ３０％？おかしくね？

でも、正常に動いてる感じだけどな・・・

イヤな予感がしてNVRAM Enentsを確認すると、ベイ２のドライブがMinor エラーでBad sector is found on physical diskがずらりと並んでる。
とある方から教えられた。「再構築（リビルド）は他のドライブにも一斉に負荷がかかるので、障害が顕在化し易い」

ああ、たしかに、すでに３台クラッシュしていて、残りの３台も同じ時期（おそらくロットも）のドライブ。そしてまさにこのBarracuda 3TB ST3000DM001

再構築中にBad sectorでたら、どうなるんだ・・？
ってか、RAID5なので、いま、もう1台、ドライブが死んだら全滅・・・。

急ぎ追加の交換用バラクーダを発注しつつ、重苦しい気分で、エラーを吐くドライブでリトライとリビルドの戦いをみる。そもそもこのリビルドに成功しないとクラッシュしそうなドライブを外せないじゃん・・・バックアップは二重に取ったいま、交換用ドライブがくるまでできることはないし、もしリビルトできたら、エラーだしたベイ２のドライブを交換して再々構築しないと。

DAY-4
牛車の歩みのように進むリビルドをみつつ

DAY-5 夕方
ベイ２のドライブはリビルドの負荷に耐えられなかった。ベイ２のドライブが失われ、６発中、２発のドライブをロストしたRAID5が崩壊。データが失われた。
さすがに、ああほうかい、とオヤジギャグを飛ばす余裕はなかった。

DAY-6
今度はゼロからPegasus RAIDを構築する。
結局、２台のドライブを交換することになったが、まだ、４年目のST3000DM001が２発残っている。これらはいつクラッシュするかもしれないし、また、リビルド中にもう片方がやられることもないとはいえない。
SEAGATEが信頼性が低いというより、このST3000DM001 3TB 12年製のロットが鬼門なんだろうなあと思う。

ので、今回は残存する古いST3000DM001のベイ配置を確認した上で、RAID50に設定してみた。容量的には不利になるが、別グループになったST3000DM001が同時にクラッシュしてもデータは保持される計算。

DAY-7
RAID構築もおよそ１２時間くらいだった。バックアップからデータを書き戻し、チェック。
長い１週間になってしまった。
結果的に失われたのは時間のみでデータは失われなかったが、対応には反省も残るなあ。

ちなみにPegasusu R6は、こんな構成になっていて赤で塗った２台のST3000DM001が今回クラッシュ。

交換後にはこうなった。
２台同時にクラッシュすると分かっていたら、この機会に全台、HGSTのドライブに入れ替える手はあったなあとも思いつつ、この辺は運次第の部分か。

ただ、ポジショントークに誤解されたくないのですが、このPegasusu R6導入後、G-RAID Thunderboltはじめ何台かのG-Technologyドライブを入れていますが、現在の所、１台も故障していません。ただし、このPegasus R6（とST3000DM001）はひたすら稼動していたとも言えるので、仕方ないかな。

–ads–