spr3ngmeister schrieb:
nein, den zweiten versuch mit ddrescue habe ich noch nicht gestartet, da ich befürchtet habe, mit dem --force den bestehenden klon und daher den ersten durchgang zu überschreiben.
Mit der Option --reverse sollte das erst dann passieren, wenn Du den Teil erreicht hat, der sowieso schon geklont wurde, damit fängt ddrescue ja von hinten an.
spr3ngmeister schrieb:
ich würde also den zweiten durchgang starten, mit
HTML:
ddrescue --force -d -r3 -v /dev/sdc /dev/sdd /mnt/logstick/ddrescue.log
Das kannst Du versuchen, mache zur Sicherheit vorher eine Kopie des Logfiles.
spr3ngmeister schrieb:
in den letzten 3 stunden habe ich DMDE über den angelegten klon laufen lassen, er hat in dieser zeit ca. eine million von 900 millionen headern, oder welche einheiten das auch sind, gescannt. dabei 400 jpgs gefunden. das wird also dauern.
Probiere halt mehere Tools aus, aber je nachdem wie weit der erste Versuch gekommen ist, stehen die Chance mehr oder weniger gut, dass auch der MFT mitkopiert wurden und das ist fürs Recovery eine wichtige Metadatei von NTFS, die steht gewöhnlich etwa in der Mitte des Adressbereiches eines Volumens.
spr3ngmeister schrieb:
könnt ihr also empfehlen, mit der obenstehenden eingabe ddrescue nochmals laufen zu lassen? wenn das logfile gemountet ist, wird ddrescue den ersten durchgang wohl fortsetzen können..?
So sollte es laut Anleitung sein, was im mapfile steht wird übersprungen, da diese Bereiche ja schon kopiert wurden, bzw es zumindest erfolglos versucht wurde.
spr3ngmeister schrieb:
und gibt es eine möglichkeit, den ersten sektor irgendwie zu ersetzen / zu klonen? an dem liegt ja die lesbarkeit des gesamtlaufwerks.
Nein, wenn der nicht mehr lesbar ist, dann kommst Du auch nicht mehr an die Daten die dort gestanden haben dran. Die HDD hat ja viele schwebende Sektoren und Schwebende Sektoren sind Sektoren deren Daten nicht mehr zur ECC passen. Da geben die HDD aber keine korrupten Daten sondern eine Lesefehler zurück, wenn man versucht solche schwebenden Sektoren zu lesen. Es kann auch anderen Gründe als defekte Oberflächen geben, z.B. einen Stromausfall während eines Schreibvorgang der dazu führt, dass eben nicht die ganze Daten plus der neuen ECC geschrieben wurden oder wegen eines Stoßes oder Vibrationen ist der Kopf beim Schreiben aus der Spur gekommen und hat Daten auf der Nachbarspur überschrieben, aber bei der Anzahl ist ein Oberflächenfehler, ggf. zusammen oder in Konsequenz einer Problems der Köpfe die wahrscheinlichste Ursache, vielleicht hat die HDD auch einen Schlag bekommen oder ist gestützt.
Die Controller merken sich die schwebenden Sektoren und prüfen die Daten nach dem erneuten Schreiben auf diese Sektoren, dann verschwinden diese einfach oder werden eben durch Reservesektoren ersetzt, was hier bei 2 Sektoren auch schon der Fall war.
