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

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

# move
mv new_file old_file

# copy
cp new_file old_file

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

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

答えは「たぶんそうですが、それはファイルシステムのタイプとタイミングに依存します」です。

これら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

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

• vi existing_file。場合はvi、実際にあるvim、:xコマンドは次の処理を行います。

  unlink（ "existing_file〜"）= -1 ENOENT（そのようなファイルまたはディレクトリはありません）

  rename（ "existing_file"、 "existing_file〜"）= 0

  open（ "existing_file"、O_WRONLY | O_CREAT | O_TRUNC、0664）= 3

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

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

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

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

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です。

いいえ（巨大なアスタリスク付き）と言います。

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

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

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

興味深いと思うのは断片化です。

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

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

簡単に言えば、データはおそらく失われます（顕微鏡で見ている極端なフォレンジックプロセスを経ることなく）。ただし、まだ存在する可能性があります。

/ 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で文字列を検索します。

それは主にそこにあるかもしれません、あなたが行方不明の行スペース、ブラケット、sysmbolsなどをチェックするのを見つけた場合

ファイル内の検索語を使用します。検索語は、ファイル内のデータ量を削減するために、かなりユニークな文字列または文字列です。「echo」などの単語を検索すると、システムには単語echoを含むファイルがたくさんあるため、文字列の負荷が戻ります。

12時間分のテストデータでテキストファイル（VQ1.txt）を上書きしました：リストには、「失われた」データが含まれていた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

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

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

その中で、削除されたファイルについて説明していますが、rsyncで上書きされたファイルでも幸運でした。そして、私は4 MBのファイルで上書きされた60 GBのファイルについて話しているのですが、幸いなことに、開いたままにしていた実行中のプロセスを停止しなかったので、元のファイルを回復できました。