サエバサバエのちょっとセキュアなお話、あるいは、呑み女子エンジニアのだらしない食卓

第16話 ある晩に自宅サーバが起動しなくなったこともあったわね（４）、あるいは、適当過ぎるモスコミュール

「本当はライムとか入れるんだけど、ま、ウォッカをジンジャーエールで割ったらモスコミュールってことでいいわよね」

「はぁ、おいしい、です」

　お互いの杯を傾けながら、いよいよ復旧の経験談も佳境に入る。

　そろそろ、実演が必要かしらね？

　ノートパソコンを準備してっと。

　それじゃぁ、続きね。

　あの日は、時間が遅かったので作業は翌日に回したわ。無理してミスを重ねてはいけないからね。

　そうして、翌日の仕事を難なくこなして帰宅してから、焦らず、落ち着いて対策を考えたわ。

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

「仮想イメージの動作確認は、どうすればいいと思う？」

「それは……実際に仮想環境を動かす環境を作って確認です。だから、買ってきたハードディスクに新しい環境を構築して、そこでやるのが確実ですね」

　ちびちびと飲んでいるからか、酔った様子もなくウエノちゃん。

　ま、以前つぶれたときは、あたしが入れたお酒を飲んでたからね。反省はしてるのよ、うん。

　それはさておいて。

「確かに正解だけど、ディスクを抜き出して放置してたサーバ本体に、改めてディスクを指してあれこれする時間が惜しかったから、別の手を使ったわ」

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

　だからあたしは、 VMWare に登場願ったわ。

　あるバージョンから商用利用は有償になったけど、個人使用は無償で使えるからね。 Windows 上で手軽に使えるのを使ったわ。

　だから、実際の環境と同じ CentOS 5 を VMWare にインストールしたわ。

「あれ？　その当時の時点で CentOS 5 のサポートは切れていたんじゃないですか？」

「いいえ。ギリギリ残ってたわ」

　誤差の範囲だけどね。でも、復旧作業中にバージョンアップまでする気力がなかったのよ。

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

　ま、 CentOS 5 のインストールなんて今更学んでも仕方ないので割愛するわ。

　で、コピーできたらマウントね。

　サルベージしたディスクイメ―ジを /mnt/rescue にマウントして、その中身を /mnt/rescure/... という形で読み出せるようにマウント作業を始めたわ。

「え？　仮想のイメージってマウントできるんですか？」

　ウエノちゃんが驚くのも無理はない。

　あまり説明されてないけど、ディスクイメージなんだから、できちゃうのよね。

「じゃぁ、実演してみるわね」

　当時は色々調べながらだったけど、今では覚えている。

　準備していたノートパソコンがようやく活躍するときだ。当時のイメージそのままあるしね。

　CentOS 5 の仮想環境を起動して、実演を始める。

　まずは、ファイルをディスクとして扱うためにループバックデバイスに割り当てるところからよ。

　これは、 losetup コマンドで、ディスクイメージを /dev/loop0 というような形でオペレーティングシステム上からハードウェアデバイスと同じように見えるようにする作業ね。

　次は、ディスクの各パーティションを読めるようにする必要があるわ。

　割り当てたループバックデバイスはディスク全体になるから、その中身のパーティション単位で見えるようにするために、 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

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

#

　そっけなく、次のコマンド入力待ちのプロンプトが表示された。

「 Linux とかの UNIX 系 OS で何も出ないときってどういうときかしら？」

「何も出ないのは処理成功の証、でしたね」

　以前教えたこと、ちゃんと覚えててくれたのね。

　そうよ。何も出ない＝処理成功なのよ。

　ああ、当時を思い出すわ。

　ここから、ついに具体的なファイルの確認になるからね。

　ls コマンドをたたけば……

「出ましたね！」

　ノートパソコン上で開いたコンソールには、 etc , home , usr , var といった、お馴染みのディレクトリが並んでいた。

「でも、油断したらダメなのよ」

　これは、大外の枠組みが見えただけ。ディレクトリの中が読み出せるかは解らないわ。

　ディレクトリ構成が壊れてたら、中を辿って行けずにファイルを見付け出せない、なんてことは壊れたディスクではよくあることなのよ。

　それで、優先度だけど、サーバ再構築には、何より設定ファイルがあると助かるわよね。あれこれ悩まず、動いてたときの設定そのままコピーすればいいだけだもんね。

　あとは、ウェブの公開ディレクトリと、個人用の作業ファイル、ってところが重要。

　まとめると、 etc 、 var/www 以下、 home 以下、ってことになるわ。

　他にも svn のリポジトリもあったわ。

「……家でもバージョン管理してるんですか？」

「そりゃ、するわよ。便利だもん。今では、 git に移行したいけど、一人で作業する分には、 svn で十分なのよね」

　ファイル変更の履歴を残しておけば、後でやっぱり前の方が……ってときに戻せたり、どこを変更したか直前のバージョンと比較したり、とできて色々便利でしょ？　自宅サーバを運用していると、いろいろと履歴を辿りたい事態はあるのよ。

　それで、 svn のリポジトリだけど、それは /var/repos に置いていたわ。

　それで、読もうとしたんだけど、

「あれ、開かないですね？」

　そうなのよ。

　ls var をすると、 repos ディレクトリの表示がおかしい。

「このディレクトリは、残念ながら死亡してたのよ」

　実物を使っているから、問題も再現できていいわね。

「まぁ、 svn は最新の作業コピーがメインＰＣ上にあるから、履歴が失われただけでデータは無事だったから、傷は浅かったわ」

「それだと、作業コピーが履歴も含んだリポジトリに簡単に置き換わる、 git の分散管理の方が便利じゃないですか？」

「ま、そうなんだけどね……さっきも言ったけど、運用に特に支障がないから、乗り換えられないのよ」

　でも、この機会に置き換えるのもいいかもしれないわね。

「さて、残念ながら、ここが読めなかった、ってことは、仮想ディスクはやっぱり壊れてたってことになるわ。つまり？」

「他にも、読めないディレクトリやファイルはあるって考えた方がいいということですね」

「そうよ。でも、本当なら全てを失ってもおかしくない状況でここまで来たから、信じて作業を進めることにしたのよ」

　こうなったら、一つ一つの細かいディレクトリを確認するのはあきらめて、必要な etc 、 var/www 、home ディレクトリを、 tar コマンドで丸ごとアーカイブすることにしたわ。

「エラーが出てますね」

「でも、エラーのあったファイルは無視して読み出せたファイルは tar ファイルにどんどん収められて行ってるでしょ？」

　そうしてできあがった tar ファイルを、 VMWare を動かしている Windows 側へと scp でどんどん吸い出していく。

「この通り、いくつか破損はあったけど、設定ファイルやら公開用の HTML やら CGI のファイルの多くは吸い出せたのよ。おかげで、サーバ環境の復旧はゼロからよりは格段に楽になったわ」

　ただ、

「実は、 MySQL も動いてたのよね」

「ダンプファイルとかはないんですか？」

「それが、ダンプ先の仮想ディスクは死んでたのよ」

「ということは、実際のデータベースの構成ファイルしかない、ってことですね」

「そうよ。それに、ファイルが読み出せただけで、データベースが動いているわけじゃないから、ダンプもできない状態」

　まぁ、データベースの構成ファイルをコピーして設定ファイルの辻褄を合わせるって方法もあるけど、構成ファイルが壊れている可能性があるから、そもそもデータベースが動かない可能性があってリスクが高いわ。

「でも、それならダメ元でデータベースを動かしてみるのではいけないんですか？」

　当時のあたしと同じことに気づいたみたいね。

「ええ、そうよ。その理屈なら、動かしてみたらはっきりするでしょ？　だから、あたしは大きな賭けに出たの」

　データベース以前に、オペレーティングシステムが立ち上がるかもわからない。

　それでも、サルベージした仮想ディスクさえバックアップしておけば、やり直しは効くでしょ？

　だから、あたしは一旦、サルベージ用の仮想環境を停止して、このイメージをバックアップしてね。

「 VMWare 上の CentOS に Xen を入れて、仮想ディスクを動かしてみることにしたのよ」

「仮想環境の中で、さらに仮想環境を動かせるんですか？」

「できるわよ。ま、リソースは食うけどね」

　そうして、メタな環境構築に取り掛かったわ。

yum install xen

　って感じで、 VMWare 上の CentOS にサクッと必要なソフトをインストールするだけよ。

　ただ、 xen は、専用のカーネルじゃないと動かないから、再起動してカーネルを切り替える必要があるのがちょっと不便ね。

　準仮想化ってやつね。

　ま、幸いにして xen の設定ファイルはサルベージできてたから、後は、所定のパスに入れるだけ。

　とまぁ、その作業をしたディスクイメージがこれよ。

　当時のイメージを起動する。

　ファイルは設置済みの状態で置いてある。

　そんなわけで、これが、復旧したファイルね。

/etc/xen

　を示す。

　で、こっちが仮想ディスクね。

/var/lib/xen/images

　を示す。

「なんだか、 KVM と似たような感じなんですね」

「そうよ。だから、その後 xen から KVM へ移行したわ」

　それはさておき、

「ここまで準備できれば起動できるから、起動してみるわね」

xen create sabae

　と、起動コマンドを叩く。

「これも KVM みたいですけど……仮想環境に自分の名前を付けるのはどうかと思いますよ？」

「いいじゃない。親からもらったこの名前、気に入ってるんだもん」

　いいながら、

xen console sabae

　とコマンドを打って起動中の状況を確認する。

「え？　なんだか、酷いことになってませんか？」

　無情にも、ディスクエラーで起動が止まっていたのだ。

「一難去ってまた一難ってところだけど、ま、想定の範囲内よ」

「ぶっちゃけあり得ない、とか思ったりはしなかったんですね」

　当時のあたしと同じネタを言うとは、中々やるわね。

「それで、どうしたと思う？」

「それは……ディスクチェック、しかないですよね。 root のパスワードを入れて、コマンドラインに入るんですよね」

　その通り。

　あたしは、手順通り root のパスワードを入れて、fsck 《file system check》コマンドを実行する。

「うわ、凄いですね。ここまでエラーが頻発するの初めてです」

　よかったわ。当時の復旧前のスナップショットを残しておいたのが、こうして役立つなんてね。

　画面上には、出るわ出るわのエラーの嵐。

「でもこれ、修復するか問われる度に『 yes 』の y を入力してエンターするより、最初から -y を付けて実行した方がよかったんじゃないですか？」

「ここまで数が出るとは思わなかったから、当時のあたしは一つ一つ確認する道を選んだのよ。すぐに終わると信じながら、しばらくは Y キーを押すだけのマシーンと化した心境だったけど、確実に前に進んでいると感じられて、苦にはならなかったわ」

　でもま、今回は結果を知っているから、モスコミュール片手に Y を押してるんだけどね。

　おつまみは、修復ログが延々流れるディスプレイと、それを真剣に見詰める可愛い後輩の姿、かしらね。

「なんだか、楽しくなってきましたね」

　修復が進んでいる実感はあるからね。妙な高揚感が出てくるのよね。

　あのときも、そうだったわ。

　そうして、しばらくすると。

「終わりましたね」

　流れていたメッセージが止まり、入力待ちのプロンプトが表示される。

「何も出ないのは処理成功の証。修復成功ということよ」

「でも、読めないファイルを破棄するようなメッセージも沢山出ていましたよね？」

　よく見てたわね。実は、ディスクの修復って読めないところを切り捨ててただけなのよね。

「そうね。でも、修復は完了したんだから、後は試すだけね」

　当時のあたしのようにドキドキして拳を握り緊張するウエノちゃんの前で。

reboot

　再起動のコマンドを実行すると、真っ黒い背景の素っ気ないコンソールに、沢山の文字が流れていく。

　起動シーケンスが実行されている証ね。

　さっきは、このシーケンスの中のディスクチェックでエラーで止まってたけど、今度は……

「通った！」

　ウエノちゃんが歓声を上げる。

　当時のあたしもそうだったわ。ディスクチェックをクリアし、サービスが起動し始めたのよ。

　そして、待つことしばし。

login:

　というプロンプトが表示された。

「来ましたね。これって、起動したってことですよね」

　その通りよ。ここまでくれば、少なくともオペレーティングシステムのレベルでは起動してログイン可能な状態となったってことよね。

　root ユーザでログインしてみる。

「もしかして、何か問題があるんですか？」

　時間が掛かるので、ウエノちゃんが心配そうにしているが、結果を知っているあたしは余裕がある。

#

　かなりの時間が経過して、管理者を示す # のプロンプトが表示され、コマンド実行可能な状況になった。

「それじゃぁ、ここでデータベースの確認ですよね」

　ちゃんと覚えてたみたいね。

　この賭けは、データベースの復旧のための作業よ。

「ところで、データベースには何が入ってるんですか？」

　趣味で書いてるブログの記事なんかが入ってるのよね。千件以上の記事があったりするから、復活させられると、とっても嬉しいって感じだった。

　でも、なんだか気恥ずかしくって、

「乙女の秘密よ。でも、とっても大切なデータ」

「そんなんですか。てっきり、読んだ本や映画の感想ブログの記事が入っていると思ったんですが……千件以上のエントリがありますし、ディスク障害を起こした日より前のデータもあるから、きっと復旧は成功したんだと思ってたんですが」

「ま、待って……知ってたの？」

「あ、やっぱりあれ、小枝葉先輩のブログなんですね。読んでいる本とか映画と連動しているから、きっとそうだと思ってたんですよ」

　しまった。カマを掛けられてたのか……でもま、いいわ。

「そうよ。あのブログのデータ。そして、想像通り復旧はできたんだけど、その過程を見てみましょうか」

　ここで焦ってうっかりデータを消しちゃったりするってミスはやりがちだからね。

「さて、じゃ、データベースである mysqld のプロセス起動状況を確認するんだけど、どうやったらいいかしら？」

　キーボードを示して問えば、

「こうですね」

ps -ef | grep mysqld

　サクッと実行し、

「 mysqld のプロセスは起動はしていますね」

　結果を報告する。

　ま、これぐらいのことはできて当然ね。

「つまり、ダンプできるってことよ」

　早速、ダンプコマンドを実行する。

# mysqldump --all-database -uroot -p --opt -r/tmp/mysql_dump

「あれ？　復旧できたんじゃないんですか？」

　エラーが表示されて不思議そうにするウエノちゃん。

「ううん。すんなりはいかなかったのよ。とりあえず、修復を試みたりしたわ」

#mysqlcheck -uroot -p --all-database

　チェックコマンドを実行してみると。

「まだ、エラーが残ってますね」

　若干のテーブルは修復できたけれど、どうにもならないテーブルがまだいくつかある。

「これは、どうやって復旧したんですか？」

　復旧コマンドでもエラーになったテーブルをどうやって復旧させたか？

　技術者として気になるところよね？

　ウエノちゃんは期待に満ちた目で次の言葉を待っているけど、あたしの答えは、

「捨てたわ」

「え？」

「色々調べたら、奇跡的にログデータばかりだったから、別になくても支障がなかったのよ」

　少し納得いかない表情のウエノちゃんだけど、そこはきちんと指導しなきゃね。

「ウエノちゃん。完全に復旧させることに拘泥すると本当の目的を見失うわよ？　切り捨てていいものは切り捨てて、最低限の大切な部分だけでも復旧させるっていう場面は、仕事でも今後出てくるかもしれないからね。たとえば、壊れそうなディスクからのデータ復旧では、優先度の高いデータから読み出して、途中で壊れた場合の被害を抑える、なんかも、この考え方に従ってのことよ」

　最善を尽くすってことは大事だけど、完璧を常に目指すのは間違いってことが多々あるってことね。

「よく解りました。本当、私はまだまだ未熟ですから、引き続きご指導ご鞭撻お願いします」

　素直に受け入れてくれるのは嬉しいわね。

「じゃ、切り捨てるわ」

#mysql -uroot -p

　mysql の操作コンソールに入り、 DROP TABLE で件のテーブルを削除してしまう。

「ま、ここでテーブル名間違えると悲劇だから、実際はもっと慎重にやったんだけどね」

　そうして、エラーになったテーブルがなくなった状態で、再びダンプを実行。

# mysqldump --all-database -uroot -p --opt -r/tmp/mysql_dump

「何も出ないのは処理成功の証ですね」

　ウエノちゃんが嬉しそうに言う。

「そうよ。これで、データの復旧は九割成功したって言えるわ」

　サーバの各種設定、その他補助的自作のスクリプト、ファイルベースのデータ、そして、データベースのダンプまでがサルベージできたからね。

「確かに、そこまであれば、後は簡単ですね」

　オペレーティングシステムのインストールなんて、定型的な作業だしね。

「そうよ。どうかしら？　復旧作業の追体験はできた？」

「はい、ばっちりです！」

　そう、なら。

「まとめの前に、次ね」

　こうなると、お米が恋しいわ。

　一升瓶を持ってきて、湯飲みに注ぎ。

　未だ一本をちびちび飲んでいるウエノちゃんの前に差し出し、

「乾杯！」