先日まで、バーチャルボックスでこのサイトを構築して、めりめり書き込んでいたところ、何かの拍子で再起動をかけたタイミングが何かはわすれたが、起動時にカーネルパニックを起こして起動しなくなってしまった。。。

[code lang=text] Kernel panic – not syncing: Attempted to kill init! [/code]

幸いVMなので、まあ、どうでもよかったのですが、めりめり書き込んでいたデータベースの内容と、このwordpressのデータが消えてしまうのはいただけない。。

ということで、データをサルベージする方法を記載します。すげー苦労した・・。

結局のところ、カーネルパニックはSELinuxを無効にしたからが原因っぽいのですが、もはや、OSのブートすらできない状態なので今悔やんでも、しょうがない。。とにかく、カーネルパニックを起こしたVMのディスクを、他のVMの追加ディスクとして認識させマウントすればデータは救えるだろ。という復旧計画で作業を行った（のちにハマる）

手順

以下に手順を書いておきます。

新規ゲストOSの作成

とりあえず、新規で、VMを作成することろは割愛します。同様のスペック/OS（CENTOS6.5）でVMを作成し、起動するところまで確認したところで、コンソールから停止します

[code lang=text] shutdown -h now [/code]

ディスクの追加

上記で作成したOSから、カーネルクラッシュしたＯＳのディスクを追加します

追加後のイメージ

ディスクの確認

追加したディスクが認識されているか確認します

[code lang=text] ディスク /dev/sda: 21.5 GB, 21474836480 バイトヘッド 255, セクタ 63, シリンダ 2610 Units = シリンダ数 of 16065 * 512 = 8225280 バイトセクタサイズ (論理 / 物理): 512 バイト / 512 バイト I/O size (minimum/optimal): 512 bytes / 512 bytes ディスク識別子: 0x0004ddbb

デバイスブート始点終点ブロック Id システム /dev/sda1 * 1 64 512000 83 Linux パーティション 1 は、シリンダ境界で終わっていません。 /dev/sda2 64 2611 20458496 8e Linux LVM

ディスク /dev/sdb: 10.7 GB, 10737418240 バイトヘッド 255, セクタ 63, シリンダ 1305 Units = シリンダ数 of 16065 * 512 = 8225280 バイトセクタサイズ (論理 / 物理): 512 バイト / 512 バイト I/O size (minimum/optimal): 512 bytes / 512 bytes ディスク識別子: 0x000ad674

デバイスブート始点終点ブロック Id システム /dev/sdb1 * 1 64 512000 83 Linux パーティション 1 は、シリンダ境界で終わっていません。 /dev/sdb2 64 1306 9972736 8e Linux LVM

ディスク /dev/mapper/vg_centos-lv_root: 18.8 GB, 18832424960 バイトヘッド 255, セクタ 63, シリンダ 2289 Units = シリンダ数 of 16065 * 512 = 8225280 バイトセクタサイズ (論理 / 物理): 512 バイト / 512 バイト I/O size (minimum/optimal): 512 bytes / 512 bytes ディスク識別子: 0x00000000

ディスク /dev/mapper/vg_centos-lv_swap: 2113 MB, 2113929216 バイトヘッド 255, セクタ 63, シリンダ 257 Units = シリンダ数 of 16065 * 512 = 8225280 バイトセクタサイズ (論理 / 物理): 512 バイト / 512 バイト I/O size (minimum/optimal): 512 bytes / 512 bytes ディスク識別子: 0x00000000

ディスク /dev/mapper/VolGroup-lv_root: 9135 MB, 9135194112 バイトヘッド 255, セクタ 63, シリンダ 1110 Units = シリンダ数 of 16065 * 512 = 8225280 バイトセクタサイズ (論理 / 物理): 512 バイト / 512 バイト I/O size (minimum/optimal): 512 bytes / 512 bytes ディスク識別子: 0x00000000

ディスク /dev/mapper/VolGroup-lv_swap: 1073 MB, 1073741824 バイトヘッド 255, セクタ 63, シリンダ 130 Units = シリンダ数 of 16065 * 512 = 8225280 バイトセクタサイズ (論理 / 物理): 512 バイト / 512 バイト I/O size (minimum/optimal): 512 bytes / 512 bytes ディスク識別子: 0x00000000 [/code]

追加されたディスクをマウント

上記の結果ですと、サルベージ対象のデータはは、/dev/sdb2 のはずなので、これをマウントします・・があれ？エラーになっちゃいました。まず、ここでハマりました。

[code lang=text] mkdir -p /backup ; chmod 777 /backup

mount /dev/sdb2 /backup
mount: 未知のファイルシステムタイプ 'LVM2_member' [/code]

LVMとは・・

そこでいまさらなのですが、LVMであることに気づきました

LVM(Logical Volume Manager)とは、何台かのディスクをひとつのグループにまとめ、そこから論理ボリューム(パーティション)を切り出すことのできるHP-UXの機能です

とのことで、論理的に、ひとつのディスクとして見せる仕様ですね。CENTOS6.5のデフォルトインストールだと、すでにLVMになってるっぽい。じゃあこれをどうやって再認識するの？ってことを以降説明しますね。

vgscanで確認する

vgscan で、どんなグループがあるか確認します。この場合ですと、VolGroupと、vg_centosの２つあることを確認できたかと思います。

[code lang=text]

vgscan

Reading all physical volumes. This may take a while... Found volume group "VolGroup" using metadata type lvm2 Found volume group "vg_centos" using metadata type lvm2 [/code]

lvscan

lvscan で現在のVGの状態を確認します。

すべてアクティブの場合は、以下のようになります

[code lang=text]

lvscan

ACTIVE '/dev/VolGroup/lv_root' [8.51 GiB] inherit ACTIVE '/dev/VolGroup/lv_swap' [1.00 GiB] inherit ACTIVE '/dev/vg_centos/lv_root' [17.54 GiB] inherit ACTIVE '/dev/vg_centos/lv_swap' [1.97 GiB] inherit [/code]

今回追加したディスクがアクティブでない場合はこんな感じで表示されます。私の場合は以下のようになっておらず、、なんとVG名が重複しており、ここでさらにハマりました

*こんなワーニングが出たと思う・・

[code lang=text] WARNING: Duplicate VG name VolGroup00: Existing XXXXXXXX [/code]

lvsscanでは、inactive になっておりました

[code lang=text]

lvscan

inactive '/dev/VolGroup/lv_root' [8.51 GiB] inherit inactive '/dev/VolGroup/lv_swap' [1.00 GiB] inherit ACTIVE '/dev/vg_centos/lv_root' [17.54 GiB] inherit ACTIVE '/dev/vg_centos/lv_swap' [1.97 GiB] inherit [/code]

詳細を確認

vgdisplay コマンドで詳細を確認できます。今回の対応は、VG名がたぶってしまっためんどくさい例を想定してデータをサルベージする手順を公開したいと思います

vgdisplay

[code lang=text]

vgdisplay

--- Volume group --- VG Name VolGroup System ID
Format lvm2 Metadata Areas 1 Metadata Sequence No 3 VG Access read/write VG Status resizable MAX LV 0 Cur LV 2 Open LV 0 Max PV 0 Cur PV 1 Act PV 1 VG Size 9.51 GiB PE Size 4.00 MiB Total PE 2434 Alloc PE / Size 2434 / 9.51 GiB Free PE / Size 0 / 0
VG UUID Ptt0Vz-e5V3-VJjN-aBus-584P-21N8-6omnhN

--- Volume group --- VG Name vg_centos System ID
Format lvm2 Metadata Areas 1 Metadata Sequence No 3 VG Access read/write VG Status resizable MAX LV 0 Cur LV 2 Open LV 2 Max PV 0 Cur PV 1 Act PV 1 VG Size 19.51 GiB PE Size 4.00 MiB Total PE 4994 Alloc PE / Size 4994 / 19.51 GiB Free PE / Size 0 / 0
VG UUID DxfnYe-gGWn-uVf1-xB9f-XGri-4h20-4K37lc [/code]

データのサルベージを行います

とにかく目標はデータのサルベージ、しかも、追加したVGが重複してしまっているということを想定して以降説明します

かぶったVG名をリネームする

とにかく名前がかぶっている限り、ボリュームを追加することはほぼ不可能なので追加したディスク側のVG名を変更するところから始めます。VG名の変更は特定できないのでここでは、uuidをベースに変更をかけております

vgrename

[code lang=text]

vgrename Ptt0Vz-e5V3-VJjN-aBus-584P-21N8-6omnhN vg_restore

Volume group "VolGroup" successfully renamed to "vg_restore" [/code]

変更後確認

vgscan

[code lang=text]

vgscan

Reading all physical volumes. This may take a while... Found volume group "vg_restore" using metadata type lvm2 Found volume group "vg_centos" using metadata type lvm2 [/code]

lvscan

[code lang=text]

lvscan

inactive '/dev/vg_restore/lv_root' [8.51 GiB] inherit inactive '/dev/vg_restore/lv_swap' [1.00 GiB] inherit ACTIVE '/dev/vg_centos/lv_root' [17.54 GiB] inherit ACTIVE '/dev/vg_centos/lv_swap' [1.97 GiB] inherit [/code]

vg_restore をアクティブに変更します

[code lang=text]

vgchange -ay vg_restore

2 logical volume(s) in volume group "vg_restore" now active [/code]

アクティブ実行後の状態

すべてアクティブになりました

[code lang=text]

lvscan

ACTIVE '/dev/vg_restore/lv_root' [8.51 GiB] inherit ACTIVE '/dev/vg_restore/lv_swap' [1.00 GiB] inherit ACTIVE '/dev/vg_centos/lv_root' [17.54 GiB] inherit ACTIVE '/dev/vg_centos/lv_swap' [1.97 GiB] inherit [/code]

マウントの実行

ここから再度マウントを試みます。ちなみにマウントはボリューム単位で行います。今回の場合はデータ領域のみ復帰したいのでマウントはこんな感じになると思います。

[code lang=text]

mount /dev/vg_restore/lv_root /backup/

[/code]

では、マウントディレクトリを確認してみましょう。追加したディスクの中身が見えているかと思います。

[code lang=text]

ll /backup/

合計 100 dr-xr-xr-x. 2 root root 4096 7月 16 04:04 2014 bin drwxr-xr-x. 2 root root 4096 7月 9 10:17 2014 boot drwxr-xr-x. 2 root root 4096 7月 9 10:17 2014 dev drwxr-xr-x. 67 root root 4096 9月 6 00:51 2014 etc drwxr-xr-x. 3 root root 4096 7月 16 03:45 2014 home dr-xr-xr-x. 8 root root 4096 7月 16 04:04 2014 lib dr-xr-xr-x. 8 root root 12288 7月 16 04:47 2014 lib64 drwx------. 2 root root 16384 7月 9 10:17 2014 lost+found drwxr-xr-x. 2 root root 4096 9月 23 20:50 2011 media drwxr-xr-x. 2 root root 4096 9月 23 20:50 2011 mnt drwxr-xr-x. 2 root root 4096 9月 23 20:50 2011 opt drwxr-xr-x. 2 root root 4096 7月 9 10:17 2014 proc dr-xr-x---. 3 root root 4096 9月 2 18:43 2014 root dr-xr-xr-x. 2 root root 4096 7月 15 09:44 2014 sbin drwxr-xr-x. 2 root root 4096 7月 9 10:18 2014 selinux drwxr-xr-x. 2 root root 4096 9月 23 20:50 2011 srv drwxr-xr-x. 2 root root 4096 7月 9 10:17 2014 sys drwxrwxrwt. 4 root root 4096 9月 6 00:51 2014 tmp drwxr-xr-x. 13 root root 4096 7月 9 10:18 2014 usr drwxr-xr-x. 20 root root 4096 8月 29 07:03 2014 var [/code]

データのサルベージ

私の場合は、webと、mysqlのデータベースを中心にサルベージしました

サルベージ

[code lang=text] cd /backup/ cp -arf var/lib/mysql/ /var/lib/ cp -arf var/www/ /var cp -arf tmp/* /tmp/ [/code]

後始末

サルベージが終わりましたら、umountして、対象のVGもinactiveに戻しておきましょう

[code lang=text]

cd

umount /backup/

vgchange -an vg_restore

[/code]

如何でしょうか？ ^_^ これで復旧できなかった人すみません

Database JUNKY

MySQL,MariaDBを中心としたブログです

バーチャルボックス：カーネルパニックからのデータ復旧

手順

新規ゲストOSの作成

ディスクの追加

上記で作成したOSから、カーネルクラッシュしたＯＳのディスクを追加します

追加後のイメージ

ディスクの確認

追加されたディスクをマウント

LVMとは・・

vgscanで確認する

vgscan

lvscan

lvscan

lvscan

詳細を確認

vgdisplay

データのサルベージを行います

かぶったVG名をリネームする

vgrename Ptt0Vz-e5V3-VJjN-aBus-584P-21N8-6omnhN vg_restore

変更後確認

vgscan

lvscan

vg_restore をアクティブに変更します

vgchange -ay vg_restore

アクティブ実行後の状態

lvscan

マウントの実行

mount /dev/vg_restore/lv_root /backup/

では、マウントディレクトリを確認してみましょう。追加したディスクの中身が見えているかと思います。

ll /backup/

データのサルベージ

後始末

cd

umount /backup/

vgchange -an vg_restore