一時はどうなることかと……。

CentOS5.4がリリースされたので、HVMなGungnir.mythril.ne.jpを5.3→5.4のアップデートを試みた。これ自体は

yum upgrade

だけで終了なのだが、再起動を掛けたら起動しなくなったからさぁ大変。

起動時のfsckで「signal 11」が出てしまい、手動のfsckすら通用しない、というかなり深刻な事態。幸い、メンテナンスモードから中のデータは無事っぽいことが判明。理由は不明だが、ハードディスクイメージが破損した、ということ自体は確定のようだ。

仕方がないのでDVDバックアップしたGungnirのHDDイメージをコピー、Xenで起動させ、しばらく前のマシン状態には戻した。問題はMySQLのDBデータである。

ログのようなシステム的に更新が掛かっているデータは特に破棄でも問題はない。が、XOOPS/WordPressのバックグラウンドで動作しているMySQLのデータはそうはいかない。極力サルベージ→レストア、としたい。

というわけで、破損したGungnirのHDDイメージからMySQLのDBデータをサルベージした。


1.LVMパーティションのマウント
　GungnirのHDDイメージはLVMパーティションが含まれており（ルートパーティションとスワップ……のはず）、通常のmount動作でマウントすることはできない。やり方はここ参照。手順がややこしいのでマウントできた時点でLVM単位でddコマンドで別途イメージファイル化した。

2.MySQLデータのサルベージ
　「1.」でできたイメージファイルを別途ループバックでマウント、それで見える/var/lib/mysql以下がMySQLのDBデータの実体なので、これを取り出し、tarで固める。

3.MySQLデータのレストア
　バックアップから起動させたGungnirのmysqldを一旦停止させ、サルベージデータをやはり/var/lib/mysql以下に展開。mysqldを起動し直して終了。


再度このXOOPSサイトとブログサイトが表示されたときは心底ほっとした。さっと確認した限りでは問題なく復旧できているようだ。

MySQLのDBデータのダンプの方法は多数あるが、結局のところは特定のディレクトリ以下にあるファイル群が実体で、単純にこれをコピー→配置してやるだけでOK、というのは非常に有り難い仕組みである。

OSアップグレードでここまでコケたのは今回は初。こんなことがあると物理サーバのアップグレードなんかおっかなくてとてもやる気になれないわ（滝汗）。

Gungnirは、XOOPS/WordPress用のMySQLデータ以外に関して言うと、ぶっちゃけ設定ファイルに基づくサービス動作のみで、大規模なアップデートや機能削除/追加を行わない限りはほとんど中身が変わらないのと同義である。ハードディスクイメージ全体をバックアップすることも必要だが、MySQLのDBデータに限っては別途それだけでのダンプ/バックアップの仕組みを考えた方が良いのかもしれない、と思った。