Frage zu Wiederherstellung von Partition testdisk

[cabriofahrer]

Ich hatte damals die Festplatte von einem alten 2006 MacBook (Intel) enfernt, weil ich damals einfach nur die Daten runterkopieren wollte, um die Platte dann anderweitig zu formatieren. Mit irgendwelchen HFS-Tools hatte ich mir damals das Partitionsschema zerschossen und mit testdisk glaube ich wiederhergestellt, kam aber an einem Punkt nicht weiter. Ich will jetzt nun nach langer Zeit die Sache wieder in Angriff nehmen, bin mir aber nicht sicher, welche Option ich nun nehmen soll, die Anleitung von testdisk gibt mir darüber keinen Aufschluss:

Laut Anleitung bin ich an dem Punkt, an dem ich "Superblock" auswählen soll. Ich bekomme dann tatsächlich die Meldung "Volume Header: Bad", wie der erste Screenshot von testdisk zeigt.
Meine Frage ist jetzt, welche der beiden Optionen ich nun wählen soll:

Org. BS (Copy superblock over backup sector)

oder

Dump (Dump superblock and backup superblock)?

Es geht wie gesagt darum, auf die Daten der Partition wieder zugreifen zu können, um diese herunterzukopieren und die Platte dann anderweitig verwenden zu können.

 

[mr44er]

Also bei einem Datenrettungsversuch auf der originalen, jetzt 17 Jahre alten Platte herumschreiben finde ich mutig.
"Normalerweise" clont man zunächst mal die zu rettende Platte auf eine andere (oder gleich zwei Platten), die muss auch nicht identisch sein. Dann kann man gefahrlos experimentieren, auch mit unbekannten Dateisystem, denn von Applezeug weiß ich nichts.

 

[Andy_m4]

"Normalerweise" clont man zunächst mal die zu rettende Platte auf eine andere

Oder in eine Imagedatei. Auf der lässt sich ja auch wie auf ein Blockdevice arbeiten.

 

[turrican]

Auf den Screenshots besagt die Meldung dass der Backup Volume Header defekt ist, der Volume Header aber ok - so würde ich das interpretieren - d.h. das kopieren vom Header in den Backup Header wie vorgeschlagen sollte ok sein.
Normalerweise hat man ja eher den umgekehrten Fall (und deshalb den Backup Volume Header) - nämlich, dass der Volume Header kaputt ist, und nicht der Backup Volume Header.

Wie mr44er aber schon schrieb, am Besten auf ner 1:1 Kopie der Disk arbeiten oder wie Andy_m4 meinte auf ner Image Datei davon.

 

[cabriofahrer]

Also bei einem Datenrettungsversuch auf der originalen, jetzt 17 Jahre alten Platte herumschreiben finde ich mutig.

Es handelt sich nicht um die originale Platte, sondern um eine Jahre später ersetzte und bessere Platte.

Auf den Screenshots besagt die Meldung dass der Backup Volume Header defekt ist, der Volume Header aber ok - so würde ich das interpretieren - d.h. das kopieren vom Header in den Backup Header wie vorgeschlagen sollte ok sein.

Welche der beiden Optionen ist nun bedeutungsgleich mit "wie vorgeschlagen" bzw. "Kopieren vom Header in den Backup Header"?

Org. BS (Copy superblock over backup sector) oder Dump (Dump superblock and backup superblock)? Ich nehme an ersteres ("Org .BS")?

Wie mr44er aber schon schrieb, am Besten auf ner 1:1 Kopie der Disk arbeiten oder wie Andy_m4 meinte auf ner Image Datei davon.

Klingt ähnlich wie die Möglichkeit, mit testdisk eine Imagedatei zu erstellen:

Image Creation

www.cgsecurity.org

Wenn ich das richtig verstehe, könnte man dann diese Image-Datei ("image.dd") dann mounten?

Unter Linux würde das laut Anleitung mit mount -o loop,ro image.dd directory gehen, wie wäre es mit FreeBSD?

Oder das andere Beispiel darunter für MacOS, die Datei einfach in .img umbenennen? Könnte die dann so unter FreeBSD gemountet werden?

 

[mr44er]

Es handelt sich nicht um die originale Platte, sondern um eine Jahre später ersetzte und bessere Platte.

Das schützt trotzdem nicht vor falsch gewählten Schritten oder wenn sie zufällig genau jetzt im laufenden Betrieb hardwaretechnisch kaputt geht. Wegen falsch gewählten Schritten befindest du dich ja bereits in der misslichen Lage.

Wie wäre es, wenn du die Platte wenigstens einmal klonst und erst dann mit der Diagnose ausprobierst, wie und ob man ein image schreiben kann? Dann erst darauf die Rettungsversuche aufbauend.

Jeder noch so gute Tip hier ohne Klon kann game over bedeuten...das sind auch keine Tätigkeiten, die man problemlos blind jeden Tag macht.

 

[Andy_m4]

wie wäre es mit FreeBSD?

Das Stichwort wäre hier Memory-Disk (md) mit dem Tool mdconfig. Da kommt dann ein Blockdevice im Schema /dev/mdX raus, worauf Du dann alle normalen Blockdevice-Operationen (inkl. mounten, was Du bei Deinem Beispiel ja machst) machen kannst.

 

[turrican]

Welche der beiden Optionen ist nun bedeutungsgleich mit "wie vorgeschlagen" bzw. "Kopieren vom Header in den Backup Header"?

Org. BS (Copy superblock over backup sector) oder Dump (Dump superblock and backup superblock)? Ich nehme an ersteres ("Org .BS")?

Copy sp over backup sector - annehmend, das mir das dann den (guten) Volume Header auf den (defekten) Backup Volume Header schreibt;

 

[medV2]

Erster Schritt sollte auf jedenfall sein, eine Kopie der Platte zu erstellen und dann auf einer Kopie der Kopie zu arbeiten. Wurde hier ja schon erläutert.

Da du "nur" die Daten retten willst: Scheiß auf das Partitionsgedöns, nimm photorec (kommt ja idr. mit testdisk mit) und sag ihm, er soll auf der ganzen Platte suchen. Nachteil ist nur, dass du vermutlich keine Dateinamen mehr haben wirst - kommt dann etwas auf die zu rettenden Daten an, ob das sinnvoll ist.

 

[pit234a]

Klingt ähnlich wie die Möglichkeit, mit testdisk eine Imagedatei zu erstellen:

habe ich nicht so verstanden, sondern es wird eher erklärt, wie mit einem image umzugehen ist.
Einfachstes Tool zum erstellen eines Images ist sicher dd, besser aber ist dd-rescue und ich habe nun einfach mal einen Namen geschrieben, ohne nochmal nachzusehen. Es gibt ein obsoletes ddrescue, das eine etwas abweichende Schreibweise zum aktuellen hat und ich kann mich nie erinnern, was nun gerade welches ist. Das kannst du aber auch selbst nachlesen.

Da du "nur" die Daten retten willst: Scheiß auf das Partitionsgedöns, nimm photorec

genau.
Davon abgesehen, dass ich selbst noch nie mit testdisk Erfolg hatte, irgendwelche Dateisysteme oder Partitionen wieder her zu stellen, wenn ich nicht genau wusste, was davon ich zuvor kaputt gemacht hatte, ist meiner Erfahrung nach gerade die Unterstützung für HFS im OpenSource-Land recht rumpelig, um das mal so zu sagen. Mir selbst haben eher die Dateisystem-eigenen (fsck) Tools oft gut geholfen.
Allerdings mache ich auch nicht täglich mit solchen Tools herum, sondern bestenfalls alle paar Jahre mal und Gottlob sind die letzten Versuche nun auch schon lange her. Es kann sich da also echt was geändert haben.

Zur Analyse und dann evtl daraus abgeleiteter Wiederherstellung fand ich den sleuthkit oft hilfreich. Den gibt es auch für FreeBSD. Ist aber eine recht hohe Lernkurve zu bewältigen und keine Ahnung, wie hilfreich er bei HFS sein kann, wenn man das noch nicht mal richtig kennt.

 

[mr44er]

Ergänzend:
Aus dem kostenpflichtigen HDDSuperClone wurde vor kurzem OpenSuperClone, Scott Dwyer hat das Projekt abgegeben.
https://www.hddsuperclone.com/ -> ploff -> https://github.com/ISpillMyDrink/OpenSuperClone

Ich habe mal reingeschaut, aber noch nicht ernsthaft damit gearbeitet...gerade kein Testmeerschweinchen vorhanden.
Eine Platte kann man damit zwar regulär klonen, aber es ist eher dickes Geschütz für die Fälle die bereits mechanische Schäden haben.

Weiters wurde mir noch https://dmde.com/de/ nahegelegt, es soll sehr intuitiv sein.

 

[cabriofahrer]

Da du "nur" die Daten retten willst: Scheiß auf das Partitionsgedöns, nimm photorec (kommt ja idr. mit testdisk mit) und sag ihm, er soll auf der ganzen Platte suchen. Nachteil ist nur, dass du vermutlich keine Dateinamen mehr haben wirst - kommt dann etwas auf die zu rettenden Daten an, ob das sinnvoll ist.

Mit photorec hatte ich auch schon überlegt, aber nein, das wäre das totale Chaos, zumal auf der Partition ja auch das komplette MacOS drauf ist. Ich will nur an die Daten ran, die im Homeverzeichnis des Users drin sind und selbst davon wohl auch nicht alle.
Das Problem, was ich habe, ist, dass ich nirgendwo eine Platte mit mehr als 465 GB freien Speicherplatz habe, um die Imagedatei zu erstellen.
Ich habe wie oben in #8 vorgeschlagen die Option "Org. BS" genommen, doch auch wenn wie der Screenshot zeigt, die Angabe jetzt korrekt ist, wird die Partition trotzdem nicht gemountet (die EFI-Partition, wie auch vorher, aber schon). Der Screenshot zeigt auch eine Meldung von dmesg "Partition 2 on ... is not aligned on 4096 bytes". Ist das vielleicht das Problem? Mit testdisk kann man wohl auch die Geometrie ändern. Weiterer Gedanke: Was, wenn ich mit testdisk einfach den Partitionstyp ändere, z.B. anstatt von hfs auf FreeBSD ufs? Würden die Daten erhalten bleiben und die Partition dann gemountet werden? Ansonsten bleibt mir im Moment nichts anderes übrig, als irgendwo 500 GB Speicherplatz herzubekommen.

 

[Lance]

Für alle die unter Linux/FreeBSD ein grafisches freies Tool verwenden möchten, möchte ich an dieser Stelle nochmal auf https://diskdigger.org/ verweisen. Das Tool lief bei mir problemlos auch unter FreeBSD. Ihr braucht dazu nur Mono. (Kein Wine, etc.)

Für @cabriofahrer mag es in diesem Falle evtl. nicht das richtige Tool sein, da es offiziell weder APFS noch HFS(+) unterstützt.

 

[Alexco]

Der Screenshot zeigt auch eine Meldung von dmesg "Partition 2 on ... is not aligned on 4096 bytes". Ist das vielleicht das Problem?

Nein, das Ausrichten auf einen 4k Block verhindert nicht, dass die Daten gelesen werden, es gibt halt nur Performance-Probleme, meistens beim Schreiben. Lass also die Geometrie unverändert, da machst Du alles nur noch schlimmer durch.

Gedanke: Was, wenn ich mit testdisk einfach den Partitionstyp ändere, z.B. anstatt von hfs auf FreeBSD ufs? Würden die Daten erhalten bleiben und die Partition dann gemountet werden?

Nein, denn die internen Strukturen auf der Platte sind zwischen HFS und UFS komplett anders, dann sagt Dir FreeBSD nur, dass die UFS Partition nicht gemountet werden kann und startet fschk...

Ich glaube, es wäre das Einfachste, Du besorgst Dir eine 2TB Platte und machst ein paar Images. Was sagt eigentlich macOS, wenn Du dort im Festplattendienstprogramm die "erste Hilfe" startest?

 

[cabriofahrer]

Ich glaube, es wäre das Einfachste, Du besorgst Dir eine 2TB Platte und machst ein paar Images.

Warum ein paar? Ich brauche doch nur eins, um es mounten und die Daten dann rauskopieren zu können.

Was sagt eigentlich macOS, wenn Du dort im Festplattendienstprogramm die "erste Hilfe" startest?

Keine Ahnung, ich habe kein MacOS. Ob es erfolgversprechend wäre, die Platte wieder in das MacBook einzubauen um zu gucken, was beim Booten passiert (falls es dann überhaupt bootet), weiss ich nicht. Leider ist es beim MacBook keine so einfache Operation, die Festplatte auszutauschen, da muss man das halbe Teil auseinandernehmen.

 

[pit234a]

Ich brauche doch nur eins, um es mounten und die Daten dann rauskopieren zu können.

nein.
Du brauchst das Image, um daran zu arbeiten und Dinge zu verändern und deine Daten dann wieder zugänglich zu bekommen. Durch das Schreiben des Image hast du ja nichts repariert, du kopierst ja alle Fehler mit.

Ein Image gibt dir nur mehr Sicherheit, weil es die alte Platte schont und du das Original nicht weiter durch eigene Fehler verhunzen kannst. Zwei Images geben entsprechend mehr Sicherheit. Dabei solltest du womöglich nicht zwei von der Platte direkt erzeugen, sondern das eine Image dann wieder klonen (kopieren).
Diese Empfehlungen macht man für gewöhnlich aus dem Hauptgrund, dass Fehler auf Platten oft daher rühren, dass sie zu alt sind und also die HW spinnt. Man will dann diese Platten möglichst schonen und schreibt sich deshalb erst mal ein Image, so lange das noch geht.
Aber tatsächlich sind die meisten Tools zur Datenrettung nicht selbst erklärend und am ehesten für Profis, also Leute, die nicht nur wissen, was sie da machen, sondern auch eine Menge Erfahrung und die nötige Fingerfertigkeit mitbringen.

Mit irgendwelchen HFS-Tools hatte ich mir damals das Partitionsschema zerschossen und mit testdisk glaube ich wiederhergestellt,

Ich beziehe mich mal darauf: so etwas passiert nur allzu leicht und wie willst du derartige Fehler nun verhindert, wo das Kind ja schon im Brunnen liegt?
Es ist mehr als wahrscheinlich, dass du nicht auf Anhieb den magischen Befehl findest, der dir deine Daten wieder bringt. Das ist allermeist, zumindest bei uns Laien, ein Versuch und Irrtum Spiel. Das will man nicht auf dem Medium veranstalten, das als einziges die relevanten Daten noch enthält.

Zu dem Zitat noch weiter: es gibt natürlich unglaublich viele Möglichkeiten, Fehler zu machen und es kann an allen Ecken und Enden was kaputt gefriemelt werden. Wenn du so sehr sicher bist, dass du da irgendwas an dem Partitions-Schema zerschossen hast, wären ja die Partitionen noch alle da und lediglich die Information im GPT wäre fehlerhaft.
Was sagt denn gpart dazu? Oder das hübsche gparted unter Linux?
Ich würde mich (aus eigener Erfahrung) eher hüten, hier irgendwas mit testdisk zu versuchen, wobei ich mir nicht sicher bin, was das macht und will. Meiner Erfahrung nach liest es ebenfalls zunächst den GPT (MBR) und erst auf besonderen Wunsch versucht es, unabhängig davon Partitionen zu finden. Dabei arbeitet es aber nicht sehr intelligent, zumindest war es mir nicht hilfreich. Nur dann, wenn ich durch andere Tools eh schon genau wusste, was ich von ihm wollte, konnte ich es gelegentlich mal erfolgreich einsetzen.

Übrigens, wenn ich es nun richtig im Kopf habe, meckert testdisk bei dir ja ganz genau an, dass GPT und sein Backup unterschiedlich sind, Das würde dafür sprechen, dass du vielleicht wirklich nur die Information in deinem GPT zerschossen hast. In dem Fall könntest du den Backup vielleicht, womöglich, vielleicht auch nicht, eben als Backup benutzen und den zurück spielen. Dafür hat man ihn ja.

Doch, als Leidgeprüfter nochmal: erst eine Sicherung des Ist-Zustandes (ein Image schreiben), wenigstens eines, dann genau hinsehen, was ist und was man will. Dann die Versuche starten, es wieder heil zu machen.

Das alles ist, wie immer, wenn es um Datenrettung geht, alles andere als einfach und flott.
Deshalb muss die allererste Frage zu Anfang lauten: will ich das wirklich auf mich nehmen? Sind die Daten dort wirklich wichtig oder zumindest interessant?
Denn es besteht auch die recht große Chance, dass eh nichts mehr zu retten ist. Trotz aller Mühe und all dem Hirnschmalz, den das alles kostet.

 

[mr44er]

Data Recovery Training - ReclaiMe Pro

Become a data recovery expert with ReclaiMe training: data recovery textbook and posters

www.data.recovery.training

Da gibts Tutorials und viele basics gratis. Zu meiner Verwunderung zwei Frauen, englisch mit gerolltem R inklusive.

 

[pit234a]

Da gibts Tutorials und viele basics gratis. Zu meiner Verwunderung zwei Frauen, englisch mit gerolltem R inklusive.

das Video zu GPT habe ich mir fast komplett gegönnt und nenne das nicht etwa schlecht. Es ist angenehm an zu sehen und zu zu hören.

Aber es hat mir kein bisschen Wissen vermittelt, das ich nun praktisch einsetzen könnte.

Das ist aber eben genau der Punkt: erst mal verstehen, was überhaupt normal ist und dann sich langsam an die Fehler heran tasten.
Das macht unverschämt viel Arbeit.

 

[mr44er]

Ja, ich finds auch angenehm zu schauen, Rescuefirmen geben selten und ungerne 'gratis' was preis, daher hielt ich das für ganz nett. Explizit und direkt hilft das mit HFS natürlich nicht, aber mal für einen groben Überblick zur Einarbeitung...es ist zwar recht allgemein gehaltener Krams (und kein Geheimwissen), aber zentral und umfangreich.

Nochmals an der Stelle der Rat: klone das mehrmals wohin und fummel nur am Klon rum...alles andere ist zuviel Risiko. Wenn dir die Daten nicht so wichtig sind, dass du dafür eine 500GB-Platte 'investieren' magst, dann kann es ja nicht so schlimm sein.

 

[Andy_m4]

Mit photorec hatte ich auch schon überlegt, aber nein, das wäre das totale Chaos, zumal auf der Partition ja auch das komplette MacOS drauf ist. Ich will nur an die Daten ran, die im Homeverzeichnis des Users drin sind und selbst davon wohl auch nicht alle.

PhotoRec hat den Charme, das es non-destruktiv arbeitet, weil es gefundene Dateien runterkopiert und nicht den Datenträger selbst ändert. Damit sparst Du Dir immerhin schon mal eine Kopie/Image zu machen.
PhotoRec erlaubt darüber hinaus die Selektion des Dateityps. Damit eben nicht jedes Binary eingesammelt wird. So kannst Du Dir gezielt z.B: nur JPEG-Dateien rausziehen lassen. Da sammelst Du zwar wahrscheinlich immer noch viel Zeug ein, was Du nicht brauchst, aber hast es schon deutlich eingeschränkt.

Ich würde es einfach mal probieren. Du hast dabei ja nicht viel zu verlieren. Im schlimmsten Fall stellst Du fest, das da hinten mehr Dateien rausfallen als dir lieb ist oder möglicherweise ist der Erfolg auch schlechter, als Du es benötigst. Aber das weißt Du halt erst, wenn Du es probierst.
Und bevor Du jetzt noch weiter grübelst und gar nichts machst oder Sachen machst, die die Situation möglicherweise sogar noch verschlimmern, versuch erst mal das.

Ob es erfolgversprechend wäre, die Platte wieder in das MacBook einzubauen um zu gucken, was beim Booten passiert

Ist auch nicht empfehlenswert. Alle Aktionen die potentiell Schreibvorgänge auf die Platte machen bergen die Gefahr mehr kaputt zu machen und so das Recovery zu erschweren.

 

[pit234a]

Da sammelst Du zwar wahrscheinlich immer noch viel Zeug ein, was Du nicht brauchst,

um gerade mal da anzusetzen: viele viele Thumbnails sind zB in der Regel unerwünschter Ballast. Hier lohnt es sich unter Umständen, sofort einen Filter zu benutzen und alle kleinen Dateien zu ignorieren.


Aber beachte bitte auch die Hinweise auf den GPT und forsche da mal etwas detaillierter. Ich habe so ein Kribbeln im Bauch...

 

[cabriofahrer]

Was sagt denn gpart dazu? Oder das hübsche gparted unter Linux?

Danke soweit erstmal für alle Beiträge, auch zur grundsätzlchen Methodik bei solchen Angelegenheiten. Ich möchte zunächst auf die Frage mit gparted eingehen und das Ergebnis hier posten. Selbst der Check schlägt fehl:

GParted 1.5.0

configuration --enable-libparted-dmraid --enable-online-resize

libparted 3.5

========================================
Device:    /dev/mmcblk1
Model:    MMC T52732
Serial:  
Sector size:    512
Total sectors:    59768832
 
Heads:    255
Sectors/track:    2
Cylinders:    117193
 
Partition table:    gpt
 
Partition    Type    Start    End    Flags    Partition Name    File System    Label    Mount Point
/dev/mmcblk1p1    Primary    2048    392675    boot, esp    EFI System Partition    fat16        /boot/efi
/dev/mmcblk1p2    Primary    393216    4393215    swap        linux-swap      
/dev/mmcblk1p3    Primary    4395008    59767039            ext4        /

========================================
Device:    /dev/sda
Model:    USB30
Serial:  
Sector size:    512
Total sectors:    976773168
 
Heads:    255
Sectors/track:    2
Cylinders:    1915241
 
Partition table:    gpt
 
Partition    Type    Start    End    Flags    Partition Name    File System    Label    Mount Point
/dev/sda1    Primary    40    409639    boot, esp    EFI System Partition    fat32    EFI  
/dev/sda2    Primary    440106    976541449            hfs+      

========================================
Check and repair file system (hfs+) on /dev/sda2  00:00:01    ( ERROR )
       
calibrate /dev/sda2  00:00:01    ( SUCCESS )
       
path: /dev/sda2 (partition)
start: 440106
end: 976541449
size: 976101344 (465.44 GiB)
check file system on /dev/sda2 for errors and (if possible) fix them  00:00:00    ( ERROR )
       
fsck.hfsplus -f -y '/dev/sda2'  00:00:00    ( ERROR )
       
** /dev/sda2
Executing fsck_hfs (version 540.1-Linux).
** Checking Journaled HFS Plus volume.
Invalid B-tree node size
(3, 0)
** The volume could not be verified completely.

"Invalid B-tree node size" scheint hier wohl das Stichwort zu sein. Zum Thema photorec: Man bekommt damit, auch wenn man sämtliche Dateitypen, die man nicht haben will, abwählt, nur einen riesen Haufen an Dateien ohne Originaldateinamen und ohne Struktur, das ist für mich absolut unbrauchbar.
Einzig für mich brauchbares Ziel kann es nur sein, irgendetwas mounten zu können, so dass ich in der Dateistruktur /usr/home/<user> navigieren kann, um mindestens nur das Homeverzeichnis komplett herauszukopieren. Ich hänge noch Screenshots von gparted an, aus denen sich ergibt, dass von diesen 465 GB das meiste einfach unbelegter Platz ist.
Frage: Welches Programm könnte denn den Fehler "Invalid B-tree node size" beheben, wenn überhaupt? Könnte das ein Mac, oder selbst dieser nicht?

 

[pit234a]

"Invalid B-tree node size" scheint hier wohl das Stichwort zu sein.

ich gebe meinen Senf dazu. Also ausdrücklich meine eher unmaßgebliche Meinung.

Du operierst am Patienten direkt und verfolgst dabei eine Strategie. In der Wahl deiner Werkzeuge bist du aber eher unsicher: das ist eine ungünstige Kombination. Das Überleben des Patienten ist gefährdet.

Zunächst siehst du nicht nur hin, sondern willst auch etwas reparieren und das, was du an erster Stelle reparieren willst (das Allignement der Partition) ist möglicherweise gar nicht fehlerhaft gewesen, sondern nur auffällig für gparted. gparted ist dabei aber einer Linux-Tradition verhaftet, die Partitionen gerne nahe beisammen und günstig ausgerichtet sieht. Es schlägt hier stumpf Änderungen vor, die nicht immer vom Rest der Welt so gesehen werden.

Ich hätte übrigens erwartet, dass genau wie testdisk weiter oben, auch gparted über die Unterschiedlichkeit der beiden GPT-Sektionen meckert.
Da war mal was unterschiedlich.
Wenn du, mit welchem Tool auch immer, diesen Unterschied beseitigst und nicht vorher gesichert hast, ist er nun weg. Also egal, ob du sagst: ignoriere diesen oder jenen, nimm bitte den oder mach alles neu, wenn dein GPT nun keine Unterschiede mehr aufzeigt, ist das schlecht und nicht etwa gut repariert.

Meine Erfahrung mit den HFS-Tools ist begrenzt, aber schlecht. Wie mit allen proprietären Dateisystemen habe ich auch hier stets die Erfahrung gemacht, dass die hauseigenen Mittel der jeweiligen Systeme besser funktionieren, als die freien Kandidaten. Dabei liegen meine Erfahrungen aber so weit zurück, dass APFS damals noch gar nicht existierte. In neuerer Zeit (vor wenigen Jahren) hatte ich versuchsweise eine Platte mit APFS mal angesehen und erstaunlicherweise wurde sie mir in einem System als HFS(+) angezeigt, obwohl das sicher nicht war. Daraus folgere ich, dass man niemals einem einzigen Mechanismus alleine trauen darf und darauf alle Hoffnungen setzt, bevor man vollen Mutes einen finalen Schnitt ansetzt.
Ob ein Mac deshalb die Partition besser erkennt und benutzen oder reparieren kann? Die Chance ist wahrscheinlich größer, als wenn du selbst im oben gezeigten Stil weiter machst um deine Daten zu retten, aber ich würde meinen, nicht besonders groß.

Du willst natürlich deine Partition mounten.
Gemountet werden aber immer nur intakte Dateisysteme, egal, wo die nun liegen mögen. Doch wie wird das nun festgestellt, dass die Dateisysteme intakt sind? Das unterscheidet sich etwas von Dateisystem zu Dateisystem, aber ganz grob gesagt zeigt ein fsck am deutlichsten, welche Fehler erkannt werden. Erkannt! Erst kommt die Erkenntnis, dann das Reparieren. Du schießt einfach mal einen Befehl ab, alle Fehler unbedingt zu korrigieren und schon wieder veränderst du etwas, das womöglich nicht mehr rückgängig gemacht werden kann und mit ziemlicher Sicherheit, alles nur noch schlimmer macht.

Ich kann mir grad nicht vorstellen und man mag mich bitte aufklären, wie es im Betrieb zu einem Fehler kommen kann, dass der B-Tree eine ungültige node-Größe hat. Mir schweben da nur Maßnahmen vor meinem geistigen Auge, die solche Zustände gewaltsam herbeiführen oder, eine vollkommen falsche Erwartung des benutzten Programms, sprich, eine falsche Einschätzung über das benutzte Dateisystem.

Ich mag mich irren, aber ich fürchte, dass hier schon mehr Käse gequirlt wurde, als die Screenshots zeigen und dass es nun deshalb auch kaum noch einen Sinn macht, nachträglich ein Image von diesem gequirlten Käse zu erstellen. Mich selbst würde es ungemein reizen, die Platte (oder ihr Image) nochmal auszulesen, genau hinzusehen (mit hexdump) und dann in einem genialen Moment die Unstimmigkeiten zu sehen und auch korrigieren zu können. Ich verstehe diesen Spieltrieb.

Realistisch betrachtet kannst du froh sein, wenn du überhaupt irgendwelche Daten mit photorec zurück holen kannst. Es will mir als deine beste Option erscheinen, so lange der Patient noch lebt.
Hast du erst mal all die Daten, vor deren Flut du dich nun fürchtest, kannst du ja weiter deine Operation durchführen.

PhotoRec hat den Charme, das es non-destruktiv arbeitet, weil es gefundene Dateien runterkopiert und nicht den Datenträger selbst ändert. Damit sparst Du Dir immerhin schon mal eine Kopie/Image zu machen.

Da will ich nicht widersprechen.
Persönlich finde ich, dass trotzdem ein Image nicht schaden kann. Auch, wenn photorec selbst eher harmlos ist. Ein Image, so früh wie möglich, hätte wohl auch in diesem Fall vielleicht helfen können, die Verschlimmbesserung der Ausgangslage zu verhüten.
Immer erst mal Image!

Oh nein: immer Backup parat haben! Dann braucht es all diesen Datenrettungsquatsch ja nicht!
Wer schießt denn mit HFS-Tools auf Daten, die er noch braucht, ohne die vorher zu sichern?
Passiert ist passiert und wer macht keine Fehler?
Aber dann sofort Image machen! Dann sehen, dann reparieren versuchen.

 

[medV2]

Der invalid B Node Fehler spricht für mich für (zumindest auch) Probleme am FS selbst. Eventuell wäre es hilfreich die Recoverytools von Macos selbst zu verwenden. Ein Macbook hast du ja wohl, vielleicht kannst du die Platte ja per Adapter daran hängen, auch wenn ich immer noch DRINGEND zu einem Image raten würde.

Was Photorec betrifft: Wir reden hier von einer 512GB Platte, ich weiß nicht welche Daten du da hast, aber ich kann mir schwer vorstellen, dass das zusammensuchen des Photorec - Outputs mehr Aufwand ist, als was du hier gerade betreibst. Und ich habe schon die Daten der einen oder anderen HD so wiederbekommen. Du hast Filter nach Dateityp, du kannst über die Größe/Dateityp Kombination oft einiges aussclhießen, Bilder und Co lassen sich schnell anhand der Vorschau erkennen. Für Text gibts grep / zgrep oder Tools wie recoll.

 

[Andy_m4]

Bilder und Co lassen sich schnell anhand der Vorschau erkennen.

Noch eine kleine Ergänzung:
Gerade wenn man Fotos hat, enthalten die Dateien ja auch häufig EXIF-Informationen. Die kann man auch noch verwerten. Insbesondere Informationen wie der Zeitstempel wann das Foto gemacht wurde und möglicherweise noch GPS-Koordinaten, so das man dann sortieren kann nach "Urlaub 2010 in Italien" usw.

Persönlich finde ich, dass trotzdem ein Image nicht schaden kann.

Ich bin ganz auf Deiner Seite. Anscheinend ist es für ihn aber ein riesen Problem genug Speicherplatz aufzutreiben. Unter dem Aspekt ist es immer noch besser auf die Weise mit PhotoRec rumzuprobieren als Operationen am Patienten zu machen, wie Du es so schön ausgedrückt hast. Unglücklicherweise hört er nicht auf die Empfehlungen und macht es trotzdem und erklärt alle Alternativwege für unbrauchbar.

Welches Programm könnte denn den Fehler "Invalid B-tree node size" beheben, wenn überhaupt?

Es wurde ja hier schon mehrfach mit Nachdruck gesagt, aber ich machs trotzdem nochmal:
Auf dem Originaldatenträger solltest Du gar keine Schreiboperationen machen wenn Dir die Daten wichtig sind.
Ein fsck auf kaputte Dateisysteme losuzulassen heißt ja nicht, das die Bits ein wenig durchgeschüttelt werden und dann ruckeln die sich wieder zurecht.

Kaputtes Dateisystem bedeutet, das wichtige Informationen die zum Zugriff auf die Daten notwendig sind, sind kaputt. Das heißt, Du kannst nicht mehr ordentlich auf die Daten zugreifen. Wenn Du es könntest, bräuchte man diese Datenstrukturen nicht. Ein reparieren bedeutet zunächst einmal nur, das das Dateisystem ansich in Ordnung und konsistent ist. Ob damit Daten wiederhergestellt werden steht auf einem ganz anderen Blatt. Im schlimmsten Fall macht es die Situation sogar schlechter, weil Dateien "tuncated" werden usw.