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

Warum Debian und/oder eine seiner Spielarten? Was muss ich vorher wissen? Wo geht es nach der Installation weiter?
Antworten
Benutzeravatar
hikaru
Moderator
Beiträge: 13559
Registriert: 09.04.2008 12:48:59

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

Beitrag von hikaru » 08.04.2018 13:36:36

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
Zuletzt geändert von hikaru am 08.04.2018 17:45:13, insgesamt 1-mal geändert.

Benutzeravatar
smutbert
Moderator
Beiträge: 8315
Registriert: 24.07.2011 13:27:39
Wohnort: Graz

Re: Image-Vollbackup von HDD mit GPT?

Beitrag von smutbert » 08.04.2018 14:00:32

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
Beiträge: 15041
Registriert: 27.02.2006 16:50:33
Lizenz eigener Beiträge: MIT Lizenz

Re: Image-Vollbackup von HDD mit GPT?

Beitrag von rendegast » 08.04.2018 14:00:45

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.
mfg rendegast
-----------------------
Viel Eifer, viel Irrtum; weniger Eifer, weniger Irrtum; kein Eifer, kein Irrtum.
(Lin Yutang "Moment in Peking")

debianoli
Beiträge: 4068
Registriert: 07.11.2007 13:58:49
Wohnort: Augschburg

Re: Image-Vollbackup von HDD mit GPT?

Beitrag von debianoli » 08.04.2018 14:05:58

hikaru hat geschrieben: ↑ zum Beitrag ↑
08.04.2018 13:36:36
/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

Re: Image-Vollbackup von HDD mit GPT?

Beitrag von owl102 » 08.04.2018 14:20:34

smutbert hat geschrieben: ↑ zum Beitrag ↑
08.04.2018 14:00:32
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.

Benutzeravatar
hikaru
Moderator
Beiträge: 13559
Registriert: 09.04.2008 12:48:59

Re: Image-Vollbackup von HDD mit GPT?

Beitrag von hikaru » 08.04.2018 17:44:58

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.

debianoli hat geschrieben: ↑ zum Beitrag ↑
08.04.2018 14:05:58
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
Beiträge: 5501
Registriert: 06.03.2011 16:02:23
Lizenz eigener Beiträge: MIT Lizenz

Re: Image-Vollbackup von HDD mit GPT?

Beitrag von NAB » 08.04.2018 18:27:34

hikaru hat geschrieben: ↑ zum Beitrag ↑
08.04.2018 17:44:58
*) 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)
Never change a broken system. It could be worse afterwards.

"No computer system can be absolutely secure." Intel Document Number: 336983-001

owl102

Re: Image-Vollbackup von HDD mit GPT?

Beitrag von owl102 » 08.04.2018 19:08:27

hikaru hat geschrieben: ↑ zum Beitrag ↑
08.04.2018 17:44:58
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.)
Zuletzt geändert von owl102 am 09.04.2018 09:20:04, insgesamt 1-mal geändert.

Benutzeravatar
hikaru
Moderator
Beiträge: 13559
Registriert: 09.04.2008 12:48:59

Re: Image-Vollbackup von HDD mit GPT?

Beitrag von hikaru » 09.04.2018 09:01:16

NAB hat geschrieben: ↑ zum Beitrag ↑
08.04.2018 18:27:34
Und woher weißt du, wo der partitionierte Bereich ist, wenn die vordere GPT versehentlich gelöscht wird?
Guter Punkt! ;)
owl102 hat geschrieben: ↑ zum Beitrag ↑
08.04.2018 19:08:27
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". :?

Antworten