Ein ddrescue (d) -Image kann nicht in HD-Format zurückgeschrieben werden

391
John D'Eau

Ich habe eine Image-Datei einer fehlerhaften Festplatte, die mit ddrescue unter Linux erstellt wurde. Die Festplatte ist 750 GB, wenn ich mich recht erinnere, konnten nur etwa 30 MB nicht gespeichert werden. Ich habe andere fehlerhafte HDs und kann mich nicht erinnern, ob diese zu meinem Windows- oder Linux-Computer gehörte.

Ich versuche, das Bild auf eine 2 TB HD wiederzugeben. Egal, ob ich das HD als NTFS oder EXT formatiere und das Bild auf das neue HD schreibe, sobald es fertig ist, wird es als unformatiert und leer wieder angezeigt. Ich habe gelesen, dass wir Fehlerkorrektur-Tools für die Bilder verwenden sollten, bevor sie zurückgeschrieben werden. Also habe ich versucht, fsck und ntfsfix zu verwenden, aber niemand kann das Bild identifizieren und korrigieren.

Wenn ddrescue es geschafft hat, so viel von dieser fehlerhaften HD einzusparen, warum können Tools die Fehler nicht korrigieren und warum können sie nicht zurückgeschrieben werden? Es ist mir gelungen, eine weitere fehlerhafte 160 GB HD zurückzuschreiben, daher weiß ich nicht, warum diese 750 GB nicht funktioniert.

Bearbeiten, um das von mir verwendete Bild zurückzuschreiben:

sudo ddrescue -f seagate750de.img / dev / sdb restore.log

head -n 16 seagate750gb.log

# Rescue Logfile. Created by GNU ddrescue version 1.17 # Command line: ddrescue -d -r5 -R /dev/sdb seagate750gb.img seagate750gb.log # current_pos current_status 0x89B7F4A00 + # pos size status 0x00000000 0x89B7F4800 + 0x89B7F4800 0x00000200 - 0x89B7F4A00 0x010AA200 + 0x89C89EC00 0x00000200 - 0x89C89EE00 0x21775200 + 0x8BE014000 0x00000200 - 0x8BE014200 0x000DA400 + 0x8BE0EE600 0x00000200 - 0x8BE0EE800 0x00369600 + 0x8BE457E00 0x00000200 - 0x8BE458000 0x002B6000 +

Datei seagate750gb.img

seagate750gb.img: x86 boot sector

gdisk -l seagate750gb.img

GPT fdisk (gdisk) version 0.8.8  Partition table scan: MBR: MBR only BSD: not present APM: not present GPT: not present   *************************************************************** Found invalid GPT and valid MBR; converting MBR to GPT format in memory.  ***************************************************************  Disk seagate750gb.img: 1465149168 sectors, 698.6 GiB Logical sector size: 512 bytes Disk identifier (GUID): 2891CCD9-92FB-4380-AB03-801E0E4F90CC Partition table holds up to 128 entries First usable sector is 34, last usable sector is 1465149134 Partitions will be aligned on 2048-sector boundaries Total free space is 1465149101 sectors (698.6 GiB)  Number Start (sector) End (sector) Size Code Name

sudo gdisk -l / dev / sdb

(das ist meine 2 TB HD, nachdem das Bild darauf geschrieben wurde)

GPT fdisk (gdisk) version 0.8.8  Partition table scan: MBR: MBR only BSD: not present APM: not present GPT: not present   *************************************************************** Found invalid GPT and valid MBR; converting MBR to GPT format in memory.  ***************************************************************  Disk /dev/sdb: 3907029168 sectors, 1.8 TiB Logical sector size: 512 bytes Disk identifier (GUID): 59784077-576E-4CC1-918D-773D10916B46 Partition table holds up to 128 entries First usable sector is 34, last usable sector is 3907029134 Partitions will be aligned on 2048-sector boundaries Total free space is 3907029101 sectors (1.8 TiB)  Number Start (sector) End (sector) Size Code Name
0
Haben Sie immer noch das `ddrescue'-Protokoll von dieser Operation? Wenn ja, geben Sie bitte die Ausgabe von `head -n 16 the_logfile` ein. Welchen exakten Befehl verwenden Sie, um das Bild zurückzuschreiben? Was ist die Ausgabe von `file the_image_file`? Was ist die Ausgabe von `gdisk -l the_image_file`? Was sagt gdisk -l / dev / sdX über die logische Sektorgröße Ihrer 2-TB-Festplatte aus? Bitte beantworten Sie diese Fragen nicht in Kommentaren, [bearbeiten] Sie Ihre Frage und fügen Sie dort Informationen hinzu. Kamil Maciorowski vor 6 Jahren 0

1 Antwort auf die Frage

0
agc

Bevor du spekulierst, überprüfe ein paar Dinge:

  • Stellen Sie sicher, dass das Festplatten-Image tatsächlich Daten enthält. Versuchen Sie etwas wie:

    lzop < disk.img | wc -c - disk.img

    Dies dauert einige Minuten, um die Zeichen sowohl im Bild als auch in einem etwas komprimierten lzopStream des Bildes zu zählen. Wenn das Bild nur aus Nullen besteht, ist die lzopAnzahl relativ klein.

    Wenn die lzopAnzahl mindestens 10% der Größe des Roh-Images beträgt, befinden sich einige Daten in disk.img .

  • Wenn es Daten zu geben scheint, schauen Sie sich an, was ein paar Standardwerkzeuge dazu sagen:

    file disk.img

    ... sollte etwas darüber erzählen, was da ist. Wenn es sich um eine Partitionstabelle handelt, versuchen Sie Folgendes:

    gpart -v disk.img

Verwandte Probleme