先日まで、バーチャルボックスでこのサイトを構築して、めりめり書き込んでいたところ、何かの拍子で再起動をかけたタイミングが何かはわすれたが、起動時にカーネルパニックを 起こして起動しなくなってしまった。。。
[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]
如何でしょうか？ ^_^ これで復旧できなかった人すみません
