ある晩、自宅サーバが起動しなくなって

第七話 遠回りしてもたどりつけるのなら

　朝、布団から出て顔を洗う。

「うん、今日は大分マシな顔になったわね」

　鏡に映った顔は、隈も取れて見れるものになってる。

　頭もすっきり。

　まだまだ中身が無事かは未知ながら、最低限のサルベージに成功してよく眠れたからに違いない。

「まずは、お仕事頑張らないとね」

　眼鏡を掛けて、色々スイッチを入れる。

　かくして、サクッと仕事をこなしてまっすぐ帰宅に成功。

「さぁ、復旧作業よ！」

　ＰＣの前に座って気合を入れる。

　でも、焦っちゃいけない。

「落ち着いて、どうすればいいか考えましょう」

　ディスクイメージを抜き出しても、 Windows 上では簡単には読めない。

「ここはやっぱり、 Linux 上でマウントするのが確実だけど、実サーバで試行錯誤するよりは、仮想でやった方がいっか」

　物理サーバに新しいディスクはまだ差してない。

　焦ってディスク抜き出すだけ抜き出したサーバの本体は、今も蓋開けっぱなしで寝室の隅に放置してあったりするけど見ない振り。

　ディスクイメージ内のデータがどれぐらい無事かを確認するのが先決、というか気になって先に進めないわ。

「ここは VMWare の出番ね」

　VMWare は色々ある仮想環境構築ソフトの一つ。商用でも沢山実績のあるとても有名なものね。

　個人利用は無償だから、自宅では使い放題。気軽に色々な OS を動かせてておても便利。こういうときは、本当、重宝するわ。

「とりあえず、冒険せずに元のサーバと同じ CentOS 5 でいきますかね」

　バージョンが古くてもうすぐサポート切れちゃうんだけど、壊れる前のサーバをセットアップする時に「枯れた技術の方が安心よね、うん」という技術者的視点で OS 選んだのだ。

　今は、それに合わせておくのが無難よね。

「ま、 CentOS のインストールなんて、慣れたものよねぇ」

　仕事でもちょっとした実験に仮想環境を作っては色々試してきたから、サクッとインストールを完了する。

「さてさて、読めるかしら？」

　仮想環境のディスクへ、まずはサルベージした外部公開用の方のサーバのディスクイメージを転送する。ファイルサーバはそんなに構築に手間はかからないので、やっぱりこっちのサーバの方が重要なのよ。色んなアプリケーション動いてたし。

　そうして、容量が２０ＧＢと大きいだけに時間が掛ったけど、

「やっと完了か……さて、マウントできるかしら？」

　Xen という仮想化ソフトで使うためのディスクイメージを、 Linux 上で読めるようにするには「マウント」という作業が必要になる。

　これは、 Windows だと新しく追加したハードディスク上に作成したパーティションに E: とか F: とかドライブレターを割り当てるようなものね。

　Linux とかの Unix の流れを組む OS では、特定のディレクトリの下を、特定のディスクのパーティションに紐づけるってことになる。

　例えば、 /mnt/sda1 とかにディスクのパーティションを割り当てたりするわ。

　まぁ、解らないなら解らないでいいの。

　今からは、 サルベージしたディスクイメ―ジを /mnt/rescue にマウントして、その中身を /mnt/rescure/... という形で読み出せるようにしようってしてる、ぐらいのことよ。

　って、誰に話しかけてるのかしら、あたし？

「えっと、どうやるんだっけ？」　

　何度かやったことあるんだけど、すぐに忘れてしまう。

「あ、そうだ、ファイルをディスクとして扱うためにループバックデバイスってのに割り当てて……」

　まずは、losetup というコマンドを使って、ディスクイメージを /dev/loop0 というような形で OS 上からハードウェアデバイスと同じように見えるようにする。

「次は、ディスクの各パーティションを読めるようにしてっと……」

　先ほど割り当てたデバイスはディスク全体になるから、その中身のパーティション単位で見えるようにするために、 kpartx というコマンドを使用する。

「うんうん、いいわよ、エラーなし！」

　無事、 /dev/mapper/loop0p1 という形で、ディスクイメージの中のパーティションが見えるようになった。

「いよいよマウント……ってエラー」

　 やっぱりだめなの……って違う違う。

「 LVM 使ってたんだった……」

　LVM というのは、複数のパーティションをまとめて一つの大きなドライブのようにする形式。後からシステムを止めずにディスクを追加して全体の容量を増やしたりってことができるんだけど、こういうときは単体で読み出せないので面倒になる。

　幾つか余計な手順が必要になって遠回りを強いられちゃうの。

「でもま、いいわ。遠回りでもファイルの読出しまで辿り着けるのなら、データ復旧のスタートラインに立てるからね」

　pvscan

　まずはディスクの中身そのものにあたる物理ボリューム（ Phisical Volume ）を見て、

　vgscan

　その中の LVM を構成するボリュームグループ（ Volume Group ）を見て、

　lvscan

　 論理ボリューム（ Logical Volume ）を見て……うん、ここまでは、問題なく見えてるわね。

　じゃ、

　vgchange -a

　ボリュームを有効にして……　/dev/VolGroup00/LogVol00 ってのが、ディスクイメージの中身ね。

　こうして、周りくどい手順を踏んで、再びマウント。

「エラーでないでよ……」

　mount /dev/VolGroup00/LogVol00 /mnt/rescue

　コマンドを叩き、少しの間の後、

#

　そっけなく、次のコマンド入力待ちとなる。

「マウント成功！」

　何も出ないのは処理成功の証。

「さぁ、ファイルは無事かしら？」

　ドキドキしながら、あたしは ls コマンドを叩く。

　って細かいことはいいのよ。

　最終的に論理ボリュームが有効になれば、マウントできるようになるだけ。

　復旧作業の手順をまとめてみる。

・ VMWare 上に元のサーバと同じ CentOS をセットアップ

・仮想環境上にサルベージしたイメージファイルを設置

・まずは、マウントして中身が読めるか確認

・あわよくば、 Xen 上で起動してデータベースのダンプを試みる

　枯れた技術がいいからと、 CentOS 5 で構築していたのだ。

　実は CentOS 6 からは Xen よりも KVM の方が扱いやすくなってたりするんで、

　この機会に、 KVM にしちゃおっかな？