- PR -

LVMハードディスクの復旧について

«前のページへ 1|2
投稿者投稿内容
jun
会議室デビュー日: 2009/02/05
投稿数: 7
投稿日時: 2009-02-05 20:09
pvscanを試してみました。

# /sbin/pvscan
Incorrect metadata area header checksum
Found duplicate PV AyZpUvpjyZf6fct5pXk6p847gua6PfYA: using /dev/sdb5 not /dev/loop0
Incorrect metadata area header checksum
Incorrect metadata area header checksum
Incorrect metadata area header checksum
PV /dev/sdb1 VG volold lvm2 [76.00 MB / 76.00 MB free]
PV /dev/sdb2 VG volold lvm2 [8.00 GB / 8.00 GB free]
PV /dev/sda3 VG VolGroup_ID_16178 lvm2 [348.34 GB / 5.75 GB free]
PV /dev/sda1 VG VolGroup_ID_16178 lvm2 [117.19 GB / 0 free]
PV /dev/sdb5 lvm2 [66.23 GB]
Total: 5 [539.84 GB] / in use: 4 [473.61 GB] / in no VG: 1 [66.23 GB]

次はvololdに対して何らかのコマンドを発行して、マウントできないものか試してみます。

デューン
大ベテラン
会議室デビュー日: 2004/04/21
投稿数: 174
お住まい・勤務地: Tokyo
投稿日時: 2009-02-05 20:58
ボリュームグループの重複にマウントは関係なかったですね、すいません

LVMを初期構築する時の流れをざっくりと言えば
物理ボリューム(pv)を作成し、
pv配下にボリュームグループ(vg)を作成し、
vg配下に論理ボリューム(lv)を作成し、
論理ボリュームをマウントする。
だったと思います（はっきりでなくてすいません）。



（イメージからのマウントが実現できなく申し訳ないのですが）
/dev/sdb5のマウントをためしてもいいのであれば、
/dev/loop0をアンマウントし、
lvm vgscanで重複していないことを確認、

lvm lvscanを行い
ACTIVE '/dev/volold/xxxx' 〜〜
とでたなら
mount /dev/volold/xxxx [マウントポイント]
などでマウントしてみる。


でどうでしょうか。
# よくみたら重複はpvですね。イメージだから当り前か。



jun
会議室デビュー日: 2009/02/05
投稿数: 7
投稿日時: 2009-02-05 22:22
早速のご返答ありがとうございます！

アンマウントを試してみましたが、下記のようなエラーとなりました。

# /bin/umount /dev/loop0
umount: /dev/loop0: not mounted

lvscanの結果は下記のとおりです。

# /usr/sbin/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

調べてみたところ、デフォルトで付けられるVolGroup00という名称が、現在使っているシステムのVG名と当っている可能性がありそうです。これを回避するにはCDROMなどで起動して、名称を変更してみるのがよいのかなと考えています。どちらにしても、再起動が必要なんですが・・。

pvscanで調べると、/dev/sdb5はVGに到達しておらず、きっと名称が問題なんだろうなと思っています。

# /sbin/pvscan
Incorrect metadata area header checksum
Found duplicate PV AyZpUvpjyZf6fct5pXk6p847gua6PfYA: using /dev/sdb5 not /dev/loop0
Incorrect metadata area header checksum
Incorrect metadata area header checksum
Incorrect metadata area header checksum
PV /dev/sdb1 VG volold lvm2 [76.00 MB / 76.00 MB free]
PV /dev/sdb2 VG volold lvm2 [8.00 GB / 8.00 GB free]
PV /dev/sda3 VG VolGroup_ID_16178 lvm2 [348.34 GB / 5.75 GB free]
PV /dev/sda1 VG VolGroup_ID_16178 lvm2 [117.19 GB / 0 free]
PV /dev/sdb5 lvm2 [66.23 GB]
Total: 5 [539.84 GB] / in use: 4 [473.61 GB] / in no VG: 1 [66.23 GB]

/dev/sdb5は以前使えていたので、LVは作成されているはずで、名称が当たらなければマウントできる可能性があるのかなとにらんでいるのですが、考え方としては間違えていないでしょうか？

LVMは便利なのかもしれませんが、本業の片手間でサーバ管理していたものにはちょっと敷居が高いですね。BINDのchrootにも驚かされましたが・・・。

デューン
大ベテラン
会議室デビュー日: 2004/04/21
投稿数: 174
お住まい・勤務地: Tokyo
投稿日時: 2009-02-06 00:27
携帯からなのであまり書けませんが、
イメージをマウントする前は重複エラーはでてませんから、デフォルトのvg名との重複は関係ないと思われます

アンマウントできない理由はわかりませんが(イメージをマウントしたことないので)イメージとsdbとで物理IDみたいなものがバッティングしてるのが現状のはずです

再起動可能＆同時に認識させたいのであればイメージをマウントしない段階か、ハードディスクをはずした状態でpv名を変更する必要があります
冬寂
ぬし
会議室デビュー日: 2002/09/17
投稿数: 449
投稿日時: 2009-02-06 09:56
参考になるかわかりませんが、時間がないので、ちょっと見つけたリンクだけ
http://d.hatena.ne.jp/gunshot/20080604/p1

# どうも、かなり記憶が曖昧で間違えていたみたいなのですみません
jun
会議室デビュー日: 2009/02/05
投稿数: 7
投稿日時: 2009-02-06 11:27
ありがとうございます！
アドバイスにあるように、やはりハードディスクははずしてイメージだけで試してみようと思います。

下記URL、とても参考になりました！

http://d.hatena.ne.jp/gunshot/20080604/p1

マウントまでの一連のコマンドが少し把握できてきたので、もう一度チャレンジしてみます（何かあっても明日は休日なので業務に支障きたさないですし）。
原因がわかれば、もしくはダメだったらまた投稿させていただきます。
«前のページへ 1|2

スキルアップ／キャリアアップ（JOB@IT）