Bei mir ist vor etwa 5 Tagen die Festplatte eines 500 GB-Laufwerks abgestürzt. Ich habe ddrescuevor ein paar Tagen an der wichtigen Partition gearbeitet und seit fast 2 Tagen steht dort „Fehlgeschlagene Blöcke werden gekürzt“.
Ursprünglicher Befehl:
ddrescue -n /dev/rdisk1s2 /Volumes/OSXBackup/rdisk1s2.img /Volumes/OSXBackup/rdisk1s2.log
Aktueller Output:
Initial status (read from logfile)
rescued: 248992 MB, errsize: 1007 MB, errors: 15867
Current status
rescued: 249021 MB, errsize: 978 MB, current rate: 17408 B/s
ipos: 44405 MB, errors: 15866, average rate: 2784 B/s
opos: 44405 MB, time from last successful read: 0 s
Trimming failed blocks...
Der ursprüngliche Befehl verwendete den ddrescue -nParameter und ich habe den Vorgang nach Bedarf einige Male neu gestartet (und jedes Mal schien er genau dort fortgesetzt zu werden, wo er aufgehört hatte).
Gibt es eine Möglichkeit, diesen Vorgang zu beschleunigen?
Bearbeiten:Sechs Stunden später ist dies der aktuelle Status:
rescued: 249079 MB, errsize: 920 MB, current rate: 409 B/s
ipos: 39908 MB, errors: 15851, average rate: 2698 B/s
opos: 39908 MB, time from last successful read: 0 s
Trimming failed blocks...
Während „Errors“ quälend langsam herunterzählt, zählt ipos/opos anscheinend herunter, wie viele Daten es verarbeiten muss, und es scheint mit einer Geschwindigkeit von 750 MB/Stunde zu arbeiten. Bei dieser Geschwindigkeit wird es in ~53 Stunden abgeschlossen sein. Igitt.
Bearbeitung Nr. 2:Zwei Tage später läuft es immer noch. Es gibt jedoch Hoffnung. Es hat den Abschnitt „Fehlerhafte Blöcke kürzen“ hinter sich gelassen und ist zur nächsten Phase „Fehlerhafte Blöcke aufteilen“ übergegangen. Wenn man sich diese Frage ansieht, sollte man zumindest mitnehmen, dass dies definitiv lange dauert, wenn eine große Menge an Daten/Fehlern im Spiel ist. Meine einzige Hoffnung ist, dass ich am Ende einige wichtige Daten erfolgreich wiederherstellen kann.
rescued: 249311 MB, errsize: 688 MB, current rate: 0 B/s
ipos: 26727 MB, errors: 15905, average rate: 1331 B/s
opos: 26727 MB, time from last successful read: 20 s
Splitting failed blocks...
Antwort1
Ich habe festgestellt, dass es hilfreich sein kann, die -nOption (no-split) zusammen mit -r 1(retry once) zu verwenden und -c(Clustergröße) auf einen kleineren Wert festzulegen.
Mein Eindruck ist, dass der Teilungsschritt sehr langsam ist, da ddrescuedie beschädigten Bereiche immer wieder geteilt werden. Dies nimmt viel Zeit in Anspruch, da ddrescueversucht wird, sehr kleine Datenmengen wiederherzustellen. Daher bevorzuge ich die Verwendung von -n(no-split) zusammen mit -c 64, -c 32, -c 16, usw.
Wahrscheinlich -nsollte (kein Split) immer für einen ersten Durchgang in Vorwärts- und Rückwärtsrichtung verwendet werden. Es scheint, dass das Klonen umso langsamer wird, je mehr die Daten aufgeteilt werden, obwohl ich mir da nicht sicher bin. Ich gehe davon aus, dass beim ddrescueerneuten Durchlauf die Größe der nicht behandelten Bereiche am besten ist, da dann mehr zusammenhängende Sektoren geklont werden müssen.
Da ich eine Protokolldatei verwende, zögere ich nicht, den Befehl mit Ctrl+ abzubrechen C, wenn die Datenlesegeschwindigkeit zu niedrig wird.
Ich verwende auch den -R(Rückwärts-)Modus und nach einem ersten Durchgang sind meine Rückwärtslesegeschwindigkeiten häufig höher als die Vorwärtslesegeschwindigkeit.
Mir ist nicht klar, wie mit bereits wiederholten Sektoren ( -r N) verfahren wird, wenn der ddrescueBefehl erneut ausgeführt wird, insbesondere wenn abwechselnd Vorwärts- (Standard) und Rückwärts- ( -R) Klonbefehle verwendet werden. Ich bin mir nicht sicher, ob die Anzahl der Versuche in der Protokolldatei gespeichert wird, und wahrscheinlich wird die Arbeit nutzlos erneut ausgeführt.
Wahrscheinlich -ikann das Flag (Eingabeposition) auch dazu beitragen, die Dinge zu beschleunigen.
Antwort2
Es kann sehr schwierig sein, den Fortschritt von zu erkennen ddrescue, aber es ist ein weiterer Befehl namens enthalten ddrescuelog.
Ein einfacher Befehl ddrescuelog -t YourLog.txtgibt diese netten Informationen aus:
current pos: 2016 GB, current status: trimming
domain size: 3000 GB, in 1 area(s)
rescued: 2998 GB, in 12802 area(s) ( 99.91%)
non-tried: 0 B, in 0 area(s) ( 0%)
errsize: 2452 MB, errors: 12801 ( 0.08%)
non-trimmed: 178896 kB, in 3395 area(s) ( 0.00%)
non-split: 2262 MB, in 9803 area(s) ( 0.07%)
bad-sector: 10451 kB, in 19613 area(s) ( 0.00%)
ddrescueSie können es sogar während des Betriebs verwenden ...
Antwort3
Ich habe festgestellt, dass man die Dinge beschleunigen kann, wenn man mit dem Parameter -K spielt. Soweit ich das gesehen habe, versucht ddrescue, wenn es einen Fehler findet und mit der Option -n läuft, eine feste Anzahl von Sektoren zu überspringen. Wenn es immer noch nicht lesen kann, springt es doppelt so weit. Wenn Sie große beschädigte Bereiche haben, können Sie einen großen K-Wert angeben (z. B. 100 M), sodass die Sprünge bei einem Fehler beim ersten Mal größer sind und es einfacher ist, problematische Bereiche beim ersten Mal schnell zu vermeiden.
Übrigens gibt es eine wunderbare grafische Anwendung zur Analyse des Protokolls.
Antwort4
Eine weitere Möglichkeit, den Fortschritt von ddrescue zu überwachen (zumindest unter Linux), ist die Verwendung von strace.
Suchen Sie zunächst die PID für den ddrescue-Prozess mit „ps aux | grep ddrescue“
root@mojo:~# ps aux | grep ddrescue
root 12083 0.2 0.0 15764 3248 pts/1 D+ 17:15 0:04 ddrescue --direct -d -r0 /dev/sdb1 test.img test.logfile
root 12637 0.0 0.0 13588 940 pts/4 S+ 17:46 0:00 grep --color=auto ddrescue
Führen Sie dann "strace" für diesen Prozess aus. Sie werden etwas sehen wie:
root@mojo:~# strace -p 12083
Process 12083 attached - interrupt to quit
lseek(4, 1702220261888, SEEK_SET) = 1702220261888
write(4, "\3101\316\335\213\217\323\343o\317\22M\346\325\322\331\3101\316\335\213\217\323\343o\317\22M\346\325\322\331"..., 512) = 512
lseek(3, 1702220261376, SEEK_SET) = 1702220261376
read(3, "\3101\316\335\213\217\323\343o\317\22M\346\325\322\331\3101\316\335\213\217\323\343o\317\22M\346\325\322\331"..., 512) = 512
lseek(4, 1702220261376, SEEK_SET) = 1702220261376
write(4, "\3101\316\335\213\217\323\343o\317\22M\346\325\322\331\3101\316\335\213\217\323\343o\317\22M\346\325\322\331"..., 512) = 512
^C
...und so weiter. Die Ausgabe ist schnell und hässlich, also leite ich sie durch „grep“, um die Dinge herauszufiltern, die mich interessieren:
root@mojo:/media/u02/salvage# nice strace -p 12083 2>&1|grep lseek
lseek(4, 1702212679168, SEEK_SET) = 1702212679168
lseek(3, 1702212678656, SEEK_SET) = 1702212678656
lseek(4, 1702212678656, SEEK_SET) = 1702212678656
lseek(3, 1702212678144, SEEK_SET) = 1702212678144
lseek(4, 1702212678144, SEEK_SET) = 1702212678144
lseek(3, 1702212677632, SEEK_SET) = 1702212677632
lseek(4, 1702212677632, SEEK_SET) = 1702212677632
lseek(3, 1702212677120, SEEK_SET) = 1702212677120
lseek(4, 1702212677120, SEEK_SET) = 1702212677120
lseek(3, 1702212676608, SEEK_SET) = 1702212676608
^C
In diesem Beispiel entspricht „1702212676608“ „der Datenmenge, die auf der 2-TB-Festplatte, die Sie retten möchten, noch verarbeitet werden muss.“ (Ja. Autsch.) ddrescue spuckt in seiner Bildschirmausgabe eine ähnliche Zahl aus – allerdings als „1720 GB“.
strace bietet Ihnen einen Datenstrom mit VIEL höherer Granularität für die Untersuchung; es ist eine weitere Möglichkeit, die Geschwindigkeit von ddrescue zu bewerten und einen Fertigstellungstermin abzuschätzen.
Es ständig laufen zu lassen, ist wahrscheinlich keine gute Idee, da es mit ddrescue um CPU-Zeit konkurrieren würde. Ich habe angefangen, es an „head“ weiterzuleiten, damit ich die ersten 10 Werte abrufen kann:
root@mojo:~# strace -p 4073 2>&1 | grep lseek | head
Hoffe, das hilft jemandem.