web-dev-qa-db-ja.com

rm *を実行して今削除したファイルを復元するにはどうすればよいですか?

誤って、多くのcプログラムファイルを作成した現在のディレクトリでrm *を実行しました。私は朝からこれらに取り組んできました。これで、朝からファイルを作成するために費やした時間を再び取ることができなくなりました。回復方法を教えてください。彼らもごみ箱に入っていません!

54
Ravi

実行中のプログラムで削除されたファイルがまだ開いている場合は、/proc/[pid]/fd/[num]の開いているファイル記述子を使用してファイルを回復できます。これに該当するかどうかを判断するには、次のことを試してください。

$ lsof | grep "/path/to/file"

上記がフォームの出力を与える場合:

progname 5383 user 22r REG 8,1 16791251 265368 /path/to/file               

2番目の列のPIDと4番目の列のファイル記述子番号に注意してください。この情報を使用すると、次のコマンドを発行してファイルを回復できます。

$ cp /proc/5383/fd/22 /path/to/restored/file

lsofを使用してファイルが見つからない場合は、ファイルを読み取り専用で格納していたファイルシステムをすぐに再マウントする必要があります。

$ mount -o remount,ro /dev/[partition]

または、ファイルシステムを完全にマウント解除します。

$ umount /dev/[partition]

これは、ファイルのリンクが解除され、問題のファイルへのハードリンクがなくなるとすぐに、基盤となるファイルシステムが、削除されたファイルに以前割り当てられていたブロックを解放する可能性があるためです。別のファイルに割り当てられ、その内容は上書きされます。したがって、ファイルシステムへのそれ以上の書き込みを停止することは、リカバリを可能にする場合にタイムクリティカルです。ファイルシステムがルートファイルシステムであるか、他の理由で読み取り専用またはマウント解除できない場合は、システムをシャットダウンし(可能な場合)、ターゲットファイルを残すことができるライブ環境からのリカバリを続行する必要がある場合があります。システムは読み取り専用です。

ファイルシステムへの書き込みが防止された後、実際のリカバリを試行するための即時の急ぎはありません。安全に再生するには、ファイルシステムのバックアップを作成して、実際にリカバリを実行することができます。

$ dd bs=4M if=/dev/[partition] of=/path/to/backup

次の手順は、ファイルシステムの種類によって異なります。典型的なUbuntuのインストールを想定すると、ext3またはext4ファイルシステムが存在する可能性が高くなります。この場合、 extundelete を使用してリカバリを試みることができます。マウントされていない(または読み取り専用でマウントされている)限り、バックアップまたはrawデバイスのいずれかでリカバリを安全に試行できます。 ライブファイルシステムからのリカバリを試みないでください。これにより、ファイルシステムが不整合な状態になる可能性があります。

extundeleteは、見つかったファイルをRECOVERED_FILESという名前の現在のディレクトリのサブディレクトリに復元しようとします。削除されたすべてのファイルをバックアップから復元する一般的な使用法は次のとおりです。

$ extundelete /path/to/backup --restore-all 
60
Thomas Nyman

はい、ファイルを復元できます。すべてが回復するかどうかはまだ確認していませんが、確認したいくつかは回復しています。そのツール/コマンドを介して回復される多くのファイルがあるので、それらのファイルのテキストパターンをgrepして、どれが私のものかを確認する必要があります。ファイルは異なる名前で復元されます(システムによって生成される場合があります)。私は別のフォーラムから解決策を得ました、そしてコマンドはphotorecです

Sudo photorec

これにより、テキストベースのウィンドウが開きます。私は指示に従いました、そしてそれは素晴らしいです。

11
Ravi