受注の経緯
関西方面で幅広く展開されている、ソフト開発会社の担当者様からの電話で、「Linuxサーバーのデータ復旧は可能か？」という問い合わせが有りました。
ＯＫと答えると、「関東のお客様から電話をさせるから、話を聞いてくれ」とのことでした。
ほどなくして関東のお客様から電話が有りました。
「実は、近くのパソコン修理会社へ、データ復旧を依頼したところ、一か月も連絡が来なかった。こちらから電話すると、はっきりした返事が無いので、どうしたら良いか、知り合いの関西のソフト会社に相談したところ、御社を紹介された。データ復旧はできそうか？」とのことでした。
弊社からは本体を送って頂ければ、判定をするという旨をお伝えしました。
本体の到着
到着後、機器の確認をしてみると、DELL製のPrecision T7400 という機種であることがわかりました。中を開けてみると、1.5TBのハードディスクが7台内蔵されており、これらが HP SmartアレイP400/512 BBWCという、8台のHDDを装着可能なRAIDコントローラに接続されていました。いわゆるハードウェアRAIDの構成です。
DELL製の本体の中にHP製のRAIDコントローラが格納されており、512MBバッテリ バックアップ式ライト キャシュ (512 BBWC) が、メモリカバー（黒いプラスチックの部品）に両面テープで貼り付けられており、いささか不格好に思われました。
そして、理由は後でわかるのですが、不可解なことに背面にUSBメモリが装着されていました。
HDD7台のクローンを作成
ハードウェアRAIDの場合、RAIDコントローラに接続されているHDDの順番を間違えると、RAID構成が出来ないだけでなく、最悪の場合には元のRAID構成情報が全く失われてしまいます。
ですので、このような場合には、HDD 7台を取り出す前に、写真撮影・配線図の作成・SATAケーブルとHDDへのラベリングを行います。
今回の機材の場合には、これ以前に別の業者が触っていますので、その業者が貼ったと思しき番号のついたラベルが各HDDに残っていました。しかし、不自然なことに、SATAケーブル側には『4』と書かれたもの以外のラベルは貼り付けてありませんでした。また、そのSATAケーブルには『7』と書かれたラベルの貼り付けられたHDDが接続されていました。これは、前の業者がHDDの順序をデタラメにして返送した可能性が非常に高いことを示唆しています。
かなり嫌な気分になる話ですが、先に作業を担当した業者が、自分たち以外の業者が仕事を手掛けられないようになんらかの工作を施した状態の機材が、弊社へ送られてくることはしばしばあります。
今回は、前の業者が善良であることに望みをかけて、この時点での接続が正しいことを前提として記録作業を行いました。
この作業が終わって、ようやく、HDDを取り外し、2TBのHDD 7台にそれぞれコピーを行います。(クローンHDDを作成)
クローンHDD作成作業の結果として、７台のHDD中、1台は完全に故障しており、もう一台は途中からコピーができない状態であることがわかりました。
クローンHDD作成後、電源ON
通常の弊社のデータ復旧作業は、ソフトウェアRAIDの製品を取り扱っています。この場合は、RAID構成情報はHDDに書き込まれていますので、HDD の個体番号などが違っても問題になることはありません。
しかし、今回のようなハードウェアRAIDでは、RAIDコントローラがHDDの個体番号を記憶し、正しいHDDなのかを識別する動作をすることが予期されます。このことから、ハードウェアRAIDでRAIDコントローラが故障していない場合は、オリジナルのHDDを使用してデータ復旧することになります。但し、この時点では、RAIDコントローラが故障しているかどうかは不明です。
2)で作成した配線図を元に、オリジナルHDDをRAIDコントローラ、並びにPCへ接続していきます。
そして、電源を入れます。（緊張の瞬間です）
BIOSの画面からRAIDコントローラの設定画面を呼び出します。
RAIDコントローラの設定画面を見るとRAIDが構成できていません。すでにRAID構成情報が失われてしまっている可能性が出てきました。もしそうであるならば、作業はかなり難航する見通しになります。
どうしようもないので、この状態を写真撮影し、RAIDコントローラの設定画面から抜けました。
すると、予想に反して、OSらしき物が起動を開始します。画面表示によって、このOSが「VMware ESXi 5.0.0」とわかりました。
当初、RAIDが構成されていないのに何故かVMware が起動したため、かなり不思議に思われました。その後の調査でOSは筐体背部に接続されたUSBメモリに格納されていることがわかりました。
現時点での問題点と対策
RAIDコントローラについて
①HDDの接続順番が変わった事で、RAID構成情報は失われたのか？
⇒中古で、同一機種のコントローラの手配
②RAID構成情報は失われていない場合、接続するHDDの順番は？
⇒コントローラの手配後、対処策を検討
③RAID構成は？
⇒それぞれのHDD内部を覗いて、類推してみる。
VMwareについて
④ログインするためのユーザー名とパスワードは？
⇒お客様への問い合わせた結果。分からないと回答有り。
⑤ユーザー名とパスワードは初期化可能か？
⇒初期化できた記事が有る。(英語)
⑥VMware内で、何が構成されているのか？
⇒それぞれのHDD内部を覗いて、類推してみる。
HDD内部を覗いてみて
HDDの中のデータを専用のバイナリエディタで確認した結果、以下のようなことがわかりました：
- “EFI PART” という文字列を含むHDDが2台あることから、何らかの形で仮想マシンのイメージが2台分含まれているということ
- ファイル名らしき文字列の特徴から、仮想マシンのOSはそれぞれ、FreeBSD と Windows 7 ではないかということ
結局、HDDの順番とRAIDの構成が明確にわかる手がかりは見つけられませんでした。
RAIDコントローラ到着
RAIDコントローラが到着したので、以下の手順で、RAID構成の方法、HDDを入れ替えて電源ONした場合にRAID構成情報が消えるかどうかを試してみました。
- RAIDコントローラと、ダミーのHDDを本体に接続して、RAID構成を設定
- HDDの順番を入れ替えて、電源をON
- HDDの順番を 1 の状態にして、電源ON
この結果、HDDの順番を入れ替えて、電源をONしただけでは、RAID構成情報は、失われない事が判明しました。
今回のテストで、このRAIDコントローラは、4台ずつ2組のHDDグループが有り、このグループ内ではHDDの順番は関係無いように見えました。
この情報から、この時点で不明である、HDDの 正しい 接続順序の探索が少し楽になる見通しが得られました。なぜならば、7台のHDDを2グループにわけるだけでよくなったからです。
この情報を得る前の時点では、HDDの正しい接続順序を見つけるために
7! = 7×6×5×4×3×2×1＝5040通り
分の試行が必要でした。
7台のHDDを2グループにする組み合わせは：
7C3 ＝ ((7×6×5)/(3×2×1)) ×2 ＝ 70通り
実際には、2台のHDDが故障しているので：
(5C1 ＋ 5C2 ＋ 5C3 ＋ 5C4) ×2 ＝(5＋(5×4)/(2×1)＋(5×4)/(2×1)+5)×2 ＝(5＋10＋10＋5)×2 ＝60通り
限りなく、試すパターンが少なくなりました。
HDDの装着と、RAID構成の再現
7台のHDDの内、2台が故障しているので、RAID構成が出来るか不安でしたが、6)の調査から、考えられる組み合わせで、HDDを接続して、RAID構成が見える、HDDの組み合わせを試しました。
とうとう、RAIDを構成情報が見える組み合わせにたどり着きました！
サーバーをお預かりしてから、ここまで2週間かかりました。
前の業者が余計な工作をしなければ、この2週間分の手間は不要だったのですが。
この時点で判ったことは以下のことです：
- RAID 6で構成されており、内1台がホットスペアであること
- 上記のRAIDアレイを、３つの論理ドライブに分割していること
- これは HP Smart Array コントローラの機能によるもの
VMware ESXi の起動と、仮想マシンの起動
VMware の管理画面にアクセスするためには、そのユーザー認証情報が必要ですが、お客様がこれをご存じありませんでした。幸い、このバージョンのVMware ESXi のパスワードをリセットする方法を見つけることができました。
しかし、この情報が本当かどうかもわからないため、原本に処置を施すのはためらわれます。そこで、同容量の USBメモリを使用してクローンを作成しました。しかし、VMware ESXi は起動しませんでした。これは、USBメモリの個体識別番号に対して何らかのライセンス認証による起動制限がかけられているものと思われました。
方針を変えて、原本のUSBメモリのイメージをバックアップしてから、原本に対して上記の処置を行うことにしました。結果、見事にVMware ESXi の起動とパスワードのリセットに成功しました。
VMware ESXi に別PC上のvSphere Client からアクセスします。
3つに分割された論理ドライブのうちの一つに、以前の予測通り、FreeBSDとWindows 7 の仮想マシンのイメージが格納されていました。
試しにFreeBSDの仮想マシンを起動してみると、FreeNASの画面が表示されました。この、FreeBSD の仮想マシンはOSのほかに4台の仮想HDD で構成されており、その4台の仮想HDDでRAID5 を構成していました。
率直に言って、不可解に不可解を重ねたような構造になっているという感想を持ちました。
データの取り出し
他のパソコンから、FreeNAS 上の共有フォルダにアクセスしたところ、無事、それらしい中身が確認できました。しかし、フォルダをダブルクリックしたら、フォルダを開くまでに十数分かかる状態で、このままではデータ取り出しにものすごい時間が掛ることが予想されました。
そこで、FreeNAS にまつわる仮想HDDイメージのそれぞれを、1TBのHDDにコピーをし、より高性能なマシン上で VMware を稼働させて、データを取り出すことにしました。
最初に、vSphere Client から VMware ESXi の設定を変更し、SSH によるアクセスを有効にしました。これにより、vSphere 上で認識されているファイル群にも直接アクセスできるようになりました。
最初に、サーバー機へUSB接続外付けHDDを接続して、そこへ
ファイルをコピーすることを考えました。しかし、これは複合的な理由で安定したファイル転送ができなかったため、断念しました。
結果として、scp 経由でファイルを吸い出すことになりました。
仮想HDDイメージひとつにつき、そのコピーに約20時間、計80時間掛りました。その間、延々とサーバーの爆音に耐えねばなりませんでした。
ようやく4台のHDDへのコピーが終了し、データの取り出しを開始しました。こちらは50GB／1時間の速度で約10時間。サクッと終了です。
終了後、即座にお客様へ納品しました。
まとめ
故障の原因
今回の機材は、HDD 7台中、6台がアクティブ、1台がスペアのRAID6という構成でしたが、故障に際して以下のような問題があったように見受けられます：
① ホットスペア機能が動作しなかった
通常、1台のHDDが故障した場合、ホットスペア1台と入れ替えが自動で行われ、RAIDの再構成が行われるのですが、何故かホットスペアはアクティブ状態に切り替わっていなかった。
②故障2台目のHDDの症状が複雑だった
RAIDコントローラでは、HDDとして認識されるが、データへのアクセス時、特定のセクタへのRead／Writeが出来ない状態だった為、RAIDコントローラ側では、うまく動作できなかった？
③RAID6で、HDD 2台の故障なのに、RAID構成ができなかった
故障当時の状況が判らないので、何とも言い難いが、おそらく②の原因が災いして、故障2台目のHDDを判別できず、RAIDに参加させ続けた為、起動はするが、途中でハングする状況だったのではないかと、類推されます。
データ復旧を複雑にした要因
①初期導入の業者と連絡が取れない状態だった。
これは、有ってはならない事ですが、現実にはこのような事の有ることを知りました。
②導入時に、システム仕様書等の納品物が無かった。
今回の設定は、弊社では全くの予想外でした。USB起動のVMware、ハードウェアRAIDの中に、更に仮想マシン内でのRAIDを構築など。
このような場合は、仕様書等を残すのが通例かと思います。
③初回の業者が、HDDの接続を変更してしまった。
これは、復旧業者としては、絶対にやってはいけない事だと思います。現状復帰で、返却するのが必須と弊社では、注意して実行しています。
復旧料金について
お客様からお話を聞いた際には、高くても30万円位と見積もっていました。しかし、HDD接続が変更され、HDD接続の順番を解析するところだけで、30万程度の費用が発生してしまいました。
実のデータ復旧作業は、一週間だったので、HDDの順番解析の作業が無ければ、30万より安くできたと思っています。
