Wie stellt man eine gelöschte HFS+-Partitionstabelle wieder her?

Ich habe eine externe 2-TB-Festplatte mit einer HFS+-Partition und habe versehentlich die ersten ~500 MB davon überschrieben. Ich habe sorglos einige neue Partitionen platziert, um es zu reparieren, weil ich ein Online-Backup hatte, falls die Dinge schief gehen sollten. Die Sicherung ist jedoch fehlgeschlagen, und ich muss die Daten jetzt von diesem Laufwerk wiederherstellen. Die lesbaren Daten in der Partitionstabelle sind höchstwahrscheinlich unbrauchbar oder irreführend.

Ich habe versucht, Testdisk auszuführen und die Partition mit pdisk und dieser Anleitung zu platzieren , ohne Erfolg. Ich weiß nichts über die Partitionierung vor dem versehentlichen dd, außer dass ich die Standardoptionen für HFS + aus dem Festplatten-Dienstprogramm dafür ausgewählt und den gesamten Speicherplatz auf dem Laufwerk verwendet habe.

Gibt es eine Möglichkeit, das Laufwerk einfach wieder als einzelne HFS+-Partition zu formatieren, ohne dass alle Daten verloren gehen? Wie speichert HFS+ seine Dateien und Metadaten und ist es möglich, die Daten auf diese Weise wiederherzustellen?

Hier ist das Protokoll dessen, was aus dem Shell-Protokoll passiert ist:

$ diskutil list
[...]
/dev/disk2
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     FDisk_partition_scheme                        *2.0 TB     disk2
   1:                  Apple_HFS WD-40                   2.0 TB     disk2s1

$ diskutil unmountDisk /dev/disk2
Unmount of all volumes on disk2 was successful

$ sudo dd if=/Users/Felix/Downloads/xubuntu-12.04.3-alternate-i386.img of=/dev/disk2 bs=1m
^C503+0 records in
502+0 records out
526385152 bytes transferred in 16.409358 secs (32078351 bytes/sec)
$ diskutil list
[...]
/dev/disk2
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     FDisk_partition_scheme                        *2.0 TB     disk2
   1:                       0x17                         715.1 MB   disk2s1

Und das Protokoll vom Testdisk-Scan (Deeper Search), den ich bei etwa 40% Fortschritt abgebrochen habe, weil das Laufwerk so groß ist:

[...]
LVM magic value at 31676/178/3

LVM magic value at 31685/19/35
Search for partition aborted

Results
     MS Data                354087269  354093442       6174
     NTFS found using backup sector, blocksize=512, 3161 KB / 3087 KiB
     MS Data                354093442  354099615       6174 [Boot]
     NTFS, blocksize=512, 3161 KB / 3087 KiB
   P MS Data                354099734  354120472      20739 [NO NAME]
     FAT12, blocksize=4096, 10 MB / 10 MiB
     MS Data                358938549  358944722       6174
     NTFS found using backup sector, blocksize=512, 3161 KB / 3087 KiB
     MS Data                358944722  358950895       6174 [Boot]
     NTFS, blocksize=512, 3161 KB / 3087 KiB
   P MS Data                358951010  358971748      20739 [NO NAME]
     FAT12, blocksize=4096, 10 MB / 10 MiB
     MS Data                363749573  363755746       6174
     NTFS found using backup sector, blocksize=512, 3161 KB / 3087 KiB
     MS Data                363755746  363761919       6174 [Boot]
     NTFS, blocksize=512, 3161 KB / 3087 KiB
   P MS Data                363762034  363782772      20739 [NO NAME]
     FAT12, blocksize=4096, 10 MB / 10 MiB
   P MS Data                371716138  371719017       2880 [EFISECTOR]
     FAT12, blocksize=512, 1474 KB / 1440 KiB
     MS Data                371720053  371726226       6174
     NTFS found using backup sector, blocksize=512, 3161 KB / 3087 KiB
     MS Data                371726226  371732399       6174 [Boot]
     NTFS, blocksize=512, 3161 KB / 3087 KiB
   P MS Data                377878122  377881001       2880 [EFISECTOR]
     FAT12, blocksize=512, 1474 KB / 1440 KiB
   P MS Data                377881002  377883881       2880 [EFISECTOR]
     FAT12, blocksize=512, 1474 KB / 1440 KiB
   P MS Data                421662274  421665153       2880 [EFISECTOR]
     FAT12, blocksize=512, 1474 KB / 1440 KiB
     MS Data                421674913

Antworten (3)

Da die Tabelle höchstwahrscheinlich überschrieben wurde, ist es wahrscheinlich die einzige Option, nach den Dateien zu suchen und sie auf diese Weise zu sichern. DataRescue ist eines der beliebtesten.

Schreiben Sie keine weiteren Daten in dieses Dateisystem oder Laufwerk. Sie könnten versuchen, ob DiskWarrior einige der HFS-Dateisystem-Metadaten aufräumen kann, aber ein Programm wie Data Rescue ist die beste Wahl, um alle Dateien wiederherzustellen, die noch intakt sind, ohne Dateisystem-Metadaten zu benötigen.

Ich habe etwas ähnlich Dummes gemacht: Ich habe dd verwendet, um ein Raspbian-Image über mein TimeMachine-Backup-Laufwerk zu schreiben. Die hier aufgeführten Befehle haben bei mir nicht funktioniert:

$ sudo gpt -v recover /dev/disk3       
gpt recover: /dev/disk3: mediasize=2000398933504; sectorsize=512; blocks=3907029167
gpt recover: /dev/disk3: error: device contains a MBR

DiskWarrior konnte das Laufwerk überhaupt nicht erkennen und DataRescue konnte nach einem Tiefenscan keine Dateien wiederherstellen.

Glücklicherweise war der Backup-gpt-Eintrag noch intakt:

$ sudo gpt -r show /dev/disk3          
       start        size  index  contents
           0           1         MBR
           1        8191         
        8192      524288      1  MBR part 12
      532480     7036928      2  MBR part 131
     7569408  3899459726         
  3907029134          32         Sec GPT table
  3907029166           1         Sec GPT header

Also habe ich das großartige gdisk für Mac installiert, die Backup-Partitionstabelle geladen, die Festplatte überprüft, die Änderungen geschrieben usw. Danach wurde die Festplatte gemountet und im Festplatten-Dienstprogramm als namenlos angezeigt, aber DiskWarrior konnte den Index neu erstellen und bringen in einen brauchbaren Zustand.