web-dev-qa-db-ja.com

上書きされたファイルは復元できますか？

回復中削除されたファイル について話しているのではなく、上書きされたファイルについて話している。すなわち、以下の方法による：

# move
mv new_file old_file

# copy
cp new_file old_file

# edit
vi existing_file
> D
> i new_content
> :x

Linuxマシンに特別なプログラムがインストールされていないと仮定して、上記の3つのアクションのいずれかが実行された場合、何かを取得することは可能ですか？

data-recoveryext4
45
Question Overflow

答えは「おそらくはい、それはファイルシステムのタイプとタイミングに依存します」です。

これらの3つの例のいずれも、偶然でない限り、old_fileまたはexisting_fileの物理データブロックを上書きしません。

  • _mv new_file old_file_。これによりold_fileのリンクが解除されます。 old_fileへの追加のハードリンクがある場合、ブロックはそれらの残りのリンクで変更されないままになります。それ以外の場合、ブロックは一般に（ファイルシステムのタイプによって異なります）フリーリストに配置されます。次に、mvにコピーが必要な場合（ディレクトリエントリを移動するだけではなく）、mvの書き込みとして新しいブロックが割り当てられます。

    これらの新しく割り当てられたブロックは、解放されたばかりのブロックと同じ場合と異なる場合があります。 [〜＃〜] ufs [〜＃〜] のようなファイルシステムでは、可能であれば、ファイルが作成されたディレクトリと同じシリンダーグループからブロックが割り当てられます。ディレクトリからファイルを作成し、その同じディレクトリにファイルを作成すると、解放されたばかりの同じブロックの一部が再利用（および上書き）されます。これが、ファイルを誤って削除した人に対する標準的なアドバイスは、誰かがファイルの回復を試みることができるまで、ディレクトリツリー内のファイルに（できればファイルシステム全体に）新しいデータを書き込まないことです。

  • _cp new_file old_file_は次のことを行います（straceを使用してシステムコールを表示できます）：

    open（ "old_file"、O_WRONLY | O_TRUNC）= 4

    上記のmvと同様に、O_TRUNCフラグを使用すると、すべてのデータブロックが解放されます。そして上記のように、それらは通常フリーリストに追加され、cpコマンドによって行われる後続の書き込みで再利用される場合とそうでない場合があります。

  • _vi existing_file_。 viが実際にvimである場合、_:x_コマンドは次のことを行います。

    unlink（ "existing_file〜"）= -1 ENOENT（そのようなファイルまたはディレクトリはありません）
    rename（ "既存のファイル"、 "既存のファイル〜"）= 0
    open（ "existing_file"、O_WRONLY | O_CREAT | O_TRUNC、0664）= 3

    そのため、古いデータも削除されません。データはバックアップファイルに保存されます。

    FreeBSDでは、viはopen("existing_file",O_WRONLY|O_CREAT|O_TRUNC, 0664)を実行します。これは、上記のcpと同じセマンティクスを持ちます。

特別なプログラムがなくても、データの一部またはすべてを回復できます。必要なのは、grepとdd、およびrawデバイスへのアクセスだけです。

小さなテキストファイルの場合、リンクした質問の @ Steven Dからの回答 の単一のgrepコマンドが最も簡単な方法です。

_grep -i -a -B100 -A100 'text in the deleted file' /dev/sda1
_

しかし、連続していない複数のブロックにある大きなファイルの場合は、次のようにします。

_grep -a -b "text in the deleted file" /dev/sda1
13813610612:this is some text in the deleted file
_

一致する行のオフセットをバイト単位で示します。この後に一連のddコマンドを続けます。

_dd if=/dev/sda1 count=1 skip=$(expr 13813610612 / 512)
_

また、そのブロックの前後のいくつかのブロックを読み取る必要があります。 UFSでは、ファイルブロックは通常8KBであり、通常はかなり隣接して割り当てられます。単一のファイルのブロックは、他のファイルまたは空き領域の8KBブロックと交互にインターリーブされます。 UFS上のファイルの末尾は最大7つの1KBフラグメントで、連続していてもいなくてもかまいません。

もちろん、データを圧縮または暗号化するファイルシステムでは、リカバリはこれほど簡単ではない場合があります。

Unixには、既存のファイルのデータブロックを上書きするユーティリティはほとんどありません。頭に浮かぶのは_dd conv=notrunc_です。もう1つはshredです。

65
Mark Plotnick

私は（巨大なアスタリスクで）ノーと言うつもりです。

データがディスク上にどのように配置されるかを考えてください。データを含み、次のブロック（ある場合）を指すブロックがあります。

データを上書きすると、ブロックの内容が変更されます（ファイルを拡張する場合は、すべての終了マーカー）。したがって、何もすべき回復することができません（以下を参照）.

ファイルを短くすると、古いブロックが失われ、すぐにリサイクルされます。プログラマーの場合は、解放/削除を行わずにリストの半分を「失う」リンクされたリストを考えてください。そのデータはまだ残っていますが、幸運にもそれを見つけることができます。

考えるのが面白いかもしれない何かが断片化です。

断片化は、ディスク上に隣接しないデータの「穴」がある場合に発生します。これは、ファイルを変更してファイルを拡張または短縮し、ディスク上の元の場所に収まらないことが原因である可能性があります。

ファイルが元のサイズを超えた場合（この時点で移動する必要があります）、ファイルシステムによっては、ファイル全体を古い場所にある新しい場所にコピーできます（ただし、空きとしてマークされます）。または、古い終了ポインタを変更して新しい場所を指すようにします（これによりスラッシングが発生します）。

簡単に言えば、データはおそらく失われます（顕微鏡で観察する極端な法医学プロセスを経なければ）。ただし、まだ残っている可能性があります。

6
SailorCire

/ var/tmpまたはどこかに大きなディスク容量があることを確認してください。

試す

 grep -i -a -B100 -A100 'a string unique to your file' /dev/sda1 |
 strings > /var/tmp/my-recovered-file

/ dev/sda1はシステム上のディスクです。

次に、my-recovered-fileで文字列を検索します。

それはmightほとんどそこにあります、それが見つからない場合は、行間、括弧、sysmbolsなどがないか確認してください。

ファイル内のデータ量を削減するかなり不明確な文字列であるファイルから、検索ワードを使用します。 「echo」などのWordを検索すると、システムにはWordのエコーが含まれた多数のファイルが含まれるため、文字列のロードが返されます。

3
AndyM

TL; DR-上書きされたファイルが実行中のプロセスによって開いたままになっている場合、次のブログ投稿でベーコンを節約できます。

https://www.linux.com/news/bring-back-deleted-files-lsof/

その中で、それはdeletedファイルについて話しますが、rsyncによって上書きされたファイルであっても、うまくいきました。また、4 GBのファイルで上書きされた60 GBのファイルについて話しています。幸い、ファイルを開いたままにしていた実行中のプロセスを停止していなかったため、元のファイルを復元できました。

0
fulv

テキストファイル（VQ1.txt）を12時間分のテストデータで上書きしました。リストに、「失われた」データが含まれるVQ1.txt〜が表示されました！

$ cat VQ1.txt~  
Start time at: Thu Apr  2 18:07:23 PDT 2015
User, KW: 12hrFA_OEM_HelloVoiceQ
Test Case: 
Detection:  1, 1, 04-03 01:07:00.673 D/MultiKeywordBdctReceiver( 1743): vs status 258 : 2 : 1
Detection:  2, 1, 04-03 01:09:04.813 D/MultiKeywordBdctReceiver( 1743): vs status 258 : 2 : 1
Detection:  3, 1, 04-03 04:09:26.023 D/MultiKeywordBdctReceiver( 1743): vs status 258 : 2 : 1
Detection:  4, 1, 04-03 04:11:29.893 D/MultiKeywordBdctReceiver( 1743): vs status 258 : 2 : 1
Detection:  5, 1, 04-03 07:12:27.013 D/MultiKeywordBdctReceiver( 1743): vs status 258 : 2 : 1
Detection:  6, 1, 04-03 07:14:30.803 D/MultiKeywordBdctReceiver( 1743): vs status 258 : 2 : 1
Detection:  7, 1, 04-03 08:37:13.113 D/MultiKeywordBdctReceiver( 1743): vs status 258 : 2 : 1
Detection:  8, 1, 04-03 10:21:23.533 D/MultiKeywordBdctReceiver( 1743): vs status 258 : 2 : 1
Detection:  9, 1, 04-03 10:23:27.733 D/MultiKeywordBdctReceiver( 1743): vs status 258 : 2 : 1
Detection:  10, 1, 04-03 13:23:47.893 D/MultiKeywordBdctReceiver( 1743): vs status 258 : 2 : 1
Detection:  11, 1, 04-03 13:25:52.203 D/MultiKeywordBdctReceiver( 1743): vs status 258 : 2 : 1

12hrFA_OEM_HelloVoiceQ,  
KW detect count: 11
0
catsat