スポンサーリンク
Nas4Free(Xigma NAS)で構築したファイルサーバのHDDが久々壊れた。
さあ今回はうまく交換できるかなと思ったら、やっぱりはまったのだ。
NAS4Free/Xigma NASについてのまとめはこちら。
我が家では週に1回バックアップを取ることにしている。
今回も自作メインPCのJisaku7でEaseUS Todo Backupを使ってバックアップファイルを作り、
NAS4Freeを起動してバックアップファイルをコピーした。
NAS4Freeはバックアップをするときだけ起動するので、毎回状態を確認している。
今回もバックアップファイルをコピーし終えて、シャットダウンするときに通常用のプールが
DEGRADEDになっていることを発見した。
NAS4Free status
RAIDをどう構成したか次第だが、自分の環境では4D+1PのRAID-Z1構成、つまり5本構成のプールに対して
データとして記録できるのが4本分で、残り1本はパリティだ。つまり1本を冗長なドライブとして
故障に備えている。
このパリティがあるおかげで、データ用HDDが1つ壊れても残り3本とパリティドライブからデータを
再構成できるので、
データは失われていない。しかし冗長性が失われているので、プールはDEGRADEDという状態になった。
このプールで同時に2本のHDDが故障すると、さすがにデータを再構成する方法がないのでデータは失われる。
このような事態になる前に早急にドライブを交換して冗長性を取り戻す必要がある。
蛇足だが、1本の冗長性では足りない場合は2本を冗長とするRAID-Z2という選択肢もある。
この場合同じ5本でプールを構成すると3D+2Pとなり、同じHDDで構成したら記録できる容量が減る。
以前にも書いた手順で、故障ドライブを新品に交換する。つまり、
AtBGCgL@@w܂ƓuOɕVxA^cɂȂ܂B
交換対象のHDD
Replace実施
Replace実施
Replace実施
これで以前はうまくいったが、DM-SMRの影響なのか、6TBのドライブに交換するようになってから
必ず失敗するようになった。
今回も結局一晩を経て状況を確認したが、Replace中のエラーがあるわけでもないのに成功していない。
Replace実施結果
最初の故障ドライブ(3TB)は/dev/ada0/oldと表示され、交換したのでないのだが、データとして残っている。
そして2つ目の故障ドライブ(6TB)は/dev/ada0と表示され、接続しているがReplaceが成功しなかったので
こいつもUNAVAILという状態だ。困ったものだ。
Replace実施
一旦scrubしてデータが壊れていないかを確認する。問題なし。
scrub実施
終了後再度Replaceしようとするが指定ができない。反応が非常に遅いので再起動したら
Replaceの続きが始まった。初回のReplaceの続きなのだろうか。
Replace実施
Replace実施
うまくいかないので、ダメもとで最初の故障したドライブ(3TB)をオフラインにしてみた。状況が変わるかな。
Replace実施結果
暫く間をあけた次の週末。状況は変わらず、プールはDEGDAREDのまま。
ここで故障した3TBの状態を見るが、以前と同じくSMARTでは問題が無さそう。うむむ。
故障HDDのSMART情報
前回もそうだったが、何らかの理由でOS上は故障としたが実はHDDは健全なのかもしれない。
DM-RAIDの6TBしか在庫がなく、CMRの3TBの予備はもうないので一旦この故障したと思えた
HDDを戻すことにする。電源を落としてHDDを交換し起動すると、再びReplaceが開始。うーむ、いつの？
Replace実施
再起動するとReplaceするのはそういう情報が残っているからだろう。
きっとZFSにはReplaceを中止する手段があると思う。しかしNAS4FreeのGUIでは見当たらない。
しかたない、ZFSのマニュアルを検索すると、あった。
zpool detach pool_200405 ada0
これにより、プール状態はUNAVAILなada0が2台あるおかしな状態を脱した。ふう。
Replace中止結果
最初の状態に戻った。HDDは故障したもの自身であるがこれでReplaceを実施してみる。
（本当は6TBで再度試したかったが）
Replace実施
今回はHDDが/dev/ada0p1となっている。命名ルールは謎だ。Replaceを実行する。
Replace実施
12時間たって、無事終了。プール状態はONLINEに戻った。
Replace実施結果
やっと終わった。
今回やって分かったこと。
次回は年末頃にまた壊れるのかな。その時こそ6TBドライブでやっていけるかの判断ができそうだ。
PR
