破損したLVMリカバリ
HyperVクラスターからVmware変換ツールを使用して移行されたCentos6.7ホストがありました（ここでは過去の時間に注意してください）。したがって、そのディスクの最終的な構成は次のとおりです。
/ dev / sda1 -> BOOT
/ dev / sdb1 -> Physical Volume
VG on / dev / sdb1
6 LVs on VG, root included
時が来て、論理ボリュームがいっぱいになり、VGには拡張できる空きPEがありませんでした。そこで、忍者を動かして/dev/sdbを拡張し、（間違って）パーティションテーブルを書き直してPVを拡張しました。その後、LVMメタデータが上書きされたため、VMは再起動しませんでした。
私はいくつかのシナリオを試しましたが、最も成功したのはstrings / dev / sdb | head -n 1000で、LVM情報のコピーを見つけ（自動バックアップから各変更まで）、最新の構成と思われるものからファイルを作成し、PVを作成しました。 uuidは元のファイルと同じで、指定されたファイルは--restorefileです。 vgcfgrestoreとvgchange -ayを続行すると、すべての論理ボリュームが表示されましたが、マウントが失敗し、bad superblock or wrong fs typeエラーが発生します。私はLVの境界が正しくなく、古い構造と重複していると感じているため、マウント中のファイルシステムに問題があります。
そのようなものを見た人はいますか？誰かが解決策を提案できますか？
ホスト構成とデータのバックアップがある場合は、OSを再インストールして復元する方が高速です。
ddなどを使用して、LVのバックアップイメージを通常のファイル、またはおそらくLVMスナップショットに作成します。 xfs_repair -f /backup/lvなどのファイルシステム修復ツールをバックアップで実行します。これは、回復可能なファイルシステムがあるかどうかを示すのに役立ちます。
編集：あなたはext4を示しました。 UNIX Stack Exchangeで説明されているように、すべてのスーパーブロックを試してください： ext4スーパーブロックの回復 。リンクされた buntu wikiのデータ復旧ページ には、バックアップのないファイルが本当に必要な場合に、いくつかのファイル抽出ユーティリティがあります。
個人的には、/dev/sdbなどのパーティションテーブルなしでディスク全体にPVを作成することを好みます。サイズ変更されたディスクはすぐに追加できます。