web-dev-qa-db-ja.com

Debian Lenny-SAN-LVMが失敗する

'datavg'という名前のVGの唯一のPVとして構成されたSAN接続を持つLennyサーバーがあります。

昨日、Debianパッチでボックスを更新し、再起動しました。

再起動後、/ dev/mapper/datavg-datalvが見つからないと言って起動しませんでした。

これは私がしたことです：
-レスキューモードで起動し、/ etc/fstabのマウントにコメントしました
-フルユーザーモードで再起動しました。 （マウントポイントは/ dataであり、postgresqlのみを開始できませんでした）
-ボリュームグループに何が起こったかを調べるために、vgdisplay、lvdisplay、pvdisplayを実行しました。 （datavgが完全に欠落していました）

その後、LinuxからLUNが表示され、LVMパーティションも表示されることに気付きました。

# ls -la /dev/mapper/mpath0*
brw-rw---- 1 root disk 254, 6 2009-11-23 15:48 /dev/mapper/mpath0
brw-rw---- 1 root disk 254, 7 2009-11-23 15:48 /dev/mapper/mpath0-part1


-次に、PVを見つけることができるかどうかを調べるためにpvscanを試しました。残念ながら、パーティションをPVとして検出しませんでした。
-パーティションでpvckを実行しましたが、ラベルが見つかりませんでした。

# pvck /dev/mapper/mpath0-part1 
  Could not find LVM label on /dev/mapper/mpath0-part1


-次に、LUNがおそらく空かどうか疑問に思っていたので、最初の数MBのddを作成しました。これで、LVMヘッダーを見ることができました：

datavg {
id = "removed-hwEK-Pt9k-Kw4F7e"
seqno = 2
status = ["RESIZEABLE", "READ", "WRITE"]
extent_size = 8192
max_lv = 0
max_pv = 0

physical_volumes {

pv0 {
id = "removed-AfF1-2hHn-TslAdx"
device = "/dev/dm-7"

status = ["ALLOCATABLE"]
dev_size = 209712382
pe_start = 384
pe_count = 25599
}
}

logical_volumes {

datalv {
id = "removed-yUMd-RIHG-KWMP63"
status = ["READ", "WRITE", "VISIBLE"]
segment_count = 1

segment1 {
start_extent = 0
extent_count = 5120

type = "striped"
stripe_count = 1        # linear

stripes = [
"pv0", 0
]
}
}
}
}

これは、pvckがLVMラベルを見つけられなかったパーティションから来ていることに注意してください！


-パーティションに新しいLVMラベルを書き込み、バックアップファイルからパラメーターを復元することにしました。

pvcreate --uuid removed-AfF1-2hHn-TslAdx --restorefile /etc/lvm/backup/datavg  /dev/mapper/mpath0-part1


-次に、vgcfgrestore -f/etc/lvm/backup/datavgdatavgを実行しました
-その後、pvscanを発行すると表示されます。
-vgchange-ay datavgを使用して、VGをアクティブにすると、LVが使用可能になりました。
-LVをマウントしようとすると、ファイルシステムが見つかりませんでした。いくつかの方法で回復を試みましたが、成功しませんでした。
-影響を受けたLVのDDを作成した後、次の方法でスーパーブロックを再作成しようとしました

mkfs.ext3 -S /dev/datavg/backupdatalv


-しかし、この結果はマウントできません：

# mount /dev/datavg/backupdatalv /mnt/
mount: Stale NFS file handle

そもそもこれが起こり得るという事実は、控えめに言ってもあまりいいことではないので、この誤動作について私ができるすべてのことを知りたいと思います。

私の質問：
-パッチと再起動後にLVMラベルが消えるのはどうしてですか？
-PVを回収した後、ファイルシステムが存在しないのはなぜですか？ （pvcreateコマンドはデータを破棄しましたか？）
-LV内のext3ファイルシステムはまだ回収可能ですか？
-この問題を防ぐために私ができることはありますか？

よろしくお願いします、Ger。

debiandisaster-recoveryext3data-recoverylvm
2
Ger Apeldoorn

私はかつて同様の問題に遭遇しました。私たちの場合、誰かがPVを保持するためのパーティションを作成しましたが、pvcreateコマンドを実行すると、パーティションを指定するのを忘れ、代わりにデバイス全体を使用しました。 LVMがPVを検出できなくなった再起動まで、システムは正常に動作していました。

それで、あなたの場合、誰かが「pvcreate/dev/mapper/mpath0-part1」ではなく、作成時に「pvcreate/dev/mapper/mpath0」を実行した可能性はありますか？その場合は、PVを含むディスクからパーティションテーブルを削除する必要があります。

Pvcreate（8）のマニュアルページからパーティションテーブルを削除するには：

dd if =/dev/zero of = PhysicalVolume bs = 512 count = 1

デバイスにパーティションテーブルがある場合、カーネルのLVMコードはデバイスPV全体を認識しません。パーティションテーブルを削除すると、PVが認識され、データに再度アクセスできるようになりました。

4
Shane Meyers