![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
このページは、（業者に頼らず）自分でデータを復旧しようとするチャレンジャーに有益な情報を提供できる事を目指して作成しています。
このページでは、IOデータ製NASドライブのHDL-GTシリーズにおいて、RAID崩壊モードになった場合の、データ救済方法について記載する。
まず、以下にこのモデル（以下、HDLと記載）の特徴を公式HPから転載する。
「LAN DISK Tera」はRAID 5によるデータ保護機能を備えたNASLAN接続型ハードディスク）製品です。 カートリッジ式のハードディスクを採用し、ホットスワップにも対応。万が一の障害発生時もシステムを停止することなく障害ハードディスクを交換することが可能。 更に、外付けeSATAハードディスクへのミラーリング機能も搭載し、保存したデータを障害から守ります。
こちらの環境でRAID崩壊が発生したケースは、「RAID5運用中に１台のHDが故障した状態で、電源を切った」場合である。（下図）
 |
上記の製品概要の文章では、「ホットスワップにも対応」という書き方をしている事から、コールドスワップ*1でも良いような印象を持つが、取扱説明書にはホットスワップの方法しか記載が無い。コールドスワップは本当に非対応かもしれない。
そして、ひとたびRAID崩壊モードに陥れば、通常の方法ではデータ復旧は不可能となる。
HDLは、システムとユーザーが保存するデータが共にHDDに保存されている。
そこで、システムやユーザーデータがどのように保存されているのかをここでざっくりと説明しておく。
まず、HDDは複数のボリュームにパーティショニングされている。システムは4台のHDDにRAID1（ミラーリング）で保存されている。ユーザーデータは、システムとは異なるボリュームに保存されている。
各HDDのボリュームの構成は以下の表のとおりとなっている。特に、ユーザーデータに用いられるmd13は複雑で、RAIDの入れ子構造になっている。これは、外付けディスクのバックアップに対応するためである。
| ボリューム1 | ボリューム2 | ボリューム3 | ボリューム4 | ボリューム5 | ボリューム6 | ||
| ドライブ1 /dev/sda | デバイス番号 | sda1 | sda2 | sda3 | sda4 | sda5 | sda6 |
| フォーマット | RAID1(md1) | RAID1(md2) | swap | 拡張領域 | RAID1(md5) | RAID5(md10) | |
| ドライブ2, 3, 4 /dev/sdb, sdc, sdd | ドライブ1と同じ構成 | ||||||
| ボリューム | フォーマット | マウント先 | RAID構成 |
| /dev/md1 | ext2 | /boot | RAID1(sda1,sdb1,sdc1,sdd1) |
| /dev/md2 | ext3 | / | RAID1(sda2,sdb2,sdc2,sdd2) |
| /dev/md5 | ext3 | /mnt/hda5 | RAID1(sda5,sdb5,sdc5,sdd5) |
| /dev/md10 | RAID1アレイ | md13 | RAID1(sda6,sdb6,sdc6,sdd6) |
| /dev/md13 | xfs | /mnt/sataraid1 | RAID1(md10,外付けドライブ) |
すでにHDLをハッキングし、telnetを有効化していれば、telnetでログインすることでデータ救済が可能だが、telnetを有効化していない場合はHDLをコマンドラインで操作する方法は無い。
そこで、ドライブをすべて取り出し、別のPCに接続することでRAID崩壊したディスクから大切なデータを救済する。
必要なツールは以下の通り
PCに接続されていたHDDは作業が終了するまで取り外す。
ここでは、RAID5運用していたHDLのドライブ2が故障し、RAID崩壊に陥った場合を想定する。図の様に故障ドライブ以外のNASドライブと救済用HDをPCに接続する。もしドライブ3が故障した場合は、図のドライブ２とドライブ３で救済用HDの接続位置が入れ替わる。
救済用PCのSATA端子が４個しか無い場合、USB光学ドライブがあれば構成可能*2。
 |
PC本体の構成が完了したら、KNOPPIXを起動する。
以下、GUIは使わないので、ターミナルを起動し、rootユーザーになる。
$su -
接続したドライブがどのデバイスに割り当てられているか、RAIDアレイのスーパーブロックをmdadmで読み取って確認する。
#mdadm --misc --examine /dev/sda1 <--コマンドで指定したデバイス
/dev/sda1:
Magic : xxxxxxxx
Version : 0.90.xx
UUID : 705f919a:8b56e077:93875f94:f8cbfdfd
Creation Time : Mon Jan 1 00:00:00 20xx
Raid Level : raid5
Array Size : 2923628928 (2788.19 GiB 2993.80 GB)
Used Dev Size : 974542976 (929.40 GiB 997.93 GB)
Raid Devices : 4
Total Devices : 4
Preferred Minor : 0
Update Time : Sun Nov 04 00:00:00 2012
State : clean, degraded
Active Devices : 3
Working Devices : 3
Failed Devices : 1
Spare Devices : 0
Checksum : abcdefgh - correct
Events : 12345678
Layout : left-symmetric
Chunk Size : 256K
Number Major Minor RaidDevice State
this 0 8 145 0 active sync /dev/sda1 <--一致しているかどうか確認する場所
0 0 8 6 0 active sync /dev/sda1
1 1 0 0 1 removed
2 2 8 38 2 active sync /dev/sdc1
3 3 8 54 3 active sync /dev/sdd1
ここで、コマンドで指定したデバイスとコマンド結果のthisの行のデバイスが一致していれば問題ない。一致していない場合は、PCの接続が間違っている可能性がある。そのまま修復作業を続けても良いが、一致させて置いた方がベター。
他のデバイスも同様に、mdadmで確認する。
デバイス確認が終わったところで、ユーザーデータが入っているRAIDドライブの復旧作業に入る。
RAID崩壊モードからの復旧とは即ち、故障アレイ以外のアレイで同期をとる事である。
#mdadm -A --run --force /dev/md10 /dev/sda6 /dev/sdc6 /dev/sdd6
オプションの-Aは--assembleと同じで、既存のRAIDアレイを構築することを指示している。
また、元のRAIDに対してデバイス数が足りない場合でも強制的にアクティブにするために--runと--forceをつけている。
ここで、もしmd10が見つからないというエラーが出た場合は、以下のコマンドでブロックデバイスmd10を作る。
#mknod /dev/md10 b 9 10
それから、先ほどのコマンドを実行する。
md10のステータスを確認する。以下のコマンドでactiveとなっていれば、RAID5が動作している。
#cat /proc/mdstat
md10 : active raid5 sdd6[2] sdc6[1] sda6[0]
1234567 blocks level 5, 64k chunk, algorithm 2 [4/3] [U_UU]
これでRAID5のデバイスは同期がとれてRAID縮退モード（degraded mode デグレーデッドモード）で運転が開始した。
ここまでで、RAID5のRAID崩壊は回復している。
もし、同期をとる最中の場合は、recoveryと表示されるので、同期が完了するまで待っておく。
#cat /proc/mdstat
md10 : active raid5 sdd6[2] sdc6[1] sda6[0]
1234567 blocks level 5, 64k chunk, algorithm 2 [4/3] [U_UU]
[>>>>>>>>>>>..........] recovery = 50% (12345/1234567) finish=99.9min speed=12345K/sec
次に、md13を作成する。先ほどと同じ要領で、強制的にアクティブにする。
#mdadm -A --run /dev/md13 /dev/md10
そして、md13をマウントする。
#mount -t xfs /dev/md13 /mnt/sataraid1
注意
メモリのバイトオーダーがxfsファイルシステムで互換性が無いため、HDL（ARM系CPU）と救済用PC（X86系CPU）の組み合わせでは、md13をマウントしてもフォルダ構造を正常に認識できない。ここでは、sataraid1配下にshareが入っているかどうかの確認にとどめておく。
#ls -l /mnt/sataraid1 ?????????? ? ? ? ? ? ? ? share sataraid1にアクセスできません。
上記のようにshareという所をみるだけで確認は終了。
作成するパーティションのサイズは、md13の全データが入るように、md13以上の容量を確保しておく。 もしまだmd13をactiveにしていなかった場合は以下のコマンドを実行する。
#mdadm -A --run /dev/md13 /dev/md10
md13の容量を確認する。
#fdisk -l /dev/md13 2993.8GB (2993795883008bytes)
上記以上のサイズのパーティションを作成する。上の容量+1049000bytesのパーティションをpartedで生成。
#parted /dev/sdb (parted) mkpart primary 2048s 299379632008B (parted) quit
次に、救済用HDにデータをコピーする。
データ救済はユーザーデータ内のファイルやフォルダを１つ１つコピーするのではなく、RAIDドライブmd13のデータそのものを丸ごと救済用HDにコピーする。ddコマンドを使用する。
#dd if=/dev/md13 of=/dev/sdb1 ibs=1024k obs=1024k conv=sync
通常のデータ救済では、読み込みブロックサイズをHDDのセクタサイズと同じ512バイトに、conv変数にnoerrorを付加して不良セクタのデータをNULLで埋めるのが定石となっているが、RAID5縮退モードではセクタ単位での読取エラーという事象は無く、いずれかのドライブで異常があれば即停止するだけである。
つまり、noerrorオプション付きでコピー中にRAIDデバイスが停止した場合、それ以後のデータがすべてNULLで代替され、残りのデータは全く救済されていない。
もし、救済中にRAIDが停止した場合、事態はいっそう深刻なものとなる。なぜなら、RAIDアレイのいずれかのドライブが壊れかけているからである。そこで、停止したRAIDアレイのステータスを確認し、異常が発生したドライブを急いで特定する。
#cat /proc/mdstat md10 : active raid5 sdd6(2) sdc6(1) //sda6が消えている＝sdaのドライブが故障
mdstatで停止したドライブを特定できたら、即座にPCをいったんシャットダウンし、故障したドライブ以外のアレイと救済用HDDは誤操作防止のためいったんすべて取り外し、代わりに故障したドライブと同等以上の容量のHDDを準備してPCに接続し、再度KNOPPIXを起動する。
まず、ルートになる。
#su -
故障ドライブのデバイス番号を確認する。
#fdisk -l /dev/sda #fdisk -l /dev/sdb
fdiskの結果でパーティションが見えた方が故障ドライブである。ここでは故障ドライブをsdaとして進める。
故障ドライブのデータを新しいHDDに救済する。
#dd if=/dev/sda of=/dev/sdb ibs=512 obs=512 conv=noerror,sync
ddコマンドでのデータ救済では、obs=1024kとしているホームページが多いが、不良セクタ以外のデータを確実にコピーできるようibsとobsは同じ値にしている。処理のスピードもさほど変わらない。
救済が完了したら、RAIDデータのコピー作業を続けるため、PCへの接続からやり直す。ただし、故障したアレイの代わりに新しいHDDを接続する。
mdadm(8) ver.1.5 man page [日本語]
いきあたりばったりのおもいつきめも : NASの情報を見る（参考）
mdadmで壊れたアレイを修復できるか？：ぴろにっき：So-netブログ
チラシの裏にでも書いてろ な！: mdadmでRAID構築（まとめ)
matoさんのぶろぐ mdadmでRAID1を試し組み
Linuxでmdadmを使ったソフトウェアRAIDの構築・管理メモ - nabeの雑記帳
最新の10件を表示しています。 コメントページを参照
