web-dev-qa-db-ja.com

混乱したドライブ(Ext4の上に書かれたLVM)からデータを回復する方法は?

現在私の監督下にあるサーバーの前の管理者がミスを犯しました。彼は、実際にデータを含むExt4パーティションを含むディスク上に、誤ってLVMボリューム(pvcreateにすぎないと思いますが、確かではありません)を作成しました。このような間違いからデータを回復するにはどうすればよいですか? ext4のドキュメントを読んで自分でロールアウトする準備はできていますが、おそらく必要はありませんか?私が試したいくつかのツールでは、Ext4ファイルシステムを見つけることができなかったので、もっと深刻なものが必要だと思います。

5
Vilx-

mkfs.ext4 -n /the/partitionを実行すると、そのシステムでEXT4でフォーマットされたドライブがどのように表示されるかが出力されます。

# mkfs.ext4 -n /dev/dm-3
mke2fs 1.42.8 (20-Jun-2013)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
3276800 inodes, 13107200 blocks
655360 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
400 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks: 
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
    4096000, 7962624, 11239424

注目すべきは、スーパーブロックの場所がどこにあるかを教えてくれることです。

この情報を使用して、代替スーパーブロックを使用してドライブをマウントしてみてください。

mkdir /tmp/mntpnt
mount -o ro,sb=163840 /dev/dm-3 /tmp/mntpnt

パーティションのヘッダーのみを提供すると、このmayが機能する可能性があります。

ただし、それが機能しない場合は、スーパーブロックアドレスを指定して、fsck.ext4を使用してファイルシステムを修正してみてください。 これを行う前に、ddなどでデータをバックアップしてください

fsck.ext4 -b 163840 /dev/dm-3

このmayは、不良スーパーブロックを既知の良好なスーパーブロックの1つで上書きするだけで、ディスク全体を再マウントするのに十分である可能性があります。次に、mayがキーiノード(ルートファイルシステムiノードなど)を失う可能性があります。走行距離は異なる場合があります。

6
Matthew Ife

FS Explorerデモ 何を検出できるか試してみます...これはファイルシステム回復のための私の頼りになるユーティリティです。私はかつて400万のファイルが誤って削除されたXFSパーティションを持っていて、このユーティリティを使用してデータを回復しました。

しかし、それ以外では、それは学習体験であり、バックアップルーチンをテストするチャンスです。失くしてすみません。

3
ewwhite

リカバリ操作の最初のステップは、データのコピーを作成し、そのコピーに対してリカバリを実行することです。それが済んだら、データの回復を試みることができます。

管理者が行ったことに応じて、最も可能性の高い損傷は、パーティションテーブルが破損しているか、ボリュームのプライマリスーパーブロックが破損しているか、またはその両方です。 fdiskを使用してパーティションテーブルを再構築できます。元のパーティションテーブルと同じ設定で、新しいパーティションテーブルを作成するだけです。タイプ(MBRまたはGPT)が正しいことを確認してください。 e2fsck -bを使用すると、スーパーブロックのセカンダリコピーの1つを使用してファイルシステムの修復を実行できます。万が一、それらがすべて破損している場合は、mke2fs -Sは、データに触れることなくメタデータ構造を再作成します。

3
Mark