- - PR -
LVMハードディスクの復旧について
| 投稿者 | 投稿内容 | ||||
|---|---|---|---|---|---|
|
投稿日時: 2009-02-05 13:09
先日、Redhat Enterprise Linux 5がハードディスクの障害でカーネルパニックで起動しなくなりました。ハードディスクは完全に壊れているということではないようで、別のハードディスクで起動し、fdiskで確認すると下記のように表示されました。
Disk /dev/sdb: 80.0 GB, 80000000000 bytes 255 heads, 63 sectors/track, 9726 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/sdb1 1 10 80293+ de Dell Utility /dev/sdb2 11 1055 8393962+ 8e Linux LVM /dev/sdb3 1056 1080 200812+ 83 Linux /dev/sdb4 1081 9726 69448995 5 Extended /dev/sdb5 1081 9726 69448963+ 8e Linux LVM Linuxには不慣れで、LVMという概念も初めて知ったぐらいですが、mountやfdiskは以前から使っていました。どうやら普通にmountしてもLVMはマウントできないようですが、LVMに関するサイトを見てもどうやって無事に内容を確認できるかわかりませんでした。 詳しい情報が全然掲載できないので、この状態でどうしたらよいかとお聞きするのも心苦しいのですが、なんとかハードディスクを確認できる状態にして、いくつかのファイルを安全な場所にコピーしたいと考えています。 まずは、他サイトを見ながら/dev/sdb5をバックアップしました。 # dd if=/dev/hdb3 of=hdb3.img bs=512 conv=noerror,sync 次に、下記コマンドでマウントをしようとして、失敗しました。 mount -o loop ./sdb5.img /mnt/sdb5 mount: wrong fs type, bad option, bad superblock on /dev/loop0, missing codepage or other error In some cases useful info is found in syslog - try dmesg | tail or so dmesgしましたが、多くの出力があったのですが、それも掲載したほうが良いでしょうか？ なにかヒントなどがありましたら、教えていただけると嬉しいです。 | ||||
|
投稿日時: 2009-02-05 14:47
別のハードディスクから起動していると、
同じVG名がついてたりする可能性もありますね これに関しては #lvm vgscan で確認できたと思います。 | ||||
|
投稿日時: 2009-02-05 15:15
コマンドの結果は以下の通りでした。
# /sbin/lvm vgscan Reading all physical volumes. This may take a while... Incorrect metadata area header checksum Found volume group "volold" using metadata type lvm2 Found volume group "VolGroup_ID_16178" using metadata type lvm2 vololdはハードディスクの障害があってから、復旧しようとしてID名を付けるところまで進めたものです。テスト的な作業で、比較的壊れてもよいパーティションで行いました。VolGroup_ID_16178は新しくインストールしたLinuxの領域です。 できれば、下記を復活させたいと考えています。 Device Boot Start End Blocks Id System /dev/sdb2 11 1055 8393962+ 8e Linux LVM /dev/sdb5 1081 9726 69448963+ 8e Linux LVM 特に/dev/sdb5を復活させたくて、ddコマンドでsdb5.imgまで作成しました。 これ以降どうしたらよいかで右往左往しております。 tune2fsというコマンドを使ってみましたが、特にヒントになりそうな情報がありませんでした。 # /sbin/tune2fs -l sdb5.img tune2fs 1.39 (29-May-2006) Filesystem volume name: <none> Last mounted on: <not available> Filesystem UUID: 654c7a9f-d97b-41d2-a8b1-aae1ea9af3bd Filesystem magic number: 0xEF53 Filesystem revision #: 1 (dynamic) Filesystem features: resize_inode dir_index filetype sparse_super large_file Default mount options: (none) Filesystem state: not clean with errors Errors behavior: Continue Filesystem OS type: Linux Inode count: 8683520 Block count: 17362240 Reserved block count: 868112 Free blocks: 11673898 Free inodes: 5931008 First block: 0 Block size: 4096 Fragment size: 4096 Reserved GDT blocks: 1019 Blocks per group: 32768 Fragments per group: 32768 Inodes per group: 16384 Inode blocks per group: 512 Filesystem created: Tue Feb 3 23:45:01 2009 Last mount time: n/a Last write time: Thu Feb 5 15:04:10 2009 Mount count: 0 Maximum mount count: 33 Last checked: Tue Feb 3 23:45:01 2009 Check interval: 15552000 (6 months) Next check after: Sun Aug 2 23:45:01 2009 Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root) First inode: 11 Inode size: 128 Default directory hash: tea Directory Hash Seed: 6e4aa84b-89ee-4d7c-907e-13a8f9338b7a そのほか、下記のコマンドを試してみました。 # /sbin/e2fsck sdb5.img e2fsck 1.39 (29-May-2006) Group descriptors look bad... trying backup blocks... Corruption found in superblock. (blocks_count = 0). The superblock could not be read or does not describe a correct ext2 filesystem. If the device is valid and it really contains an ext2 filesystem (and not swap or ufs or something else), then the superblock is corrupt, and you might try running e2fsck with an alternate superblock: e2fsck -b 32768 <device> スーパーブロックが読めないということですが、ヒントっぽい/sbin/e2fsck -b 32768 sdb5.imgを試し、同じ結果が表示されたところでご質問をさせていただいております。 | ||||
|
投稿日時: 2009-02-05 16:09
ちょっとうろ覚えなのですが、まずはそのvololdをマウントするとして
lvm lvscanを実行し volold 配下の論理ボリュームになにがあるかとACTIVEかどうか見る必要があると思います。 すでにactiveであれば、 mount /dev/volold/[論理ボリューム名] [マウントポイント] でマウント可能でしょう。 ACTIVEでない場合、lvm vgchange のayオプションかlvm lvchange のayオプションでアクティブにしてあげればマウントできるのではないかと。 | ||||
|
投稿日時: 2009-02-05 16:17
これはつまり、「LVMのディスクイメージをマウントしたい」という問題なのではないでしょうか？
LVMをいじったのはもう２年前になるみたいなのでよく覚えてないのですが そのときのメモを貼り付けると
こんな感じだったみたいです。 # 全然覚えておらんので参考程度に。確か、kpartxで検索すると色々情報が見つかったはずです。 # あと、e2fsckを強制実行したらディスクイメージが壊れたと思いますので注意 | ||||
|
投稿日時: 2009-02-05 17:39
アドバイスありがとうございます。
いただいたアドバイスで以下の作業をしてみました。 ・使用されていない最初の loop デバイスを見つける。 # /sbin/losetup -f /dev/loop0 ・loop デバイスにファイルイメージをマウントする # /sbin/losetup /dev/loop0 sdb5.img （特に返答なし） ・LVMディスクイメージを認識させるようにする # /sbin/kpartx -a /dev/loop0 （特に返答なし） ・Volume Group を検索する # /sbin/vgscan Reading all physical volumes. This may take a while... Incorrect metadata area header checksum Found duplicate PV AyZpUvpjyZf6fct5pXk6p847gua6PfYA: using /dev/sdb5 not /dev/loop0 Incorrect metadata area header checksum Found volume group "volold" using metadata type lvm2 Found volume group "VolGroup_ID_16178" using metadata type lvm2 ・lvm lvscanの実行 # /sbin/lvm lvscan Incorrect metadata area header checksum Found duplicate PV AyZpUvpjyZf6fct5pXk6p847gua6PfYA: using /dev/sdb5 not /dev/loop0 Incorrect metadata area header checksum ACTIVE '/dev/VolGroup_ID_16178/LogVol1' [4.00 GB] inherit ACTIVE '/dev/VolGroup_ID_16178/LogVol2' [4.00 GB] inherit ACTIVE '/dev/VolGroup_ID_16178/LogVol5' [153.75 GB] inherit ACTIVE '/dev/VolGroup_ID_16178/LogVol4' [178.84 GB] inherit ACTIVE '/dev/VolGroup_ID_16178/LogVol0' [2.00 GB] inherit ACTIVE '/dev/VolGroup_ID_16178/LogVolHome' [117.19 GB] inherit PV（物理ボリューム）が重複しているといメッセージがありました。 これはddでコピーしたsdb5.imgと、コピー元の/dev/sdb5が重複、ということでしょうか？ 検索し、下記のコマンドを実行しました。 # /usr/sbin/vgdisplay Incorrect metadata area header checksum Found duplicate PV AyZpUvpjyZf6fct5pXk6p847gua6PfYA: using /dev/sdb5 not /dev/loop0 Incorrect metadata area header checksum --- Volume group --- VG Name volold System ID Format lvm2 Metadata Areas 2 Metadata Sequence No 2 VG Access read/write VG Status resizable MAX LV 256 Cur LV 0 Open LV 0 Max PV 256 Cur PV 2 Act PV 2 VG Size 8.08 GB PE Size 4.00 MB Total PE 2068 Alloc PE / Size 0 / 0 Free PE / Size 2068 / 8.08 GB VG UUID s729bP-7Ppm-LkLy-kpL3-0Xqv-b83s-3aJyEg --- Volume group --- VG Name VolGroup_ID_16178 System ID Format lvm2 Metadata Areas 2 Metadata Sequence No 8 VG Access read/write VG Status resizable MAX LV 0 Cur LV 6 Open LV 6 Max PV 0 Cur PV 2 Act PV 2 VG Size 465.53 GB PE Size 32.00 MB Total PE 14897 Alloc PE / Size 14713 / 459.78 GB Free PE / Size 184 / 5.75 GB VG UUID 8E9Q2j-1XKc-5nLt-kRZv-2m92-2uPm-ME8wp8 /dev/sdbを物理的にはずして、再度作業したほうがよいでしょうか？ 実際にやってみると良いのでしょうが、いろいろ作業しているので、再起動しなくなった場合が怖くて、先にお聞きしました。 よくfstabに不正なマウント情報があると再起動しなかったりしますが、LVMでも同様でしょうか？ | ||||
|
投稿日時: 2009-02-05 18:48
冬寂がのおっしゃる通り作業対象はイメージファイルが望ましいのですよね。 vgscanで目当ての(junさんが設定した)ボリュームグループが見つかったので 突っ走ってしまいました、すいません。 イメージファイルをマウントして duplicateがでましたので、 /dev/sdb5とsdb5.img で重複してると思われます。 /dev/sdb5はバックアップの時にマウントしました？ 再起動に関しては、実物を見てみないとなんとも言えません （大丈夫だとは思うのですが、迂闊なことは言えないというか・・・） | ||||
|
投稿日時: 2009-02-05 19:47
早速のご返答ありがとうございます！
/dev/sdb5はマウントしていないというか、マウントできないんです。 ということは、重複しているのは違う何かということなんでしょうか？ 新しいPCをDELLに発注したので、それが到着したら再起動も怖くないのですが、社内サーバに使っているもので、実務がとまらないようにあまりへたなことができません。 10人以下の小さい会社ですので予備のマシンなどを用意していないんです（とほほな感じですね）。 新しいPCが届くまで2週間もあるので、休日出勤して再起動しようかと思っているのですが、事前にできることがあればと。 > ACTIVEでない場合、lvm vgchange のayオプションかlvm lvchange のayオプションでアクティブにしてあげればマウントできるのではないかと。 上記が理解できていなかったのですが、現状はこちらをちょっと調べております。 | ||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。