Kopiergeschwindigkeit dd bzw. ddrescue

DKK007 · 13. Dezember 2016

Hallo,

Ich wollte mal fragen, ob jemand Erfahrungen mit der Geschwindigkeit von ddrescue hat. Ziehe gerade von einer Platte ein Image und die average Kopiergeschwindigkeit liegt bei 10-12 kB/s.
Das hat natürlich die Folge, das nach mehreren Stunden gerade mal knapp 450 MB kopiert sind - und ich hab noch 470 GB vor mir.

Laufen tut das ganze mit dem -n Parameter, wo ja eigentlich recht "schnell" über defekte Sektoren drüber gelesen wird.

Code:

sudo ddrescue -n /dev/sdb image_sdb.dd logdatei.log

Die 2,5" 500GB Platte steckt in ner Dockingstation und es wird auf eine 3,5" 2TB platte, die daneben steckt, geschrieben. Sollte aber eher nicht daran liegen, da das ganze per USB3.0 angebunden ist und letzten mit anderen Programm und Platte problemlos 50MB/s erreicht hat.

Gute Nacht
mfg. DKK007

Kusanar · 13. Dezember 2016

Du könntest mit dem Schalter -T noch angeben, wie lange er auf einen erfolgreichen Leseversuch warten soll. Ein Timeout von 5 bis 15 Sekunden sollte reichen, wenn du ein schnelles Ergebnis haben willst auch darunter. Und wenn du ein Image ziehst, auf jedenfall noch die Option -S mit angeben, dann werden keine Nullen ins Image geschrieben wenn der unbelegte Speicherplatz ausgelesen wird.

sdb ist ja nicht gemounted, oder? Wenn ja, dann vorher unmounten. Könnte auch daran liegen.

DOcean · 13. Dezember 2016

Ddrescue – Wikipedia

auf Wikipedia stehen 2 Durchläufe die sich ergänzen, vlt was für dich...

Du könntest auch mit dem -c Parameter testen (entspricht ca dem bs von dd) osx - ddrescue extremely slow on USB hard drive - Unix & Linux Stack Exchange

Kusanar · 13. Dezember 2016

Hm, ja die -n Option für No-Scrape und -r 1 (nur einen Retry fürs Lesen) oder gar -r 0 könnte noch interessant sein, falls er an defekten Blöcken zulange rumnödelt.

DKK007 · 13. Dezember 2016

Mounten ließ sich die Platte gar nicht mehr. Zumindest der Anfang scheint OK zu sein und da existiert der GPT mit 5 Partitionen hinter dem leeren MBR.

Mittlerweile hat er ja "schon" 1,1 GB geschafft.

Deep Thought · 13. Dezember 2016

Bei mir hat ddrescue neulich knapp eine Woche lang kopiert.

Dafür haben am Ende von 1.5TB nur noch ein paar kB gefehlt.

In der Spitze ging es bei unbeschädigten Bereichen auch mal auf ca. 80 MB/s hoch. (Das ganze unter VMware)

Edit: ich hab mit -K die Anzahl der zu lesenden Sektoren erhöht. Bilde mir ein, dass es damit etwas schneller wurde.

DKK007 · 14. Dezember 2016

Hier fehlen nicht nur ein paar KB. Derzeit wurden 8964 MB gelesen ujnd davon wurden bisher 8292 MB übersprungen. (18 Errors)

Von der großen 450 GB NTFS Partition fehlt leider auch der Anfang, aber zumindest der Backupblock am Ende der Partition ist da. Da hatte ich gestern Abend mal schnell mit dd nachgeschaut.

Kusanar · 14. Dezember 2016

Also für die schwierigste Datenrettung, die ich je hatte, war der Rechner 5 Tage lang durchgehend beschäftigt. Und das waren damals nur knapp 30GB an Daten... bei ATA133-Anbindung. Kann also bei manchen Fehlern durchaus mal dauern. Da hilft dann nur Geduld.

8 Gigabyte bei nur 18 Fehlern überprungen kommt mir übrigens ein bissl viel vor. So ein Speicherblock hat ja keine 10 oder 100 Megabyte, sondern bewegt sich im Kilobyte-Bereich :huh:

Welche Fehler waren das genau laut Log?

DKK007 · 14. Dezember 2016

Soweit ich weiß, überspringt ddrescue die folgenden Sektoren, wenn ein Defekt auftrat, bis wieder etwas lesbares gefunden wurde. Mit dem oben von DeepThought erwähnten -K Parameter kann man laut Manual die Größe (initial und max) des Skip-Bereiches angeben. GNU ddrescue Manual

Vielleicht wird immer nur der Erste Fehler gezählt.
Ins Log muss ich heute Abend mal schauen.

Mal sehen, wie weit der dann gekommen ist.

Ich bin ja wirklich gespannt, was auf der Platte drauf ist.

Edit: Logdatei:

# Rescue Logfile. Created by GNU ddrescue version 1.17
# Command line: ddrescue -n /dev/sdb image_sdb_ddrescue.dd logdatei.log
# current_pos current_status
0x21B7C1000 ?
# pos size status
0x00000000 0x08745000 +
0x08745000 0x0000B000 *
0x08750000 0x00006000 +
0x08756000 0x00000200 -
0x08756200 0x0000A000 *
0x08760200 0x00001E00 +
0x08762000 0x00000200 -
0x08762200 0x0000E200 *
0x08770400 0x00002C00 +
0x08773000 0x00000200 -
0x08773200 0x0000D400 *
0x08780600 0x00000200 -
0x08780800 0x00010000 *
0x08790800 0x00000200 -
0x08790A00 0x00020000 *
0x087B0A00 0x00000200 -
0x087B0C00 0x00040000 *
0x087F0C00 0x00000200 -
0x087F0E00 0x00080000 *
0x08870E00 0x00000200 +
0x08871000 0x00000200 -
0x08871200 0x000FFE00 *
0x08971000 0x00000200 -
0x08971200 0x001FFC00 *
0x08B70E00 0x00000200 -
0x08B71000 0x003FF800 *
0x08F70800 0x00000200 -
0x08F70A00 0x007FF000 *
0x0976FA00 0x00000200 -
0x0976FC00 0x00FFE000 *
0x0A76DC00 0x00000200 -
0x0A76DE00 0x01FFC000 *
0x0C769E00 0x00000200 -
0x0C76A000 0x03FF8000 *
0x10762000 0x00001000 +
0x10763000 0x00000200 -
0x10763200 0x07FEF000 *
0x18752200 0x02BB7E00 +
0x1B30A000 0x00000200 -
0x1B30A200 0x0D426200 *
0x28730400 0x06E5EC00 +
0x2F58F000 0x00000200 -
0x2F58F200 0x139ED800 *
0x42F7CA00 0x00897600 +
0x43814000 0x00000200 -
0x43814200 0x26B43A00 *
0x6A357C00 0x019C6400 +
0x6BD1E000 0x00000200 -
0x6BD1E200 0x3E639C00 *
0xAA357E00 0x00000200 -
0xAA358000 0x40000000 *
0xEA358000 0x03887000 +
0xEDBDF000 0x00000200 -
0xEDBDF200 0x3C779000 *
0x12A358200 0x00015E00 +
0x12A36E000 0x00000200 -
0x12A36E200 0x3FFEA200 *
0x16A358400 0x00000200 -
0x16A358600 0x40000000 *
0x1AA358600 0x00000A00 +
0x1AA359000 0x00000200 -
0x1AA359200 0x3FFFF600 *
0x1EA358800 0x09947800 +
0x1F3CA0000 0x00010000 *
0x1F3CB0000 0x00000200 -
0x1F3CB0200 0x00010000 *
0x1F3CC0200 0x00000200 -
0x1F3CC0400 0x00020000 *
0x1F3CE0400 0x00000200 -
0x1F3CE0600 0x00040000 *
0x1F3D20600 0x00000200 -
0x1F3D20800 0x00080000 *
0x1F3DA0800 0x00000200 -
0x1F3DA0A00 0x00100000 *
0x1F3EA0A00 0x00000200 -
0x1F3EA0C00 0x00200000 *
0x1F40A0C00 0x00000400 +
0x1F40A1000 0x00000200 -
0x1F40A1200 0x003FFC00 *
0x1F44A0E00 0x00000200 -
0x1F44A1000 0x007FF800 *
0x1F4CA0800 0x00000800 +
0x1F4CA1000 0x00000200 -
0x1F4CA1200 0x00FFE800 *
0x1F5C9FA00 0x00000200 -
0x1F5C9FC00 0x01FFD000 *
0x1F7C9CC00 0x00000200 -
0x1F7C9CE00 0x03FFA000 *
0x1FBC96E00 0x00002200 +
0x1FBC99000 0x00000200 -
0x1FBC99200 0x07FF1E00 *
0x203C8B000 0x0429E000 +
0x207F29000 0x00000200 -
0x207F29200 0x0BD45C00 *
0x213C6EE00 0x07B52400 +
0x21B7C1200 0x7255444E00 ?

Steht aber eigentlich nur die bisher geprüfen Bereiche drin.

Obwohl es jetzt keine weiteren Fehler gab, sind immer noch gerade erst 9051 MB kopiert. (Gemeint war hier die aktuelle Position [Pos] im 1. Durchlauf, Rescued deutlich geringer)

DKK007 · 31. Dezember 2016

Update (20.12.2016): Mechanik und Controller laufen noch, es sind aber viele Sektoren anscheinend defekt. Also etwas was sich wohl mit den Smart-Daten hätte vorhersagen lassen, wenn es der Besitzer gewusst hätte.
Nach einer Woche Dauerbetrieb mit ddrescue waren "schon" 1860 MB an guten Sektoren kopiert. Platte lebt aber immer noch, nach den Ferien geht es weiter.

ddrescue hat aber jetzt schon mehrere Durchläufe hinter sich, bei denen sich das Tool an die guten Sektoren heranarbeitet.
// aktuelle Befehl ~~wird~~ ergänzt: sudo ddrescue -n -K 100MB -a 10000 /dev/sdb image.dd lodgatei.log

Update2 (04.01.2017): Gestern Abend ging es weiter, bisher 2315 MB rescued.

Update3 (17.01.2017): Stand bei 5939 MB rescued.
Hab mal ausgerechnet, wie lange das Kopieren von 500 GB bei einer durchschnittlichen Geschwindigkeit von 5000 Byte/s braucht. Sind 3,2 Jahre. :wow:

Zuletzt lag die durchschnittliche Geschwindigkeit aber nur bei etwas über 3000 Byte/s.
Update4 (23.01.2017): Mittlerweile sind schon 7206 MB rescued.

Bild:

Bildschirmfoto vom 2017-01-23 22:32:20.png

Update5 (07.02.2017): Schon 10764 MB geschafft.
Update6 (01.03.2017): 16750 MB

DKK007 · 21. März 2017

Update7 (21.03.2017): 26899 MB.

Mal wieder ein Update, von der Platte würden mittlerweile über 25 GiB an guten Sektoren kopiert. Da kann ich dann langsam mal schauen, ob was sinnvolles drauf ist, was man auswerten kann. Wenn man Pech hat, liegen die Sektoren natürlich an Stellen die ohne Daten waren und somit nur aus 00 bestehen.
Die Kopiergeschwindigkeit ist in den letzten Tagen sogar wieder gestiegen und liegt meistens bei 6000-9000 Bytes/s.

Bildschirmfoto vom 2017-03-21 17:56:26.png

Update7.1 (21.03.2017): 26911 MB rescued.

DKK007 · 22. November 2017

Wie ich bei einer anderen Platte feststellen musste ist die Kopiergeschwindigkeit möglicherweise auch extrem vom Dateisystem der Zielplatte abhängig. Linux kann enorme Probleme zu haben, wenn bei NTFS die Komprimierung aktiv ist.
Beim Wechsel auf eine andere Zielplatte mit ext4 hatte sich da die Kopiergeschwindigkeit von 330 kB/s auf etwa 30000 kB/s = 30 MB/s knapp verhundertfacht.
Insbesondere war mir das Problem durch die hohe CPU-Last von mount.ntfs und das ich beim Kopieren nicht auf die Zielplatte zugreifen konnte aufgefallen.
Scheint da wohl ein Problem mit dem NTFS-Treiber von Linux zu geben. Krazy About Technology: Solution to Linux NTFS performance woes :- Bad performance / 100% CPU usage when using VirtualBox / VMWare and In general

Somit ist es empfehlenswert als Zielplatte eine mit ext4 zu verwenden und das Image später nach Bedarf auf eine Platte mit NTFS (ohne Komprimierung) zu kopieren . FAT32 fällt aufgrund der 4 GiB Grenze pro Datei raus.

---

Die Platte ist vergangenes Wochenende (17.-19.11.2017) während ich unterwegs war anscheinend still und leise verstorben. Läuft überhaupt nicht mehr an. Klappert aber auch nichts.
Hat somit aber 11 Monate durchgehalten.

Ergebnis:

107,35 / 465,75 GiB konnten kopiert werden, das entpricht 23%.

979141-kopiergeschwindigkeit-dd-bzw-ddrescue-ddrescue_500gb_defekt.png

(Bild erstellt mit ddrescueview)

Kopiergeschwindigkeit dd bzw. ddrescue

DKK007

PCGH-Community-Veteran(in)

Kusanar

BIOS-Overclocker(in)

DOcean

PCGHX-HWbot-Member (m/w)

Kusanar

BIOS-Overclocker(in)

DKK007

PCGH-Community-Veteran(in)

Deep Thought

Freizeitschrauber(in)

DKK007

PCGH-Community-Veteran(in)

Kusanar

BIOS-Overclocker(in)

DKK007

PCGH-Community-Veteran(in)

DKK007

PCGH-Community-Veteran(in)

DKK007

PCGH-Community-Veteran(in)

DKK007

PCGH-Community-Veteran(in)

Anhänge

Ähnliche Themen