Um diese Antwort für andere Benutzer mit ähnlichen Problemen zumindest teilweise nützlich zu machen, lassen Sie uns die entscheidenden Teile Ihres Protokolls hier anführen:
# Rescue Logfile. Created by GNU ddrescue version 1.18.1 # Command line: ddrescue -f -d -R -r3 /dev/sde /dev/sdf /mnt/somedir/logfiles/log3.log # Start time: 2017-08-14 10:22:44 # Current time: 2017-08-14 12:13:09 # Copying non-tried blocks... Pass 1 (backwards) # current_pos current_status 0x27BF0520000 ? # pos size status 0x00000000 0x02870000 + 0x02870000 0x001A0000 * 0x02A10000 0x00010200 + 0x02A20200 0x0005FE00 * # ... many lines here 0x2BA92360000 0x00040000 ? 0x2BA923A0000 0x00010000 * # binary garbage here 0xE4E1710000 0x00010000 * # ... many lines here 0x13D75970000 0x00000200 + 0x13D75970200 0x00
Sie haben die Zeile unmittelbar vor dem Binärspeicher als die letzte gültige identifiziert. Er sagt, 0x2BA923A0000 0x00010000 *und es ist die Zeilennummer 880829 in Ihrem Fall. Es ist sinnvoll, weil die Zeilen hinter dem Müll niedrigere Positionen (erste Zahlen) haben, sie scheinen frühere Zeilen zu duplizieren.
Ich tat
<log3.txt head -n 880829 > log3new.txt und ausführen ddrescue(mit infileLoop-Gerät aus einer großen spärlichen Datei sollte es jedoch keine Rolle spielen). Es beschwerte sich über die Linie 583658.
Dies ist die Linie mit der Nachbarschaft:
# ... 0x186C6940000 0x00000200 + 0x186C6940200 A9520200 0x0001FE00 * # <- this line here 0x24AA9540000 0x00000200 + # ...
Um dies zu beheben, sollten Sie den gesamten Bereich von 0x186C6940200bis abdecken 0x24AA9540000, so dass die Protokolldatei zusammenhängend ist. Die Länge ist 0x24AA9540000- 0x186C6940200= 0xC3E2BFFE00. Die gesamte Linie 583658 sollte sein:
0x186C6940200 0xC3E2BFFE00 ? wo ?bedeutet nicht erprobte Blöcke.
Ich habe eine Lösung mit gemacht
sed -i '583658s/.*/0x186C6940200 0xC3E2BFFE00 ?/' log3new.txt Die resultierende Protokolldatei ist gültig für ddrescue.
BEARBEITEN
Das Problem, das ich habe, ist, dass DDrescue den Eindruck hat, dass es nur 2041 GB wiederhergestellt hat, während der Absturz bei über 2800 GB lag und wie Sie sich vorstellen können, dass diese letzten 800 GB viele Wochen erholten.
Tatsächlich wissen wir nicht, ob es die gleichen 800 GB sind. Es gibt ein Tool ddrescueview (mit GUI, als ddrescueviewPaket in Ubuntu erhältlich), das Ihnen zeigt, wo genau diese nicht getesteten Blöcke sind, die wir eingeführt haben. Beachten Sie, dass sich die aktuelle Position an anderer Stelle befindet:
Ich frage mich also, ob die Informationen nach dem Müll vielleicht etwas damit zu tun haben? Wie können wir es in die Protokolldatei aufnehmen?
Ich habe diesen Teil "nach dem Müll" isoliert, die letzten 129289 Zeilen:
tail -n 129289 log3.txt > extra.txt Dieser Befehl zeigt Ihnen Zeilen an, die in, extra.txtaber nicht in log3new.txt:
diff --suppress-common-lines extra.txt log3new.txt | grep -e '^<' Die Ausgabe ist
< 0x13D75970200 0x00
Es bedeutet, dass nur die letzte (unvollständige) Zeile hinter dem Müll vor dem Müll im Original nicht vorhanden ist log3.txt. Sorry, es scheint mir log3new.txtschon das Beste zu sein, was man bekommen kann.