最近、HDDがクラッシュし、fsck
コマンドを実行する必要がありました。多くのファイルがlost+found
フォルダーに移動され、find
とgrep
を使用して重要なファイルを取得しましたが、SQLデータベースが見つかりません。
#1を試してください
多分それはまだそこにあります、その名前だけがf.eに変更されました。/lost + found /#3456254など。あなたの代わりに、私はfile -szL
のすべてに対して再帰的な/lost+found
を実行し、innodbをgrepしました。
find /lost+found -type f|xargs -P 1 -n 500 file -szL|grep -i innodb
Innodbデータベースがまだ存在する場合は、保存するデータがあります。幸運を!
#2を試してください:
データベースに大量のテキストデータがある場合は、セクターベースのヘキサ検索も役立ちます。
IS削除されたため、問題のファイルをfsckで再構築できなかった可能性があります。fsckプログラムは修復のみを試み、ファイルと同様にファイルの再構築を非常に困難に試みます。ただし、これはいかなる種類のバックアップでもありません。fsckによって実行されるアクションは、基本的に元に戻すことはできません。
データベースは1つのファイルに含まれていませんが、データベースの回復を期待するには「同期」している必要がある多くのファイルがあるため、lost + foundディレクトリに含まれるMySQLデータベースの一部を使用する場合は注意が必要です。あらゆるタイプの信頼性またはデータ整合性があるモード。
ファイルの回復に関しては、申し訳ありませんが、データが重要だったのでおそらく作成していたバックアップに戻る必要があります。そうでなければ、あなたは本当に運が悪いです。
データが非常に重要である場合、あなたは多くのデータ復旧サービスの1つの助けを求めることを試みることができるかもしれません。それは高価であり、結果は完璧ではありません。
あなたは運が悪いと思います。唯一のオプションは、lost+found
ディレクトリを調べて、各ファイルを視覚的に検査し、元のIDに関する手がかりを探すことです。
このブログ投稿のタイトルは次のとおりです。 更新:lost + foundからファイルを自動的に復元する このシナリオで役立つ2つのツールについて説明しています。
make-lsLR.sh
-これを定期的に(cron)呼び出して、/ root /に保存される必要なファイルを作成します。もちろん、場所を簡単に変更して、他のディレクトリをスキャンから除外することができます。
check_lost+found.py
-2番目のスクリプトは、fsckがファイルを台無しにして、それらをlost + foundディレクトリに保存したときに実行されます。それは3つの引数を取ります:1)あなたの台無しにされたlost + foundディレクトリがあるソースディレクトリ、2)データが保存されるターゲットディレクトリ、そして3)ドライランの代わりに実際にそれを実現するためのスイッチ。
2つのスクリプトは連携して機能し、システムに存在するファイルのインベントリを作成するには、最初のスクリプトを定期的に実行する必要があります。 2番目のスクリプトは、lost+found
ディレクトリからファイルを復元する必要がある場合に、このインベントリを利用できます。