Linuxhotel Wiki

Wie ging das nochmal?

Benutzer-Werkzeuge

Webseiten-Werkzeuge


lpi1:systemsicherung

Komplettsicherung des Systems

Zuverlässiger ( z.B. offene Dateien ) und möglicherweise einfacher ( z.B. udev ) ist es aus einem Rettungssystem heraus zu sichern. Die folgende Anleitung zeigt dagegen wie man aus einem laufenden System heraus sichert. Hürden wie eine nach /dev gemountete Ramdisk für udev werden dabei gemeistert. Dienste wie Mailserver oder Datenbanken ( offene Dateien ) sollten vorher angehalten werden.

Abschätzen, wie viel Platz benötigt wird:

df -Thlx tmpfs -x devtmpfs

→ Summe der Daten auf persistenten, lokalen Dateisystemen

Vorbereitung Zielsystem

evtl. Platz schaffen wie in Plattenplatz, Partitionierung und lvm beschrieben

mkdir -p /mnt/backup/dateien

Ubuntu

Zielverzeichnis /mnt/backup muss dem Ubuntu-Nutzer gehören:

chown nutzerXX /mnt/backup

Debian (ab 8)

Entweder

  • sudo einrichten und wie unter Ubuntu beschrieben vorgehen.
  • einen ssh-Schlüssel beim Benutzer root hinterlegen

oder

  • root das Anmelden mit Passwort erlauben 1)

Sicherung

Diese Schritte werden auf dem zu sichernden System ausgeführt.

Sicherung der UEFI-Einstellungen

Bei UEFI-Systemen ist es manchmal hilfreich die EFI Variablen zu sichern:

efibootmgr -v > sicherung.efivars

Sicherung der Partitionierung

Partitionstabelle im Textformat sichern:

sfdisk -d /dev/sda > sicherung.sfdisk

2) 3)

Sicherung LVM Informationen

vgcfgbackup -f sicherung.vg
pvdisplay > sicherung.pvdisplay
vgdisplay > sicherung.vgdisplay
lvdisplay > sicherung.lvdisplay

Sicherung anderer Storage Informationen

Sicherung der Dateisystem-Einstellungen

Von welchen Dateisystemen müssen Einstellungen gesichert werden?

lsblk -f

oder

df -Thlx tmpfs -x devtmpfs

→ alle persistenten, lokalen Dateisysteme müssen gesichert werden

ext2 / ext3 / ext4
tune2fs -l /dev/sdaX > sicherung.ext.sdaX

4)

xfs
xfs_admin -l -u /dev/sdaX  > sicherung.xfs.sdaX
xfs_info /dev/sdaX  >> sicherung.xfs.sdaX

5)

btrfs

btrfs läßt sich nicht einfach mit rsync oder tar sichern. Die beste Alternative ist, statt dessen ein Image des Dateisystems mit fsarchiver oder partclone zu erstellen. 6)

vfat
blkid /dev/sdaX > sicherung.vfat.sdaX

7)

swap
blkid /dev/sdaX > sicherung.swap.sdaX

8)

Einstellungs-Dateien auf Zielsystem kopieren

Ubuntu:

scp sicherung.* nutzer@server:/mnt/backup

andere Distributionen (bei denen root ein Passwort hat):

scp sicherung.* root@server:/mnt/backup

Sicherung der Dateien

Einhängen der Dateisysteme unter /mnt/system

mkdir /mnt/system
mount --bind / /mnt/system

In der Ausgabe von df -hT -x tmpfs -x devtmpfs die Mountpoints aller weiteren persistenten, lokalen Dateisysteme (mit Ausnahme von loop-Devices) identifizieren und unterhalb von /mnt/system bind-mounten:

mount --bind /boot /mnt/system/boot

und/oder

mount --bind /boot/efi /mnt/system/boot/efi

und möglicherweise weitere:

mount --bind ...

9)

mit rsync über ssh Dateien kopieren

Auf Quell- und Zielsystem muss rsync installiert sein. Alternativ kann man auch tar über ssh verwenden.

Debian (ab 8)

Wie oben unter „Vorbereitung Zielsystem“ beschrieben kann man entweder so vorgehen

oder

  • wie bei Ubuntu
Ubuntu

Unter Ubuntu gibt es defaultmäßig kein root Passwort. Wenn ein Ubuntu System das ZIEL ist, muss man zunächst dem User, mit dem man sich auf dem Ziel einloggen will, einen Eintrag machen, der rsync via sudo ohne Passwort erlaubt:

sudo visudo -f /etc/sudoers.d/backup

und diese Zeile ergänzen:

/etc/sudoers.d/backup
%sudo  ALL=(ALL) NOPASSWD: ALL

10)

Der Benutzer muss in der Gruppe sudo sein

Und dann lautet der Befehl zum Backup:

rsync -aSH --xattrs --acls --numeric-ids --del --rsync-path="sudo rsync" /mnt/system/ user@zielsystem:/mnt/backup/dateien
SuSE / BTRFS

Btrfs snapshot subvolumes können nicht sinnvoll mit rsync oder tar gesichert und wieder hergestellt werden, da die Deduplizierung von Btrfs dabei nicht mehr genutzt wird und die Dateien mehrfach im Backup landen würden.

andere Distributionen (bei denen root ein Passwort hat)
rsync -aSH --acls --xattrs --numeric-ids --del /mnt/system/ root@server:/mnt/backup/dateien

11) 12) 13)

Plausibilitätsprüfung

Die wichtigsten Fragen sind:

  • sind alle Dateien angekommen? → Dateien auf Original und Backup zählen
  • sind die Berechtigungen korrekt? → Eigentümer/Berechtigungen auf Original und Backup vergleichen, dabei die Unterschiede in den Benutzer IDs auf Original- und Backupsystem beachten
  • Sind die Dateien vollständig angekommen?
Sind alle Dateien angekommen?
  • einfach mal mit ls stichprobenartig nachschauen
  • mit Hilfe von find und wc Dateien zählen
Sind die Berechtigungen korrekt?
  • einfach mal mit ls -l stichprobenartig nachschauen
Sind die Dateien vollständig angekommen?

Einfache Lösung:

  • den selben rsync-Aufruf noch mal ergänzt durch die Schalter -nv
  • Größenvergleich mit du -sh → Achtung: die Größen sind nie exakt gleich, die Größenordnung pro Dateisystem sollte passen.

Optionale, genauere Prüfung für Freude der Unix-Kommandozeile

ACLs und erweiterte Attribute

Löschen des Systems

14)

schnell

wipefs -af /dev/sda

Oder bei SSDs:

blkdiscard --force /dev/sda

15)

sicher

dd if=/dev/zero of=/dev/sda

… und nach ein paar Sekunden ist das System zumindest unbrauchbar. Oder bei SSDs:

blkdiscard -s /dev/sda

paranoid

dd if=/dev/urandom of=/dev/sda

… und laaaange warten

Gefahr der Beschädigung der Hardware

Bis Kernel 4.5 ist es möglich, dass durch das Löschen der Dateien unter /sys/firmware/efi/efivars die UEFI-Firmware beschädigt wird und der Rechner nicht mehr booten kann.

Daher vorsichtig sein mit

rm -rf /…

Mehr dazu bei heise und im entsprechenden Kernel-Patch

Wiederherstellung des Systems

Rettungssystem booten (im Linuxhotel-Netz: PXE-Boot und debian11live eingeben)

Schritte im Rettungs-System

Wiederherstellung der Partitionierung

Partitionstabelle wiederherstellen:

sfdisk /dev/sda < sicherung.sfdisk

16)

Wiederherstellung LVM

In Knoppix muss dazu zuerst lvm2 gestartet werden:

service lvm2 start

mit vgcfgrestore

IDs der Physical Volumes herausfinden:

less sicherung.vg

Physical Volumes anlegen:

pvcreate -ff --zero y --restorefile ~/sicherung.vg --uuid xxxxxx-xxxx-xxxx-xxxx-xxxx-xxxx-xxxxxx /dev/sdaX
...

Name der Volume Group herausfinden:

less sicherung.vg

Volume Group und Logical Volumes wiederherstellen:

vgcfgrestore -f ~/sicherung.vg centos_notebook17
vgchange -a y

von Hand

LVM anhand der Informationen aus der gesicherten Datei sicherung.pvdisplay, sicherung.vgdisplay, sicherung.lvdisplay und/oder gemäß etc/fstab aus dem Backup wie in lvm beschrieben anlegen.

Dateisysteme anlegen

Dateisysteme mit mkfs.* gemäß etc/fstab aus dem Backup anlegen. Dabei wenn nötig die Dateisystem-Einstellungen aus der Sicherung berücksichtigen (UUID, …) 17)

ext4

mkfs.ext4 -U xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx /dev/sdaX

18)

xfs

mkfs.xfs -m uuid=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx /dev/sdaX

19)

fat

mkfs.vfat -i xxxxxxxx /dev/sdaX

20)

Swap anlegen

21)

mkswap -U xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx /dev/sdaX

Mounten der Zielpartitionen

In /mnt/backup/dateien/etc/fstab aufgeführte Mountpoints mit mkdir anlegen und Dateisysteme mit mount einhängen: 22) 23)

mkdir /tmp/system
mount /dev/sdaX /tmp/system
mkdir /tmp/system/boot
mount /dev/sdaY /tmp/system/boot

und/oder

mkdir /tmp/system/boot/efi
mount /dev/sdaZ /tmp/system/boot/efi

und möglicherweise weitere:

mkdir /tmp/system/…
mount …

Wiederherstellen der Dateien mit rsync über ssh

rsync -aSH --acls --xattrs --numeric-ids --del root@server:/mnt/backup/dateien/ /tmp/system 

24) 25)

Ubuntu

rsync -aSH --acls --xattrs  --numeric-ids --del --rsync-path="sudo rsync" user@server:/mnt/backup/dateien/ /tmp/system 

ACLs und erweiterte Attribute

Bootfähig machen

chroot vorbereiten

mount --rbind /dev  /tmp/system/dev
mount --rbind /proc /tmp/system/proc
mount --rbind /sys  /tmp/system/sys
mount --rbind /run  /tmp/system/run

26) 27) 28)

UEFI

(nur bei UEFI-Systemen)

efivars schreibbar machen

mount -o rw,remount /tmp/system/sys/firmware/efi/efivars

oder (falls /tmp/system/sys/firmware/efi/efivars kein mountpoint ist)

mount -t efivarfs efivarfs /tmp/system/sys/firmware/efi/efivars

Schritte im chroot Zielsystem

chroot /tmp/system /bin/bash

grub-efi bzw. efivars wiederherstellen

Debian:

grub-install dummy

SuSE (ab 15.4):

grub-install
shim-install

CentOS / Rocky (ab 8):

grub-install funktioniert nicht, also müssen die EFI-Einträge manuell gesetzt werden

efibootmgr -v

→ alle alten Einträge löschen:

efibootmgr -B -b 000f

29)

EFI ESP Partition merken

grub2-probe -t device /boot/efi/EFI/

EFI-Eintrag anlegen

efi_label='Name der Distribution' # z.B. ''CentOS Linux'' oder ''Rocky Linux''
distro='DISTRIBUTION' # ''centos'' oder ''rocky''
boot_device='/dev/sda' # ''/dev/sda'' oder ''/dev/nvme0n1''
esp_partition_id=2
efibootmgr --create --disk "$boot_device" --part "$esp_partition_id" --label "$efi_label" --loader "/EFI/$distro/shimx64.efi"

grub-config neu erzeugen

grub2-mkconfig -o /boot/grub2/grub.cfg

oder

grub2-mkconfig -o /boot/efi/EFI/$distro/grub.cfg

Ab RHEL/CentOS/Rocky 8 werden zusätzlich Einträge für BLS (/boot/loader/entries/) benötigt, da grub.cfg keinen direkten Eintrag für Kernel und initrd enthält:

dnf -y reinstall kernel-core

oder mit grubby von Hand:

source /etc/default/grub
grubby --add-kernel=/boot/vmlinuz-5.14.0-284.30.1.el9_2.x86_64 --args="$GRUB_CMDLINE_LINUX" --initrd=/boot/initramfs-5.14.0-284.30.1.el9_2.x86_64.img --title="Rocky Linux"

30)

EFI Variablen prüfen

blkid
efibootmgr -v
  • Partition unique GUID: muss zur ESP Partition passen
  • The path of the EFI image to boot must use \ (backslash) instead of / (forward slash) as path separator.

BIOS: Bootloader in mbr schreiben

(nur bei BIOS-Systemen)

Schritte im chroot Zielsystem

chroot /tmp/system /bin/bash

grub2 wiederherstellen

Debian (ab 6.0), Ubuntu (ab 16.04)
grub-install /dev/sda
update-grub2
openSuSE 12.2
grub2-install /dev/sda
update-bootloader --refresh
CentOS (ab 7)
grub2-install /dev/sda
grub2-mkconfig > /boot/grub2/grub.cfg
andere
grub2-install /dev/sda
grub-mkconfig > /boot/grub/grub.cfg

grub1 / grub legacy wiederherstellen

Grub in den MBR schreiben:

grub
> root (hd0,0)
> setup (hd0)
> quit

oder mit

grub-install --recheck --no-floppy hd0

reboot

chroot-Umgebung (z.B. mit Strg+d) verlassen und

reboot

Anpassungen bei geänderter Hardware oder geänderten Partitionen

Ubuntu (22.04 LTS)

  • TODO: Nach Backup/Restore ist snap kaputt

Rebuild Red Hat / Rocky / Alma 8

komplettes Rebuild Bootmanager UEFI+Rocky/Alma/Red Hat 8

Je nach dem wie sich die Hardware geändert hat, sind folgende Bereiche anzupassen:

Format Partitionstabelle

Wenn die neue Festplatte größer als 2TB ist, dann GPT als Format für die Partitionstabelle verwenden.

Wenn Linux von der Festplatte auch booten soll, dann braucht Grub vor der ersten Partition etwas Platz. Die erste Partition sollte daher - wie heute üblich - bei Block 2048 (= 1MiB ≈ 1,05MB) starten. Alternativ kann man diesen unpartitionierten Bereich mit einer BIOS Boot Partition z.B. von Block 34 bis Block 2047 vor Veränderungen schützen.

31) 32)

/boot auf separater Partition

Bei Debian mit UEFI anpassen: /boot/efi/EFI/debian/grub.cfg

Bootloader grub

/boot/grub/menu.lst :

Neue Partitionsnummern beachten, wichtig sind z.B.

  • die Einstellungen zur Boot-Partition ( root ) in Grub-Terminologie
  • die Lage des Kernels ( /boot/vmlinuz* oder /vmlinuz* )
  • Kernel-Parameter zum root-Dateisystem ( root= … )

Bootloader grub2

/boot/grub/grub.cfg : (sollte automatisch über update-grub2 erstellt werden)

Neue Partitionsnummern beachten, wichtig sind z.B.

  • die Einstellungen zur Boot-Partition ( root ) in Grub-Terminologie
  • die Lage des Kernels ( /boot/vmlinuz* oder /vmlinuz* )
  • Kernel-Parameter zum root-Dateisystem ( root= … )

BIOS -> UEFI

Um ein (ehemaliges) BIOS System auf einer UEFI Hardware wieder herzustellen braucht man

  • Partitionstabelle mit gpt (siehe oben)
  • eine FAT32 Partition für /boot/efi, für den Linux Bootloader Grub allein reicht eine Größe von wenigen MByte. Wenn auch der Linux Kernel und/oder Windows auch drauf soll deutlich größer (500MB?).
  • GRUB2:
    • Debian: die Pakete grub-efi, grub-efi-amd64-bin und efibootmgr installieren. Dann grub-install + update-grub ausführen.
    • Ubuntu: wie bei Debian, zusätzlich optional noch shim bzw. shim-signed
    • CentOS: Pakete grub2-efi, grub2-efi-x64-modules und efibootmgr installieren. Dann grub-install + update-grub
    • SuSE: grub2-x86_64-efi und efibootmgr installieren. Dann grub-install + update-bootloader ausführen.

/etc/fstab

/etc/fstab : Neue Partitionsnummern, Software-RAID und Logical Volumes beachten

/etc/mtab

/etc/mtab : Neue Partitionsnummern, Software-RAID und Logical Volumes beachten 33)

Kernel-Module und initrd

Je nach Änderung muß eine neue initrd erzeugt werden und/oder die bei Booten geladenen Module müssen überarbeitet werden

dracut (CentOS 8)

in der chroot-Umgebung

dracut --hostonly --persistent-policy 'by-uuid' --force /boot/initramfs-4.18.0-80.11.2.el8_0.x86_64.img 4.18.0-80.11.2.el8_0.x86_64

dracut (CentOS 7 / openSuSE 42.1)

in der chroot-Umgebung

/etc/dracut.conf.d/10-xfs.conf
add_drivers+=" xfs "
dracut --force /boot/initrd-4.4.87-18.29-default 4.4.87-18.29-default

CentOS 6

in der chroot-Umgebung

mkinitrd --force /boot/initramfs-2.6.32-220.el6.x86_64.img 2.6.32-220.el6.x86_64

udev

Gerätenamen in /etc/udev/rules.d anpassen

Alternative Sicherungswege

tar über ssh

Sicherung

tar cz --numeric-owner --sparse --xattrs --acls --directory /mnt/system . | ssh nutzer@server "cat > /mnt/backup/sicherung.tgz"

Wiederherstellen

ssh nutzer@server 'cat /mnt/backup/sicherung.tgz' | tar xz --numeric-owner --sparse --xattrs --acls --xattrs-include='*' --directory /tmp/system

Dokumentation

cpio über ssh

Sicherung

34)

cd /mnt/system
find -xdev -depth -print0 | cpio -o0 --sparse --format=crc | bzip2 | ssh nutzer@server 'cat > /mnt/backup/sicherung.cpio.bz2'

Wiederherstellen

cd /tmp/system
ssh nutzer@server 'cat /mnt/backup/sicherung.cpio.bz2' | bunzip2 | cpio -dumin --sparse 

rsync

Auf lokale Platte:

rsync -a --hard-links --sparse --acls --xattrs --numeric-ids --del / /mnt/usbdisk/root/ 

Übers Netz via ssh:

rsync -a --hard-links --sparse --acls --xattrs --numeric-ids --del / server:/mnt/backup/dateien

Übers Netz via rsyncd: 35)

rsync -a --hard-links --sparse --acls --xattrs --numeric-ids --del / server::/backup/dateien/

Installation mit

apt-get install rsnapshot

Konfiguration unter:

/etc/rsnapshot.conf

Dabei wichtig:

snapshot_root                          -  wohin soll gesichert werden
interval daily 7                       -  Wieviele Versionen vom täglichen Backup sollen behalten werden?
interval weekly 4                      -  Wieviele Versionen vom wöchentlichen Backup sollen behalten werden?
interval monthly 6                     -  Wieviele Versionen vom monatlichen Backup sollen behalten werden?
backup    /quelle     zielrechner/     -  Zb localhost/ oder im Zusammenhang mit SSH gebrauchen

Testen der Config

rsnapshot configtest

Danach kann man das Ganze erst einmal im Probedurchlauf testen ohne wirklich Dateien zu schreiben:

rsnapshot -t daily

Problem: udev

Seit Kernel 2.6 und der Einführung von udev haben Linux Distributionen das Verzeichnis /dev von einem temporären Dateisystem überdeckt. Linux benötigt diese überdeckten Dateien aber beim Booten. Neuere Distributionen (RHEL / CentOS 6, …) tun das nicht mehr.

Lösungswege:

  1. Beim Backup das Verzeichnis /dev explizit angeben. Die wichtigsten Gerätedateien sollten auch darin enthalten sein.
  2. Auf das Orginalsystem kann man mit mkdir /tmp/system && mount –bind / /tmp/system zugreifen. Die Sicherung muss man dann mit tar czpf /dev/st0 –numeric-owner –directory /tmp/system . starten.

FRAGE: das müsste doch durch die bind-mounts nach /mnt/system gelöst sein, oder?!

Antwort: richtig

Dokumentation

Software

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
    btrfs subvol create .backup
  • 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:
    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
  • Subvolumes welche gesichert werden:
       /
       /home
       /opt
       /srv
       /var
       /root
       /usr/local
       /tmp
       /boot/grub2/x86_64-efi
       /boot/grub2/i386-pc
  • Schritt 3: die Read-Only Snapshot-Volumes mittels btrfs send und über SSH (komprimiert) auf einen entfernten Rechner übertragen. Das Dateisystem auf dem Zielsystem muss genügend freien Speicher aufweisen um das Backup aufzunehmen. Der erste Parameter für den „ls“ Befehl ist ein Eins „1“, kein „l“ (kleines Ell)!
ls -1 -d /.backup/* | xargs btrfs send  | ssh -C nutzerXX@192.168.1.2XX "cat > notebookXX.btrfs"
  • Hiermit ist die Sicherung abgeschlossen. Die Backup-Snapshots können nun wieder entfernt werden
    btrfs subvol delete /.backup/root-fs
    btrfs subvol delete /.backup/usr-local
    btrfs subvol delete /.backup/srv
    ...
    btrfs subvol delete /.backup

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)
    rm -rf /usr
  • 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!!)
    mkfs.btrfs -f /dev/nvme0n1p3
  • Neues Dateisystem unter /mnt einhängen
    mount /dev/nvme0n1p3 /mnt
  • Subvolume für das Zurückspielen der Backups erstellen
    btrfs subvol create /mnt/.restore
  • BTRFS Dateisysteme von Backup-System via SSH zurückspielen
    ssh nutzerXX@192.168.1.2XX "cat notebookXX.btrfs" | btrfs receive /mnt/.restore
  • Neue schreibbare Snapshots aus dem Read-Only Snapshots erstellen. Die Namen der Subvolumes müssen nicht den original Namen entsprechen
    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
    ...
  • Subvolume für automatische Snapshots erstellen (wenn dieses nicht gesichert und zurückgespielt wurde)
    btrfs subvol create /mnt/snapshots
  • Subvolumes auflisten, Volume-ID des neuen Root-Filesystems notieren
    btrfs subvol list /mnt
  • Root-Filesystem-ID als neues Default-Volume des BTRFS Dateisystems eintragen
    btrfs subvol set-default <id> /mnt
  • BTRFS Dateisystem /mnt aushängen
    umount /mnt
  • Neues BTRFS Dateisystem mit neuem (default) Root-Filesystem einhängen
    mount /dev/nvme0n1p3 /mnt
  • Pseudo-Dateisysteme aus dem Rettungs-System in das neue Root-Filesystem mounten (wird von der „chroot“ Umgebung benötigt
    mount --rbind /dev /mnt/dev
    mount --rbind /sys /mnt/sys
    mount --rbind /proc /mnt/proc
  • In die „chroot“ Umgebung wechseln
    chroot /mnt
  • 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
  • Beispiel Datei /etc/fstab nach Wiederherstellung
    /dev/nvme0n1p3  /                        btrfs  defaults                          0  0
    /dev/nvme0n1p3  /.snapshots              btrfs  subid=279               0  0
    /dev/nvme0n1p3  /var                     btrfs  subvol=var                     0  0
    /dev/nvme0n1p3  /usr/local               btrfs  subvol=usr-local               0  0
    /dev/nvme0n1p3  /tmp                     btrfs  subvol=tmp                     0  0
    /dev/nvme0n1p3  /srv                     btrfs  subvol=srv                     0  0
    /dev/nvme0n1p3  /root                    btrfs  subvol=root                    0  0
    /dev/nvme0n1p3  /opt                     btrfs  subvol=opt                     0  0
    /dev/nvme0n1p3  /home                    btrfs  subvol=home                    0  0
    /dev/nvme0n1p3  /boot/grub2/x86_64-efi   btrfs  subvol=x86_64-efi   0  0
    /dev/nvme0n1p3  /boot/grub2/i386-pc      btrfs  subvol=i386-pc      0  0
     
    /dev/nvme0n1p1  /boot/efi       vfat    rw      0       2
    /dev/nvme0n1p2  none    swap    sw      0       0
  • Init-Ramdisk initrd neu erstellen
    mkinitrd
  • Bootloader Grub2 neu installieren
    grub2-install
  • Grub2 Konfiguration neu erstellen
    grub2-mkconfig -o /boot/grub2/grub.cfg
  • chroot verlassen mit exit
  • System neu booten, Daumen drücken …
    reboot
  • Nach erfolgreichem Boot die Restore-Subvolumes löschen
1)
/etc/ssh/sshd_config
PermitRootLogin yes
2)
bei GPT-Partitionstabellen eine inzwischen veraltete Warnung der Entwickler vorweg: As of March 2014 (version 0.8.10), sgdisk should be considered beta software.
3)
Lesbarer, aber nicht automatisch wiederherstellbar geht das auch so:
fdisk -l -o device,size,type,uuid /dev/sda > sicherung.fdisk
oder
parted /dev/sda print > sicherung.parted
Mehr zur Vorgehensweise siehe Partitionierung.
4) , 5) , 7) , 8) , 17) , 21)
/dev/sdaX ist hier nur ein Beispiel für ein Speichergerät ( Partition, LVM, …). Liegt das Dateisystem auf einem Logical Volume, dann heißt das Device /dev/mapper/xxx oder ähnlich
6)
Vielleicht ist auch https://github.com/mwilck/btrfs-clone eine brauchbare Alternative
9)
ab RedHat 6, openSuSE 13.1, Debian 8 und Ubuntu 16.04 könnte man auf diesen Schritt verzichten, und statt dessen bei rsync die Option -x bzw. –one-file-system nutzen und die entsprechenden Mountpoints einzeln angeben
10)
oder
/etc/sudoers.d/backup
%sudo  ALL=(ALL) NOPASSWD: /usr/bin/rsync
11)
mehr zu rsync, u.a. wie man hier rsync auch ohne root-Rechte benutzen kann
12)
mehr zu ssh
13)
wenn man ein Art Fortschrittsbalken haben will: progress installieren und progress -wm ausführen während rsync läuft.
14)
Und wie geht es weiter, wenn die Festplatte gelöscht ist? Wie kann ich dann noch rebooten?
echo 1 > /proc/sys/kernel/sysrq
echo b > /proc/sysrq-trigger
Siehe sysctl
15)
Das System lebt jetzt mit den Daten aus dem Cache etwas weiter. Cache löschen:
echo 1 > /proc/sys/vm/drop_caches
16)
Alternativ: Partitionierung manuell anhand der Informationen aus der gesicherten Datei sicherung.parted und/oder gemäß etc/fstab aus dem Backup wie in Partitionierung beschrieben anlegen Typ der Partitionstabelle (gpt oder msdos) beachten.
18) , 19)
xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx steht hier für die UUID aus der Sicherung
20)
Eine UUID die von blkid im Format UUID="066B-5CE0" ausgegeben wurde muss mkfs.vfat mit 066B5CE0 (also ohne Minus) übergeben werden
22)
evtl. mount-optionen ( z.B. acl ) beachten
23)
/dev/sdaX ist hier nur ein Beispiel für ein Speichergerät ( Partition, LVM, …). Liegt das Dateisystem auf einem Logical Volume, dann heißt das root-Device /dev/mapper/xxx oder ähnlich
24)
mehr siehe rsync
25)
Notlösung: Berechtigungen (teilweise) wiederherstellen, wenn sie nicht richtig gesichert wurden
rpm -qa | xargs rpm --setperms
Todo: debian?
26)
/run ist sinnvoll bei der Verwendung von lvm oder raid
27)
nicht alle diese Befehle sind in allen Fällen notwendig! grub braucht hauptsächlich /dev, und das ist, wenn man zuvor beim Sichern mit mount –bind gearbeitet hat, schon minimal befüllt. Kann man also weglassen, aber wenn grub meckert, sollte man das versuchen!
28)
=== Alternativ mit bind statt rbind ===
mount --bind /dev /tmp/system/dev
mount --bind /dev/pts /tmp/system/dev/pts
mount --bind /proc /tmp/system/proc
mount --bind /sys /tmp/system/sys
mount --bind /run /tmp/system/run
29)
000f ist hier nur ein Beispiel für einen veralteten Eintrag
30)
Nachfolgend die Befehle, die notwendig sind, ein reines EFI-System wiederherzustellen oder wenn alle EFI-Informationen verloren sind === EFI Variablen schreiben === Die folgenden Shell-Variablen gemäß Ausgabe von
ls /boot/efi/EFI/
und der Datei sicherung.efivars setzen:
efi_label='Name der Distribution'
distro='DISTRIBUTION'
boot_device='/dev/sda'
esp_partition_id=2
efibootmgr --create --disk "$boot_device" --part "$esp_partition_id" --label 'UEFI OS' --loader '\EFI\BOOT\BOOTX64.EFI'
efibootmgr --create --disk "$boot_device" --part "$esp_partition_id" --label "$efi_label" --loader "\\EFI\\$distro\\SHIMX64.EFI"
=== Grub2 konfigurieren === In CentOS 8 BLSCFG abschalten:
/etc/default/grub
…
GRUB_ENABLE_BLSCFG=false
…
TODO: Lösung mit BLSCFG finden == CentOS ==
grub2-mkconfig -o /boot/efi/EFI/$distro/grub.cfg
== Debian, Ubuntu ==
dpkg-reconfigure grub-efi-amd64
oder
update-grub2
31)
aus dem archlinux-Wiki: Keep in mind that if your Boot-Manager is GRUB, it needs a BIOS Boot Partition. If your MBR Partitioning Layout isn't too old, there is a good chance that the first partition starts at sector 2048 for alignment reasons. That means at the beginning will be 1007 KiB of empty space where this bios-boot partition can be created. To do this, first do the mbr→gpt conversion with gdisk as described above. Afterwards, create a new partition with gdisk and manually specify its position to be sectors 34 - 2047, and set the EF02 partition type.
32)
aus der GRUB Doku: When creating a BIOS Boot Partition on a GPT system, you should make sure that it is at least 31 KiB in size. (GPT-formatted disks are not usually particularly small, so we recommend that you make it larger than the bare minimum, such as 1 MiB, to allow plenty of room for growth.) You must also make sure that it has the proper partition type. Using GNU Parted, you can set this using a command such as the following:
parted /dev/disk set partition-number bios_grub on
If you are using gdisk, set the partition type to ‘0xEF02’. With partitioning programs that require setting the GUID directly, it should be ‘21686148-6449-6e6f-744e656564454649’.
33)
möglicherweise kann man /etc/mtab auch einfach löschen
34)
Vermeidet die Probleme von tar und gzip bei Datenfehlern
35)
erfordert laufenden rsyncd auf dem Zielsystem server
lpi1/systemsicherung.txt · Zuletzt geändert: 2024/02/23 17:11 (Externe Bearbeitung)