Hier werden die Unterschiede zwischen zwei Versionen gezeigt.
Beide Seiten, vorherige Überarbeitung Vorherige Überarbeitung Nächste Überarbeitung | Vorherige Überarbeitung Nächste Überarbeitung Beide Seiten, nächste Überarbeitung | ||
admin_grundlagen:systemsicherung [2022/10/21 21:57] sh [Anpassungen bei geänderter Hardware oder geänderten Partitionen] |
admin_grundlagen:systemsicherung [2022/12/08 21:58] carsten_strotmann Suse Backup und Restore |
||
---|---|---|---|
Zeile 473: | Zeile 473: | ||
===== Anpassungen bei geänderter Hardware oder geänderten Partitionen ===== | ===== Anpassungen bei geänderter Hardware oder geänderten Partitionen ===== | ||
+ | ==== Rebuild Red Hat / Rocky / Alma 8 ==== | ||
+ | **[[Rebuild Red Hat 8|komplettes Rebuild Bootmanager UEFI+Rocky/Alma/Red Hat 8]]** | ||
+ | |||
Je nach dem wie sich die Hardware geändert hat, sind folgende Bereiche anzupassen: | Je nach dem wie sich die Hardware geändert hat, sind folgende Bereiche anzupassen: | ||
- | [[Rebuild Red Hat 8|komplettes Rebuild Bootmanager UEFI+Rocky/Alma/Red Hat 8]] | + | |
==== Format Partitionstabelle ==== | ==== Format Partitionstabelle ==== | ||
Wenn die neue Festplatte größer als 2TB ist, dann GPT als Format für die Partitionstabelle verwenden. | Wenn die neue Festplatte größer als 2TB ist, dann GPT als Format für die Partitionstabelle verwenden. | ||
Zeile 626: | Zeile 629: | ||
* [[http://www.partimage.org/Main_Page]] | * [[http://www.partimage.org/Main_Page]] | ||
+ | ====== Backup / Bare-Metal Restore Suse Linux ====== | ||
+ | |||
+ | Diese Anleitung beschreibt die Sicherung und Wiederherstellung eines Suse Linux Systems mit BTRFS Dateisystem. | ||
+ | |||
+ | Getestet wurde diese Anleitung auf einem Suse Leap 15.x im Dezember 2022 auf einem Tuxedo Laptop mit NVME Speicher. | ||
+ | |||
+ | ===== Sicherung (aka Backup) ===== | ||
+ | |||
+ | * Für die Sicherung des BTRFS benutzen wir die nur-lese (read-only) Snapshot Funktion des BTRFS zusammen mit dem ''%%btrfs send%%'' Befehl, um die Daten via SSH auf ein entferntes System zu sichern. | ||
+ | * Schritt 1: Erstellen eines Subvolumes, welches die zu sichernden Snapshots aufnimmt<code example> | ||
+ | btrfs subvol create .backup | ||
+ | </code> | ||
+ | |||
+ | * Schritt 2: von jedem Subvolume des Root-Dateisystems ein read-only Snapshot unterhalb des Backup-Subvolumes erstellen. Am Ende prüfen das auch alle Subvolumes (ggf. mit Aussnahme von ''%%/.snapshots%%'') als Read-Only Volume vorliegen:<code example> | ||
+ | btrfs subvol list / | ||
+ | btrfs subvol snap -r / .backup/root-fs | ||
+ | btrfs subvol snap -r /usr/local .backup/usr-local | ||
+ | btrfs subvol snap -r /tmp .backup/tmp | ||
+ | ... | ||
+ | ls -l /.backup | ||
+ | </code> | ||
+ | |||
+ | * Schritt 3: die Read-Only Snapshot-Volumes mittels ''%%btrfs send%%'' und über SSH (komprimiert) auf einen entfernten Rechner übertragen:<code example> | ||
+ | ls -1 -d /backup/* | xargs btrfs send | ssh -C nutzerXX@192.168.1.2XX "cat > notebookXX.btrfs" | ||
+ | </code> | ||
+ | |||
+ | * Hiermit ist die Sicherung abgeschlossen. Die Backup-Snapshots können nun wieder entfernt werden<code example> | ||
+ | btrfs subvol delete /.backup/root-fs | ||
+ | btrfs subvol delete /.backup/usr-local | ||
+ | btrfs subvol delete /.backup/srv | ||
+ | ... | ||
+ | btrfs subvol delete /.backup | ||
+ | </code> | ||
+ | |||
+ | |||
+ | ===== System-Verlust simulieren (der spassige Teil) ===== | ||
+ | |||
+ | * System "zerstören", indem das Unix-System-Root (USR) Verzeichnis gelöscht wird (am besten aus einer grafischen Sitzung heraus)<code example> | ||
+ | rm -rf /usr | ||
+ | </code> | ||
+ | |||
+ | * Reboot testen -> das System sollte nicht mehr starten | ||
+ | |||
+ | ===== Bare-Metal System-Wiederherstellung ===== | ||
+ | |||
+ | * Diese Anleitung geht davon aus, das die EFI-Bootpartition, die Swap-Partition der Boot-Record des Bootloaders (Grub2) noch intakt sind. Aufgrund der Unterstützung von bootbaren BTRFS-Snapshots (''%%snapper%%'') ist die Logik des Boot-Loaders Grub2 und die Skripte innerhalb der Init-Ramdisk ''%%initrd%%'' komplexer als bei anderen Linux Varianten (z.B. Debian). Hat die Partitions-Tabelle, der Boot-Record des Speichers oder die EFI-Partition Schaden genommen, so wird empfohlen erst mittels eines Suse-Installations-Mediums ein minimales frisches Suse-System zu installieren, und danach das BTRFS-Root-Dateisystem nach dieser Anleitung aus dem Rettungs-Linux zu ersetzen. | ||
+ | * Ist das Ziel-System mit einer anderen Speicher-Lösung als NVME ausgestattet müssen im weiteren die Üfade der Grätedatei entsprechend angepasst werden (z.B. ''%%/dev/sda3%%'' statt ''%%/dev/nvme0n1p3%%'') | ||
+ | |||
+ | ==== Rettungs-Linux starten ==== | ||
+ | |||
+ | * Mit einem Rettungs-Linux starten | ||
+ | * Tuxedo F7 beim UEFI Bootbildschirm | ||
+ | * Thinkpad F12 beim UEFI Bootbildschirm | ||
+ | * Netzwerk-Boot auswählen | ||
+ | * F4 -> Live-Linux-Systeme | ||
+ | * sysrcd starten | ||
+ | * Neues BTRFS Dateisystem erzeugen (ggf. Gerätedatei anpassen!!)<code example> | ||
+ | mkfs.btrfs -f /dev/nvme0n1p3 | ||
+ | </code> | ||
+ | |||
+ | * Neues Dateisystem unter ''%%/mnt%%'' einhängen<code example> | ||
+ | mount /dev/nvme0n1p3 /mnt | ||
+ | </code> | ||
+ | |||
+ | * Subvolume für das Zurückspielen der Backups erstellen<code example> | ||
+ | btrfs subvol create /mnt/.restore | ||
+ | </code> | ||
+ | |||
+ | * BTRFS Dateisysteme von Backup-System via SSH zurückspielen<code example> | ||
+ | ssh nutzerXX@192.168.1.2XX "cat notebookXX.btrfs" | btrfs recieve /mnt/.restore | ||
+ | </code> | ||
+ | |||
+ | * Neue schreibbare Snapshots aus dem Read-Only Snapshots erstellen. Die Namen der Subvolumes müssen nicht den original Namen entsprechen<code example> | ||
+ | btrfs subvol snap /mnt/.restore/tmp /mnt/tmp | ||
+ | btrfs subvol snap /mnt/.restore/root-fs /mnt/root-fs | ||
+ | btrfs subvol snap /mnt/.restore/usr-local /mnt/usr-local | ||
+ | ... | ||
+ | </code> | ||
+ | |||
+ | * Subvolume für automatische Snapshots erstellen (wenn dieses nicht gesichert und zurückgespielt wurde)<code example> | ||
+ | btrfs subvol create /snapshots | ||
+ | </code> | ||
+ | |||
+ | * Subvolumes auflisten, Volume-ID des neuen Root-Filesystems notieren<code example> | ||
+ | btrfs subvol list /mnt | ||
+ | </code> | ||
+ | |||
+ | * Root-Filesystem-ID als neues Default-Volume des BTRFS Dateisystems eintragen<code example> | ||
+ | btrfs subvol set-default <id> | ||
+ | </code> | ||
+ | |||
+ | * BTRFS Dateisystem ''%%/mnt%%'' aushängen<code example> | ||
+ | umount /mnt | ||
+ | </code> | ||
+ | |||
+ | * Neues BTRFS Dateisystem mit neuem (default) Root-Filesystem einhängen<code example> | ||
+ | mount /dev/nvme0n1p3 /mnt | ||
+ | </code> | ||
+ | |||
+ | * Pseudo-Dateisysteme aus dem Rettungs-System in das neue Root-Filesystem mounten (wird von der "chroot" Umgebung benötigt<code example> | ||
+ | mount --rbind /dev /mnt/dev | ||
+ | mount --rbind /sys /mnt/sys | ||
+ | mount --rbind /proc /mnt/proc | ||
+ | </code> | ||
+ | |||
+ | * In die "chroot" Umgebung wechseln<code example> | ||
+ | chroot /mnt | ||
+ | </code> | ||
+ | |||
+ | * Datei ''%%/etc/fstab%%'' anpassen | ||
+ | * UUID durch Geräte-Pfad ersetzen | ||
+ | * Namen der Snapshots anpassen (aus ''%%subvol=/@/tmp%%'' wird ''%%subvol=tmp%%'') | ||
+ | * Kurze Namen der Snapshots oder Subvol-IDs benutzen | ||
+ | * Mount testen mit ''%%mount -a%%'' | ||
+ | * Init-Ramdisk ''%%initrd%%'' neu erstellen<code example> | ||
+ | mkinitrd | ||
+ | </code> | ||
+ | |||
+ | * Bootloader Grub2 neu installieren<code example> | ||
+ | grub2-install | ||
+ | </code> | ||
+ | |||
+ | * Grub2 Konfiguration neu erstellen<code example> | ||
+ | grub2-mkconfig -o /boot/grub2/grub.cfg | ||
+ | </code> | ||
+ | |||
+ | * chroot verlassen mit ''%%exit%%'' | ||
+ | * System neu booten, Daumen drücken …<code example> | ||
+ | reboot | ||
+ | </code> | ||
+ | |||
+ | * Nach erfolgreichem Boot die Restore-Subvolumes löschen |