überschriebene Daten von USB-Stick retten

Thalia

Newbie
Registriert
März 2012
Beiträge
6
Hallo ihr Lieben,

wie die Überschrift andeutet, hab ich nen wahnsinns Bock geschossen: Statt ein Backup vom USB-Stick in meinen leeren Ordner zurückzuspielen habe ich ein Backup vom leeren Ordner gemacht -- und das ursprüngliche damit überschrieben. Ums kurz zu machen: Ich "hätte die Daten gerne wieder" (Will heißen: Ich hänge wirklich an den Daten...).

(ihr dürft kurz Lachen, seid mir nich böse, wenn ich nich mitlache...)

So. Nachdem die Tränen vor Lachen weggewischt wurden, weiter im Text.

Ich will jetzt nich hören, dass das nich geht ("geht nich, gibt's nicht) oder dass das "etwas" kompliziert werden könnte (ach was) ;-) Ich bin mir durchaus bewusst, dass die Chancen eher "bescheiden" sind.

ABER: Was mir ein (sehr winzig) kleines wenig Hoffnung macht, ist die Tatsache, dass es sich um einen USB-Stick handelt, Stichwort Wear-Leveling. Ich habe also die Hoffnung, dass die Daten physikalisch noch gar nicht wirklich überschrieben wurden.
Da es sich auch "nur" um etwa 6MB Daten handelt und ich den File-Header kenne, würde mir eine einfache Historie der zuletzt geschriebenen Bytes vollkommen ausreichen (bin fast wunschlos glücklich :D)

Einzige Frage: Wie komme ich da ran?^^
Oder: Gibt's noch andere Lösungsvorschläge?

Nachdem die (falschen) Daten geschrieben wurden, hab ich natürlich den Stick sofort abgezogen. Habe mich bisher auch nicht mit den Standard-Tools rangetraut, weil ich nich glaube, dass die da was helfen :-(

Ich *schätze*, man müsste irgendwie um den USB-Controller rumkommen. Hat da jemand Ahnung? :-)

Achso, partielles Wiederherstellen würde insofern nichts helfen, da es ein verschlüsseltes (sic -.-) Archiv war. Wäre ja sonst zu einfach :-(

Dateisystem ist übrigens NTFS, geschrieben wurde über eine Umlenkung von stdout unter Linux. Ersteres könnte vielleicht tatsächlich helfen... letzteres nur der Vollständigkeit halber.

So weit, so schlecht. Fühlt euch herausgefordert :-)

Herzliche Grüße und vielen Dank schonmal für alles
Thalia
 
Hallo Thalia

Ich habe mir zur Datenrettung, auch für einen USB-Stick, GetDataBack for NTFS/FAT gekauft. Ist nicht gerade billig aber hat mir geholfen. Ich glaube auch das du das Tool auch testen kannst, zeigt dir die Daten an die gefunden werden, aber ein sichern ist erst mit der gekauften Version möglich.

Tschau und Grüße, CS.
 
Also, ich bin nicht ganz sicher ob ich damit das treffe was du suchst, aber du könntest mal Recuva probieren...
Weiß aber nicht obs wirklich funktioniert, weil du von Verschlüsselung geschrieben hast...
 
CoolmanG35 schrieb:
Also, ich bin nicht ganz sicher ob ich damit das treffe was du suchst, aber du könntest mal Recuva probieren...
Weiß aber nicht obs wirklich funktioniert, weil du von Verschlüsselung geschrieben hast...

Die Verschlüsselung ist das Problem nicht; der TE will ja nicht beim Datenretten auch gleichzeitig entschlüsseln; das kann er mit den geretteten Daten dann auf seinem System immer nich machen !

Der Weg bezüglich Zugriff auf wear-leveling ist wohl der Richtige, kann ich Dir aber nicht viel sagen dazu; entweder googlest Du weiter ode es findet sich hier noch jemand, der sich auskennt; aber auch mit normalen Rettungstools kannst Du das sicher einmal probieren, die ändern ja keine Daten und es ist ja nicht gesagt, dass Deine alten Daten durch die neuen überschrieben wurden; wahrscheinlich wurde nur deren Registrierung gelöscht.
 
Zuletzt bearbeitet:
Hallo ihr Lieben,

erstmal vielen Dank für die schnellen Antworten!

Gallen schrieb:
es ist ja nicht gesagt, dass Deine alten Daten durch die neuen überschrieben wurden; wahrscheinlich wurde nur deren Registrierung gelöscht.
"Logisch", also auf Dateisystemebene betrachtet, sind die Daten überschrieben worden :-( Statt einer Backup.tgz.gpg, die mein Backup enthält, habe ich jetzt eine Backup.tgz.gpg, die quasi nichts enthält.

Das ist auch der Grund, warum ich den "üblichen Tools" wenig zutraue. Und weil ich keine Ahnung habe, wie das Wear-Leveling funktioniert, traue ich mich im Moment nichtmal, lesend auf den Stick zuzugreifen. (Weil wohl trotzdem Metadaten aktualisiert, d.h. geschrieben, werden, o.Ä.) Genaugenommen traue ich mich kaum, den Stick anzusehen^^

Werde mir die Tools trotzdem mal anschauen, aber erst Morgen... wer weiß, was ich jetzt gerade noch alles kaputt machen würde.

Wenn aber jemand speziell zu Wear-Leveling irgendwelche Tipps, in welcher Form auch immer, hat: Mein Dank wäre sicher :-)

herzliche Grüße
Thalia
 
Ganz ehrlich: Wenn Dir wirklich was an den Daten liegt konsultier eine entsprechende Firma. Da sieht's normal schon düster aus, aber dein Fall ist ein GANZ spezieller.
Auf Flashmedien ist oft nur partielles Wiederherstellen möglich und da du ein verschlüsseltes Archiv wiederherstellen möchtest, wirds gleich doppelt tricky. Ein Bitfehler und das Archiv wird sich nicht öffnen lassen. Das noch mti einem Linux-Treiber formatiert... :-/
Aber ich denke, das weißt Du.

Daher mein Vorschlag: Schau mal, ob die Files nicht irgendwo in irgendwelchen temporären Ordnen liegen. Leider sind da viele Programme/Systeme etwas schlampig -aber das könnte dein Vorteil sein.^^

MfG, Thomas
 
Seit wann kommt denn wear leveling bei USB-Sticks zum Einsatz? Wäre mir neu.

Wenn die Speicherzellen einmal überschrieben wurden, dann wird sich da nichts mehr machen lassen. Ansonsten versuche es mal mit dem schon erwähnten Recuva.
 
Nicht überschrieben?
Du kannst Testdisk testen.
Gehe auf das Menü Advanced und Undelete.
Dort werden dir alle gelöschten Dateien angezeigt.
Nehme die Version 6.14.
Unten im Mneü Advanced siehst du die Befehle zum kopieren der Daten auf einen intakten Datenträger.
Ansonsten teste PhotoRec im Testdisk-Ordner.
Wenn dein Dateityp nicht erkannt wird, kannst du ihn kurzfristig mit fidentify zufügen.
Infos hier;
http://www.cgsecurity.org/wiki/Add_your_own_extension_to_PhotoRec
Noch auf englisch, sollte ich aber bald übersetzen.
Wenn ich Zeit habe! :eek:
 
Hallo ihr Lieben,

HighTech-Freak schrieb:
Ganz ehrlich: Wenn Dir wirklich was an den Daten liegt konsultier eine entsprechende Firma.
Mhm, wäre sicher ne Idee. Aber erstens kost' das wohl jede Menge Geld und zweitens... ist das doch ne interessante Herausforderung :-D

Aber vielleicht kann ich ja mal ein paar ganz unverbindliche Mails schreiben und mir anhören, was die so zu sagen haben^^

HighTech-Freak schrieb:
Daher mein Vorschlag: Schau mal, ob die Files nicht irgendwo in irgendwelchen temporären Ordnen liegen.
Mhm... habe ich bereits erfolglos versucht. Ein paar Daten konnte ich aus anderen Backups wiederherstellen. Aber ein bisschen was fehlt leider noch :-(


pyrol schrieb:
Seit wann kommt denn wear leveling bei USB-Sticks zum Einsatz?
Soweit ich das gelesen habe (bin im Moment erst dabei, mich in die Thematik einzulesen), kommt auch bei USB-Stick schon eine primitive(re) Form von Wear-Leveling zum Einsatz. Was auch der Grund ist, warum man Daten nicht einfach so "sicher löschen" kann durch mehrmaliges Überschreiben. Weil eben die Schreibzugriffe "gleichmäßig" verteilt werden. Genau DAS ist ja auch der Grund, warum ich mir überhaupt noch ein bisschen Hoffnung mache :-)

Fiona schrieb:
Nicht überschrieben?
doch :-( Zumindest ist im Dateisystem nur noch die "falsche" Datei drin. Und Testdisk und Konsorten arbeiten, wenn ich das richtig verstanden habe so, dass sie nur "gelöschte" Dateien wiederfinden, weil da eben nur eine Referenz als "gelöscht" markiert wurde, aber physikalisch eben nichts geändert wurde.

Aber ich lasse mich gerne eines Besseren belehren :-)

Ich habe jetzt mal ein Image vom Stick gezogen um mal die Tools drauf loszulassen. Aber wie gesagt: Ich glaube, um die Daten wiederzubekommen... müsste man *unter* das Dateisystem :freak:

Herzliche Grüße
Thalia
 
Wie groß ist der Stick insgesamt, und wieviele Dateien sind da sonst noch drauf?
Unter Linux, fürchte ich, wird kein Logfile geschrieben, von wo man die ursprüngliche Anordnung der verwendeten Cluster für diese Datei rauskriegen könnte.

Mir fällt zur Untersuchung, wie es auf dem Stick tatsächlich aussieht, eigentlich nur der DiskExplorer von Runtime unter Win ein; dessen Verwendung ist außerdem 1 Monat kostenlos.

Wenn der darübergeklatschte Ordner 0 Bytes hatte, wurde auch nichts von den alten Daten überschrieben.
 
Zuletzt bearbeitet:
Hallo ihr Lieben,

habe mich jetzt an ein paar Tools versucht, allerdings mit wenig Erfolg. Einige _gelöschte_ Dateien konnte ich zwar finden, aber nicht die, die ich überschrieben habe :-(

Ernst@at schrieb:
Wie groß ist der Stick insgesamt, und wieviele Dateien sind da sonst noch drauf?
Der Stick ist insgesamt 16GB groß und hat ungefähr 3000 (ungelöschte^^) Dateien.

Ernst@at schrieb:
Mir fällt zur Untersuchung, wie es auf dem Stick tatsächlich aussieht, eigentlich nur der DiskExplorer von Runtime unter Win ein;
Habe ich eben auf die Schnelle ausprobiert, aber wirklich übersichtlich und intuitiv finde ich das Programm nicht ;-)

Ernst@at schrieb:
Wenn der darübergeklatschte Ordner 0 Bytes hatte, wurde auch nichts von den alten Daten überschrieben.
Leider ist es nicht ganz so. Ein bisschen was kam da noch zustande. Und da es sich insgesamt nur um 5-6MB handelt...

Aber jetzt muss ich nochmal ganz konkret nachfragen. Ich versteh's nicht, tut mir leid: Können solche Tools überhaupt an die originalen Daten rankommen, wenn sie logisch überschreiben wurden?
Mag sein, dass ich mich da falsch festgebissen habe, aber für meine Begriffe: Nein, können sie nicht. Weil sie genau das gleiche sehen, wie das Betriebssystem: Die logische Darstellung des Sticks. Und DIE besagt ja, dass die Datei da ist :/

Rein aus Interesse: Ein COW-Dateisystem hätte jetzt echte Vorteile, oder? :rolleyes:

herzliche Grüße
Thalia
 
Können solche Tools überhaupt an die originalen Daten rankommen, wenn sie logisch überschreiben wurden?
Abgesehen von der krausen wear-Levelling Theorie:
Wenn neue Daten an eine physische Adresse geschrieben wurden, sind die alten weg.

Im NTFS- Filesystem wird nicht zwingend durch das Schreiben einer Datei gleichen Namens der gleiche Platz verwendet wie für die alte Datei.
Habe ich eben auf die Schnelle ausprobiert, aber wirklich übersichtlich und intuitiv finde ich das Programm nicht ;-)
Intuitiv ist's nur für jemanden, der die NTFS-Filesystemstruktur und der Metadaten zumindest in den Grundzügen kennt.

Während das NTFS-Filesystem gemounted ist, werden (zumindest unter Win) für diese Session sämtliche Änderungen der Metadateninformationen im Logfile mitgeführt, daraus kann man bei einer derartigen Fehlhandlung daraus die Information gewinnen, wo die Daten der gelöschten Datei physisch lokalisiert waren und außerdem feststellen, ob durch die neue Datei davon Teilbereiche zerstört wurden.
Wie gesagt: ob dies auch unter Linux im ntfs-3g passiert, weiss ich nicht.
 
Hallo Ernst@at,

Ernst@at schrieb:
Abgesehen von der krausen wear-Levelling Theorie:
Wenn neue Daten an eine physische Adresse geschrieben wurden, sind die alten weg.
Klar, wenn die Daten physisch weg sind, sind sie weg. Allerdings dachte ich, dass (verzeih mir) Wear-Leveling die physischen Blöcke von der logischen Darstellung trennt. Sodass zwar das Dateisystem nach bestem Wissen und Gewissen überschreibt, aber ggf. eben nicht klappt.
Darf ich fragen, was an der "Wear-Levelling Theorie" so kraus ist? Einfach, weil's ziemlich schwierig wird, oder weil ich das Prinzip komplett nicht verstanden hab und das so gar nich klappen kann?

Ernst@at schrieb:
Im NTFS- Filesystem wird nicht zwingend durch das Schreiben einer Datei gleichen Namens der gleiche Platz verwendet wie für die alte Datei.
Okay, klingt schonmal vielversprechend. Heißt dann auch, dass File-Carving eventuell Chancen auf Erfolg hätte?
Danke auf jeden Fall für die Info... ein bisschen Hoffnung :D

Ernst@at schrieb:
Während das NTFS-Filesystem gemounted ist, werden (zumindest unter Win) für diese Session sämtliche Änderungen der Metadateninformationen im Logfile mitgeführt,
Mhm... ohne genaue Kenntnisse wie das Log aussehen sollte... 64MB voller 0xff spricht wohl nicht dafür, dass Linux da viel sinnvolles reinschreibt :/

Herzliche Grüße und schönen Sonntag
Thalia
 
Darf ich fragen, was an der "Wear-Levelling Theorie" so kraus ist?
Wenn Du das Gehäuse des Sticks aufmachst, wirst du kaum was anderes als einen winzigen Controllerchip vorne beim Anschluss finden so wie hier .
Für wear-levelling ist etwas größerer Aufwand nötig, um die Adressumsetzung und Verwaltung zu betreiben. Ob jetzt die alten Daten überschrieben wurden oder das Mapping auf die neuen woandershin zeigt, ist egal, denn selbst auf einer SSD ist das auslesen solcher "entmappter" Inhalte nicht per Software möglich.

Mhm... ohne genaue Kenntnisse wie das Log aussehen sollte... 64MB voller 0xff spricht wohl nicht dafür, dass Linux da viel sinnvolles reinschreibt :/
Das heißt, beim Format wurde $Logfile angelegt und initialisiert, aber nie verwendet :(
damit sinken die Chancen, die ursprünglichen Speicherorte rauszufinden.

Das ist eine Chance weniger, die Daten wiederzufinden.
Windows killt aber die Informationen von Dateien >4GB sofort(ein kleiner Designfehler), was Linux vielleicht nicht tut - eine Chance mehr?

Erschwerend wirkt die Große Anzahl an Dateien, denn technisch hat man so bloss die Möglichkeit, nach $MFT-Einträgen zu suchen, welche freigegeben wurden und noch eine riesige Runlist für die 6GB Daten aufweisen(wenn der Stick häufig in Gebrauch und nicht defragmetiert wurde) und diese dann mit der $BitMap abzugleichen, ob und wo da was schon neu verwendet wurde.

Jedenfalls ist das Problem eine Spielwiese für Experten...
 
Zuletzt bearbeitet:
Hallo zusammen,

Ernst@at schrieb:
Ob jetzt die alten Daten überschrieben wurden oder das Mapping auf die neuen woandershin zeigt, ist egal, denn selbst auf einer SSD ist das auslesen solcher "entmappter" Inhalte nicht per Software möglich.
Danke für die Desillusionierung :) War hat so ein verzweifelter, letzter Gedanke^^


Ernst@at schrieb:
Windows killt aber die Informationen von Dateien >4GB sofort(ein kleiner Designfehler), was Linux vielleicht nicht tut - eine Chance mehr?
rein aus Interesse: HÄ?
Die vermissten Daten selbst waren nur etwa 10MB (ja, "M"!) groß. Die Gesamtbelegung war bei knapp 2GB. Daher verstehe ich den Hinweis nicht so ganz -- oder war da einfach ein Missverständnis?

Ernst@at schrieb:
Im NTFS- Filesystem wird nicht zwingend durch das Schreiben einer Datei gleichen Namens der gleiche Platz verwendet wie für die alte Datei.
Ich verneige mich an dieser Stelle vor dir! :king: Der Hinweis hat mich einerseits davor bewahrt, den USB-Stick zur Anwendung der "krausen Theorie" zu zerstören UND mir sogar meine Daten zurückgebracht!!! (sorry, ich mache normalerweise nie mehr als ein Satzzeichen, aber hier ist's es wert :))

Ein kleines Python-Skript (ja, ich wollte es selbst machen...:rolleyes:), was über das Image carvt, nach dem Header sucht und die jeweils nächsten 10MB rauskopiert. Zum Glück hatte ich keine Probleme mit Fragmentierung und GPG zickt nicht rum, wenn die Datei zu groß ist.

Am Ende hatte ich sogar mehrere Stände der verloren geglaubten Datei.

Ernst@at schrieb:
Jedenfalls ist das Problem eine Spielwiese für Experten...
Darf ich mich jetzt zu den Experten zählen? :D Oder ist das eher was für die Kategorie "dummer Bauer, dicke Kartoffeln"?

Nochmal: Vielen, vielen Dank an alle und besonders an Ernst@at! Diesmal hat der Osterhase seine Geschenke wirklich gut versteckt...

In dem Sinne: Frohes Osterfest euch allen und liebe Grüß
Thalia
 
Darf ich mich jetzt zu den Experten zählen?
Ja! unbedingt. Wenn schon Sprichwort, dann das mit dem Huhn. :)
Das mit den 6MB hab ich irrtümlich als 6GB interpretiert, so kleine Dateien kann man sich ja fast nicht vorstellen...
 
Zurück
Oben