web-dev-qa-db-ja.com

削除されたLVM論理ボリュームからext4ファイルシステムを回復する方法はありますか？

先日、VmwareでLinuxゲストのディスクを拡張しているときに、適切な脳のおならの瞬間がありました。 Vmwareディスクファイルを目的のサイズに拡大してから、Linuxゲストで通常行うことを実行しましたLVMなし：LVMパーティションを削除して再作成しました、古いものと同じ場所から開始しますが、ディスクの新しいサイズに拡張します。 （その後にfsckとresize2fsが続きます。）

そして、LVMがrawパーティションでext2/3/4と同じように動作しないことに気づきました...最新のバックアップからLinuxゲストを復元した後（幸運なことに、わずか5時間前に取得）、私は今興味があります次のシナリオからどのように回復できたか。結局のところ、私が将来もばかげたお尻になることは事実上保証されています。

256MBの1つの/ boot（プライマリ）パーティション（/ dev/sda1）にパーティション分割され、残りは論理的な拡張パーティション（/ dev/sda5）にパーティション化された1つのディスクを持つ仮想Linuxゲスト。

次に、/ dev/sda5は、pvcreateを使用して物理ボリュームとしてセットアップされ、その上に通常のvgcreateコマンドを使用して1つのボリュームグループ（vgroup00）が作成されます。次に、vgroup00は、論理的に/とスワップに使用される2つの論理ボリュームrootとswapに分割されます。 /はext4ファイルシステムです。

壊れたゲストのバックアップがあったので、/ etc/lvm/backupの下にあるバックアップLVMセットアップからvgcfgrestoreを使用して、物理ボリュームなどに同じUUIDを使用してボリュームグループを再作成できました。これを実行した後、以前と同じサイズの2つの論理ボリュームがあり、ディスクを拡張した場所に4GBの空き領域がありました。

しかし、「fsck/dev/mapper/vgroup00-root」を実行しようとすると、スーパーブロックが壊れていると文句を言いました。 「mke2fs-n/dev/mapper/vgroup00-root」を実行してバックアップスーパーブロックを見つけようとしましたが、いずれも機能しませんでした。次に、 TestDisk を実行しようとしましたが、スーパーブロックを見つけるように要求すると、ファイルシステムが壊れているためにファイルシステムを開くことができないというエラーが表示されました。

したがって、Ubuntu Server 10.04 64ビットのLVM2のデフォルトの割り当てポリシーでは、論理ボリュームがボリュームのendから割り当てられる可能性があります。グループ？これは、復元された論理ボリュームに期待されるデータが含まれていなかった理由を明確に説明します。以前とまったく同じサイズとディスク位置で/ dev/sda5を再作成することで、回復できたでしょうか。ファイルシステムを見つけて回復するために使用できた他のツールはありますか？ （そして明らかに、問題は私が最初から別の方法でこれを行うべきだったかどうかではありません、私はそれを知っています。これはたわごとがすでにファンを襲ったときにどうするかについての質問です。）

linuxlvmdata-recoveryext4
4
Vegar Nilsen

デフォルトでは、LVMで操作を実行するたびに、以前のメタデータが_/etc/lvm/archive_にアーカイブされます。 vgcfgrestoreを使用して復元するか、手作業で拡張を取得できます（難しいですが、lvcreate(8)でカバーする必要があります）。

編集：

そして、できるだけ簡単にするために、説明を見て、破壊的な操作の前に最後のバックアップを見つけることができることを追加する必要があります。

_# grep description /etc/lvm/archive/vg01_*
/etc/lvm/archive/vg01_00001.vg:description = "Created before executing 'lvremove -f /dev/vg01/foo'"
/etc/lvm/archive/vg01_00002.vg:description = "Created before executing 'lvremove -f /dev/vg01/bar'"
/etc/lvm/archive/vg01_00003.vg:description = "Created before executing 'lvremove -f /dev/vg01/baz'"
_

編集：

normal割り当てポリシー（デフォルトは1）は、十分なスペースがある場合に、最初の空きPEからストライプを割り当てます。 LVが割り当てられた場所を確認したい場合は、アーカイブファイルを調べることができます。これらのファイルは、人間が完全に読み取ることができます。

3
Pierre Carrier

本当に良い回復オプションはありませんし、私の知る限りこれをサポートするツールもありません。ただし、手動リカバリに関するいくつかの記事については、 LVMの危険性と警告 のデータリカバリのセクションを参照してください。

一般に、壊れたボリュームまたは基盤となるディスクのrawイメージバックアップを実行し、バックアップバージョンでデータ回復を実行して、回復を再試行する方法を用意するのが最善です。

上記の回答には、LVMボリュームのサイズ変更に関するセクションもあります。ボリュームを拡張することはかなり安全です。通常、削除して再作成するのではなく、lvresizeを使用することをお勧めします。

関連する点：VMwareを使用しているため、ハードディスクの書き込みキャッシュフラッシュ（書き込みバリア）がゲストLinuxカーネルからハイパーバイザーおよびホストOSを介して正しく伝播することにも注意する必要があります。ゲストFSおよびゲストカーネル（2.6.33以上）に書き込みバリアを設定することも重要です。

0
RichVel