回答:
LVMは、メタデータを/etc/lvm/backupとにバックアップし/etc/lvm/archiveます。各ファイルの上部には、ファイルが生成された時刻/データが表示されるため、LVを削除する前の古いメタデータのコピーが存在する可能性があります。メタデータが変更されると、バックアップは自動的に行われると思います。
以下は危険で破壊的な場合があるため、十分に注意し、可能であれば完全なバックアップを作成してください。
これらのボリュームグループのメタデータのバックアップを復元するコマンドはvgcfgrestoreです。vgcfgbackup/ etc / lvm / backupまたは/ etcにあるファイルを変更しないように、-fフラグを指定したコマンドを使用して出力に別のファイルを指定し、既存の作業構成の現在のコピーを作成してください。/ lvm / archiveフォルダー。現在の構成と復元したい構成を必ず比較して、適用しようとしている変更が、最近削除したLVの再作成のみであることを確認してください。データの完全バックアップを作成することも、おそらく悪い考えではありません。また、私がこれを自分でやる必要はなかったので、先に進む前にサポート契約を結んでいる場合は、サポート/ガイダンスについてLinuxベンダーに連絡することを検討してください。
幸運を。
「より具体的にバックアップファイルからEFROMとETOを見つけてください。すべてのlvのバックアップファイルに0からの「start_extend」があるため、少し迷います:)ありがとう！-user186975 13年8月24日17で：06 "
わかりました、私は非常に具体的です...論理ボリュームを回復する最も簡単な方法で。
例：
1-論理ボリュームを削除しました！
$ sudo lvremove /dev/vg1/debian.root
2-最初に行うことは、/ etc / lvm / archive / vg1_（xxxxx）.vgでアーカイブファイルを探すことです。論理ボリュームを削除した日付を見るだけで、それができます！
$ sudo ls -l /etc/lvm/archive |more
3-見つけた！
-rw------- 1 root root 16255 Mar 20 14:29 vg1_00223-235991429.vg
-rw------- 1 root root 16665 Mar 20 16:49 vg1_00224-748876387.vg
-rw------- 1 root root 17074 Mar 20 16:49 vg1_00225-931666169.vg
-rw------- 1 root root 17482 Mar 20 16:50 vg1_00226-1238302012.vg
-rw------- 1 root root 18081 **Mar 20 21:57 vg1_00227-2048533959.vg**
lvremoveを実行した日付!!! ...それは数分前でした。
4-ファイルを見てみましょう！
$ sudo head /etc/lvm/archive/vg1_00227-2048533959.vg
*# Generated by LVM2 version 2.02.95(2) (2012-03-06): Thu Mar 20 21:57:58 2014
contents = "Text Format Volume Group"
version = 1
description = **"Created *before* executing 'lvremove /dev/vg1/debian.root'"**
creation_host = "server" # Linux server 3.8.0-35-generic #50-Ubuntu SMP Tue Dec 3 01:24:59 UTC 2013 x86_64
creation_time = 1395363478 # Thu Mar 20 21:57:58 2014*
5-回復する前にテストを行います！
$ sudo vgcfgrestore vg1 --test -f /etc/lvm/archive/vg1_00227-2048533959.vg
Test mode: Metadata will NOT be updated and volumes will not be
(de)activated. **Restored volume group vg1**
6-わかりました、今（--test）なしでコマンドラインを繰り返します
$ sudo vgcfgrestore vg1 -f /etc/lvm/archive/vg1_00227-2048533959.vg
**Restored volume group vg1**
7-チェック！
$ sudo lvscan |grep debian
ACTIVE '/dev/vg1/debian.root' [7,81 GiB] inherit
8-論理がアクティブでなかった場合は、実行してください！
$ sudo lvchange -a y /dev/vg1/debian.root
すべてです
これが、このソリューションを探している他の人々に役立つことを願っています！
lvremoveから回復する最も簡単な方法は（LVが常駐していた範囲に書き込みを行わないと仮定した場合）です。
/ etc / lvm / archiveでメタデータのバックアップを見つけて把握するだけです
A）LVは（EFROM、ETO）に居住してエクステントた
あなたのLVが上に常駐し、それが（PFROM、PTO）を使用していたそのPVに拡張したPVS B）
この情報を入手したら、LVの最初の8kBを消去せずに、まったく同じPV拡張でまったく同じサイズの新しいLVを作成します。
lvcreate --extents EFROM-ETO --zero n --name customer007 YOUR-VG-NAME /dev/yourpv:PFROM-PTO
（前述のthermomanによると）削除されたLVMボリュームを簡単に再作成する方法は、ゼロ化せずに lvcreateで作成し、ディスク上の同じ位置にあることを確認することです。（サーモマンの答えからのコマンドは機能しませんでした。）
/ etc / lvm / archive内のファイルを読み取ることにより、削除前の論理ボリュームのサイズと位置を確認します。ボリュームのサイズはであるextent_countのsegment1（または合計segment*/extent_count、それはいくつかのエクステントを持っていた場合の値）。位置はstripes、物理ボリュームエイリアスの後のセクションpv0です（例：）。
たとえば、ボリュームセクションは次のようになります。
physical_volumes {
pv0 {
device = "/dev/somedisk" # Hint only
...
}
}
logical_volumes {
...
example {
...
segment_count = 1
segment1 {
start_extent = 0
extent_count = 1024 # 4 Gigabytes
type = "striped"
stripe_count = 1 # linear
stripes = [
"pv0", 30720
]
}
}
...
}
このexampleボリュームのサイズは1024で、エクステント30720から始まる/ dev / somediskにありました。
開始+サイズ-1 = 30720 + 1024-1 = 31743として最後のエクステントを計算します。そのボリュームの問題を再作成するには、次のようにします。
lvcreate --extents 1024 --zero n --name example vgname /dev/somedisk:30720-31743
同様の状況がありました。目的のLVを含むすべてのPVがありましたが、VGにPVがなく、LVがありませんでした。次の操作を行って回復しました。
pvsすべてのドライブの収集のUUIDに。physical_volumesセクション、設定device =/のUUIDにより報告された現在のデバイスと一致する行をpvs、明確な"MISSING"フラグを、任意の除去pvN実際欠落したセクション。logical_volumesセクション、上のストライプを持っていたすべての出品削除pvNもはや存在しないセクションを。それだった、それから私は走った
vgcfgrestore --test vg -f /root/dangerously_edited.vg
--testオプションなしで再実行しました。PV sdgおよびsdhを使用してVGを拡張することで、特定の状況を達成しました。次に/dev/sdg /dev/sdh、コマンドラインで指定して新しいLVを作成し、新しいLVがそれらのドライブにあることを確認しました。次に、それらのドライブだけを新しいマシンに移動しました。古いマシンは行方不明のドライブについて非常に怒っており、それらを強制的に削除すると、すべてのLVも削除されました。残念。
もちろん、次回は、この問題を回避するために新しいVGを作成します。