HS Auslesen - Dr Ungeschickt hat zugeschlagen

[Uwe!]

@Gaston: die zwei Tools werde ich mal suchen und testen.
Danke!!!

[gaert]

Glückwunsch, freut mich für Dich! Aber denk immer dran: Du hattest riesen Glück im Unglück!

[Egonulf]

da hat sich ja noch ein richtiger experten thread gebildet hier (ernstgemeint!)

also die gute Nachricht ist: Ico aus anderem Projekt kopiert, alles geht, inkl. ETS Backup!

Ich bin, trotz massivem Zeiteinsatz, wieder glücklich und freue mich nun auf die kommende SSD :-)

[Gaston]

Ok, das dachte Ich mir denn ein Bitfehler ist bei JPEG als solches nicht zu erkennen. Ich müsste das Bild schon sehen um zu wissen wie wahrscheinlich eine Datenrettung möglich ist.

Das Problem bei JPEG ist dass der Algorithmus (bzw dessen Eckdaten) nicht fest vorgegeben ist, somit kann das gleiche unkomprimierte Bild das mit zwei unterschiedlichen Applikationen mit gleichen Enstellungen in JPEG abgespeichert wurde zu unterschiedlichen Ergebnissen führen. Ausserdem ist ein Rekonstruktion der Original Daten aus Fehlerhaften Daten sehr schwierig bis unmöglich.

JPEG ist ein mehrstufiges Verfahren wobei die wichtigsten DCT, Quantisierung und Komprimierung sind die in dieser Reihenfolge ausgeführt werden.

Dabei wird das Pixelbild in einen Frequenzraum überführt die aus einem DC und einem AC Teil besteht darauf hin wird ein Tiefpass angelegt der Je Nach Qualitätseinstellung die Frequenzen mehr oder weniger beschneidet.

Das Resultat wird dann noch mit Huffman komprimiert. Ein Fehler in den ersten beiden Schritten macht sich als Artefakt von 8x8 Pixel bemerkbar. Wird die fertige Datei beschädigt wirk sich der Fehler zuerat auf den Huffman Algorithmus aus. Dis bedeutet dass ein einzelnes Bit mehrere Bits in den entpackten Daten beschädigen kann.

Nun gibt es tool sdie versprechen die zu können wie z.B. Picturte Doctor aber Ich glaub nicht dass da shier wa sbringen wird (schaden wird's wohl auch nicht). Interessant ist auch noch VG JPEG-Repair, der repariert nicht aber nennt die Chance mit welcher eine Datei repariert werden kann. Die Reparatur selbst wird dann manuell vom Autor durchgeführt.

Schlussendlich ist es so als wenn Du einen Satz mit einem Schlüssel gleicher Länge per XOR verschlüsselst. Dies ist unknackbar da es immer einen Schlüssel gibt für jeden möglichen Satz in jeder möglichen Sprache gleicher Länge.

Gruss,
Gaston

[Uwe!]

Gute Frage;-)

Also 100% genau weiß ich es nicht, es könnten auch mal 2 oder 3 bit sein...

Das "lustige" ist, die Bilder sind noch gut zu erkennen nur z. B. ab einer bestimmten Stelle die Farben "verschoben" oder auch mal ein Block ganz links, der eigentlich rechts sein müsste etc. Die Stellen sind "optisch" sehr einfach zu erkennen, weiß aber nicht, ob man sie maschinell einfach im JPG finden kann.
Und auch nicht, wie tief man in die JPG-Struktur einsteigen muss, um das per Hex-Editor zu finden.
Außerdem hab ich so vielleicht 100 JPGs in dieser Art....

[Gaston]

Führt jetzt zwar etwas weg vom Thema, aber kennt jemand ein Tool um einzelne gekippte Bits in einem JPG (halb-)maschinell zu korrigieren?

Du weist genau welches Bit, dann geht jeder HEX Editor. Und wenn Du nicht das genau Bit kennst wie weist Du dann dass es ein einzelnes Bit ist ?

Gruss,
Gaston

[Uwe!]

Das Phänomen kenne ich nur zu gut im Zusammenhang mit der Rettung von JPGs: Sieht zunächst alles gut aus, nur leider finden sich mitten im JPG gerne mal Bereiche/Blöcke mit Pixelsalat.

Führt jetzt zwar etwas weg vom Thema, aber kennt jemand ein Tool um einzelne gekippte Bits in einem JPG (halb-)maschinell zu korrigieren?

[Klaus Gütter]

ETS 4: Ich kam heute morgen nur dazu die Backup File in der ETS wieder her zu stellen. Es kam aus der ETS keine Beschwerde während und nach dem einlesen. Genaueres kann ich aber erst heute Abend sagen, mir hat die Zeit gefehlt.

Am besten als erstes dein Projekt als knxproj exportieren. Die Funktion liest alle relevanten Daten und du sieht sofort, wenn was nicht stimmt.

Gruß, Klaus

[MatthiasS]

Die hs3-Datei hat eine Checksumme. Wenn der Experte beim Öffnen nicht meckert, ist das schon mal ein gutes Zeichen.

[Egonulf]

Wie schon erwähnt wurde: Sind die Daten sehr wichtig und nicht ohne Weiteres zu ersetzen, würde ich immer eine professionelle Datenrettung beauftragen - ohne zunächst auf eigene Faust "Rettungsversuche" zu unternehmen. Das kann gut gehen oder auch nicht... Im Besten Fall klappt's, im schlimmsten Fall scheitert anschließend jegliche professionelle Rettung, weil der Defekt noch verschlimmert wurde.

Wie auch immer, Glückwunsch zur Rettung Eine Frage bleibt allerdings: Funktionieren die geretteten Daten auch? Bloß weil der Dateiname stimmt (stammt aus der FAT - hat mit den Nutzdaten rein garnichts zu tun), müssen die eigentlichen Daten nicht zwangsläufig korrekt sein. Diese Rettungstools können auch nicht zaubern: Wenn auch nur ein Bit fehlerhaft ist, kannst Du die Daten ohne tiefergehende Kenntnisse der Struktur vergessen. Die Rettungstools unterlaufen schließlich die Fehlerkorrektur wenn's nicht anders geht - und suggerieren somit "gerettet"...

Das Phänomen kenne ich nur zu gut im Zusammenhang mit der Rettung von JPGs: Sieht zunächst alles gut aus, nur leider finden sich mitten im JPG gerne mal Bereiche/Blöcke mit Pixelsalat.

bzgl. der Datenqualität:

ETS 4: Ich kam heute morgen nur dazu die Backup File in der ETS wieder her zu stellen. Es kam aus der ETS keine Beschwerde während und nach dem einlesen. Genaueres kann ich aber erst heute Abend sagen, mir hat die Zeit gefehlt.

Homerserver: Das Projekt habe ich eingelesen. Außer einer fehlenden ICO Datei hat heute morgen der Projektaufruf funktioniert, einschliesslich öffnen und kurzer Überflug im Q-Client.

Falls noch weitere Fehler auftreten poste ich....

[gaert]

Wie schon erwähnt wurde: Sind die Daten sehr wichtig und nicht ohne Weiteres zu ersetzen, würde ich immer eine professionelle Datenrettung beauftragen - ohne zunächst auf eigene Faust "Rettungsversuche" zu unternehmen. Das kann gut gehen oder auch nicht... Im Besten Fall klappt's, im schlimmsten Fall scheitert anschließend jegliche professionelle Rettung, weil der Defekt noch verschlimmert wurde.

Wie auch immer, Glückwunsch zur Rettung Eine Frage bleibt allerdings: Funktionieren die geretteten Daten auch? Bloß weil der Dateiname stimmt (stammt aus der FAT - hat mit den Nutzdaten rein garnichts zu tun), müssen die eigentlichen Daten nicht zwangsläufig korrekt sein. Diese Rettungstools können auch nicht zaubern: Wenn auch nur ein Bit fehlerhaft ist, kannst Du die Daten ohne tiefergehende Kenntnisse der Struktur vergessen. Die Rettungstools unterlaufen schließlich die Fehlerkorrektur wenn's nicht anders geht - und suggerieren somit "gerettet"...

Das Phänomen kenne ich nur zu gut im Zusammenhang mit der Rettung von JPGs: Sieht zunächst alles gut aus, nur leider finden sich mitten im JPG gerne mal Bereiche/Blöcke mit Pixelsalat.

[Gaston]

streitet euch nicht, ein Stück weit habt ihr doch beide Recht!

$

Streiten war auch nicht das Ziel !

Mir ging es darum zukünftige Leser des Threads vor zu schnellen Entscheidungen zu warnen.

Auch wenn Ich keine professionelle (sprich HW basierte) Datenrettung betreibe so war Ich doch bis Anfang der 2000er Jahre professionell sehr nah am Interna von Festplatten (SCSI/FC und Anfang von SATA) dran (zuerst im Support dann Entwickelung von grossen Storage Systemen.

Gruss,
Gaston

[Gaston]

das beste ist ja, dass diverse test Tools auch garkeinen fehler entdeckt haben, manche Bereiche aber definitiv tot sind (ETS4 ORdner z.B.)

ich habe gestern den entschluss gefasst nochmals selbst zu versuchen an die files dran zu kommen und wurde (nach dem ganzen Pech) eben mit Glück belohnt :-)

Habe dieses Post leider erst nach meinem letzten Post gelesen. Genau solche Aussagen sind das worüber Ich mir im letzten Post sorgen gemacht haben.

Es wird immer schnell davon ausgegangen WinDoof & Linunschalgbar. Das sieht aber manchmal nur so aus. Meine Befürchtung ist dass trotz augenscheinlicher gelungener Wiederherstellung einzelne Blöcke immer noch fehlerhaft sind. Windows gibt bei Lesefehler aus gutem Grund ziemlich schnell auf. Je öfter ein defekter Block wiederholt gelesen wird desto grösser die statistische Chance dass er einmal als korrekt erkannt und dennoch fehlerhaft ist. Die Chance ist bei mechanische Defekten grösser als bei "normalen" defekten und hängt vom verwendeten ECC Code ab.

Des weiteren wäre zu befürchten dass je nach verwendeter Methode der Block schlussendlich ohne ECC (READ LONG oder SET FEATURE) gelesen wurde.

etztendlich wäre es mit die proffessionelle Rettung nicht wert gewesen. da hätte ich vorher wirklich nochmals von vorne angefangen.

In dem Moment wo diese Entscheidung fällt ist natürlich alles "erlaubt".

Gruss,
Gaston

[Uwe!]

streitet euch nicht, ein Stück weit habt ihr doch beide Recht!

WENN man eine professionelle Datenrettung in Betracht zieht, dann selbstverständlich alle Stecker raus und Finger weg! Gar keine Frage!

Für den Privatanwender wird das aber fast immer zu teuer sein. Ich hatte mal ein ähnliches Problem und hab mir erst mal drei Angebote zur Datenrettung geholt. Und dann selbst Hand angelegt. Auch bei mir hab ich letzlich alles retten können, aber das kann natürlich auch mal schief gehen!

Und auch richtig, jede Sekunde, die die Platte läuft, beschädigt sie potentiell weiter.

[Gaston]

Gaston: Lies dir vielleicht die ersten drei Posts nochmal durch.

Ok, wenn Du nachden ersten 3 Posts schon aufgibst OK, aber Du solltest schon mal weiterlesen bevor du irgend etwas schreibst was keinen Sinn macht.

Die Aussagen auf die Ich mich bezogen habe kamen nach folgender Aussage des TE:

Fazit: Ich werde die Platte wohl zu einer prof. Datenrettung einsenden müssen. Die Zeit ist es nicht Wert

Und die ist eben nicht in den 3 ersten Posts.

Dass die Platte noch mit Linux lesbar war, war kein Glueck, sondern der TE hatte nur etwas weniger Pech als zunächst befürchtet.

Echt jetzt ? Er hatte kein Glück weil er weniger Pech hatte ? Das hier ist ein seriöses technisches Forum keine politische Bühne.

Moderne Platten sind aber erfahrungsgemäss unglaublich robust.

Das hat mit der Thematik nichts zu tun. Die Platten sind heute robuster in Bezug auf einen Defekt. Sind sie einmal defekt sind sie nicht robuster als alte Platten im Bezug auf Wiederherstellung. Wegen der grossen Dichte eher weniger.

Und es ist nun mal so: wenn Windows nicht mehr zurecht kommt, heisst es noch lange nicht dass alles verloren ist. Warum, das weiss nur der Bill.

Oh das ist klar, aber das weis nicht nur der Bill. Ausserdem ist ebenso klar dass man eine mechanische defekte Platte durch Wiederherstellungsversuche weiter beschädigen kann.

@Egonulf: Hast Du die Daten ergiebig getestet (z..B im Experten alles einmal geöffnet) ? Wurden die Daten mit cp kopiert ? Nicht dass es je nach verwendeter Methode später zu bösen Überraschungen kommt.