Ext3ドライブは、停電後にマウントされません。ファイルを回復する方法は？
Linuxボックス（Ubuntu 8.10）の電源が通常の実行状態から2回急速にオフになった最近の電源障害の後、ドライブがマウントされません。
更新：ドライブはマウントされることがありますが、完全に空（Lost + Foundでもない）として表示され、14.9 GBの空き容量（500 GBドライブ）が表示されます。何かをしようとすると、アクセス許可エラーが発生し、ドライブがアンマウントされます。 （または、おそらく、そもそも実際にマウントされていませんでしたか？）
マウントしようとしたときのエラーメッセージは次のとおりです。
〜$ Sudo mount -a mount：間違ったfsタイプ、不正なオプション、/ dev/sdd1の不正なスーパーブロック、 コードページまたはヘルパープログラムの欠落、またはその他のエラー 場合によっては、syslogに役立つ情報があります-try dmesg |しっぽかそこら
それで、多分fsタイプを指定しますか？
〜$ Sudo mount -t ext3/dev/sdd1 /media/disk-7 mount：間違ったfsタイプ、不正なオプション、/ dev/sdd1の不正なスーパーブロック、 がありませんコードページまたはヘルパープログラム、またはその他のエラー 場合によっては、syslogに有用な情報があります-try dmesg |しっぽかそこら
いいえ、同じです。それで何かがめちゃくちゃですか？
〜$ Sudo fsck /dev/sdd1 fsck 1.41.3（12-Oct-2008） e2fsck 1.41.3（12-Oct-2008） /dev/sdd1：ジャーナルの回復 fsck.ext3：/ dev/sdd1 を再度開こうとしているときにそのようなファイルまたはディレクトリがありません...警告...デバイス/ dev/sdd1のfsck.ext3がシグナル11で終了しました。
信号11をグーグルで検索することは推奨されませんでしたが、ディスクを修復する他の方法をいくつか見つけました。
〜$ Sudo e2fsck /dev/sdd1 e2fsck 1.41.3（12-Oct-2008） /dev/sdd1：ジャーナルの回復 e2fsck：試行中にそのようなファイルまたはディレクトリはありません/dev/sdd1 スーパーブロックを読み取ることができなかったか、正しいext2 ファイルシステムを記述していません。デバイスが有効で、実際にext2 ファイルシステムが含まれている場合（スワップやufsなどは含まれていません）、スーパーブロック が破損しているため、別のスーパーブロックでe2fsckを実行してみてください。 e2fsck -b 8193 [デバイス]
それでもこの障害が停電と関係があることを期待して、スーパーブロックが破損しているか何かを想定し、別のことを試してください:(最初にmakefs -nを使用してブロックサイズが32kであることを確認します）
〜$ Sudo e2fsck -b 32768 /dev/sdd1 e2fsck 1.41.3（12-Oct-2008） ext3リカバリフラグはクリアされていますが、ジャーナルにはデータがあります。 リカバリフラグバックアップスーパーブロックに設定されていないため、とにかくジャーナルを実行します。 /dev/sdd1：ジャーナルの回復 e2fsck：/ dev /の ext3ジャーナルの回復中はジャーナルが1024ブロック以上である必要があります。 sdd1
以下のAveryPayneによると、私は次のことを試しました。
Sudo mount -t ext2 -o ro/dev/sdd1/media/disk-7
しかし、このエラーメッセージが表示されます：
マウント：間違ったfsタイプ、不正なオプション、/ dev/sdd1の不正なスーパーブロック、 コードページまたはヘルパープログラムの欠落、またはその他のエラー 場合によってはsyslogに有用な情報が見つかります-try dmesg |しっぽかそこら 〜$ dmesg | tail [261157.639721] EXT2-fs：sdd1：サポートされていないオプション機能のためにマウントできませんでした（4）。
そして、それは私が立ち往生しているところです。リストされているすべてのバックアップスーパーブロックを試しましたが、同じ結果が得られました。それが役に立った場合、「ジャーナルの回復」ステップは、それが機能していないことを通知するまでに長い時間がかかります。
正直なところ、クラッシュの数分前にドライブの状態を取り戻すことはあまり気にせず、ドライブにある400GB以上の他のデータを回復するだけです。誰かが私が試すことができる他の何か、ext3データ復旧ユーティリティまたはテクニックなどを知っているなら、私はそれを大いに感謝します！
あなたが抱えている問題は、デバイスの単なる電力損失（かなり重い書き込みアクティビティの間でも）から私が予想するよりもはるかに広範囲に聞こえます。インターフェイス/ドライバレベルで本当に問題が発生しているのか、パーティションテーブルが破損しているのか、そのような問題が発生しているのか、疑問に思う必要があります。
物事の音から、問題を修正しようとしている間に行ったすべてのスラッシングで問題をさらに悪化させた可能性があります。
この事件を手伝うことができるかどうかはわかりませんが、まだあきらめていません。
将来的には、次のテクニックを学ぶことをお勧めします。
LinuxまたはUNIXでドライブに問題が発生した場合は、通常、ddを使用して、デバイス全体のビットイメージコピーを他の場所に作成できます。少なくとも問題のドライブと同じ大きさのドライブを見つけて、次のようなコマンドを試してください。dd if=$PROBLEMATIC of=$TARGET bs=4M ... if（入力ファイル）およびof（出力ファイル）ディレクティブには十分注意してください。その実行を残します。 tail -f /var/log/messages &（または/etc/syslog.confに応じて可能なバリアント）を実行することをお勧めします...バックグラウンドまたは別のウィンドウで実行します。 ddの拡張バージョンがあり、再試行と不良ブロックの通過をより堅牢に処理できます（sddは頭に浮かぶ名前です）。ただし、最初はstock GNU ddコマンドを使用してみてください。
このようなデバイス全体のコピー（たとえば、/ dev/sdd）またはパーティションのみ（/ dev/sdd1）を作成できます。 「短い読み取りまたは同様のエラーが発生した場合は、デバイスに特定のシリンダーを通過する読み取りを妨げる物理エラーがあるか、パーティションの場合はパーティションテーブルが何らかの方法でマングルされていることを示しています。2つの異なるddを作成することもできます。画像...それぞれ1つ。
秘訣は次のとおりです。fsckとmountをすべて試行し、コピーしたイメージでTCT（The Coroner's Toolkit）などの他のさまざまな回復ツールを使用してください。
これにより、ドライブの実行に費やされる時間が最小限に抑えられ（操作時にハードウェアレベルで低下する可能性があります）、失敗した、場合によっては誤ったリカバリ試行の影響が最小限に抑えられます。 （状況によっては、1つの画像を作成し、それに基づいて別の画像を作成し、常に3次画像を操作します...データの価値によって異なります）。
個人的には、hexdumpやstringsのようなものを実行して画像を読み取ることをお勧めします...長い間スクロールして、データの断片のように見えるプレーンテキストを探してください。私はgrepを使用して、他の方法では完全に壊れたファイルシステムから有用な（テキスト）データを回復しました。データ復旧の英雄としてではなく、サニティチェックとして提案している場合に備えて。数十メガバイトまたは数ギガバイトのデータをスクロールしても、認識できるテキストが表示されない場合は、おそらく絶望的なケースがあるか、何か非常に間違ったことをしています（あなたは本当にこれらのif =およびof =オプションに注意してください？）。
これらのいずれかが現在の取り組みに役立つかどうかはわかりません。しかし、これらのトリックを今すぐ学んでください。そうすれば、データ復旧への次の進出は間違いなくそれほど怖くなくなります。 （はい、正常なシステムで1〜2回練習してください--- 16進エディターを使用して、独自のクリエイティブな破損をあちこちで追加してみてください---もちろんCOPYに追加してみてください！それから修正してみてください）。
ああ、これはバックアップとデータ復旧の計画と手順を確認する（または顧客/同僚/クライアント/友人/その他にもっと良いアドバイスを提供する）のに本当に良い時期です。
あなたが私の過ちから学ぶことを願うことを除いて、私は提供するものがあまりありません。やめる！ディスクの複製を作成します。 ddはこれを行うのに役立ち、優れたユーザーインターフェイスを提供するドライブイメージングアプリケーションがたくさんあります。最初にディスクを複製せずに、fsckを掘り下げたり、バックアップスーパーブロックを探したりするのを間違えました。私は絶対にすべてを失いました。すでにバックアップなしを選択したようですが、意図的な復元を試みてドライブをさらに破壊する前に、ドライブのコピーを取得するのに遅すぎることはありません。
私は偶然出くわしました この記事 同様の状況での回復について。別のスーパーブロックを使用するようにマウントに指示できるようです。 -t ext3と組み合わせると、小さな希望が生まれる可能性があります。
Backtrack は、このようなツールのホストがパッケージ化されたLinuxディストリビューションです。ただし、これはパワーユーザーの上層部を真っ向から狙っています。彼らのウェブサイトには彼らのツールを使用するためのいくつかの良いチュートリアルがあるかもしれません、それはあなたに役立つかもしれません。
/ dev/sdd1が本当に探しているドライブであり、他のドライブではないことを確認しますか？デバイスの名前は、ドライブが接続されている順序によって異なります。たとえば、後でUSBドライブを接続する場合と、起動時に接続する場合では異なる場合があります。使用する /dev/disk/by-id/正しいディスクに触れていることを確認してください。
次のステップは、ディスク全体またはパーティションのみがトーストであるかどうかを判断して、その起動を行うことです。
cfdisk /dev/sdd
または、選択した別のパーティションツールを使用して、パーティションがまだ適切な場所にあるかどうか、および期待どおりにあるかどうかを確認します。パーティションテーブルがトーストの場合は、gpartを試してそれらを回復するか、レイアウトを覚えていれば最初から再作成できます。
dmesgは疑わしいものを出力していますか？死にかけているハードドライブでは、ほとんどの場合、大量のエラーメッセージが表示されます。
そして、他の人が述べているように、パーティションテーブルなどを変更する前にデータをコピーしてください。
起動中にlivecdで起動できる場合は、スワップを使用せず、その/dev/sdaをマウントして、USB HDDを使用している場合、またはネットワーク経由でそこからすべてのデータをコピーできます。次に、システムを再起動して再フォーマットし、データをダンプバックできます。
ドライブでLVM2を使用している場合は、ボリュームを修復する前にLVM2を実行する必要があります。最初にこれを試して、ボリュームが存在するかどうかを確認してください。
Sudo pvscan && Sudo vgscan && Sudo lvscan
見つかったボリュームは、/dev/sdd1のような直接参照ではなく、マウントするデバイスになります。
ドライブでLVMを使用していない場合は、下位互換性があるため、いつでもドライブをExt * 3 *ではなくExt * 2 *として再マウントすることができます。 これにより、ファイルシステムのマイナーな破損のウィンドウが開きますが（ジャーナルが再生されないため）、ファイルシステムが「クリーン」であることをすでに示しているため、残りのデータにアクセスできます。ビットはすでに設定されています。ボリュームを再マウントする場合は、ファイルシステムタイプを直接指定する必要があります。
Sudo mount -t ext2 /dev/sdd1 /media/disk-7 && ls /media/disk-7
そこから、データを回復できます。データを回復した後、既存のExt3ファイルシステムを正常な状態に戻すことができない場合は、データセット全体をバックアップし、ファイルシステムを再フォーマットして、復元します。もちろん、これは常にオプションであるとは限りませんが、少なくともデータを取り戻すことができます。
ファローアップ：
グーグルで簡単に検索すると、カーネルのバージョン管理に問題がある可能性があります。 カーネルをアップグレードしましたか、それともカスタムイメージをコンパイルしましたか？ちょっと興味があるんだけど。