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

```
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  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:


Spoiler



# 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*.  Zuletzt lag die durchschnittliche Geschwindigkeit aber nur bei etwas über 3000 Byte/s.
Update4 (23.01.2017): Mittlerweile sind schon 7206 MB rescued.

Bild:



			Dieser Inhalt steht nur eingeloggten Mitgliedern zur Verfügung.
        



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. 




			Dieser Inhalt steht nur eingeloggten Mitgliedern zur Verfügung.
        



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



			Dieser Inhalt steht nur eingeloggten Mitgliedern zur Verfügung.
        


(Bild erstellt mit ddrescueview)


----------

