web-dev-qa-db-ja.com

クイックフォーマット後にext4ファイルシステムを回復

ドライブの1つを誤ってフォーマットしましたが、クイックフォーマットを行っただけで、ファイルシステムの大部分を回復できることを望んでいます。

2台目の同一のハードドライブをインストールした後、Ubuntuの（14.04）Disks-Applicationを介して誤って誤ったドライブを誤ってフォーマットしました。ドライブは以前はext4フォーマットでしたが、再びext4のクイックフォーマットを行いました。ドライブには単一のパーティションしかありませんでした。損傷が発生してからわずか数秒で、偶発的な書き込みを避けるためにドライブをアンマウントしました。

私が後にいるファイルはバイナリ形式です（.npy.t7.matなど、私が知っている限り拡張子はありません）、いくつかは.txtファイルです。

フォーラムやブログを読んで、Testdisk + Photorecが失われたパーティションの回復に役立つ可能性があることを理解しました。 Photorecを試してみましたが、重要なファイルのほとんどはバイナリであり、ファイルの署名がないため、数千の無用な.txtファイルと読み取り不可能な.matファイルがありました。一方、テストディスクは、私が理解している限り、決定的なプロンプトを表示しません。情報がドライブの一番最初にあると予想されるため（ドライブは8TB）、ディープスキャンをまだ実行しようとしませんでした。詳細については、次のTestdiskスナップショットを参照してください。

パーティション選択画面

パーティションタイプとして[なし]を選択した後の詳細メニュー

  • パーティションタイプとしてEFI-GPTまたはIntelを選択すると、使用可能なパーティションがないことを示すTestdiskが表示されます。

ドライブの分析（なしタイプを選択した後）では、パーティションが空になります（空のlost + foundを除く）。対照的に、GPTタイプを選択した後にドライブを分析すると、このタイプの多くの同一エントリが生成されます。ext40 0 1 972801 80 63 156280533168

スーパーブロック：

superblock 0, blocksize=4096
superblock 32768, blocksize=4096
superblock 98304, blocksize=4096
superblock 163840, blocksize=4096
superblock 229376, blocksize=4096
superblock 294912, blocksize=4096
superblock 819200, blocksize=4096
superblock 884736, blocksize=4096
superblock 1605632, blocksize=4096
superblock 2654208, blocksize=4096

質問

  1. クイックフォーマットを選択するとき、Ubuntuはドライブに対して具体的に何をしますか？そのことから、ファイルシステムをまったく（または）回復できるかどうかを推測できますか？

  2. スーパーブロックを使用して構造の一部を回復できますか？バックアップスーパーブロックが1024の位置に書き込まれていることをどこかで読んだことがあります。それは回復可能ですか、またはクイックフォーマットでもクリアされていますか？

  3. PhotorecやScalpelなどのファイルリカバリ以外のオプションは、ファイルシステムをリカバリするために残っていますか？回復したい最も重要なファイルの完全なパスを知っています。

hard-drivefilesystemdata-recoveryformat
4
Max

バックアップスーパーブロックを使用して、すべてのファイルを正常に回復できました！ TestDiskが私を助けられなかった後、関連する question からアプローチを試みました。わかりやすくするために、ここでファイル構造を回復するための手順を示します。

  1. ドライブがアンマウントされていることを確認してください。

  2. 経由でバックアップスーパーブロックを見つける

    dumpe2fs /dev/<drive-id> | grep -i superblock

    例えばdumpe2fs /dev/sdb | grep -i superblock

  3. スーパーブロックの1つに基づいてファイルシステムをチェックしますが、この特定のスーパーブロックが構造的に完全であるかどうかを確認するために、まだ変更を適用しません。

    fsck.ext4 -v -n -C 0 -b <Superblock> /dev/<drive-id>

    例えばfsck.ext4 -v -n -C 0 -b 2654208 /dev/sdb

    -vはコマンドを詳細に表示し、-nは各プロンプトに対して常に「no」と応答することによりファイルシステムを修正しようとしないことを確認し、-C 0は進行状況バーを表示し、 -bは、前のステップで指定されたスーパーブロックの開始位置を定義します。

  4. 適切なスーパーブロックが見つかった場合は、fsck.ext4を-nに置き換えてすべての修正を自動的に受け入れることにより、-yでファイルシステムを修正します。

    fsck.ext4 -v -y -C 0 -b <Superblock> /dev/<drive-id>

  5. ドライブを再起動してマウントします。

私の場合、ディレクトリ名の最初のレベルは回復できませんでした。したがって、それらはすべて、隠されているlost+foundディレクトリ内のinode名に基づいて見つけることができます。

2
Max