最近、HDD がクラッシュしたため、fsckコマンドを実行する必要がありました。多くのファイルがフォルダーに移動されlost+found、とを使用して重要なファイルを取得しましたfindがgrep、SQL データベースが見つかりません。
質問
- lost+found ディレクトリで InnoDB データベースを見つけるにはどうすればよいですか?
- fsck が SQL データベースを保存していない可能性はありますか?
- もしそうなら、このファイルを回復できますか?
答え1
試し1:
おそらく、まだそこにあるのでしょうが、名前が fe /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：
データベースに大量のテキストデータがある場合は、セクターベースの 16 進検索も役立ちます。
答え2
問題のファイルは fsck で再構築できず、削除された可能性があります。fsck プログラムは修復のみを試み、可能な限りファイルの再構築に努めます。ただし、これはバックアップの一種ではありません。fsck によって実行されるアクションは基本的に元に戻せません。
データベースは 1 つのファイルに含まれているのではなく、信頼性やデータの整合性が確保されるモードでデータベースを回復できるようにするには、複数のファイルが「同期」されている必要があるため、lost+found ディレクトリに含まれる MySQL データベースの一部を使用する際には十分注意してください。
ファイルの回復に関しては、残念ですが、データが重要だった頃からおそらく作成していたバックアップに戻る必要があります。そうしないと、本当に運が悪くなります。
データがそれほど重要な場合は、数あるデータ復旧サービスのうちの 1 つに協力を依頼してみるのもよいかもしれません。ただし、費用は高く、結果も完璧とは言えません。
答え3
運が悪いようです。唯一の選択肢は、lost+foundディレクトリを調べて各ファイルを視覚的に検査し、元のファイルの識別に関する手がかりを探すことです。
将来
次のようなタイトルのブログ投稿があります:更新: lost+found からファイルを自動的に復元では、このシナリオで役立つ 2 つのツールについて説明しています。
make-lsLR.sh- これを定期的に呼び出して (cron)、/root/ に保存される必要なファイルを作成します。もちろん、場所を簡単に変更して、他のディレクトリをスキャン対象から除外することもできます。
check_lost+found.py- 2 番目のスクリプトは、fsck がファイルを台無しにして、それらを lost+found ディレクトリに保存した場合に実行されます。これには 3 つの引数が必要です: 1) 台無しになった lost+found ディレクトリがあるソース ディレクトリ、2) データが保存されるターゲット ディレクトリ、3) ドライ ランではなく実際に実行するためのスイッチ。
2 つのスクリプトは連携して動作し、1 つ目のスクリプトは定期的に実行して、システムに存在するファイルのインベントリを作成する必要があります。2 つ目のスクリプトは、ディレクトリからファイルを復元する必要がある場合に、このインベントリを利用できますlost+found。