[gelöst] Image-Vollbackup von HDD mit GPT?

[hikaru]

Hallo,

ich wollte ein Vollbackup der HDD mit dem ausgelieferten Endless-Linux aus [1] machen. /dev/sdc sei die Endless-HDD und 500GB groß:

Code: Alles auswählen

dd if=/dev/sdc of=/dev/sdd bs=1M

/dev/sdd ist 1TB groß, enthält nun das Backup und ist bootfähig. Da ich nicht 500GB bzw. 1TB in meinem Backup sinnlos verbraten möchte, habe ich mit gparted die Partitionen auf /dev/sdd so weit wie sinnvoll möglich verkleinert und komme damit auf eine Gesamtgröße von knapp 40GB:

Code: Alles auswählen

# fdisk -l /dev/sdd
Disk /dev/sdd: 931,5 GiB, 1000204885504 bytes, 1953525167 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 7A108545-D817-4626-8617-D6689B367060

Device        Start      End  Sectors  Size Type
/dev/sdd1      2048   129023   126976   62M EFI System
/dev/sdd2    129024   131071     2048    1M BIOS boot
/dev/sdd3    131072 63045631 62914560   30G Linux root (x86-64)
/dev/sdd4  63045632 71434239  8388608    4G Linux swap
/dev/sdd5  71434240 77496319  6062080  2,9G Lenovo boot partition

Das Resultat ist nach wie vor bootfähig.

So weit, so gut. Nun möchte ich das aber nicht auf einem gesonderten Datenträger haben, sondern als Image. Meiner bisherigen Erfahrung mit MBR-Datenträgern zufolge, hätte das funktionieren sollen:

Code: Alles auswählen

dd if=/dev/sdd of=endless1.img bs=1G count=40

Wenn ich das Image allerdings wieder auf eine andere HDD schreibe (/dev/sde, 300GB), dann kommt das dabei heraus:

Code: Alles auswählen

# dd if=endless1.img of=/dev/sde bs=1GB
# fdisk -l /dev/sde
GPT PMBR size mismatch (1953525166 != 625142447) will be corrected by w(rite).
Disk /dev/sde: 298,1 GiB, 320072933376 bytes, 625142448 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000

Device     Boot Start        End    Sectors   Size Id Type
/dev/sde1           1 1953525166 1953525166 931,5G ee GPT

Ist das ein Image in einem Image? Das ist so natürlich nicht bootfähig.
Und tatsächlich sieht schon das Image so aus:

Code: Alles auswählen

# fdisk -l endless1.img 
GPT PMBR size mismatch (1953525166 != 83886079) will be corrected by w(rite).
Disk endless1.img: 40 GiB, 42949672960 bytes, 83886080 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000

Device        Boot Start        End    Sectors   Size Id Type
endless1.img1          1 1953525166 1953525166 931,5G ee GPT
# file endless1.img 
endless1.img: DOS/MBR boot sector, extended partition table (last)

Was ist hier schiefgegangen? Eignet sich dd generell nicht für Image-Backups von HDDs mit GPT? Meine Recherchen lieferten darauf keinen Hinweis.
Sollte ich lieber ein anderes Programm für diesen Zweck nutzen? Ich würde ein CLI-Programm bevorzugen, dessen Vorhandensein ich auf jedem Linux annehmen kann.


[1] viewtopic.php?f=12&t=169061

[smutbert]

Das hat (glaube cih) alles seine Richtigkeit.

Vermutlich weil die Datenträgergröße nicht mit der Größt laut Partitionstabelle übereinstimmt, interpretiert fdisk die GPT gar nicht erst sondern zeigt nur den Protective MBR an, also die altmodische Partitionstabelle, die mit der einen eingetragenen Partition verhindern soll, dass alte Tools, Betriebssysteme, die noch nichts von GPT verstehen, den Datenträger für unpartioniert halten.

Ich nehme an du könntest mit gdisk problemlos die GPT reparieren, damit die Göße laut GPT und die tatsächliche Größe wieder übereinstimmen – schlimmstenfalls indem du mit einer leeren GPT beginnst und die Partitionen mit denselben Start- und Endsektoren neu einträgst.

[rendegast]

Protective-MBR schützt die GPT-Tabelle vor unpassenden klassischen Partitionstools.
Der steht ja immer noch auf 1GB.

GPT arbeitet wohl auch mit einer Kopie am Ende der Platte, die durch das dd ja nicht mitgenommen wurde.
Eventuell sorgt diese Diskrepanz dann für diesen Zustand.
Es könnte auch ala smutbert einfach sein, daß der eingetragene PMBR nicht zur aktuellen Platte paßt.
Versuche es wie vorgeschlagen mit einem Schreibvorgang durch fdisk.

[debianoli]

/dev/sdd ist 1TB groß, enthält nun das Backup und ist bootfähig. Da ich nicht 500GB bzw. 1TB in meinem Backup sinnlos verbraten möchte, habe ich mit gparted die Partitionen auf /dev/sdd so weit wie sinnvoll möglich verkleinert und komme damit auf eine Gesamtgröße von knapp 40GB:

Code: Alles auswählen

# fdisk -l /dev/sdd
Disk /dev/sdd: 931,5 GiB, 1000204885504 bytes, 1953525167 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 7A108545-D817-4626-8617-D6689B367060

Device        Start      End  Sectors  Size Type
/dev/sdd1      2048   129023   126976   62M EFI System
/dev/sdd2    129024   131071     2048    1M BIOS boot
/dev/sdd3    131072 63045631 62914560   30G Linux root (x86-64)
/dev/sdd4  63045632 71434239  8388608    4G Linux swap
/dev/sdd5  71434240 77496319  6062080  2,9G Lenovo boot partition

Das Resultat ist nach wie vor bootfähig.

So weit, so gut. Nun möchte ich das aber nicht auf einem gesonderten Datenträger haben, sondern als Image. Meiner bisherigen Erfahrung mit MBR-Datenträgern zufolge, hätte das funktionieren sollen:

Code: Alles auswählen

dd if=/dev/sdd of=endless1.img bs=1G count=40

Versteh ich irgendwie nicht ganz. Du verkleinerst die Partitionen und machst per dd ein Image. Aber das wird deshalb doch nicht kleiner als die Gesamtplatte? Meines Wissens nach schreibt dd stur Block für Block ins Image, also auch die, die nicht belegt sind.

Und GPT hat doch zwei header, einen am Anfang und einem am Ende.

[owl102]

Ich nehme an du könntest mit gdisk problemlos die GPT reparieren

So würde ich auch vorgehen.

damit die Größe laut GPT und die tatsächliche Größe wieder übereinstimmen

Damit die Größen lauf GPTs wieder stimmen. Es gibt ja noch eine zweite GPT am Plattenende, die fehlt, dies muß auch noch korrigiert werden. Auch dies ist ein Fall für gdisk.

[hikaru]

Danke für die Hinweise auf gdisk!

Mit den folgenden Aktionen habe ich die HDD mit dem eingespielten Image bootfähig bekommen:

Code: Alles auswählen

x	extra functionality (experts only)
e	relocate backup data structures to the end of the disk
w	write table to disk and exit

Allerdings bin ich mir nicht sicher, ob die ersten beiden nötig waren.
Schon das letzte Kommando allein sorgt für eine sinnvoll aussehende fdisk-Ausgabe:

Code: Alles auswählen

# fdisk -l /dev/sde 
Disk /dev/sde: 298,1 GiB, 320072933376 bytes, 625142448 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 7A108545-D817-4626-8617-D6689B367060

Device        Start      End  Sectors  Size Type
/dev/sde1      2048   129023   126976   62M EFI System
/dev/sde2    129024   131071     2048    1M BIOS boot
/dev/sde3    131072 63045631 62914560   30G Linux root (x86-64)
/dev/sde4  63045632 71434239  8388608    4G Linux swap
/dev/sde5  71434240 77496319  6062080  2,9G Lenovo boot partition

Das führte in mehreren Testläufen teils, aber nicht zuverlässig zum Booten des Systems auf der HDD. Der Zielrechner hat teils trotzdem die HDD nicht als Bootmedium erkannt. Das mag eine weitere Eigensinnigkeit des UEFI auf dem Rechner sein. Ich bin mir noch nicht sicher, ob ich das Muster richtig erkenne, aber es scheint so, dass das UEFI beim ersten Start (egal ob kalt oder warm) mit der angesteckten HDD darauf keine bootfähigen Systeme erkennt.

Wie auch immer, ich habe jetzt ein Image für's Backup und weiß, wie ich ein Restore machen kann.

Versteh ich irgendwie nicht ganz. Du verkleinerst die Partitionen und machst per dd ein Image. Aber das wird deshalb doch nicht kleiner als die Gesamtplatte? Meines Wissens nach schreibt dd stur Block für Block ins Image, also auch die, die nicht belegt sind.

Und GPT hat doch zwei header, einen am Anfang und einem am Ende.

Bei MBR kann man Partitionen einfach verkleinern und dann per dd nur einen Teil des Datenträgers sichern. Das ist z.B. nützlich, wenn man später das Restore auf einem kleineren Datenträger als dem Originaldatenträger macht. Außerdem kann man sich so ohne viel Mühe das Nullen des unbelegten Platzes auf den Partitionen und das anschließende Komprimieren des Images sparen und trotzdem eine halbwegs platzsparende Imagegröße erzielen.
Den selben Ansatz wollte ich hier verfolgen. Dass bei GPT der (offenbar wichtigere) sekundäre Header am Ende des Datenträgers liegt (statt am Ende des partitionierten Bereichs)*, hatte ich dabei nicht bedacht.


*) Aus dem Stehgreif halte ich das für eine schwache Designentscheidung. Ich fände das Konstrukt deutlich robuster, wenn der sekundäre Header am Ende des partitionierten Bereichs wäre.

[NAB]

*) Aus dem Stehgreif halte ich das für eine schwache Designentscheidung. Ich fände das Konstrukt deutlich robuster, wenn der sekundäre Header am Ende des partitionierten Bereichs wäre.

Und woher weißt du, wo der partitionierte Bereich ist, wenn die vordere GPT versehentlich gelöscht wird? (es könnte auch ein Schelm auf die Idee kommen, weitere GPTs auf der Platte zu verteilen, z.B. wenn er Backups per dd zieht)

[owl102]

Dass bei GPT der (offenbar wichtigere) sekundäre Header

Wichtig ist der nicht, das ist nur ein Backup, welches genommen wird, wenn beim ersten GPT die Prüfsumme nicht stimmt.

Das Hauptproblem dürfte bei dir gewesen sein, daß der MBR nicht mehr korrekt "Protective" war, sprich die Pseudo-Partition im MBR nicht mehr die komplette Platte umspannt hat, sondern deutlich mehr als die Platte, da du das Image auf eine kleinere Platte gespielt hast.

Ein UEFI sollte das aber auch nicht durcheinanderbringen, das System hätte auch so booten müssen. (Der Protective MBR ist ja nur dazu da, damit olle Tools, die noch nie was von GPT gehört haben, nicht denken, da sei irgendwas auf der Platte zur Partitionierung frei.)

Daß sich aber fdisk so leicht aus dem Tritt bringen läßt, ist vermutlich dem Umstand geschuldet, daß es ein reines MBR-Partitionstool war und GPT-Unterstützung nachträglich suboptimal hinzugefügt worden war. (Ich würde sowieso bei GPT immer gdisk nehmen, nicht fdisk.)

[hikaru]

Und woher weißt du, wo der partitionierte Bereich ist, wenn die vordere GPT versehentlich gelöscht wird?

Guter Punkt!

Das Hauptproblem dürfte bei dir gewesen sein, daß der MBR nicht mehr korrekt "Protective" war, sprich die Pseudo-Partition im MBR nicht mehr die komplette Platte umspannt hat, sondern deutlich mehr als die Platte, da du das Image auf eine kleinere Platte gespielt hast.

Ein UEFI sollte das aber auch nicht durcheinanderbringen, das System hätte auch so booten müssen.

Dann verbuche ich das also unter "weitere Eigenart meines UEFI".