Moin, ich erhalte wahrscheinlich die Tage eine externe olle 500GB PLatte, welche urspruenglich wohl eine einzige NTFS-Partition beherbergte. Der Nutzer dieser Platte hat dann wohl dummerweise die externe Platte im System eingehaengt gehabt, als er den Versuch unternahm, ein Linux-Liveimage auf einen Stick zu buegeln...und natuerlich statt dem Stick die Platte getroffen. Bis jetzt sind mir leider in Erzaehlungen bestenfalls halbe Salamischeibchen serviert worden und ich muss mir den tatsaechlichen Sachverhalt irgendwie zusammenreimen :( So weiss ich immer noch nicht, ob der Nutzer den Fehler zwischendurch bemerkt und die Prozedur abgebrochen hat. Ebenfalls ist mir nicht bekannt, welches Tool er zum Buegeln des Images anwendete, kann unter Win genausogut wie unter Linux stattgefunden haben... Da ich einen solchen Anwendungsfall selber noch nie produziert habe und aus diesem Grund auch nicht reparieren musste: Ein Liveimage auf einem Stick belegt idR ja nichtmal 4GB und die Platte duerfte formatiert um die 465GB ausweisen. Besteht eine Moeglichkeit mit gpart oder einem anderen Tool (vielleicht Testdisk) erneut eine passende Partitionstabelle auf die Platte zu schreiben und die verschollene NTFS-Partition so wieder sichtbar zu machen? Um so an die nicht ueberschriebenen urspruenglichen Daten heranzukommen? Datenrettung mit Testdisk/Photorec waere natuerlich eine Option, musste ich letztens auch erst machen, da hatte ich es allerdings relativ einfach, weil mpg-Dateien ein leichter Fall sind. Die paar avi und mp4 Dateien hingegen waren - absolut verschmerzbar - defekt. Auf der bald eintreffenden Platte sollen sich Photos (wahrscheinlich jpg) und Officedateien aufhalten. Letzteres benutze ich aus gutem Grund ueberhaupt nicht und ich stelle mir vor, dass es schwer bis unmoeglich sein duerfte, zerstueckelte Fragmente von solchen Dateiformaten zu einem funktionierenden Ganzen zusammenzufuegen..lieg ich mit dem Punkt richtig? Nachtrag: Nach bisherigen Recherchen stelle ich mir vor eine solche Vorgehensweise koennte Erfolg haben: 1. Kompletten Inhalt der Platte erstmal mit dd in Sicherheit bringen 2. Platte wie gewuenscht mit einer frischen Partitionstabelle beschreiben, die eine einzige NTFS-Partition ausweist. 3. Diese frische Partitionstabelle dann mit sfdisk auslesen und sichern. 4. Mit dd die in Schritt 1 gesicherten Daten zurueckschreiben. 5. Mit sfdisk die ausgelesene Partitionstabelle schreiben.
:
Bearbeitet durch User
Wenn du die Partition genau so anlegst, wie sie vorher war, kannst du dir die Schritte 3-5 sparen. Denn wenn eine neue Partitionstabelle geschrieben wird, wird auch nicht mehr als diese überschrieben. Dann drücke ich dir die Daumen, dass vom NTFS noch genug übrig ist, um sortiert an die Daten zu kommen. MfG, Arno
Johannes U. schrieb: > Besteht eine Moeglichkeit mit gpart oder einem anderen Tool (vielleicht > Testdisk) erneut eine passende Partitionstabelle auf die Platte zu > schreiben und die verschollene NTFS-Partition so wieder sichtbar zu > machen? > Um so an die nicht ueberschriebenen urspruenglichen Daten heranzukommen? Ja, aber das setzt voraus das nicht alle Daten überschrieben worden sind. IIRC speichert auch NTFS wichtigen Verwaltung Krams am Anfang der Partition. Also: Das kommt darauf an(tm).
Hallo Johannes U., Johannes U. schrieb: > Moin, > > ich erhalte wahrscheinlich die Tage eine externe olle 500GB PLatte, > welche urspruenglich wohl eine einzige NTFS-Partition beherbergte. > > Der Nutzer dieser Platte hat dann wohl dummerweise die externe Platte im > System eingehaengt gehabt, als er den Versuch unternahm, ein > Linux-Liveimage auf einen Stick zu buegeln...und natuerlich statt dem > Stick die Platte getroffen. Das kommt sehr häufig vor. Das ist wie mit der Fallseite der Marmeladenschnitte. > > Bis jetzt sind mir leider in Erzaehlungen bestenfalls halbe > Salamischeibchen serviert worden und ich muss mir den tatsaechlichen > Sachverhalt irgendwie zusammenreimen :( Warum sollte es bei Computern anders sein als bei Elektronik? :) > So weiss ich immer noch nicht, ob der Nutzer den Fehler zwischendurch > bemerkt und die Prozedur abgebrochen hat. > Ebenfalls ist mir nicht bekannt, welches Tool er zum Buegeln des Images > anwendete, kann unter Win genausogut wie unter Linux stattgefunden > haben... Das ist ziemlich egal. Die Images werden linear auf das Ziel gezogen, da ist der Toolname nachrangig. > Da ich einen solchen Anwendungsfall selber noch nie produziert habe und > aus diesem Grund auch nicht reparieren musste: > Ein Liveimage auf einem Stick belegt idR ja nichtmal 4GB und die Platte > duerfte formatiert um die 465GB ausweisen. > Besteht eine Moeglichkeit mit gpart oder einem anderen Tool (vielleicht > Testdisk) erneut eine passende Partitionstabelle auf die Platte zu > schreiben und die verschollene NTFS-Partition so wieder sichtbar zu > machen? Testdisk kann das unter Auswertung des Backup-Boot-Sektors der NTFS-Partition. Die Sichtbarmachung der Partition heißt aber leider noch lange nicht, dass diese auch lesbar ist. > Um so an die nicht ueberschriebenen urspruenglichen Daten heranzukommen? > > Datenrettung mit Testdisk/Photorec waere natuerlich eine Option, musste > ich letztens auch erst machen, da hatte ich es allerdings relativ > einfach, weil mpg-Dateien ein leichter Fall sind. > Die paar avi und mp4 Dateien hingegen waren - absolut verschmerzbar - > defekt. > Auf der bald eintreffenden Platte sollen sich Photos (wahrscheinlich > jpg) und Officedateien aufhalten. > Letzteres benutze ich aus gutem Grund ueberhaupt nicht und ich stelle > mir vor, dass es schwer bis unmoeglich sein duerfte, zerstueckelte > Fragmente von solchen Dateiformaten zu einem funktionierenden Ganzen > zusammenzufuegen..lieg ich mit dem Punkt richtig? Ja. Der Erfolg von Photorec hängt immer von der Fragmentierung der Festplatte ab. > Nachtrag: > Nach bisherigen Recherchen stelle ich mir vor eine solche Vorgehensweise > koennte Erfolg haben: > 1. Kompletten Inhalt der Platte erstmal mit dd in Sicherheit bringen Gut. ddrescue wäre besser, falls sich bei der Aktionen defekte Sektoren zeigen. > 2. Platte wie gewuenscht mit einer frischen Partitionstabelle > beschreiben, die eine einzige NTFS-Partition ausweist. > 3. Diese frische Partitionstabelle dann mit sfdisk auslesen und sichern. > 4. Mit dd die in Schritt 1 gesicherten Daten zurueckschreiben. > 5. Mit sfdisk die ausgelesene Partitionstabelle schreiben. Die Schritte 2 bis 5 verstehe ich nicht. Testdisk suchen lassen. Nur wenn die gefundene Partition mit Hilfe der "p"-Taste ("list files") die erwarteten Inhalte zeigt, ist es überhaupt sinnvoll, das Image zu manipulieren. Ansonsten hilft Photorec oder eine Drittanbietersoftware. Photorec macht ja nur Fingerprinting, andere Produkte werten auch die Überreste von eventuell vorhandenen Metadaten (Master-File-Table) aus bzw. kombinieren die Suchansätze vielleicht.
:
Bearbeitet durch User
Arno schrieb: > Wenn du die Partition genau so anlegst, wie sie vorher war, kannst du > dir die Schritte 3-5 sparen. Denn wenn eine neue Partitionstabelle > geschrieben wird, wird auch nicht mehr als diese überschrieben. Auch wenn Du die Partition nach besten Infos wieder so herstellen wilsst, klappt es nicht. Einzige Möglichkeit, du versuchst mit R-Studio. Hab ich hier, und finde alles wieder, sofern der Datensektor nicht überschrieben wurde. Testdisk ect. kenn ich zwar, mache aber alles meist mit meinem Tool. Erfolgsquote bei hardwareintakten HDD > 80-90 %. Gerne kann ich mich dazu einschalten.
Arno schrieb: > Wenn du die Partition genau so anlegst, wie sie vorher war, kannst du > dir die Schritte 3-5 sparen. Denn wenn eine neue Partitionstabelle > geschrieben wird, wird auch nicht mehr als diese überschrieben. Der Punkt wird gegebenenfalls schwierig. Wie gesagt: Nicht meine Platte und der Nutzer ist wirklich nur ein einfacher Nutzer und achtet nach meinen Erfahrungen nicht so wirklich darauf, was er wie macht...;) Dementsprechend sind Fragen nach Details bei jenen Malen, wo ich ihm vorher bereits geholfen habe, sehr gerne mit: 'Weiss nicht' beantwortet worden, oder auch garnicht...:( Die Platte ist nun ziemlich betagt und ich weiss, dass der Mensch frueher nur mit Win unterwegs war. Ich habe eine aehnliche Platte, nur mit 250GB halb so gross, die bekam ich 2006 neu vom Discounter. Die Platte, um die es geht stammt nun vomselben Discounter. Damit schlussfolgere ich, dass die auch so um 2006/2007 in Dienst gegangen sein duerfte. Sollte sie nicht zwischenzeitlich neu formatiert worden sein, dann wurde die zu reparierende Partition hoechstwahrscheinlich mit den Standardeinstellungen des standardmaessigen Tools der damals aktuellen Winversion erzeugt. Das muesste ich dann reproduzieren.. > Dann drücke ich dir die Daumen, dass vom NTFS noch genug übrig ist, um > sortiert an die Daten zu kommen. > > MfG, Arno stammt Jo, Thx! Bin froh, dass es nicht die Meine ist ;)
Thomas S. schrieb: > Gerne kann ich mich dazu einschalten. Vielen Dank fuer das Angebot! Noch habe ich die Platte nicht in Haenden. Die kommt erst die Tage, morgen sehe ich den Besitzer aber und werde versuchen weitere Informationen aus ihm herauszubekommen ;) Wenn ich die Platte dann wirklich habe, werde ich berichten. Vorab nochmal: Danke!
Wenn Du retten willst, dann darf auf die Platte nur 'nicht schreibend' zugegriffen werden.
Thomas S. schrieb: > Wenn Du retten willst, dann darf auf die Platte nur 'nicht schreibend' > zugegriffen werden. Ist mir 150% klar! Wenn ich die habe, dann erstmal ddrescue, dann per testdisk/photorec analysieren, dabei in getrennten Vorgaengen versuchen, die begehrten Dateitypen herauszufischen. Je nach Erfolg dabei dann weitersehen. Nur schreiben werd' ich sicher auf die Platte erstmal nix. Hab' hier zur Zeit ausreichend Platz mit einer 4TB HDD, die ich fuer die ersten Versuche geretteten Kram wegzusichern verwenden kann.
Johannes U. schrieb: > Thomas S. schrieb: >> Wenn Du retten willst, dann darf auf die Platte nur 'nicht schreibend' >> zugegriffen werden. > > Ist mir 150% klar! > > Wenn ich die habe, dann erstmal ddrescue, dann per testdisk/photorec > analysieren, dabei in getrennten Vorgaengen versuchen, die begehrten > Dateitypen herauszufischen. Profis fertigen ein Image an und arbeiten dann mit dem...
Sheeva P. schrieb: > Profis fertigen ein Image an und arbeiten dann mit dem... Da ich mich in dem Sektor nun nicht als Profi beschreiben wuerde...;) Aber danke fuer den tipp!
Gab es da nicht einen Befehl, der den MBR neu beschreibt und zwar aus einem Backaup das das System anderweitig auf die Platte schreibt? Ich hatte das früher öfters machen müssen, als Partitionmagic schief ging.
NTFS speichert ja eine Kopie der Verwaltungsdaten im letzten Drittel der Partition. Es gibt entsprechende Tools, die damit die Partition wieder herstellen können. Daten in den überschriebenen Sektoren bleiben aber zerstört.
Ich hatte mal einen ähnlichen Fall im Bekanntenkreis. Habe so gut wie alles retten können (zumindest wurde nichts vermisst). Zuerst habe ich mittels ddrescue ein vollständiges Image der betroffenden 2Tb-Platte gezogen. Dieses Image habe ich als loopback gemountet und anschließend testdisk drauf los gelassen. dafür gibt es gute Anleitungen sowie ein Forum im Netz. Achtung: das Scannen dauert schon mal nen halben Tag. PhotoRec habe ich testweise auch mal eingesetzt, aber da kamen nur unsortierte Datei-Berge mit kaputten Namen zutage. Nachtrag: In meinen Notizen habe ich mir für testdisk das Vorgehen Analyse=>Quick search=> Deep Search notiert.
:
Bearbeitet durch User
Peter D. schrieb: > NTFS speichert ja eine Kopie der Verwaltungsdaten im letzten Drittel der > Partition. Es gibt entsprechende Tools, die damit die Partition wieder > herstellen können. Ok, hatte mit NTFS sonst noch nie wirklich zu tun, benoetige selber kein Format zum Austausch zwischen Linux <--> Win, da ich hier ausschliesslich auf Linux unterwegs bin. Werd mal nach solchen Werkzeugen suchen. Aber eventuell hast Du ja den Namen eines solchen Prgramms parat? > Daten in den überschriebenen Sektoren bleiben aber > zerstört. Schon klar, das duerfte jedoch nur rund 2GB betreffen, dann groesser ist so ein geschriebenes Image eigentlich nicht, der grosse Rest (465 - 2 = 463) wurde ja soweit nicht angetastet.
Le X. schrieb: > Ich hatte mal einen ähnlichen Fall im Bekanntenkreis. > Habe so gut wie alles retten können (zumindest wurde nichts vermisst). > > Zuerst habe ich mittels ddrescue ein vollständiges Image der > betroffenden 2Tb-Platte gezogen. > Dieses Image habe ich als loopback gemountet und anschließend testdisk > drauf los gelassen. > dafür gibt es gute Anleitungen sowie ein Forum im Netz. > Achtung: das Scannen dauert schon mal nen halben Tag. Ich weiss, musste testdisk schonmal auf 4TB loslassen und das dauerte ueber 2 Tage... Und ich hatte nicht anderweitig ausreichend Platz fuer ein Image.. > PhotoRec habe ich testweise auch mal eingesetzt, aber da kamen nur > unsortierte Datei-Berge mit kaputten Namen zutage. ;) Wie gesagt, da hatte ich soweit Glueck damit, dass ich selber damit nur mpg-streams retten musste. Das war wohl auch eine Schweinearbeit, weil Berge von Teildateien mit fortlaufenden aber zusammenhanglosen Namen dabei herauskamen, und ich mir dann all die Stuecke ansehen musste, um sie so dem jeweiligen Film zuzuordnen und dann wieder mit ffmpeg zusammenzukleben ... Ich hoffe, sowas passiert mir nicht wieder, aber fuer den Fall das doch, schreibe ich mir gerade ein Skript, dass mir dann in so einem Fall fuer jedes einzelne mpg-Fragment mittels ffmpeg-Aufruf die ProgramID (es handelt sich um dvb-c Aufnahmen) herausfischt und so eine grobe Vorsortierung erlaubt. > Nachtrag: > In meinen Notizen habe ich mir für testdisk das Vorgehen > Analyse=>Quick search=> Deep Search > notiert. Standardvorgehen
Peter D. schrieb: > NTFS speichert ja eine Kopie der Verwaltungsdaten im letzten Drittel der > Partition. Meines Wissens nach ausschließlich eine Kopie des Bootsektors, aber keine Kopien von zentralen Verwaltungsstrukturen, insbesondere natürlich der MFT. Liege ich hier falsch? Falls ja, wäre ich sehr daran interessiert, herauszufinden, wie man diese Kopien findet. > Es gibt entsprechende Tools, die damit die Partition wieder > herstellen können. Daten in den überschriebenen Sektoren bleiben aber > zerstört. Das ist ja klar. Blöd halt, wenn die MFT überschrieben wurde, dann ist der Einstieg in's Filesystem weg. Eben deswegen wäre eine auffindbare Kopie eine sehr interessante Sache.
Hallo Peter D., Peter D. schrieb: > NTFS speichert ja eine Kopie der Verwaltungsdaten im letzten Drittel der > Partition. Es gibt entsprechende Tools, die damit die Partition wieder > herstellen können. Daten in den überschriebenen Sektoren bleiben aber > zerstört. nein, es sind bei NTFS nur ein paar Einträge der MFT, die gespiegelt werden, nicht die ganze MFT. c-hater schrieb: > Meines Wissens nach ausschließlich eine Kopie des Bootsektors, Ja. > aber > keine Kopien von zentralen Verwaltungsstrukturen, insbesondere natürlich > der MFT. Nein, nur eine Kopie von ein paar wenigen MFT-Einträgen, nicht aber die MFT komplett. > Liege ich hier falsch? Falls ja, wäre ich sehr daran interessiert, > herauszufinden, wie man diese Kopien findet. Die Kopie findest Du z.B. durch lineares Suchen der Festplatte per Fingerprinting. Beispielsweise AA 55 oder so ähnlich am Ende des Bootsektors.
MFT mirror enthält nur einen Teil der MFT. https://whereismydata.wordpress.com/2009/06/05/forensics-what-is-the-mft-mirror/
Peter D. schrieb: > MFT mirror enthält nur einen Teil der MFT. > > https://whereismydata.wordpress.com/2009/06/05/forensics-what-is-the-mft-mirror/ OK. Das ist leider ziemlich nutzlos, wenn die MFT überschrieben wurde. Man kann damit im Prinzip nur relativ sicher feststellen, dass das passiert ist und somit letzte Zweifel aus der Analyse des Bootsektors und seiner Kopie ausräumen. Der Einstieg in's Filesystem ist aber unwiederbringlich wech. Sieht mir insgesamt mehr nach einem Überbleibsel vom Debugging aus als nach echter Redundanz.
Ich hab jetzt mal mit den entsprechenden Begriffen gesucht und dies
hier:
>https://d.i10o.ca/writing/ntfs-mft-mftmirr/
gefunden.
Komplizierte und komplexe Prozedur, schien allerdings dort Erfolg zu
haben.
Doch wie gesagt, ich lass mich ueberaschen, wenn die Platte zu mir kommt
und die Arbeit ansteht.
Es ist ja schon viel geschrieben worden, was ich jetzt nicht alles bis ins Kleinste gelesen habe, man möge mir verzeihen, wenn ich den einen oder anderen Punkt wiederhole. Als allererstes empfehle ich, zur Wiederherstellung NUR Linux einzusetzen, alternativ eines der besseren kommerziellen „Wiederherstellungswerkzeuge“ für Windows, da kann ich aber keine Empfehlung abgeben. Ich würde auch nur auf einer Kopie arbeiten, also zuallererst mit „dd“ ein Abbild der originalen Platte abspeichern und NUR DAS „beackern“. Der „moderne“ Linux-Treiber NTFS-3G hat zahlreiche Optionen, darunter auch die, die unsichtbaren Systemdateien anzeigen zu lassen, wie $MFT. Vom Erhaltungszustand dieser Datei hängt fast alles ab. „Testdisk“ wird wahrscheinlich nicht weiterhelfen, da es bekannte Strukturen sucht, um den Anfang der Patitionen wiederzufinden, wobei wir hier davon ausgehen müssen, daß an der Stelle jetzt das falsche steht, nämlich das Zeugs von dem „drübergebügelten“ Linux und nicht mehr der Anfang der NTFS-Partition. Hier hilft aber raten und da die Daten am Anfang ohnehin weg sein dürften, ist es womöglich nicht schlimm, da nicht genau zu treffen. Einfach eine neue Partition „ganze Festplatte“ machen und fertig. Wenn das ein moderner Datenträger mit GPT war, besteht hingegen Anlaß zur Hoffnung. Dann könnte es sein, daß am Plattenanfang genügend Platz verschwendet worden und der Kopiervorgang vielleicht rechtzeitig abgebrochen worden war, so daß das NTFS komplett erhalten ist. Dann hilft „Testdisk“. „Photorec“ versucht nur, ein paar „strukturell bekannte“ Dateiformate wiederherszustellen, jedoch ohne Namen – die kann man aber bei NTFS anhand der Inode-Nummern wiederfinden, das habe ich schonmal gemacht. Mir hatte damals „INDXParse.py“ weitergeholfen: https://github.com/williballenthin/INDXParse Viele Grüße, Christoph
Hallo Christoph F., Christoph F. schrieb: > „Photorec“ versucht nur, > ein paar „strukturell bekannte“ Dateiformate > wiederherszustellen, jedoch ohne Namen – "Nur" "strukturelle bekannte" Dateiformate. Ja, 300 Dateifamilien mit 480 Formaten ist auch gar nichts. Über diese wertschätzende Aussage wird sich Christophe Grenier sicherlich freuen, der mit Photorec ein kostenloses, quelloffenes Programm geschaffen hat, das kommerzielle Fingerprinting-Wettbewerber in der Wiederherstellungsleistung in die Schranken weist. Photorec ist ein Armaggedon-Werkzeug, das eine Wiederherstellungschance bietet, wenn die Metadaten alle futsch sind. > die kann man aber bei NTFS > anhand der Inode-Nummern wiederfinden, I-Node-Nummern gibt es bei NTFS nicht, das ist Linux-Terminologie. > das habe ich schonmal gemacht. > Mir hatte damals „INDXParse.py“ weitergeholfen: > https://github.com/williballenthin/INDXParse Christoph F. schrieb: > Wenn das ein moderner Datenträger mit GPT war, besteht hingegen Anlaß > zur Hoffnung. Dann könnte es sein, daß am Plattenanfang genügend Platz > verschwendet worden und der Kopiervorgang vielleicht rechtzeitig > abgebrochen worden war, so daß das NTFS komplett erhalten ist. Dann > hilft „Testdisk“. Die Erklärung passt meines Erachtens nicht. Meiner Meinung nach kann INDXParse.py nur arbeiten, wenn eine MFT vorhanden ist, denn das Argument "filename" beinhaltet ja einen Pfadnamen, der ausgewertet werden muss: Zitat aus https://github.com/williballenthin/INDXParse#readme [... The full command line help is included here: INDX $ python INDXParse.py -h usage: INDXParse.py [-h] [-c | -b] [-d] filename Parse NTFS INDX files. positional arguments: filename Input INDX file path ...] Was das Argument "am Plattenanfang genügend Platz verschwendet wird" angeht, so hat eine moderne Festplatte den Verschnitt, der typischerweise nicht mehr als die Alignment-Hausnummer von 1Mbyte? beträgt, in einer Hundertstelsekunde überschrieben. Die Chance besteht eher darin, dass die MFT beim Defragmentieren mal nach hinten verlegt wurde und so vor überschreiben geschützt wurde. Der GPT-Vorteil besteht darin, dass sich ein zweites Exemplar der Partitionstabelle am Festplattenende befindet, das vermutlich noch nicht überschrieben wurde.
:
Bearbeitet durch User
Christoph F. schrieb: > Es ist ja schon viel geschrieben worden, was ich jetzt nicht alles bis > ins Kleinste gelesen habe, man möge mir verzeihen, wenn ich den einen > oder anderen Punkt wiederhole. > > Als allererstes empfehle ich, zur Wiederherstellung NUR Linux > einzusetzen, alternativ eines der besseren kommerziellen > „Wiederherstellungswerkzeuge“ für Windows, da kann ich aber keine > Empfehlung abgeben. Ich würde auch nur auf einer Kopie arbeiten, also > zuallererst mit „dd“ ein Abbild der originalen Platte abspeichern und > NUR DAS „beackern“. Es wird Linux only, weil ich das habe und soweit kenne. Win hab ich wohl auch, aber nur weil jeweils beim Rechner dabeigewesen, diese Platten liegen und schlummern und wenn es irgend geht, bleibt das auch genauso. > Der „moderne“ Linux-Treiber NTFS-3G hat zahlreiche Optionen, darunter > auch die, die unsichtbaren Systemdateien anzeigen zu lassen, wie $MFT. > Vom Erhaltungszustand dieser Datei hängt fast alles ab. Jo, ntfs-3g und diese Dinge kommen auch Alle in meinem letzten Link vor. > Wenn das ein moderner Datenträger mit GPT war, besteht hingegen Anlaß > zur Hoffnung. Dann könnte es sein, daß am Plattenanfang genügend Platz > verschwendet worden und der Kopiervorgang vielleicht rechtzeitig > abgebrochen worden war, so daß das NTFS komplett erhalten ist. Dann > hilft „Testdisk“. Ich wuerd mal sagen: Mit Sicherheit kein GPT. Ist eben auch kein moderner Datentraeger, wie gesagt urspruenglich geschaetzt von um die 2007, verbaut ist eine 640GB Seagate, kam um 2015 gebraucht zum Nutzer und wurde dann unter Linux - wahrscheinlich mit gparted - eingerichtet. > „Photorec“ versucht nur, ein paar „strukturell bekannte“ Dateiformate > wiederherszustellen, jedoch ohne Namen – die kann man aber bei NTFS > anhand der Inode-Nummern wiederfinden, das habe ich schonmal gemacht. > > Mir hatte damals „INDXParse.py“ weitergeholfen: > https://github.com/williballenthin/INDXParse > > Viele Grüße, Christoph Danke fuer Deine Tipps und Anmerkungen!
Peter M. schrieb: > Hallo Christoph F., > > Christoph F. schrieb: >> „Photorec“ versucht nur, >> ein paar „strukturell bekannte“ Dateiformate >> wiederherszustellen, jedoch ohne Namen – > > "Nur" "strukturelle bekannte" Dateiformate. > Ja, 300 Dateifamilien mit 480 Formaten ist auch gar nichts. > Über diese wertschätzende Aussage wird sich Christophe Grenier > sicherlich freuen, der mit Photorec ein kostenloses, quelloffenes > Programm geschaffen hat, das kommerzielle Fingerprinting-Wettbewerber in > der Wiederherstellungsleistung in die Schranken weist. > Photorec ist ein Armaggedon-Werkzeug, das eine Wiederherstellungschance > bietet, wenn die Metadaten alle futsch sind. Ich fuer meinen Teil bin sehr dankbar fuer Testdisk und photorec. Erfolgsraten von 100% hatte ich bereits damit und auch wenn mir von den zuletzt verlorenen mpgs wohl noch einige fehlen und ich somit da irgendwo bei 90% liege, haben die Werkzeuge ausgezeichnete Arbeit geleistet (im Gegensatz zu Scalpel, was im Vergleich bei der Aufgabe durchfiel). Und die fehlenden 10% koennte ich demnaechst eventuell auch noch reduzieren, weil ich zunaechst zusammengesetzt habe, was aus max. 4-5 eher grossen Fragmenten bestand. Da ist aber noch ein Haufen kleiner Dateien auf die ich wenns fertig ist mein Skript loslasse um da eine Sortierung reinzubringen und anschliessend dann ohne gross Memory spielen zu muessen die Puzzlestuecke zu einem Teil der 10% zusammenzusetzen. Ohne Photorec haette ich Alles davon in den Wind schiessen muessen.
Hallo Johannes U., Johannes U. schrieb: > Ich fuer meinen Teil bin sehr dankbar fuer Testdisk und photorec. > Erfolgsraten von 100% hatte ich bereits damit und auch wenn mir von den > zuletzt verlorenen mpgs wohl noch einige fehlen und ich somit da > irgendwo bei 90% liege, haben die Werkzeuge ausgezeichnete Arbeit > geleistet (im Gegensatz zu Scalpel, was im Vergleich bei der Aufgabe > durchfiel). > Und die fehlenden 10% koennte ich demnaechst eventuell auch noch > reduzieren, weil ich zunaechst zusammengesetzt habe, was aus max. 4-5 > eher grossen Fragmenten bestand. > Da ist aber noch ein Haufen kleiner Dateien auf die ich wenns fertig ist > mein Skript loslasse um da eine Sortierung reinzubringen und > anschliessend dann ohne gross Memory spielen zu muessen die > Puzzlestuecke zu einem Teil der 10% zusammenzusetzen. > > Ohne Photorec haette ich Alles davon in den Wind schiessen muessen. vielen Dank für diesen positiven Erfahrungsbericht! Christophe Grenier wird sich drüber freuen!
Johannes U. schrieb: > Das war wohl auch eine Schweinearbeit, weil Berge von Teildateien mit > fortlaufenden aber zusammenhanglosen Namen dabei herauskamen, und ich > mir dann all die Stuecke ansehen musste, um sie so dem jeweiligen Film > zuzuordnen und dann wieder mit ffmpeg zusammenzukleben ... Das passiert mir mit R-Studio nicht.
Hallo Thomas S., Thomas S. schrieb: > Johannes U. schrieb: >> Das war wohl auch eine Schweinearbeit, weil Berge von Teildateien mit >> fortlaufenden aber zusammenhanglosen Namen dabei herauskamen, und ich >> mir dann all die Stuecke ansehen musste, um sie so dem jeweiligen Film >> zuzuordnen und dann wieder mit ffmpeg zusammenzukleben ... > > Das passiert mir mit R-Studio nicht. R-Studio ist mit Photorec nicht vergleichbar. R-Studio ist ein Kombiprodukt. Jede Wiederherstellungssoftware die mehr Informationen auswertet, z.B. Reste von Metadaten, kann reine Fingerprintingsoftware schlagen. Deren Erfolg ist maßgeblich von der Fragmentierung der Dateien auf dem Festplatten-Probanden abhängig.
Thomas S. schrieb: > Johannes U. schrieb: >> Das war wohl auch eine Schweinearbeit, weil Berge von Teildateien [...] > Das passiert mir mit R-Studio nicht. Sicherlich ein Vorteil, doch handelt es sich dabei wohl kaum um Freeware und damit hat eben lange nicht jeder diese Moeglichkeit.. Den Punkt sollte man meines Erachtens stets im Blick behalten.
Hallo Thomas S., Thomas S. schrieb: > ohannes U. schrieb: >> Das war wohl auch eine Schweinearbeit, weil Berge von Teildateien mit >> fortlaufenden aber zusammenhanglosen Namen dabei herauskamen, und ich >> mir dann all die Stuecke ansehen musste, um sie so dem jeweiligen Film >> zuzuordnen und dann wieder mit ffmpeg zusammenzukleben ... > > Das passiert mir mit R-Studio nicht. R-Studio fiel in einem alte c't oder Computerbildtest auf, weil es ein Vielfaches der eigentlich vorhandenen zu rettenden Datenmenge produzierte. Vielleicht ist ja R-Studio mittlerweile vom Saulus zum Paulus gewandelt?
Ich arbeite gerade damit, meine 2TB zu restaurieren. Wo natürlich JEDE Software auf der Strecke bleibt, ist, wenn die HDD Defekte aufweist. Dann kommt auch eine Glaskugel nicht weiter.
Johannes U. schrieb: > ich erhalte wahrscheinlich die Tage eine externe olle 500GB PLatte, > welche urspruenglich wohl eine einzige NTFS-Partition beherbergte. > > Der Nutzer dieser Platte hat dann wohl dummerweise die externe Platte im > System eingehaengt gehabt, als er den Versuch unternahm, ein > Linux-Liveimage auf einen Stick zu buegeln...und natuerlich statt dem > Stick die Platte getroffen. Das ist ein typischer Fall von "Man muß wissen, was man tut". Und die richtigen Werkzeuge verwenden. Wenn man Buchstabenbandwürmer in schwarze Fenster eintippt, passiert das eben leicht. Intelligente Tools bieten da nur den Stick an. Auch bei DVD-Linux Distributionen wird da nur der Flash angeboten. Die Bestrafung folgt auf dem Fuße. > Bis jetzt sind mir leider in Erzaehlungen bestenfalls halbe > Salamischeibchen serviert worden und ich muss mir den tatsaechlichen > Sachverhalt irgendwie zusammenreimen :( > > So weiss ich immer noch nicht, ob der Nutzer den Fehler zwischendurch > bemerkt und die Prozedur abgebrochen hat. > Ebenfalls ist mir nicht bekannt, welches Tool er zum Buegeln des Images > anwendete, kann unter Win genausogut wie unter Linux stattgefunden > haben... Diese Daten sind wohl das Mindeste, bevor man anfangen kann. Wenn er nicht liefert, Finger weg!
Peter M. schrieb: > Hallo Christoph F., > > Christoph F. schrieb: >> „Photorec“ versucht nur, >> ein paar „strukturell bekannte“ Dateiformate >> wiederherszustellen, jedoch ohne Namen – > > "Nur" "strukturelle bekannte" Dateiformate. > Ja, 300 Dateifamilien mit 480 Formaten ist auch gar nichts. > Über diese wertschätzende Aussage wird sich Christophe Grenier > sicherlich freuen, der mit Photorec ein kostenloses, quelloffenes > Programm geschaffen hat, das kommerzielle Fingerprinting-Wettbewerber in > der Wiederherstellungsleistung in die Schranken weist. > Photorec ist ein Armaggedon-Werkzeug, das eine Wiederherstellungschance > bietet, wenn die Metadaten alle futsch sind. Mach' mal halblang; es ging hier nicht darum, meines Namensvetters Leistung herabzuwürdigen, sondern darum, daß das Teil eben dafür da ist, aus dem „Rohtext“ auf der Platte noch was HOFFENTLICH sinnvolles rauszuschneiden, was es auch sehr gut macht. Dennoch bekommt man damit viel Datenmüll und wenig Ausbeute, weil eben auch ein umkopiertes oder gelöschtes Bild „nach JPEG aussieht“ und daher gefunden wird, auch wenn es unvollständig ist. Sofern Verwaltungsinformationen übrig geblieben sind, ist es besser, diese zu nutzen. >> die kann man aber bei NTFS >> anhand der Inode-Nummern wiederfinden, > > I-Node-Nummern gibt es bei NTFS nicht, das ist Linux-Terminologie. Die Terminologie schon, es gibt bei Windows und auch sonstüberall auch diese „Zeiger auf die Dateien“. >> das habe ich schonmal gemacht. > >> Mir hatte damals „INDXParse.py“ weitergeholfen: >> https://github.com/williballenthin/INDXParse > > Christoph F. schrieb: >> Wenn das ein moderner Datenträger mit GPT war, besteht hingegen Anlaß >> zur Hoffnung. Dann könnte es sein, daß am Plattenanfang genügend Platz >> verschwendet worden und der Kopiervorgang vielleicht rechtzeitig >> abgebrochen worden war, so daß das NTFS komplett erhalten ist. Dann >> hilft „Testdisk“. > > Die Erklärung passt meines Erachtens nicht. Meiner Meinung nach kann > INDXParse.py nur arbeiten, wenn eine MFT vorhanden ist, denn das > Argument "filename" beinhaltet ja einen Pfadnamen, der ausgewertet > werden muss: Da muß man was tiefer bohren, der Pfadname steht auch in den Indexdateien und das ist eine ganze „Programmfamilie“. Ich hatte – soweit ich mich erinnere – damals mit Photorec (oder noch was anderem) Dateien gerettet, welche ansonsten verloren gewesen wären und deren Meta-Daten hernach mit diesen Programmen wiederhergestellt. > Was das Argument "am Plattenanfang genügend Platz verschwendet wird" > angeht, so hat eine moderne Festplatte den Verschnitt, der > typischerweise nicht mehr als die Alignment-Hausnummer von 1Mbyte? > beträgt, in einer Hundertstelsekunde überschrieben. Die Chance besteht > eher darin, dass die MFT beim Defragmentieren mal nach hinten verlegt > wurde und so vor überschreiben geschützt wurde. > > Der GPT-Vorteil besteht darin, dass sich ein zweites Exemplar der > Partitionstabelle am Festplattenende befindet, das vermutlich noch nicht > überschrieben wurde. Damit meinte ich eher diese sinnlosen EFI-Partitionen, die bei kommerziell vorformatierten Datenträgern oft vorkommen: -----8<----------------------------------------- Festplatte /dev/sdb: 1,8 TiB, 2000365289472 Bytes, 3906963456 Sektoren Disk model: My Passport 25E1 Einheiten: Sektoren von 1 * 512 = 512 Bytes Sektorgröße (logisch/physikalisch): 512 Bytes / 512 Bytes E/A-Größe (minimal/optimal): 512 Bytes / 512 Bytes Festplattenbezeichnungstyp: gpt Festplattenbezeichner: 048D8DDC-1A03-4D0B-AB82-41B18A6CDA0C Gerät Anfang Ende Sektoren Größe Typ /dev/sdb1 40 409639 409600 200M EFI-System /dev/sdb2 411648 3906961407 3906549760 1,8T Microsoft Basisdaten -----8<----------------------------------------- Hier hat man also 200 verschwendete MB PLUS die GPT-Struktur am Anfang, die FAT-formatiert, unter Windows versteckt und ungenutzt sind. Da besteht die Chance, daß (bei Abbruch nach der Schrecksekunde) das NTFS-Dateisystem ab Sektor 411648 noch da ist.
So, weil „hier“ immer alles gleich in eien Glaubenskrieg mündet, nochmals in aller Deutlichkeit die Gründe meiner Überlegungen/Empfehlungen: Die Grenier-Programme kratzen den Datenträger nach magischen Zahlen ab und versuchen daraus bestmöglich Wiederherstellungs-Informationen zu gewinnen – und das so ziemlich unübertroffen gut, was ich nie in Abrede stellen wollte. Sollten jedoch die Metadaten mehr oder weniger vollständig erhalten geblieben sein, wird es besser sein, darauf zurückzugreifen, was diese Programe nicht tun. Wenn das Teil also niemals umpartitioniert wurde UND die Partitionsanfänge nicht überschrieben wurden, wird Testdisk die ursprüngliche Partitionierung fehlerlos wiederherstellen. Das ist hier NICHT der Fall: es wurde die Struktur dieses Linux-Abbildes drübergeschrieben, die ERSTE(N) gefundene(n) Partition(en) dürfte(n) also falsch sein. Unter Umständen kommt man durch „Raten“ besser ans Ziel: einfach mit Fdisk eine neue Partitionstabelle schreiben, die behauptet, der ganze Datenträger wäre ab Sektor 2048 NTFS (äh – Typ 0x07…) Wenn das Laufwerk „mittelalt“ ist, sollte das Ergebnis stimmen. Wenn es zusätzlich MFT-Reste gibt, sollte man die hernehmen, statt nur Photorec. Photorec wird beispielsweise auch Bruchstücke gelöschter Dateien finden. Das von mir genannte Programmpaket ist dafür gedacht, ZUSÄTZLICH die Index-Dateien auszuwerten. Wahrscheinlich muß man da ein Skript drumrumschreiben, damit einem das was nützt. Ich hatte damals damit offensichtlich schwachsinnige Zeitstempel korrigieren können. Die gute Nachricht ist hier: gerade NTFS hat vergleichsweise viele Metadaten, die ausgenutzt werden können. (Leider weiß kaum jemand so genau wie – einschließlich MS selber, denen wahrscheinlich das meiste Wissen über ihr eigenes Dateisystem selber abhandengekommen ist.) Viele Grüße, Christoph
:
Bearbeitet durch User
michael_ schrieb: >> So weiss ich immer noch nicht, ob der Nutzer den Fehler zwischendurch >> bemerkt und die Prozedur abgebrochen hat. >> Ebenfalls ist mir nicht bekannt, welches Tool er zum Buegeln des Images >> anwendete, kann unter Win genausogut wie unter Linux stattgefunden >> haben... > > Diese Daten sind wohl das Mindeste, bevor man anfangen kann. > Wenn er nicht liefert, Finger weg! Ist doch völlig egal, ob du mit nem Porsche oder Benz einen Crash baust. Die Werkstatt (hier das entsprechende Tool) ist es, was es wieder richten muss.
Johannes U. schrieb: > Noch habe ich die Platte nicht in Haenden. > Die kommt erst die Tage, morgen sehe ich den Besitzer aber und werde > versuchen weitere Informationen aus ihm herauszubekommen ;) Vielleicht ein guter Zeitpunkt, ihm das Thema Backup schmackhaft zu machen. Ich hatte noch nie die Notwendigkeit, einen Datenträger retten zu müssen.
Hallo Christoph F., Christoph F. schrieb: > Mach' mal halblang; es ging hier nicht darum, meines Namensvetters > Leistung herabzuwürdigen, sondern darum, daß das Teil eben dafür da ist, > aus dem „Rohtext“ auf der Platte noch was HOFFENTLICH sinnvolles > rauszuschneiden, was es auch sehr gut macht. Danke! >Dennoch bekommt man damit > viel Datenmüll und wenig Ausbeute, weil eben auch ein umkopiertes oder > gelöschtes Bild „nach JPEG aussieht“ und daher gefunden wird, auch wenn > es unvollständig ist. Sofern Verwaltungsinformationen übrig geblieben > sind, ist es besser, diese zu nutzen. Ja. > >>> die kann man aber bei NTFS >>> anhand der Inode-Nummern wiederfinden, >> >> I-Node-Nummern gibt es bei NTFS nicht, das ist Linux-Terminologie. > > Die Terminologie schon, es gibt bei Windows und auch sonstüberall auch > diese „Zeiger auf die Dateien“. Diese Zeiger nennt Microsoft "file records". > >>> das habe ich schonmal gemacht. >> >>> Mir hatte damals „INDXParse.py“ weitergeholfen: >>> https://github.com/williballenthin/INDXParse >> >> Christoph F. schrieb: >>> Wenn das ein moderner Datenträger mit GPT war, besteht hingegen Anlaß >>> zur Hoffnung. Dann könnte es sein, daß am Plattenanfang genügend Platz >>> verschwendet worden und der Kopiervorgang vielleicht rechtzeitig >>> abgebrochen worden war, so daß das NTFS komplett erhalten ist. Dann >>> hilft „Testdisk“. >> >> Die Erklärung passt meines Erachtens nicht. Meiner Meinung nach kann >> INDXParse.py nur arbeiten, wenn eine MFT vorhanden ist, denn das >> Argument "filename" beinhaltet ja einen Pfadnamen, der ausgewertet >> werden muss: > > Da muß man was tiefer bohren, der Pfadname steht auch in den > Indexdateien Das wäre mir neu, inhaltlich finde ich das nicht nachvollziehbar. Aus meiner Dokumentation zu NTFS finde ich auch nichts dazu. > und das ist eine ganze „Programmfamilie“. Ich hatte – > soweit ich mich erinnere – damals mit Photorec (oder noch was anderem) > Dateien gerettet, welche ansonsten verloren gewesen wären und deren > Meta-Daten hernach mit diesen Programmen wiederhergestellt. > >> Was das Argument "am Plattenanfang genügend Platz verschwendet wird" >> angeht, so hat eine moderne Festplatte den Verschnitt, der >> typischerweise nicht mehr als die Alignment-Hausnummer von 1Mbyte? >> beträgt, in einer Hundertstelsekunde überschrieben. Die Chance besteht >> eher darin, dass die MFT beim Defragmentieren mal nach hinten verlegt >> wurde und so vor überschreiben geschützt wurde. >> >> Der GPT-Vorteil besteht darin, dass sich ein zweites Exemplar der >> Partitionstabelle am Festplattenende befindet, das vermutlich noch nicht >> überschrieben wurde. > > Damit meinte ich eher diese sinnlosen EFI-Partitionen, die bei > kommerziell vorformatierten Datenträgern oft vorkommen: > > -----8<----------------------------------------- > Festplatte /dev/sdb: 1,8 TiB, 2000365289472 Bytes, 3906963456 Sektoren > Disk model: My Passport 25E1 > Einheiten: Sektoren von 1 * 512 = 512 Bytes > Sektorgröße (logisch/physikalisch): 512 Bytes / 512 Bytes > E/A-Größe (minimal/optimal): 512 Bytes / 512 Bytes > Festplattenbezeichnungstyp: gpt > Festplattenbezeichner: 048D8DDC-1A03-4D0B-AB82-41B18A6CDA0C > > Gerät Anfang Ende Sektoren Größe Typ > /dev/sdb1 40 409639 409600 200M EFI-System > /dev/sdb2 411648 3906961407 3906549760 1,8T Microsoft Basisdaten > -----8<----------------------------------------- > > Hier hat man also 200 verschwendete MB PLUS die GPT-Struktur am Anfang, > die FAT-formatiert, unter Windows versteckt und ungenutzt sind. > > Da besteht die Chance, daß (bei Abbruch nach der Schrecksekunde) das > NTFS-Dateisystem ab Sektor 411648 noch da ist. Danke, jetzt habe ich es verstanden. 200 MB wären so grob zwei Sekunden Schreibzeit, das passt das mit der Schrecksekunde.
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.