Gibt es eine Möglichkeit, die Rettung zu beschleunigen?

Ich hatte vor ungefähr 5 Tagen einen Festplattenabsturz von 500 GB. Ich habe ddrescuedie wichtige Partition vor ein paar Tagen verwendet und sie ist nun seit fast 2 Tagen auf "Fehlerhafte Blöcke trimmen".

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 Prozess nach Bedarf einige Male neu gestartet (und er schien jedes Mal genau dort anzukommen, wo er aufgehört hat).

Gibt es eine Möglichkeit, diesen Prozess zu beschleunigen?

Edit: 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...

Es sieht so aus, als würden "Fehler" unglaublich langsam abwärts zählen, während ipos / opos abwärts zählen, wie viele Daten es durchlaufen muss, und es scheint mit einer Geschwindigkeit von 750 MB / Stunde zu arbeiten. Bei dieser Geschwindigkeit dauert es ca. 53 Stunden. Huch.

Edit # 2: Zwei Tage später läuft noch. Es gibt jedoch Hoffnung. Es wurde über den Abschnitt "Fehlgeschlagene Blöcke abschneiden" hinaus in die nächste Phase "Fehlgeschlagene Blöcke aufteilen" verschoben. Wenn überhaupt, sollte man davon absehen, dass dies definitiv lange dauert, wenn es sich um eine große Menge von Daten / Fehlern handelt. Meine einzige Hoffnung ist, dass ich einige wichtige Daten erfolgreich wiederherstellen kann, wenn alles gesagt und getan ist.

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...

Ich habe festgestellt, dass die Verwendung der -nOption (keine Teilung) zusammen mit -r 1(einmalige Wiederholung) und der Einstellung -c(Clustergröße) auf einen kleineren Wert hilfreich sein kann.

Mein Eindruck ist, dass der Aufteilungsschritt sehr langsam ist, da ddrescuedie beschädigten Bereiche immer wieder aufgespalten werden. Dies nimmt viel Zeit in ddrescueAnspruch, da versucht wird, sehr kleine Teile der Daten wiederherzustellen. Also, ich ziehe zu verwenden -n(no-split) zusammen mit -c 64, -c 32, -c 16, aso

Wahrscheinlich sollte die -n(no-split) immer für einen ersten Durchgang in Vorwärts- und Rückwärtsrichtung verwendet werden. Es scheint, dass das Klonen umso langsamer vonstatten geht, je mehr Daten aufgeteilt wurden, obwohl ich mir nicht sicher bin. Ich gehe davon aus, dass je größer die nicht behandelten Bereiche sind, ddrescuedesto besser ist es, wenn sie erneut ausgeführt werden, da mehr zusammenhängende Sektoren geklont werden sollen.

Da ich eine Protokolldatei verwende, zögere ich nicht, den Befehl mit Ctrl+ abzubrechen, Cwenn die Datenlesegeschwindigkeit um zwei verringert wird.

Ich benutze auch den -R(Rückwärts-) Modus und nach einem ersten Durchgang kann ich oft schneller rückwärts als vorwärts lesen.

Mir ist nicht klar, wie bereits wiederholte Sektoren ( -r N) behandelt werden, wenn der ddrescueBefehl erneut ausgeführt wird, insbesondere wenn Vorwärts- (Standard) und Rückwärts- ( -R) Klonbefehle abgewechselt werden. Ich bin nicht sicher, ob die Anzahl der Versuche in der Protokolldatei gespeichert ist und die Arbeit wahrscheinlich wieder unbrauchbar gemacht wird.

Wahrscheinlich kann das -iFlag (Eingabeposition) auch helfen, die Dinge zu beschleunigen.

Es kann sehr schwer sein, den Fortschritt zu sehen ddrescue, aber es gibt einen weiteren Befehl namens ddrescuelog.

Ein einfacher Befehl ddrescuelog -t YourLog.txtgibt diese netten Infos 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%)

Du kannst es sogar benutzen, während ddrescuees läuft ...

Eine weitere Möglichkeit, den Fortschritt von ddrescue zu überwachen (zumindest unter Linux), ist die Verwendung von strace.

Ermitteln 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" gegen diesen Prozess aus. Du wirst 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 das herauszufiltern, was mir wichtig ist:

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 noch auf der 2-TB-Festplatte verarbeitet werden muss, die Sie retten möchten. (Yeah. Autsch.) Ddrescue spuckt in seiner Bildschirmausgabe eine ähnliche Zahl aus - wenn auch "1720 GB".

strace bietet Ihnen einen VIEL höher granularen Datenstrom, den Sie untersuchen können. Dies ist eine weitere Möglichkeit, die Geschwindigkeit von ddrescue zu bewerten und ein Fertigstellungsdatum zu schätzen.

Es ist wahrscheinlich ein schlechter Plan, es ständig laufen zu lassen, da es mit ddrescue um die CPU-Zeit konkurrieren würde. Ich habe es auf "head" umgestellt, damit ich die ersten 10 Werte erfassen kann:

root@mojo:~# strace -p 4073 2>&1 | grep lseek | head

Hoffe das hilft jemandem.

Wenn Sie den Großteil der Daten intakt erhalten möchten, können Sie die Extraktion beschleunigen. Wenn Sie jedoch wirklich so viele Daten wie möglich retten möchten, müssen Sie ddrecue an jedem einzelnen Punkt nibbeln lassen.

Ich habe herausgefunden, dass man mit dem -K-Parameter die Dinge beschleunigen kann. Nach allem, was ich gesehen habe, wenn ddrescue beim Ausführen mit der Option -n einen Fehler feststellt, wird versucht, eine feste Anzahl von Sektoren zu überspringen. Wenn es immer noch nicht lesen kann, springt es doppelt so groß. Wenn Sie große beschädigte Bereiche haben, können Sie einen großen K-Wert (z. B. 100 M) angeben, so dass das Springen auf einen Fehler beim ersten Mal größer wird und es einfacher wird, problematische Bereiche in der ersten Vergangenheit schnell zu vermeiden.

Übrigens gibt es eine wunderbare grafische Anwendung, um das Protokoll zu analysieren.

http://sourceforge.net/projects/ddrescueview/

In welchem ​​Dateisystem der Festplatte speichern Sie das Rettungsimage und die Protokolldatei? Ich habe gerade die Erfahrung gemacht, dass das Retten einer internen 500-GB-Festplatte (über SATA verbunden) auf einem Laptop mit Linux Mint von einem USB-Stick, das Speichern des Rettungsimages und der Protokolldatei auf einer exFatformatierten USB-Festplatte, ziemlich langsam begann (1-2 MB / s). sec), aber nach ca. 250 GB wurde nur mit <100 KB / s gecrawlt. Es schien langsamer zu werden, je größer die Rettungsimagedatei wurde.

Dann habe ich das Rettungsimage und die Protokolldatei an einen anderen temporären Ort verschoben, die USB-Festplatte mit dem ext4Dateisystem neu formatiert , die Dateien wieder darauf verschoben und den ddrescue-Prozess fortgesetzt - und jetzt läuft sie wieder mit 1-20 MB / s (schwankend) aber um die 7MB / sec im Durchschnitt)!

Scheint exFatbei sehr großen Dateien (mehrere hundert Gigabyte) nicht sehr gut zu funktionieren.

Für eine schnellere und schnellere Möglichkeit, die CD zu retten, können Sie eine sh-Skriptdatei verwenden und die Datei mit "sh filename.sh" ausführen. Diese Zeile wird angezeigt. Wiederholen Sie "sudo ddrescue" und "sleep 3" noch einige Male. Der Ruhezustand wird verwendet, um das Laufwerk einige Sekunden lang in den Ruhezustand zu versetzen. Dies kann aus verschiedenen Gründen hilfreich sein:

#! /bin/sh -e  
sudo ddrescue -d -r0 -e +0 -T 1s -n /dev/drivepartition file.img log.logfile 
sleep 3

Das -r0 hat keine Antworten. Das -e +0 ist für das Beenden bei 1 Fehler. Die -T 1s wird mit 1 Sekunde fehlgeschlagenem Lesevorgang beendet. Es gibt Optionen, die als -d für direct und -n für no scrape verwendet werden können, was die Geschwindigkeit erhöhen kann.

Sie können -R nach dem Beenden mit der Option -A einmal verwenden, wodurch alle Fehlergrößen umgekehrt und beseitigt werden und der Vorgang rückwärts fortgesetzt wird. Bedeutet, dass Fehler anders gelesen werden.

dd_rhelp ist ein Shell-Skript, das dd_rescue verwendet "[...] auf Ihrer gesamten CD, ABER es wird versucht, die maximal gültigen Daten zu sammeln, bevor es jahrelang versucht, auf Gruppen von fehlerhaften Sektoren zuzugreifen".

Es ist ziemlich alt (2012), funktioniert aber immer noch. habe ddrescue noch nicht ausprobiert.