Backup UEFI GPT

[masterspoon]

Hallo
Ich wollte ein Backup meines Systems machen um im Bedarfsfall dieses wieder zurück zu schreiben.
Folgende Festplattenaufteilung habe ich.

Festplatte hat die GPT Tabelle
/dev/sda1 EFI boot
/dev/sda2 /boot
/dev/sda3 lvm mit /root /home /swap
/dev/sda4 /daten Braucht nicht berücksichtigt werden erstelle hier bei mit rsync ein Backup.

Meine Frage wäre jetzt bei einer Festplatte mit mbr musste dieser ja gesondert kopiert werden. Bsp.
dd if=/dev/sda of=/mnt/sicherung/mbr.img bs=512k count=1

Wie ist das jetzt mit GPT reicht es wen ich von den Festplattenpartitionen normale Images mache und diese dann zurückschreibe. Bsp.
dd if=/dev/sda1 bs=64k > /mnt/sicherung/sda1.img
dieses dann mit sda2 und sda3 gleichermaßen.

[smutbert]

Im Prinzip ja, aber das hängt auch davon ab wie du startest. Deiner Festplatteneinteilung entnehme ich zwar, dass dem nicht so ist, aber du könntest auch mit im Legacy-Mode (also mit der BIOS-Emulation/dem CSM des EFI) booten, das macht man üblicherweise wie gehabt mit dem MBR und zusätzlich einer eigens angelegten BIOS-Boot-Partition.

Beim Starten im EFI-Modus liegt der Bootloader dagegen in einer normalen Datei auf der EFI-Systempartition (/dev/sda1), die unter Debian standardmäßig unter /boot/efi gemountet wird. Image müsstest du dann überhaupt keines machen, es genügt iA die Dateien von /boot(/efi) zu sichern.
Es kann auch nicht schaden sich die Einträge in der Firmware für den Bootmanager anzusehen (efibootmgr -v) — die müssen unter Umständen ebenfalls wiederhersgestellt werden.

[masterspoon]

Ist es sinvoller debian im mbr betrieb laufen zulassen, bzw hat man überhaupt einen vorteil durch gpt wenn kein Windows als 2. System installiert ist?
Danke schon mahl für deine ANtwort.

[smutbert]

Zukunftsträchtiger sind sicherlich der Start im EFI-Modus und die GPT-Partitionierung, aber es heißt ja auch: "never touch a running system"

Mir gefällt GPT besser, weil man keine (kaum) Einschränkungen bei der Größe und Anzahl der Partitionen hinnehmen muss.

Übrigens kann man nicht nur mit GPT-partitionierten Datenträgern im BIOS/Legacy-Mode booten sondern auch mit MBR-partitionierten im EFI-Modus, zumindest funktioniert das mit den meisten UEFI-Implementationen. Wieder gefällt mir der EFI-Modus besser, weil man sich nicht um MBR oder PBR kümmern muss und auch die Bootreihenfolge und zT noch einiges mehr ohne BIOS/EFI-Setup anpassen kann…
…aber mir läuft auch noch ein kalter Schauer über den Rücken, wenn ich an meine ersten EFI-Bootversuche mit einem MacPro zurückdenke…

[masterspoon]

hallo smutbert
Da du ja anscheinend dan ein system mit uefi am laufen hast, reicht es einfach ein backup der Partitionen zu machen.
Für ein späterres zurückschreiben beim Festplatten crasch? von der Gesamten Festplatte kan ich kein backup mach da ich diese nocht in einer daten Patition aufgeteilt habe von der ich mir mit rsync ein backup mache.

[smutbert]

Ja und ja, aber wie genau das geht, hängt auch von der UEFI-Implementation ab. Ich mache meine Backups mit rsync oder cp (dabei darf man wie gesagt die EFI-Systempartition nicht vergessen) und die Wiederherstellung liefe auf 3 mir bekannten Rechnern etwas unterschiedlich:

• Viele EFIs laden standardmäßig oder als Fallback die Datei (/boot/efi)/EFI/boot/bootx64.efi (bzw. /EFI/boot/bootia32.efi bei einem 32bit EFI). Oft, aber nicht immer muss diese Datei dazu auf der EFI-Systempartition sein.
  Dann genügt es einmal die Datei /EFI/debian/grubx64.efi nach /EFI/boot/bootx64.efi zu kopieren. damit man auch nach einer Wiederherstellung auf eine neue Platte wieder starten kann.
  
  (das war der Mac Pro, von dem ich gesprochen habe, wobei da erschwerend das 32bit EFI auf einem 64bit Computer hinzugekommen ist)
• Andere EFIs laden diese EFI/boot/bootx64.efi lediglich von externen USB-Speichermedien oä. Für das Starten von einer internen Platte ist man also auf einen korrekten Booteintrag im EFI angewiesen. Dummerweise sind die Pfadangaben von diesen Einträgen nicht alle 100% einheitlich und können sich beim Ersetzen einer Platte ändern.
  
  Der erste Start nach der Wiederherstellung kann dann zu einer unerwarteten Herausforderung werden. Dagegen könnte man sich diese grubx64.efi auf eine EFI-Systempartition auf einem USB-Stick kopieren oder, was etwas vielseitiger ist, gleich einen kompletten grub auf eine EFI-Systempartition eines USB-Sticks installieren.
  Dann kann man zumindest immer noch über die Grub-Kommandozeile starten.
  
  (zB Asrock und Asus haben sich so verhalten)
• und dann gibt es noch ganz besonders freundlichen EFIs, die einfach von einer (offensichtlich nahezu beliebigen) .efi Datei starten.
  
  (so einfach hat es bei mir mit einem Intelmainboard funktioniert)

[masterspoon]

Meine Festplatten aufteilung siehe oben

Bei der installation von debian erstelle ich ja eine Uefi boot partition wie auch die normahle bootpartition für debian.
wenn ich mit dd dan per live boot cd ein backup inform eines image von der sda1 2 und 3 mache würde ich beim wieder herstellen ja 1 zu 1 zurück schreiben ud da ich mit debian formahls eine uefi partition angelegt habe solte doch eigentlich ales was zum starten benötigt wird vorhanden sein.

Laut anleitungen die sich allerdings auf mbr beziehen mus ich lediglich die richtigen Größen der Partitionen einhalten. Also die neue Festplatte mit den gleichen Partitions größen die auch auf der Alten wahren auf teillen.

[smutbert]

Naja, aber die Festplatte ist nach der Wiederherstellung womöglich eine andere und von der hängt manchmal oder immer der uU notwendige Booteintrag in der Firmware ab. Diese Booteinträge enthalten IDs, mit denen ich nicht allzuviel anfangen kann, aber aus eigener Erfahrung weiß ich, dass sie zumindest von der verbauten Festplatte und dem ATA-Port anhängen können.
Der automatisch von der Firmware erstellte Eintrag bei meinem Intel Mainboard

Code: Alles auswählen

Boot0001* Linux	Vendor(99e275e7-75a0-4b37-a2e6-c5385e6c00cb,)

hat wenig Ähnlichkeit mit dem von grub/efibootmgr erstellten Eintrag auf einem Asusgerät:

Code: Alles auswählen

Boot0000* debian	HD(1,800,200000,084bcf7e-7a3b-42e3-9608-5444a829a827)File(\EFI\debian\grubx64.efi)

bei Apple ist natürlich wieder alles anders und ich hege keinen Zweifel, dass sich noch etliche andere UEFI-Implementationen mit anderen Eigenheiten finden lassen. Normalerweise muss man sich damit ja nicht herumschlagen, aber wenn man eine vorhandene Installation auf eine neue Platte übersiedeln will, muss man sich eben eine zur speziellen Firmware passende Strategie überlegen.

Dafür sind die Größen und Reihenfolge der Partitionen egal, das einzige, was Grub 2 zuliebe nach der Wiederherstellung stimmen sollte, sind die UUIDs der Dateisysteme.

[masterspoon]

Dan danke für die Antwort.

Hoffe das meine Festplatte nicht so schnell den geistaufgiebt .

[smutbert]

eine kleine Ergänzung vielleicht noch:

Debians grub schreibt immer Zweizeiler in der Art von

Code: Alles auswählen

set root='(hd0,gpt2)'
search --no-floppy --fs-uuid --set=root 41986ea3-b322-4a90-bfff-5f8c64db6e7e

um auf das Dateisystem einer bestimmten Partition zuzugreifen. Mir war früher immer schleierhaft welchem Zweck das dient, denn mit der 2. Zeile alleine könnte man ja bereits eindeutig per UUID eine Partition identifizieren, dh eigentlich überschreibt die zweite Zeile die Zuweisung der ersten.

Der Sinn wird einem erst klar, wenn man etwas — zB bei einer Wiederherstellung des Systems — verpennt. Haben sich beispielsweise die UUIDs geändert, funktioniert bei der gleichen Reihenfolge der Partitionen immer noch die erste Zeile. Man erhält dann zwar von der zweiten eine Fehlermeldung, aber grub läuft problemlos weiter.
Umgekehrt genauso: Stimmen zwar die UUIDs, aber nicht mehr die Reihenfolge, erhält man zwar von der ersten Zeile möglicherweise eine Fehlermeldung, aber die zweite Zeile sorgt für die Erkennung der korrekten Partition…

Alles in allem überlebt die Grubinstallation also meistens auch einen weniger gut vorbereiteten Umzug (nur über die Eigenheiten der Firmware hilft das leider nicht hinweg).