muninのグラフを見ると障害の直前までに徐々に負荷が高まっている様子が確認できたので、なんとなく状況は把握。
この負荷が高まった原因については分かっているけど、すぐに対応できるものではないのでこちらはタスクに放り込んでスルーしておく。

止まっても緊急性のないサーバなのでのんびりと復旧を開始した。

ひとまず再起動

しょっぱなから適当に最強の回復魔法を試してみたのだが撃沈。
どうもブートの途中でひっかかってしまって起動しなくなった。

起動時にfsckが走ることを期待したのだが、そこまでも行かないっぽい。
しかしながらXenのconsoleから確認するとディスクをマウントするところで止まっているっぽいので、やはりまずはfsckをかけたいところだ。

Domain0からディスクイメージの中身をfsck

そこでDomain0からイメージファイルの中身を触って修復することにした。

まずディスクイメージをloopデバイスに割り当てる
これにはlosetupを使う。

# losetup /dev/loop0 /var/lib/xen/images/hoge.img

まだこの状態ではfsckかけてもext2じゃないよとか言われて動かないので更にパーティションごとにアクセスできるようにする。

# kpartx -a /dev/loop0

これで/dev/mapper/以下にloop0p1からloop0p8までパーティションに応じたデバイスができるので、これらをfsckすることができるようになった。

# e2fsck -c -f /dev/mapper/loop0p1

p4が欠番でp3はswapなのでスルーしてp1,p2,p5,p6,p7,p8を順にfsck。
p7とp8でいくつか不良ブロックが見つかったのでyを何回か押して修復完了。

最後に後始末しておしまい。

# kpartx -d /dev/loop0
# losetup -d /dev/loop0

これで再度起動すると無事起動して動き出した。
素晴らしい。

参考

• Xenのイメージファイルをマウントする < < そこはかと
• HDDイメージファイルをマウントして使う方法 – adsaria mood
• 19.11.ゲストディスクイメージ上のデータアクセス