it-swarm.com.de

Können überschriebene Dateien wiederhergestellt werden?

Ich spreche nicht von Wiederherstellengelöschte Dateien , sondern überschriebenen Dateien. Nämlich mit folgenden Methoden:

# move
mv new_file old_file

# copy
cp new_file old_file

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

Ist es möglich, etwas abzurufen, wenn eine der drei oben genannten Aktionen ausgeführt wird, vorausgesetzt, auf dem Linux-Computer sind keine speziellen Programme installiert?

45

Die Antwort lautet "Wahrscheinlich ja, aber es hängt vom Dateisystemtyp und vom Timing ab."

Keines dieser drei Beispiele überschreibt die physischen Datenblöcke der alten oder der vorhandenen Datei, außer zufällig.

  • mv new_file old_file. Dadurch wird die Verknüpfung von old_file aufgehoben. Wenn es zusätzliche feste Links zu old_file gibt, bleiben die Blöcke in diesen verbleibenden Links unverändert. Andernfalls werden die Blöcke im Allgemeinen (abhängig vom Dateisystemtyp) in eine freie Liste aufgenommen. Wenn dann mv kopiert werden muss (im Gegensatz zum Verschieben von Verzeichniseinträgen), werden neue Blöcke als mv-Schreibvorgänge zugewiesen.

    Diese neu zugewiesenen Blöcke können dieselben sein, die gerade freigegeben wurden . Auf Dateisystemen wie UFS werden Blöcke nach Möglichkeit aus derselben Zylindergruppe zugewiesen wie das Verzeichnis, in dem die Datei erstellt wurde. Es besteht also die Möglichkeit, dass die Verknüpfung von a aufgehoben wird Wenn Sie eine Datei aus einem Verzeichnis erstellen und eine Datei in demselben Verzeichnis erstellen, werden einige der gerade freigegebenen Blöcke wiederverwendet (und überschrieben). Aus diesem Grund wird Personen, die versehentlich eine Datei entfernen, standardmäßig empfohlen, keine neuen Daten in Dateien in ihrem Verzeichnisbaum (und vorzugsweise nicht in das gesamte Dateisystem) zu schreiben, bis jemand versuchen kann, eine Datei wiederherzustellen.

  • cp new_file old_file Führt Folgendes aus (Sie können strace verwenden, um die Systemaufrufe anzuzeigen):

    open ("old_file", O_WRONLY | O_TRUNC) = 4

    Das O_TRUNC-Flag bewirkt, dass alle Datenblöcke freigegeben werden, genau wie mv oben. Und wie oben werden sie im Allgemeinen zu einer freien Liste hinzugefügt und können durch die nachfolgenden Schreibvorgänge, die mit dem Befehl cp ausgeführt werden, wiederverwendet werden oder nicht.

  • vi existing_file. Wenn vi tatsächlich vim ist, führt der Befehl :x Folgendes aus:

    verknüpfung aufheben ("vorhandene_Datei ~") = -1 ENOENT (Keine solche Datei oder kein solches Verzeichnis)
    umbenennen ("vorhandene_Datei", "vorhandene_Datei ~") = 0
    open ("vorhandene_Datei", O_WRONLY | O_CREAT | O_TRUNC, 0664) = 3

    Es werden also nicht einmal die alten Daten entfernt. Die Daten werden in einer Sicherungsdatei gespeichert.

    Unter FreeBSD führt viopen("existing_file",O_WRONLY|O_CREAT|O_TRUNC, 0664) aus, das dieselbe Semantik wie cp oben hat.


Sie können einige oder alle Daten ohne spezielle Programme wiederherstellen. Alles, was Sie brauchen, ist grep und dd und Zugriff auf das Raw-Gerät.

Bei kleinen Textdateien ist der einzelne Befehl grep im Antwort von @Steven D in der von Ihnen verknüpften Frage der einfachste Weg:

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

Bei größeren Dateien, die sich möglicherweise in mehreren nicht zusammenhängenden Blöcken befinden, gehe ich folgendermaßen vor:

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

dadurch erhalten Sie den Versatz in Bytes der übereinstimmenden Zeile. Folgen Sie diesem mit einer Reihe von dd Befehlen, beginnend mit

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

Sie möchten auch einige Blöcke vor und nach diesem Block lesen. Unter UFS sind Dateiblöcke normalerweise 8 KB groß und werden normalerweise ziemlich zusammenhängend zugewiesen, wobei die Blöcke einer einzelnen Datei abwechselnd mit 8 KB-Blöcken aus anderen Dateien oder freiem Speicherplatz verschachtelt werden. Das Ende einer Datei in UFS besteht aus bis zu 7 1-KB-Fragmenten, die möglicherweise zusammenhängend sind oder nicht.

Auf Dateisystemen, die Daten komprimieren oder verschlüsseln, ist die Wiederherstellung möglicherweise nicht so einfach.


In Unix gibt es nur sehr wenige Dienstprogramme, die die Datenblöcke einer vorhandenen Datei überschreiben. Eines, das mir in den Sinn kommt, ist dd conv=notrunc. Ein anderer ist shred.

65
Mark Plotnick

Ich werde nein sagen (mit einem riesigen Sternchen).

Überlegen Sie, wie Daten auf eine Festplatte gelegt werden. Sie haben Blöcke, die Daten enthalten und auf den nächsten Block zeigen (falls vorhanden).

Wenn Sie Daten überschreiben, ändern Sie den Blockinhalt (und wenn Sie die Datei erweitern, alle Endmarkierungen). Also kann nichts sollte wiederhergestellt werden (siehe unten).

Wenn Sie die Datei kürzen, verlieren Sie die alten Blöcke und sie werden bald recycelt. Wenn Sie ein Programmierer sind, stellen Sie sich eine verknüpfte Liste vor, in der Sie die Hälfte Ihrer Liste "verlieren", ohne sie freizugeben/zu löschen. Diese Daten sind immer noch da, aber viel Glück beim Finden.

Interessant zu denken könnte die Fragmentierung sein.

Eine Fragmentierung tritt auf, wenn auf Ihrer Festplatte "Löcher" nicht zusammenhängender Daten vorhanden sind. Dies kann dadurch verursacht werden, dass Dateien so geändert werden, dass Sie sie erweitern oder verkürzen und sie nicht mehr an ihre ursprüngliche Stelle auf der Festplatte passen.

Wenn eine Datei ihre ursprüngliche Größe überschreitet (sie muss an dieser Stelle verschoben werden), können Sie abhängig von Ihrem Dateisystem die gesamte Datei an einen neuen Speicherort kopieren, an dem sich die alten Daten noch befinden (aber als frei markiert sind). oder Sie ändern einfach den alten Endzeiger und lassen ihn auf eine neue Position zeigen (dies führt zu Thrashing).

Kurz gesagt, Ihre Daten gehen wahrscheinlich verloren (ohne einen extremen forensischen Prozess zu durchlaufen, bei dem Sie sie unter dem Mikroskop betrachten). Es besteht jedoch die Möglichkeit, dass es noch vorhanden ist.

6
SailorCire

Stellen Sie sicher, dass Sie genügend Speicherplatz in/var/tmp oder an einem großen Ort haben.

Versuchen

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

dabei wäre/dev/sda1 Ihre Festplatte auf Ihrem System.

Dann durchsuchen Sie meine wiederhergestellte Datei nach Ihrer Zeichenfolge.

Es könnte meistens da sein, wenn Sie es finden, suchen Sie nach fehlenden Zeilenabständen, Klammern, Sysmbolen usw.

Verwenden Sie ein Suchwort aus Ihrer Datei, das ziemlich eindeutig ist, oder eine Zeichenfolge, die die Datenmenge in der Datei verringert. Wenn Sie nach einem Word wie "Echo" suchen, erhalten Sie viele Zeichenfolgen zurück, da das System viele Dateien mit dem Word-Echo enthält.

3
AndyM

TL; DR - Wenn die überschriebene Datei noch von einem laufenden Prozess geöffnet wird, speichert dieser Blog-Beitrag möglicherweise Ihren Speck:

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

Darin handelt es sich um gelöschte Dateien, aber ich hatte viel Glück damit, selbst mit einer Datei, die von rsync überschrieben wurde. Und ich spreche von einer 60-GB-Datei, die von einer 4-MB-Datei überschrieben wurde, und ich konnte das Original wiederherstellen, weil ich zum Glück den laufenden Prozess nicht gestoppt hatte, der es offen hielt.

0
fulv

Ich hatte eine Textdatei (VQ1.txt) mit Testdaten im Wert von 12 Stunden überschrieben :( Eine Vorstellung, dass Unix die vorherige Version der Datei im Format text.txt ~ speichert, ließ mich in einen Ordner schauen, der die überschriebene Datei mit $ -ll Full enthält Liste zeigte VQ1.txt ~, die meine 'verlorenen' Daten hatte!

$ 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