GPT-Tabelle, Erholung

Analyse

Der Befehl, den Sie verwendet haben

sgdisk -R /dev/sdb /dev/sdh2

Kopierte die GUID-Partitionstabelle (GPT) von /dev/sdh2 nach /dev/sdb.

Ein Problem ist, dass /dev/sdh2 eine Partition ist. Jede Partition hat keine oder Partitionstabelle. Oder zumindest sollte es nicht haben. Ich kann mir eine aussagekräftige Partitionstabelle innerhalb einer Partition vorstellen (und sie sogar irgendwie zum Laufen bringen), aber das ist umständlich, exotisch, nicht wirklich nützlich.

Die resultierende Kopie ist ein leerer GPT weil anscheinend die relevanten (aber nicht aussagekräftigen) Werte in /dev/sdh2 zu einer solchen Tabelle geführt haben. Das ist nicht wirklich wichtig.

Was zählt, ist, dass du den ursprünglichen GPT auf /dev/sdb überschrieben hast. Der Befehl, den Sie verwendet haben, hat nur die Partitionstabelle geändert, alle anderen Strukturen werden voraussichtlich noch vorhanden sein. Das Dateisystem selbst sollte in Ordnung sein (es sei denn, Ihr späterer Wiederherstellungsversuch war unglücklich genug, um es zu beschädigen). Sie haben nur eine bequeme Möglichkeit verloren, zum Dateisystem zu gelangen. Bitte lesen diese Antwort von mir, sein Anfangsteil fasst den Unterschied zwischen Partition und Dateisystem zusammen.

Ihr Ziel ist es nun, das ursprüngliche GPT irgendwie wiederherzustellen. Beachten Sie, dass Ihre Situation so ist, als befänden Sie sich mitten in der in der genannten Antwort beschriebenen Prozedur: Sie haben den Partitionstabelleneintrag zerstört, aber noch keinen neuen erstellt. Der Unterschied besteht darin, dass Sie nicht unbedingt eine größere Partition erstellen möchten und den Offset (Startsektor), in dem sich die Partition befindet, nicht kennen sollte beginnen.

GPT besteht aus primären und sekundären (Backup) Tabelle. Die sekundäre Tabelle kann Ihnen beim Wiederherstellen des alten Status nicht helfen, da sgdisk -R beide Tabellen geändert hat, um den gesamten GPT in einem konsistenten Zustand zu belassen.

Offset finden

Es gibt Tools, mit denen Sie eine Festplatte scannen, Dateisystemsignaturen finden, die Dateisystemgröße aus der Signatur lesen und einen Partitionstabelleneintrag vorschlagen können, der das Dateisystem ordnungsgemäß in eine neu definierte Partition einbetten kann, so kann es leicht montiert werden. Ein solches Werkzeug ist testdisk. Wenn nur die alte Partitionstabelle ausgelöscht wurde, sollte testdisk in der Lage sein, das Dateisystem zu finden und einen vernünftigen GPT zu erstellen. Das Scannen kann eine Weile dauern.

Alternativ können Sie versuchen, den richtigen Offset zu erraten. Die Tatsache, dass Sie nur eine Partition hatten, ist ein Vorteil.

Bitte lesen Sie dies ist eine andere Antwort von mir. In Ihrem Fall (logische Sektorgröße von 512) ist der wahrscheinlichste Startsektor 2048 und der Befehl, der Arbeit ist:

mount -o ro,offset=$((512*2048)) /dev/sdb /some/mountpoint/

Das Einbinden von schreibgeschützten Daten wirkt sich nicht auf Daten aus, die bisher überlebt haben, daher sollte es sicher sein, es zu versuchen. Wenn der Befehl erfolgreich ist und Sie überprüfen, ob Dateien und Verzeichnisse unter /some/mountpoint/ angezeigt werden, bedeutet dies, dass der Versatz richtig ist.

Hinweis: 512*2048 ist genau 1-MiB. In einem der Screenshots haben Sie:

Possible partition … offset(1mb)

Ich denke, das ist der eine. Es würde höchstwahrscheinlich auch von testdisk gefunden, wenn Sie dieses Tool verwenden würden.

Partitionstabelleneintrag erstellen manuell

Wenn Sie sich entschieden haben, testdisk (oder ähnliches) nicht zu verwenden, den Offset gefunden haben, der richtig erscheint, können Sie eine Partitionstabelle mit Sane-Eintrag manuell erstellen (mit gdisk, sgdisk oder jedes Werkzeug in der Lage, dies zu tun). Folgen Sie diesen Hinweisen:

• Wenn das Dateisystem gemountet ist (z. B. mount -o ro,offset=… … aus dem vorherigen Absatz), umount es.
• Behalte es GPT. Wenn die logische Sektorgröße stimmt, ist es sehr unwahrscheinlich, dass Sie ursprünglich eine DOS-Partitionstabelle in MBR hatten. Auch wenn Sie es ist jedoch unmöglich, dass die Partition, die am Sektor 2048 beginnt, das Ende der Festplatte erreicht. Es ist also sicher, ganz am Ende der Festplatte einen sekundären GPT zu erstellen, auch wenn es ursprünglich keinen gab (abgesehen davon, dass sgdisk -R bereits einen geschrieben hat, können Sie ihn nicht verschlimmern). Aber bitte sehen Sie" mögliche Probleme " Abschnitt später in dieser Antwort, nur für den Fall.
• Der Startsektor sollte 2048 sein, da dies der Offset ist, den Sie gefunden haben.
• Die Größe sollte gleich oder größer als die größe des Dateisystems. Im Moment ist der einzige Hinweis, den Sie haben, size(764432mb), ich bin mir nicht sicher, ob mb hier MB oder MiB bedeutet oder ob es nicht völlig falsch ist. Der sicherste Ansatz besteht darin, (vorübergehend) den Maximalwert für den Endsektor zu verwenden. Durch einen anderen Screenshot glaube ich, dass der Maximalwert für den Endsektor 5860533134.
• Die[Partitionstyp-GUID] sollte die richtige für NTFS sein: EBD0A0A2-B9E5-4433-87C0-68B6B72699C7. Hinweis in gdisk können Sie einen kurzen Code von 0700 für dieser.
• Das Werkzeug darf das Dateisystem nicht berühren, es betrifft nur die Partitionstabelle. Wenn es versucht, die "neue" Partition zu formatieren (mkfs) oder zu löschen (wipefs), ist es nicht das richtige Werkzeug. Ich glaube, gdisk ist sicher. Ich wäre sehr vorsichtig mit GUI-All-in-One-Partitionierungstools(einschließlich nativer Windows-Tools). Ehrlich gesagt bedeutet "sehr vorsichtig" in diesem Fall, dass ich sie überhaupt nicht verwenden würde.

Nachdem Sie einen richtigen Eintrag erstellt und die neue Partitionstabelle auf das Gerät geschrieben haben, /dev/sdb1 sollte angezeigt werden. Wenn es nicht angezeigt wird, rufen Sie partprobe auf.

Bestätigen Sie, dass Sie /dev/sdb1 mounten können.

Größe anpassen

Wenn /dev/sdb1 verfügbar ist, können Sie das Dateisystem einfach nach seiner Größe abfragen. Ich meine, was das Dateisystem weiß, ist seine Größe. Im Allgemeinen ist dies anders als die Größe der entsprechenden Partition. Es gibt mindestens zwei Werkzeuge, die Sie verwenden können:

• file -s /dev/sdb1
  

  Sie interessieren sich dafür, wo es steht sectors NNNNNN. Keine Sorge über hidden sectors (vergleiche ähnliche Zweifel für FAT).

• ntfsresize --info /dev/sdb1
  

  Sie interessieren sich für "Aktuelle Volumengröße". Drücken Sie es in 512-Byte-Sektoren aus (dh dividieren durch 512).

Die Zahl, die aus der Ausgabe von ntfsresize berechnet wird, unterscheidet sich möglicherweise kaum von dem, was file sagt. Ich denke, das hat etwas mit der Clustergröße zu tun. In meinen Tests scheint es, nachdem mkfs.ntfs aufgefordert wurde, eine ganze Partition zu verwenden, berichtet file einen Sektor weniger als die Anzahl der Sektoren in der partition. Verwenden Sie also eher file, nicht ntfsresize, identifizieren Sie sectors NNNNNN, fügen Sie einen hinzu. So groß muss die Partition sein. Fügen Sie im Zweifelsfall 2048 Sektoren hinzu. Es ist overkill, aber nur 1 MiB verschwendeten Platz, nicht viel; es wird Sie sicher sicher halten.

Wenn die Partition (die im vorherigen Absatz erstellt wurde) größer ist, möchten Sie sie möglicherweise verkleinern. Ich Stelle fest, Ihr Endziel war es, kopieren Sie die Dateisystem auf eine kleinere Scheibe; und es ist dies Possible partition … size(764432mb) … in einem der screenshots. Das macht mich glauben Sie, dass das Dateisystem tatsächlich kleiner ist als die neue Partition. Dies ist für sich genommen kein Problem, aber wenn Sie nach dem Ende des Dateisystems eine weitere Partition erstellen oder das Setup dennoch auf eine kleinere Festplatte kopieren möchten, ist das Verkleinern der Partition eine gute Idee.

Das Verfahren:

1. umount das Dateisystem, falls gemountet.
2. Entfernen Sie den Eintrag aus der Partitionstabelle.
3. Erstellen Sie einen neuen Eintrag wie im vorherigen Absatz, aber diesmal geben Sie die Anzahl der gerade berechneten Sektoren an. Beachten Sie, dass wir über die Größe der neuen Partition sprechen, nicht über den Endsektor. Wenn Sie den Endsektor kennen müssen, verwenden Sie diese Formel: start+size-1=end. Die Ausrichtung des Endes einer Partition sollte keine Rolle spielen (es ist wichtig für den Anfang), aber wenn das Tool darauf besteht, das Ende leicht zum Ende der Festplatte zu bewegen, lassen Sie es.
4. Speichern Sie die Partitionstabelle, führen Sie partprobe für alle Fälle aus.
5. Stellen Sie sicher, dass /dev/sdb1 fehlerfrei montiert wird. Auf den ersten Berg schreibgeschützt (mount -o ro …) nur für den Fall.

Wenn das Dateisystem gut mountet wird, sind Sie im Grunde fertig. Die Partitionstabelle ist jetzt gesund.

Mögliche Probleme

• Die neue Partition hat eine neue eindeutige Partitions-GUID. Andererseits bleibt die im Dateisystem gespeicherte "UUID" erhalten. Möglicherweise müssen Sie jedes Tool/Betriebssystem neu konfigurieren, das auf der ersteren basiert (oder den alten Wert aus einer Konfiguration abrufen und auf die neue Partition anwenden, diese einzelne move wird alle diese Konfigurationen wieder gültig machen). Ich weiß nicht, mit welcher ID Windows angibt, ob es die Partition/das Dateisystem zuvor gesehen hat.
• Ich kann die logische/physische Sektorgröße des Datenträgers als 512/4096 anzeigen. Bitte Lesen Sie diese Frage und die Erklärung in meiner Antwort darauf. Wenn mindestens ein USB-Gehäuse beteiligt ist und die Festplatte früher anders angeschlossen wurde als jetzt (d. H. In einem anderen Gehäuse; oder über SATA jetzt, in einem früheren Gehäuse; oder umgekehrt) und sie haben nicht überprüft, dass /dev/sdb1 mountet, bevor Sie sgdisk -R aufgerufen haben, dann vielleicht Die ursprüngliche (verlorene) Partitionstabelle war gültig für die logische Größe von 4096; und wenn Sie versucht haben, die Partition vor dem Missgeschick zu mounten, würde das gleiche Problem auftreten wie in der verknüpften Frage. Mein Punkt ist, dass meine Antwort Ihnen hilft, eine Partitionstabelle zu erstellen, die für das aktuelle - Setup gültig ist. Wenn dieses Problem Sie treffen würde, wird es Sie treffen, wenn Sie das Laufwerk im ursprünglichen Setup anschließen. Dann sie müssten die Partitionstabelle erneut anpassen. Meine Antwort auf die verknüpfte Frage wird helfen.

• Wenn das obige Aufzählungszeichen zutrifft und wenn size(764432mb) falsch ist, ist es möglich, dass Sie eine DOS-Partitionstabelle in MBR (nicht GPT) überschreiben (und überschreiben), die eine große Partition definiert hat, die sich bis zum Ende der Festplatte erstreckt, und das Dateisystem selbst erstreckt sich bis (fast) bis zum Ende der Festplatte. In diesem Fall hat sgdisk -R den sekundären (Sicherungs -) GPT am Ende erstellt, an dem ein Teil des Dateisystems sein sollte sein. Wenn das Dateisystem gut mountet, ist dies wahrscheinlich nicht der Fall. Im Allgemeinen kann es sein. Dies ist ein Szenario, in dem Sie möglicherweise Daten verloren haben.und Sie können mehr verlieren, wenn Sie es nicht beheben (stellen Sie bei Bedarf eine separate Frage).

  Hinweis Wenn Sie sicher sind, dass Sie GPT hatten, sind Sie sicher (weil die sekundäre Tabelle "immer" dort war). Und wenn Sie sicher sind, dass das vorherige Aufzählungszeichen nicht zutrifft, sind Sie sicher (da bei der logischen Sektorgröße von 512 und bei der DOS-Partitionstabelle im MBR die partition beginnend bei Sektor 2048 konnte nicht Spannweite, um das Ende Ihrer großen Festplatte).

Nachdem Sie die Partitionstabelle repariert haben, möchten Sie wahrscheinlich mit Ihrem ursprünglichen Plan fortfahren. Dann:

• Die andere Festplatte kann eine andere logische Sektorgröße haben. Ich bin nicht sicher, ob (richtig verwendet) sgdisk -R Einträge zwischen verschiedenen Größen neu berechnet. Ich erwarte es. Falls nicht, Sie wissen, was zu tun ist.
• Aber vielleicht sie wollten die einzige Partition von /dev/sdb (dh /dev/sdb1 oder so) nach /dev/sdh2 klonen; und es gibt /dev/sdh1, die Sie behalten möchten. Wenn ja, ist sgdisk -R nicht was Sie tun möchten. Wenn Sie die Partitionstabelle von /dev/sdb nach /dev/sdh2 (eine Partition) kopieren, erhalten Sie nichts. Wenn Sie es in /dev/sdh kopieren, wird die aktuelle Partitionstabelle dort ersetzt und mit dem aktuellen /dev/sdh2 (und /dev/sdh1 falls vorhanden) durcheinander gebracht. Verwenden Sie sgdisk -R nur, wenn die Zielfestplatte keine Daten enthält, die Sie behalten möchten. Fragen Sie im Zweifelsfall einen separaten frage nachdem Sie die Partitionstabelle von /dev/sdb behoben haben. Die neue Frage sollte die Ausgabe von gdisk -l (oder fdisk -l) für beide Festplatten enthalten und Sie sollten klar angeben, auf welche Partition(en) Sie wo klonen möchten, welche Partition(en) entbehrlich sind und welche Partition(en) sollte intakt bleiben.