Wie GPT Backup Partitionstabelle wiederherstellen?

Mr.joker

Lt. Commander
Registriert
Mai 2008
Beiträge
1.957
Hallo,

eine meiner Datenfestplatten kann unter Linux (Manjaro) nicht eingebunden und gelesen werden.

Unter Windows funktioniert sie aber nach wie vor!

Mein erster Gedanke war, mal mit Gparted nachzuschauen ...

Die erste Fehlermeldung, die dort angezeigt wird, lautet:
Screenshot_20211101_175123.png

Wenn ich auf "Ignorieren" klicke, erhalte ich das:
Screenshot_20211101_175236.png

Die Backup-GPT-Partitionstabelle scheint also korrupt, die Haupttabelle aber okay, was auch die Zugriffsmöglichkeit unter Windows erklären könnte. Scheint, als würde sich Windows einfach nicht an der kaputten Backup-Partitionstabelle stören!

Meine Internetrecherche hat mich dann auf gdisk gebracht.
Das habe ich mal im Terminal wie folgt aufgerufen:

Code:
sudo gdisk /dev/sdb                                                                                                         
[sudo] Passwort für benutzer:
GPT fdisk (gdisk) version 1.0.8

Warning! Disk size is smaller than the main header indicates! Loading
secondary header from the last sector of the disk! You should use 'v' to
verify disk integrity, and perhaps options on the experts' menu to repair
the disk.
Warning! Main and backup partition tables differ! Use the 'c' and 'e' options
on the recovery & transformation menu to examine the two tables.

Warning! One or more CRCs don't match. You should repair the disk!
Main header: OK
Backup header: OK
Main partition table: OK
Backup partition table: ERROR

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: damaged

****************************************************************************
Caution: Found protective or hybrid MBR and corrupt GPT. Using GPT, but disk
verification and recovery are STRONGLY recommended.
****************************************************************************

Command (? for help): e
b       back up GPT data to a file
c       change a partition's name
d       delete a partition
i       show detailed information on a partition
l       list known partition types
n       add a new partition
o       create a new empty GUID partition table (GPT)
p       print the partition table
q       quit without saving changes
r       recovery and transformation options (experts only)
s       sort partitions
t       change a partition's type code
v       verify disk
w       write table to disk and exit
x       extra functionality (experts only)
?       print this menu

Im Internet hatte ich schon gelesen, dass e der richtige Befehl sein sollte (was oben aber noch nicht dabei steht!).
Mittels r bin ich dann ins recovery Menü gegangen.

Code:
Recovery/transformation command (? for help): ?
b       use backup GPT header (rebuilding main)
c       load backup partition table from disk (rebuilding main)
d       use main GPT header (rebuilding backup)
e       load main partition table from disk (rebuilding backup)
f       load MBR and build fresh GPT from it
g       convert GPT into MBR and exit
h       make hybrid MBR
i       show detailed information on a partition
l       load partition data from a backup file
m       return to main menu
o       print protective MBR data
p       print the partition table
q       quit without saving changes
t       transform BSD disklabel partition
v       verify disk
w       write table to disk and exit
x       extra functionality (experts only)
?       print this menu

Demnach wäre e eigentlich das richtige, oder vielleicht doch c?

Ich habe es schon ein paar Mal mit e versucht, bin mir aber nicht sicher wegen der Syntax.

Nachdem ich e eingegeben hatte, wurde ich aufgefordert, dies noch einmal mit einer Y/N Abfrage zu bestätigen, danach passierte anscheinend nichts mehr. (Ich hatte auch statt einfach des Buchstabens, mal den kompletten Befehl sudo gdisk -e /dev/sdb eingeben, aber das erzielte auch keine andere Wirkung!)
Nachdem ich das mehrmals wiederholte (nur e eingeben), erhielt ich diese Ausgabe:

Code:
Recovery/transformation command (? for help): e
Warning! This will probably do weird things if you've converted an MBR to
GPT form and haven't yet saved the GPT! Proceed? (Y/N): Y
Caution! After loading partitions, the CRC doesn't check out!

Danach bin ich durch mehrmaliges drücken von q (Programm verlassen) und exit ganz raus gegangen und habe mit
Code:
sudo gdisk /dev/sdb
nochmal von vorne angefangen - mit selbem Ergebnis!

Also irgendwie komme ich da nicht weiter!
  • Muss ich den Kommando e noch mal mit w bestätigen oder so?
  • Soll ich es vielleicht mal mit c probieren?
  • Gibt es noch andere Möglichkeiten, die Backup-Partitionstabelle mit der Haupttabelle zu überschreiben? Von mir aus auch in Windows, darauf könnte ich in so einer Art Dualboot (via UEFI) auch noch zugreifen.

Es handelt sich um eine externe 14-TB-Platte, die gut gefüllt ist! Zum Glück ist das nur ein Backup-Platte, ich könnte also notfalls auch eine neue Partitionstabelle darauf schreiben und dann alle Daten noch mal neu drauf spielen. Aber das würde vermutlich ca. einen Tag dauern, was ich gerne vermeiden würde!

Für eine Hilfestellung wäre ich sehr dankbar.
 
warum machst du nicht
d use main GPT header (rebuilding backup)
wenn die "main" noch ok ist und das backup korrupt?

Und ja, du musst alles mit "w" write erst bestätigen, und danach verlassen ... sonst waren alle deine Änderungen nur schwebend und nicht wirklich auf der Platte :)
 
das 'e' Kommando nachdem Du suchst, dass befindet sich hinter:
x extra functionality (experts only)

anfangen würde ich bei Reparaturen defensiv mit
v verify disk
 

Anhänge

  • gdisk.png
    gdisk.png
    133,3 KB · Aufrufe: 378
Ja, "c" war definitiv Käse! Wenn, dann natürlich d. Mir ist nur der Unterschied zwischen d und e nicht wirklich klar; bei e steht halt "partition table" mit dabei, deshalb dachte ich, das wäre im Zweifel richtiger! :rolleyes:

Ich würde ja meine Partitionstabelle auch erst mal sichern, falls ich Mist baue.
Aber da stoße ich gleich auf zwei Probleme:
1. Wie sichere ich? Ginge evtl. mit "b", aber wie geht es dann wirklich (exakte Syntax), also ich meine so, dass es auch tatsächlich irgendwo abgespeichert wird, wo ich es auch wiederfinde?
2. Wie würde ich wieder zurückspielen?

Also, ich hab jetzt erst mal v eingegeben:

Code:
Command (? for help): v

Caution: The CRC for the backup partition table is invalid. This table may
be corrupt. This program will automatically create a new backup partition
table when you save your partitions.

Problem: main GPT header's backup LBA pointer (27344764927) doesn't
match the backup GPT header's current LBA pointer (27344699391).
The 'e' option on the experts' menu may fix this problem.

Problem: main GPT header's last usable LBA pointer (27344764894) doesn't
match the backup GPT header's last usable LBA pointer (27344699358)
The 'e' option on the experts' menu can probably fix this problem.

Problem: main header's disk GUID (40D93242-1516-4504-BC7F-E6BC54F25236) doesn't
match the backup GPT header's disk GUID (18DF32B6-42BE-4CF6-B435-9AE4DB70EE7E)
You should use the 'b' or 'd' option on the recovery & transformation menu to
select one or the other header.

Problem: Disk is too small to hold all the data!
(Disk size is 27344699392 sectors, needs to be 27344764928 sectors.)
The 'e' option on the experts' menu may fix this problem.

Problem: GPT claims the disk is larger than it is! (Claimed last usable
sector is 27344764894, but backup header is at
27344764927 and disk size is 27344699392 sectors.
The 'e' option on the experts' menu will probably fix this problem

Problem: partition 1 is too big for the disk.

Identified 7 problems!

Da wird ziemlich oft e empfohlen. Ob ich das mal machen soll (und mit w schreiben)? (Traue mich nicht so recht! :rolleyes:)
Ergänzung ()

PS: Das mit dem w (write table to disk and exit) habe ich deswegen noch nicht gemacht, weil ich dachte, dass ich damit eventuell einfach eine neue leere Partitionstabelle schreibe, womit ja dann definitiv die Daten weg wären.
 
Die interessante Frage ist warum denn hier das Laufwerk schrumpft. Hast du das in ein USB Gehäuse eingebaut, die fressen manchmal ein wenig was am Plattenende. Oder hast du das mit dd von einer größeren Platte kopiert? Oder an einen Hardware-RAID Controller gesteckt?

Du kannst das mal in der Luft probieren:

Code:
dd bs=1M count=1 if=/dev/sdb of=/dev/shm/sdb.img
truncate -s $((27344764928*512)) /dev/shm/sdb.img
parted /dev/shm/sdb.img unit s print free
 
hast Du eine Alternative als
The 'e' option on the experts' menu can probably fix this problem.
zu vertrauen?
 
kieleich schrieb:
Die interessante Frage ist warum denn hier das Laufwerk schrumpft. Hast du das in ein USB Gehäuse eingebaut, ...
Ja, so ähnlich!
Das ist eine WD Elements, die hatte ich aber - wenn ich mich richtig erinnere - direkt ausgebaut und an einer Docking Station betrieben. Kann sein, dass ich sie auch direkt neu partitioniert und formatiert hatte. Ich meine nämlich, dass mir die "original" Partitionierung nicht gefallen hätte, weil da ein kleiner unpartitionierter Rest war oder so (ist schon ne Weile her).
Dann habe ich die HDD aber irgendwann wieder in das ursprüngliche WD Elements Gehäuse zurückgebaut. Wieder angesteckt - und funktionierte. Das war aber noch unter Windows, kann sein, dass der Fehler dann damals schon bestand.
Ergänzung ()

@kieleich
Was macht der von dir eingefügte Befehl?
Ergänzung ()

@haiopai
Den Partitionswizard könnte ich mir mal anschauen (müsste ich dann erst mal mit Windows booten). Aber GPT in MBR umzuschreiben bei einer 14 TB Platte?
Ergänzung ()

Und noch eine Ergänzung, ich hatte vergessen, das dritte Bild von Gparted anzufügen:
Screenshot_20211101_175302.png

Also so sieht das dann aus. Auch der KDE Partitionsmanager sieht das so und deshalb kann ich unter Linux mit der Platte so nicht arbeiten (unter Windows kriege ich ja nicht mal mit, dass es da überhaupt ein Problem gibt, da wird sie ganz normal erkannt und eingebunden!).
 
Zuletzt bearbeitet:
Mr.joker schrieb:
Aber GPT in MBR umzuschreiben bei einer 14 TB Platte?
Ok, dass es eine 14TB Platte ist, hattest du nicht erwähnt.

aber evtuell kannst du den auch so einfach neu erstellen.

Hast du denn ein Backup?
 
Mr.joker schrieb:
Dann habe ich die HDD aber irgendwann wieder in das ursprüngliche WD Elements Gehäuse zurückgebaut. Wieder angesteckt - und funktionierte.
Manche externen Gehäuse nehmen ein paar der letzten Sektoren der Platte weg. Dort liegt aber der Backup-Sektor bei GPT und ggf. der letzte Rest der letzten Partition auf der Platte. Kein Wunder, dass sich Linux jetzt beschwert, dass das alles durcheinander ist (und Props an Windows, dass es sich nicht beschwert, was interessieren schon Benutzerdaten! ;) )
 
Du wirst nicht drum herum kommen die Partitionstabelle neu zu schreiben allerdings kannst du dir dabei auch das Dateisystem beschädigen wenn es zu groß ist bzw. wenn das Ende dann mit einem neuen GPT Backup überschrieben wird. Hast du NTFS oder exfat im Einsatz, für exfat gibt es meines Wissens noch kein Werkzeug unter Linux um das ein wenig kleiner zu machen.

Die oben genannten Befehle würden eine Kopie der Partitionstabelle machen, ein virtuelles Laufwerk mit der richtigen Größe, wo du dir die Partitionstabelle ausgeben lassen kannst. Mit diesen Daten kannst du dann eine neue Partitionstabelle mit den gleichen Startsektoren für jede Partition anlegen.

Du kannst auch von Windows aus versuchen das Dateisystem ein wenig zu verkleinern mit Windowswerkzeugen, da kenne ich mich aber nicht so aus
 
Ich hab die o.g. Befehle jetzt mal ins Terminal gehauen, auf gut Glück und ohne zu wissen, was ich da tue!

Code:
 dd bs=1M count=1 if=/dev/sdb of=/dev/shm/sdb.img                                                                             ✔
truncate -s $((27344764928*512)) /dev/shm/sdb.img
parted /dev/shm/sdb.img unit s print free
dd: konnte '/dev/sdb' nicht öffnen: Keine Berechtigung
WARNUNG: Sie sind kein Systemadministrator. Achten Sie auf Ihre Rechte.
Fehler: /dev/shm/sdb.img: unbekannte Partitionstabelle
Modell:  (file)                                                           
Festplatte  /dev/shm/sdb.img:  27344764928s
Sektorgröße (logisch/physisch): 512B/512B
Partitionstabelle: unknown
Disk-Flags:
    ~  sudo dd bs=1M count=1 if=/dev/sdb of=/dev/shm/sdb.img                                                                        ✔
truncate -s $((27344764928*512)) /dev/shm/sdb.img
parted /dev/shm/sdb.img unit s print free
[sudo] Passwort für benutzer:
dd: konnte '/dev/shm/sdb.img' nicht öffnen: Keine Berechtigung
WARNUNG: Sie sind kein Systemadministrator. Achten Sie auf Ihre Rechte.
Fehler: /dev/shm/sdb.img: unbekannte Partitionstabelle
Modell:  (file)                                                           
Festplatte  /dev/shm/sdb.img:  27344764928s
Sektorgröße (logisch/physisch): 512B/512B
Partitionstabelle: unknown
Disk-Flags:
    ~ 
Nachdem da was von "Keine Berechtigung" stand, dachte ich, ah, dann halt mit sudo, aber das hat, wie man sieht, auch keine Änderung bewirkt.

Aber das, was du da schreibst, klingt so, als könnte es funktionieren - wenn man Ahnung hätte (was bei mir nicht ausreichend der Fall ist)!

Und in dem Fall bringt wahrscheinlich auch der Wiederherstellungsversuch mittels gdisk und dem Befehl e (load main partition table from disk (rebuilding backup)) nichts, weil dann halt einfach nicht genügend Platz vorhanden wäre.

Die Platte ist übrigens in NTFS, weil du gefragt hattest.

Vielleicht probiere ich es gleich trotzdem mal, und wenn nicht beiße ich halt in den sauren Apfel und mache alles neu.
Ist ja wie gesagt "nur" die Backup-Platte, solange die Original-Platte jetzt nicht auch noch streikt, habe ich keinen Datenverlust, nur das erneute Beschreiben von ca. 9-10 TB wird halt ne Weile dauern! Da werden beide Platten ordentlich rumrödeln.

Am Rande frage ich mich noch: Wenn ich eh alles neu machen müsste, soll ich dann vielleicht mal was anderes nehmen, als NTFS? Vielleicht ext4?
Also, der Plan ist, dass ich eigentlich nur noch von Linux darauf zugreife, bzw. die Datensicherung von Platte A (ist aber eh noch in NTFS) nach B (ext4?) mache.
Bringt das dann irgendwas (mehr Geschwindigkeit, mehr Zuverlässigkeit), oder ist das Quatsch, weil die Original-Platte eh noch in NTFS ist (und aufgrund der großen Datenmenge, die da schon drauf ist, wohl auch so bleiben wird).
Von Linux aus könnte ich dann beide Platten lesen, sollte ich doch wieder auf Windows zurückgehen, müsste ich halt die Backup-Platte noch mal umformatieren.
Ergänzung ()

So, jetzt habe ich es gerade versucht:
Code:
Recovery/transformation command (? for help): e
Warning! This will probably do weird things if you've converted an MBR to
GPT form and haven't yet saved the GPT! Proceed? (Y/N): Y

Recovery/transformation command (? for help): w
Caution! Secondary header was placed beyond the disk's limits! Moving the
header, but other problems may occur!

Warning! Secondary partition table overlaps the last partition by
63521 blocks!
You will need to delete this partition or resize it in another utility.

Problem: partition 1 is too big for the disk.
Aborting write operation!
Aborting write of new partition table.
 
Du scheints da alle drei Zeilen auf einmal ins Terminal reinzupasten, es ist aber ein Befehl pro Zeile, da müsste dann jeweils sudo davor. Das würde auch nur mal die Partitionstabelle anzeigen (ohne irgendwas auf der Platte zu verändern).

Edit: du kannst genausogut in gdisk auchmal p print machen und die Ausgabe zeigen

Es sollte in Windows möglich sein das Dateisystem und damit auch die Partition etwas zu verkleinern.

https://docs.microsoft.com/de-DE/wi...rink-a-basic-volume#additional-considerations
 
Mit dem KDE Partitionierer könnte ich auch die Größe ändern (oder es versuchen!).
Screenshot_20211102_135325.png

Was sind denn 63521 Blöcke in MiB? Kann man das umrechnen?
 
Hi...

Leider bin ich (noch) nicht so Linux-firm, aber hier (nicht wundern - das Deutsch ist wohl aufgrund automatischer Übersetzung manchmal etwas schwer verständlich / Orig.-Art. engl.) scheint's wohl in (fast) gleicher Problem-Konstellation die Lösung deutlicher beschrieben zu geben.

Ansonsten wär ja vllt. aber auch mal interessant wg. NTFS einen Kreuzvergleich mit TestDisk unter Win zu machen - das Tool beherrscht auch Funktionen zur Bootsektor- und MFT-Reparatur. Man kann's natürlich auch genauso unter Linux nutzen.
Übrigens Achtung:
Bei der Auswahl des Partitionstabellen-Typs im Startprozess muß natürlich abweichend von dieser Anleitung bei Dir EFI GPT ausgewählt werden.​
 
Das kannst du versuchen und dann können auch die Daten weg sein.

Ich benutze keine grafischen Partitionierer, das Bild macht überhaupt keinen Sinn. Minimale Größe = Maximale Größe was soll der Quatsch. Freien Platz davor willst du nicht sondern dahinter, aber eigentlich willst du ja gar keinen freien Platz sondern einfach nur die richtige Größe. Dann die schönen Angaben in TiB wo man gar nicht sieht ob das jetzt um die paar Sektoren angepasst wird oder nicht.

Da musst du nach dem Prinzip Hoffnung hoffen daß die Entwickler sich was bei gedacht haben, erstaunlich oft ist das aber nicht der Fall bzw. du hast eine ungewöhnliche Situation auf die solche Programme oft nicht ausgelegt sind und dann passieren unberechenbare Dinge.

Viel Glück
 
Edit: Geht doch nicht mit de
kieleich schrieb:
... Minimale Größe = Maximale Größe was soll der Quatsch. ...
Geht auch gar nicht, habe ich gerade gemerkt! Ich dachte, man könnte z.B. bei "Freier Platz dahinter" einen Wert X eintragen, der dann eben die Größe um diesen Wert verkleinert. Aber man kann überhaupt keine Werte eintragen.
Ist also tatsächlich sinnlos an der Stelle.
Na ja, muss ich mal schauen ... (in der Zeit hätte ich jetzt vermutlich auch schon die Hälfte der Daten neu geschrieben! ;))
 
Kannst du einfach mal die Partitionstabelle zeigen? Du hast oben viele Ausgaben gepostet aber p print war nicht dabei.
 
Code:
Command (? for help): p
Disk /dev/sdb: 27344699392 sectors, 12.7 TiB
Model: Elements 25A3   
Sector size (logical/physical): 512/4096 bytes
Disk identifier (GUID): 40F93242-1516-4504-BC7F-E6BC54F25236
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 27344764894
Partitions will be aligned on 2048-sector boundaries
Total free space is 4029 sectors (2.0 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048     27344762879   12.7 TiB    0700
Ergänzung ()

User007 schrieb:
... aber hier (nicht wundern - das Deutsch ist wohl aufgrund automatischer Übersetzung manchmal etwas schwer verständlich / Orig.-Art. engl.) scheint's wohl in (fast) gleicher Problem-Konstellation die Lösung deutlicher beschrieben zu geben.
...​
Auf diese und ähnliche Seiten war ich auch schon gestoßen, so bin ich ja überhaupt auf gdisk gekommen.
Aber das funktioniert so bei mir nicht, s. ab Beitrag 11 (und 12 unten, da ist die Ausgabe, was passiert, wenn ich versuche, die Backup-Partitionstabelle mit der Haupttabelle zu überschreiben).
Problem: Die Platte ist zu klein, die Backup-Partitionstabelle passt einfach nicht mehr drauf!
 
Zuletzt bearbeitet:
OK, also. Ich merke gerade daß ntfsresize auch gar nicht damit umgehen kann, wenn das Device einfach zu klein ist:

Code:
ntfsresize v2021.8.22 (libntfs-3g)
Failed to read last sector (27344697309): Invalid argument
HINTS: Either the volume is a RAID/LDM but it wasn't setup yet,
   or it was not setup correctly (e.g. by not using mdadm --build ...),
   or a wrong device is tried to be mounted,
   or the partition table is corrupt (partition is smaller than NTFS),
   or the NTFS boot sector is corrupt (NTFS size is not valid).
ERROR(22): Opening '/dev/loop0p1' as NTFS failed: Invalid argument
The device '/dev/loop0p1' doesn't have a valid NTFS.
Maybe you selected the wrong partition? Or the whole disk instead of a
partition (e.g. /dev/hda, not /dev/hda1)? This error might also occur
if the disk was incorrectly repartitioned (see the ntfsresize FAQ).

D.h. selbst wenn wir das unter Linux mit der Partitionierung hinbekommen, das Dateisystem kommt da nicht davon.

Mache es mit Windows Datenträgerverwaltung und/oder sichere deine Daten.

Alternativ die Festplatte noch mal zurückbauen, und dann dort erst verkleinern bevor es zurück ins USB Gehäuse geht.
 
Zurück
Oben