Infos von ca. 2006

Daten von Festplatten retten:
In diesem Fall: Eine Partition mit einem FAT32-Dateisystem, der Anfang und damit
speziell die erste FAT war beschädigt. Funktioniert so nicht, wenn der MBR
beschädigt ist. Dann muss man den erst wiederherstellen, da kann evtl.
testdisk helfen.


Vorgehensweise:

Vorbereitend:
    - Der Rechner bootet, und erkennt die Platte. (Also ist sie wahrscheinlich
    physisch OK)

0. Von z.B. Knoppix-CD booten

1. Rauskriegen, welche Platte man eigentlich will:

    # cat /proc/ide/hdc/model 
    # echo $((`cat /proc/ide/hdc/capacity` * 512 / 1024 / 1024)) Mb
    Capacity ist in Sektoren, die sind eigentlich immer 512 Byte.

    Weiter vorbereitend:

    - smartctl -a /dev/hdc

    So kann man rauskriegen, ob die Platte doch wegen Alter/Hitze den Geist
    aufgibt. Wenn Reallocated_Sector_Count 0 ist, ist die Platte fast sicher in
    Ordnung. Der UDMA_CRC_Error_Count ist noch interessant, wenn der sehr hoch
    ist, ist wahrscheinlich das Kabel zu lang oder zu schlecht, oder eben doch
    Elektronik bei Platte oder Motherboard hin. Man kann auch noch die Platte
    einen Self-test machen lassen.

    Jetzt aber:

    ddrescue / gddrescue benutzen, um ganze Platte zu kopieren:
    # ddrescue /dev/hdc /mnt/hdb1/platten-image

2. Erzeugtes Image an loopback binden:

    # losetup /dev/loop0 /mnt/hdb1/platten-image

3. Gucken, ob der Bootsektor / die erste FAT in Ordnung sein kann:

    # dd if=/dev/loop0 bs=512 count=48 |hexdump -C

    Wenn da in der ersten Zeile MSWIN (4.1), sowie später der Name des
    Dateisystems und danach der Typ, also FAT32 steht ist der Bootsektor
    wahrscheinlich OK. Das ist wichtig weil hier (natürlich) für das
    Dateisystem wichtige Daten gespeichert sind (z.B. seine Länge). Bei mir
    gabs davon auch ein Backup an 00000c00; eins von beiden war in Ordnung. Ab
    Hexoffset 00004000 (bei mir) geht die erste FAT los. Sie sollte mit "f8 ff
    ff 0f" anfangen. Wenn das passt, mit der ersten FAT probieren, sonst mit der
    Kopie der FAT probieren. (Die befand sich bei mir bei 301400, also z.B. dd
    if=/dev/loop0 bs=512 skip=14346 count=1) Die Kopie ist direkt hinter der
    ersten FAT, aber die Größe der FATs ist natürlich der
    Größe des Dateisystems abhängig.
    
    Bei NTFS steht btw. NTFS an Byte 4-7.
    Wie da das Dateisystem ausschaut hab ich keine Ahnung :-)

    Bei meinem Linux sehe ich nur ein
    GRUB .Geom.Hard Disk.Read. Error
    als lesbare Strings am Anfang dieser Ausgabe.
    In einen Bootloader gehören auch keine Dateisysteminformationen :-)

    Bei mir war offenbar der Plattenanfang irgendwie geändert worden.
    Das meiste war noch lesbar, nur ab und zu ein Bit geändert.

4. Wenn man also weiß, welcher Bootsektor / FAT besser ist:

    dosfsck/fsck.vfat funktioniert echt schlecht, wenn Bootsektor oder FAT
    kaputt ist :-) Also erstmal evtl. Bootsektor, dann FAT wiederherstellen, und
    diese Änderung auch _sofort_, bevor fsck weitermacht, schreiben.
    Ansonsten schreibt fsck erst am Schluß, und versucht daher mit der
    alten kaputten FAT zu arbeiten.
    # fsck.vfat -wr /dev/loop0
    Zweite FAT ausgewählt, der fsck sieht viel besser aus als vorher (es
    kommen wieder sinnvolle Dateinamen), aber das fsck-Programm stürzt ab.
    Es hatte Cluster angemeckert, die in zwei Dateien vorkamen, man sollte die
    zu verkürzende Datei auswählen, danach haben aber wohl
    irgendwelche Cluster in irgendeiner Liste gefehlt, und fsck.vfat hat sich
    ungnädig beendet. Jetzt ist aber mindestens die richtige FAT
    geschrieben, also kann man jetzt so lange mit fsck testen, bis es
    durchläuft. Ich hab immer die kürzere Möglichkeit
    gewählt, das hat dann funktioniert. Im Endeffekt waren dann 5 Dateien
    kaputt.

5. Dateisystem lebt wieder.


Sollte jetzt mountbar sein.

Irgendwann evtl. noch ein losetup -d /dev/loop0

Und jetzt wo man weiß, wie's geht kann man das mit der Originalplatte
machen, und spart sich Daten rumzukopieren.