現在私の監督下にあるサーバーの前の管理者がミスを犯しました。彼は、実際にデータを含むExt4パーティションを含むディスク上に、誤ってLVMボリューム(pvcreateにすぎないと思いますが、確かではありません)を作成しました。このような間違いからデータを回復するにはどうすればよいですか? ext4のドキュメントを読んで自分でロールアウトする準備はできていますが、おそらく必要はありませんか?私が試したいくつかのツールでは、Ext4ファイルシステムを見つけることができなかったので、もっと深刻なものが必要だと思います。
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ノードなど)を失う可能性があります。走行距離は異なる場合があります。
FS Explorerデモ 何を検出できるか試してみます...これはファイルシステム回復のための私の頼りになるユーティリティです。私はかつて400万のファイルが誤って削除されたXFSパーティションを持っていて、このユーティリティを使用してデータを回復しました。
しかし、それ以外では、それは学習体験であり、バックアップルーチンをテストするチャンスです。失くしてすみません。
リカバリ操作の最初のステップは、データのコピーを作成し、そのコピーに対してリカバリを実行することです。それが済んだら、データの回復を試みることができます。
管理者が行ったことに応じて、最も可能性の高い損傷は、パーティションテーブルが破損しているか、ボリュームのプライマリスーパーブロックが破損しているか、またはその両方です。 fdisk
を使用してパーティションテーブルを再構築できます。元のパーティションテーブルと同じ設定で、新しいパーティションテーブルを作成するだけです。タイプ(MBRまたはGPT)が正しいことを確認してください。 e2fsck -b
を使用すると、スーパーブロックのセカンダリコピーの1つを使用してファイルシステムの修復を実行できます。万が一、それらがすべて破損している場合は、mke2fs -S
は、データに触れることなくメタデータ構造を再作成します。