Die Imageerstellung läuft, aber nach fast sechs Stunden knapp 3 % fertig, was ~ 8-9 GB sind. Es gibt sehr viele I/O Errors, was ich ja aber weiß.
Ja, es läuft solange weil es, afaik, versucht alles nacheinander einzulesen. Auch die fehlerhaften Sektoren, eben mit retries, was den weiteren Lesevorgang blockt.
Kannst du mir posten, wie ich für den Fall der Fälle ddrescue installiere? Ich nutze eine Live CD dafür (Kali)
Ich hab's nachgeschaut, bei Debian (und Kali) heißt das Packet UND (warum auch immer) die Binary gddrescue:
https://packages.debian.org/sid/amd64/gddrescue/filelist
Aber k.A. ob das auf der LiveCD dabei ist.
Das mit "mapfile", o.k., mache ich. Aber wenn ich nicht in das Wurzelverzeichnis schreiben will? Ich möchte ja nicht Device zu Device, sondern Device zu Image, also in eine Datei. Eine Frage, wenn ich auf sdb1 den Ordner "Sicherung" erstellt habe, dann müsste es heißen
".../dev/sdb/Sicherung/rescue.img"? Oder nicht? Ist aufgrund von Mapfile error.log uninteressant, oder?
Ich habe Dich so verstanden, dass Du ein Image auf die zweite Platte "direkt" ziehst. Daher "/dev/sdb1" (/dev steht ja für device).
Falls es eine Datei sein sollte, so natürlich zuerst die Platte mounten und den Pfad im Dateisystem angeben: /mnt/mydrive/Sicherung/imagefile
Ebenso kann die mapdatei da erstellt werden /mnt/mydrive/Sicherung/mapfile
Die HDD ist glaube ich aus dem Jahre 2014.
das sagt mir nichts
hier sollte die Ausgabe von smartmontools helfen:
smartctl -a /dev/ada0
Code:
<snip>
User Capacity: 240.057.409.536 bytes [240 GB]
Sector Sizes: 512 bytes logical, 4096 bytes physical
Ich werde es so machen, aber warum wäre es anders kontraproduktiv?
Weil Du dann den Kernel mit seinem Cache dazwischen hast
Es kann sein, dass (aus Performancegründen) z.B. größere Blöcke eingelesen werden, ein einzelner Badsektor macht dann aber den kompletten Block "ungültig" oder dass wiederholte Lesevorgänge ignoriert (gecacht) werden, weil eben der ganze Umgang mit den Laufwerken auf den "Normalfall" getrimmt ist und nicht auf diese Ausnahmeszenarios.
Und was wäre,. wenn ich das Image in WinHex oder X-Ways Forensics unter Win einlesen würde?
k.A. das kommt darauf an, wie das Laufwerk unter Windows eingehängt und angesteuert wird.
Warum sda? Das Image liegt ja dann auf sdb. Oder verstehe ich dich falsch?
k.A. ob das für Deinen Fall korrekt ist. Der Sinn der Angabe ist:
lese von defekter Platte (sda) ins Imagefile und nutze dazu die Daten in der mapfile
Also vollständig in etwa so:
ddrescue -b=4096 --no-split /dev/sda /dev/sdb1 /mnt/mydrive/Sicherung/imagefile /mnt/mydrive/Sicherung/mapfile
ddrescue --direct --max-retries=3 /dev/sda /mnt/mydrive/Sicherung/imagefile /mnt/mydrive/Sicherung/mapfile
ddrescue --direct --retrim --max-retries=10 /dev/sda /mnt/mydrive/Sicherung/imagefile /mnt/mydrive/Sicherung/mapfile
Abschließend habe ich eine allgemeine Frage. Und zwar, wann muss ich die Optionen setzen? Imnmer erst so
"ddrescue --> Optionen --> Quelllaufwerk --> Ziellaufwerk"
Wo muss der Error.log stehen? Müssen die "Schalter" nach dem Alphabet sein? Also kann ich -v (verbose) machen und dann z.B. b (Blocksize)?
Ich danke dir sehr!!!!
Also:
das Format ist folgendes:
ddrescue [options] quelle ziel [mapfile]
die Optionen können normalerweise "duchreinander" angegeben werden, es fängt ja alles mit "-" an, wichtig ist nur, dass die "benannten" (mit "-name") Argumente vor den unbenannten ("quelle" "ziel" "mapfile") kommen.
Da es ein sehr mächtiges Tool ist, kann man das nicht einfach in zwei Zeilen zusammenfassen, daher kommt man um die umfangreiche Hilfe nicht herum:
https://www.gnu.org/software/ddrescue/manual/ddrescue_manual.html
die Mapfile ist eigentlich schon ein Errorlog und kann mit ddrescuelog betrachtet werden (es enthält ja die Liste mit Badsektoren):
https://www.gnu.org/software/ddrescue/manual/ddrescue_manual.html#Ddrescuelog
zusätzlich kann die Ausgabe auf stderr (ob mit oder ohne -v) des Programms selbst über die Umleitung am Ende (zsh, bash) in eine Datei geleitet werden
mycmd foo bar 2> /mnt/pfadzulog/errors.txt