初めてのカーネルパニックと復旧までの手順

とても疲れたので文体は適当。

本ブログのサーバがyum updateで初めてカーネルパニックに出くわしたので、絶望に打ちひしがれながら、復旧作業。
理論的には知っていたけど、初めての作業だったので、時間かかった。。。でもとりあえず今ブログが見れてるということは復旧できてるということなので、その記録をしておきます。

ハードディスクが壊れたわけではないので、やることは単純で、今までbootディスクとして利用していたボリュームをただのデータディスクとして他サーバにアタッチして、マウントして必要な中身を救い出すだけ。
今回はAWS上に別のサーバ立てて、そこへ壊れたディスクをアタッチして、マウントからの救出を試みました。

以下のページを参考にカーネルパニックを起こしたマシンのサルベージを試みる
http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ebs-using-volumes.html

とりあえず、壊れた仮想マシンのスナップショットからボリューム作って、新しく作った仮想マシンにアタッチする。

mountに失敗する…orz

知らんがな

エラーでぐぐると以下のようなページを見つける。
やっぱみんな同じような悩みに出会うんだなー。

http://umasolution.blogspot.jp/2014/08/solve-mount-unknown-filesystem-type.html
http://www-kn.sp.u-tokai.ac.jp/~tsujimoto/cantreboot_fedoraHDD.html
http://pissedoffadmins.com/os/mount-unknown-filesystem-type-lvm2_member.html

みんな一様に以下のコマンドを実行していたので、とりあえずググってみる
とりあえず以下のコマンドを実行

なんかもうAWSの問題というより、LVMの問題な気がするので、
とりあえずググってでてきたコマンドをひたすら実行してふむふむと分かった気になってみることにする。

あーだこーだ試すも全然ダメ。ここまで作業開始から昼寝(ふて寝)とご飯含めて**時間。死にたい。

とりあえず、pvとかvgとかlvとかの意味が全然わからんのでググってみたら、
ボリュームグループの名前がかぶってたらダメじゃね?と気付く。

以下ページを参考に論理ボリュームの名前を変更してみる。

論理ボリューム名の変更
http://www.drk7.jp/MT/archives/001632.html

これはlv-UUIDを指定していたのでダメだと怒られた。

お( ^ω^)

おっ( ^ω^)

おっおっ( ^ω^)

キタ━━━(゚∀゚).━━━!!!

ドキュメントルートとかDBとかサーバの設定を適当にもってきて、ようやく帰ってきました。
愛着ないと思ってたけど、カーネルパニックになったときはホントに脳みそフリーズしましたわ。

こうやってディスクからサルベージさせるのね。
んー勉強になった。

※ここに書いてあることは自己責任で実行をお願いします。

この投稿へのコメント

コメントはありません。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です