Linuxhotel Wiki

Wie ging das nochmal?

Benutzer-Werkzeuge

Webseiten-Werkzeuge


admin_grundlagen:systemsicherung

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen gezeigt.

Link zu der Vergleichsansicht

Beide Seiten, vorherige Überarbeitung Vorherige Überarbeitung
Nächste Überarbeitung
Vorherige Überarbeitung
admin_grundlagen:systemsicherung [2012/09/20 14:30]
ingo_wichmann [Problem: udev]
admin_grundlagen:systemsicherung [2024/02/23 17:11] (aktuell)
ingo_wichmann [UEFI]
Zeile 3: Zeile 3:
  
 Abschätzen,​ wie viel Platz benötigt wird: Abschätzen,​ wie viel Platz benötigt wird:
-  df -h+  df -Thlx tmpfs -x devtmpfs 
 +-> Summe der Daten auf persistenten,​ lokalen Dateisystemen
  
 ===== Vorbereitung Zielsystem ===== ===== Vorbereitung Zielsystem =====
Zeile 10: Zeile 11:
   mkdir -p /​mnt/​backup/​dateien   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 ((
 +<file txt /​etc/​ssh/​sshd_config>​
 +PermitRootLogin yes
 +</​file>​
 +))
 ===== Sicherung ===== ===== Sicherung =====
 Diese Schritte werden auf dem zu sichernden System ausgeführt. ​ 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 ==== ==== Sicherung der Partitionierung ====
-Mehr zur Vorgehensweise siehe [[partitionierung]]Wenn die Wiederherstellung nicht automatisiert erfolgen mussreicht ​auch die Ausgabe von ''​parted'' ​oder ''​df''​+Partitionstabelle im Textformat sichern: 
 +  sfdisk -d /dev/sda > sicherung.sfdisk 
 + 
 +((bei GPT-Partitionstabellen eine inzwischen veraltete Warnung der Entwickler vorweg: //As of March 2014 (version 0.8.10)sgdisk should be considered beta software.// )) (( 
 +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   parted /dev/sda print > sicherung.parted
-  scp sicherung.parted root@server:/​mnt/​backup 
-(( 
-alternativ 
  
-  sfdisk -d /dev/sda > sicherung.sfdisk +Mehr zur Vorgehensweise siehe [[Partitionierung]]. )) 
-  scp sicherung.sfdisk root@server:/​mnt/​backup +
-))+
 ==== Sicherung LVM Informationen ==== ==== Sicherung LVM Informationen ====
 +  vgcfgbackup -f sicherung.vg
   pvdisplay > sicherung.pvdisplay   pvdisplay > sicherung.pvdisplay
   vgdisplay > sicherung.vgdisplay   vgdisplay > sicherung.vgdisplay
   lvdisplay > sicherung.lvdisplay   lvdisplay > sicherung.lvdisplay
-  scp sicherung.pvdisplay sicherung.vgdisplay sicherung.lvdisplay root@server:/​mnt/​backup 
  
-alternativ mit  +==== Sicherung anderer Storage Informationen ==== 
-  ​vgcfgbackup -f sicherung.vg+  ​* [[admin_grundlagen:​raid|Software RAID]] 
 +  * drbd 
 +  * [[lpi2:​iscsi|iSCSI]] 
 +  * ...
  
 ==== Sicherung der Dateisystem-Einstellungen ==== ==== Sicherung der Dateisystem-Einstellungen ====
-=== ext3 / ext4 === +=== Von welchen Dateisystemen müssen Einstellungen gesichert werden? === 
-  tune2fs -l /dev/sdaX > sicherung.tune2fs.sdaX +  lsblk -f 
-  scp sicherung.tune2fs.sdaX root@server:/​mnt/​backup+oder 
 +  df -Thlx tmpfs -x devtmpfs 
 +-> alle persistenten,​ lokalen Dateisysteme müssen gesichert werden 
 + 
 +== ext2 / ext3 / ext4 == 
 +  tune2fs -l /dev/sdaX > sicherung.ext.sdaX
 ((''/​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)) ((''/​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))
  
-=== xfs === +== xfs == 
-  xfs_admin -l /​dev/​sdaX ​ > sicherung.xfs_admin.sdaX+  xfs_admin -l -u /​dev/​sdaX ​ > sicherung.xfs.sdaX 
 +  xfs_info /​dev/​sdaX ​ >> sicherung.xfs.sdaX
 ((''/​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)) ((''/​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))
 +
 +== btrfs ==
 +btrfs läßt sich nicht einfach mit rsync oder tar sichern. Die beste Alternative ist, statt dessen ein [[image_sichern|Image]] des Dateisystems mit ''​fsarchiver''​ oder ''​partclone''​ zu erstellen. (( Vielleicht ist auch https://​github.com/​mwilck/​btrfs-clone eine brauchbare Alternative ))
 +
 +== vfat ==
 +  blkid /dev/sdaX > sicherung.vfat.sdaX
 +((''/​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))
 +
 +== swap ==
 +  blkid /dev/sdaX > sicherung.swap.sdaX
 +((''/​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))
 +
 +==== 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 ==== ==== Sicherung der Dateien ====
-=== Welche Dateisysteme müssen gesichert werden? === 
-  lsblk 
-oder 
-  df -h 
 === Einhängen der Dateisysteme unter /mnt/system === === Einhängen der Dateisysteme unter /mnt/system ===
- 
   mkdir /mnt/system   mkdir /mnt/system
   mount --bind / /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   mount --bind /boot /​mnt/​system/​boot
-evtl. weitere Verzeichnisse/Partitionen entsprechend der Ausgabe von ''​df''​ bzw''​lsblk''​+und/oder 
 +  mount --bind /boot/efi /​mnt/​system/​boot/​efi 
 +und möglicherweise weitere: 
 +  mount --bind ...
  
-=== mit rsync über ssh === +((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 )) 
-  rsync -a --numeric-ids --del -e ssh /​mnt/​system/ ​root@server:/​mnt/​backup/​dateien+ 
 +=== mit rsync über ssh Dateien kopieren ​=== 
 +Auf Quellund Zielsystem muss rsync installiert sein. Alternativ kann man auch [[#​tar_ueber_ssh|tar über ssh]] verwenden.  
 + 
 +== Debian (ab 8) == 
 +Wie oben unter "​[[#​debian_ab_8|Vorbereitung Zielsystem]]"​ beschrieben kann man entweder so vorgehen 
 +  * wie bei [[#​andere_distributionen_bei_denen_root_ein_passwort_hat|anderen Distributionen,​ bei denen root ein Passwort hat]] 
 +oder 
 +  * wie bei Ubuntu
  
-(( 
-Zweiter Aufruf, um zu sehen ob alle Dateien kopiert wurden: 
-  rsync -anv --numeric-ids --del -e ssh /​mnt/​system/​ root@server:/​mnt/​backup/​dateien 
-)) 
 == Ubuntu == == Ubuntu ==
-Unter **Ubuntu** gibt es defaultmäßig kein root Passwort! +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:+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+  sudo visudo ​-f /​etc/​sudoers.d/​backup
  
 und diese Zeile ergänzen: und diese Zeile ergänzen:
  
-  @admin ​ ​ALL=(ALL) NOPASSWD: ALL+<file txt /​etc/​sudoers.d/​backup>​ 
 +%sudo  ​ALL=(ALL) NOPASSWD: ALL 
 +</​file>​ (( oder 
 +<file txt /​etc/​sudoers.d/​backup>​ 
 +%sudo  ALL=(ALL) NOPASSWD: /​usr/​bin/​rsync 
 +</​file>​ 
 +)) 
 + 
 +Der Benutzer muss in der Gruppe //sudo// sein
  
 Und dann lautet der Befehl zum Backup: ​ Und dann lautet der Befehl zum Backup: ​
-  rsync ---numeric-ids --del -e ssh --rsync-path="​sudo rsync" /​mnt/​system/​ user@zielsystem:/​mnt/​backup/​dateien+  rsync -aSH --xattrs --acls ​--numeric-ids --del --rsync-path="​sudo rsync" /​mnt/​system/​ user@zielsystem:/​mnt/​backup/​dateien
  
-== RedHat ​CentOS ​== +== SuSE BTRFS == 
-RedHat'​s Versionen von ''​tar''​ und ''​rsync'' ​können mit ACLs und erweiterten Dateiattributen umgehen. Dazu die Optionen ''​--xattrs'' ​( ''​tar''​ ) oder ''​--xattrs --acls'' ​''​rsync'' ​) angeben.+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 
 +(( mehr zu [[rsync]], u.a. wie man hier ''​rsync'' ​auch ohne root-Rechte benutzen kann )) (( mehr zu [[ssh]] )) (( wenn man ein Art Fortschrittsbalken haben will: ''​progress'' ​installieren und ''​progress -wm'' ​ausführen während rsync läuft))
  
 === Plausibilitätsprüfung === === Plausibilitätsprüfung ===
-Datenmenge auf dem Quellsystem+Die wichtigsten Fragen sind
-  ​tar c --one-file-system / /home /boot 2>/dev/​null ​dd of=/​dev/​null +  ​* sind alle Dateien angekommen? ​-> Dateien auf Original und Backup zählen 
-Datenmenge ​auf dem Zielsystem: +  * sind die Berechtigungen korrekt? ​-> Eigentümer/Berechtigungen auf Original und Backup vergleichen,​ dabei die [[dateirechte#​beispielungewollter_eigentuemerwechsel_bei_backup_und_restore|Unterschiede in den Benutzer IDs]] auf Original- und Backupsystem beachten 
-  ​tar c /​mnt/​backup/​dateien 2>/​dev/​null | dd of=/​dev/​null+  ​* Sind die Dateien vollständig angekommen? ​
  
-Anzahl ​Dateien ​auf dem Quellsystem+== Sind alle Dateien ​angekommen? == 
-  find / /home /boot -xdev 2>/dev/null wc -l +  * einfach mal mit ''​ls''​ stichprobenartig nachschauen 
-Anzahl Dateien ​auf dem Zielsystem:​ +  * mit Hilfe von ''​find''​ und ''​wc''​ Dateien zählen 
-  ​find /mnt/backup/dateien 2>/dev/null wc -l + 
-==== Sicherung der ACL-Dateirechte ​==== +== Sind die Berechtigungen korrekt? == 
-nur nötig, wenn ''​tar'' ​oder ''​rsync''​ das nicht kann+  * 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 | 
 + 
 +Auf dem Zielsystem Checksummen für Backup-Dateien erzeugen: 
 +  cd /​mnt/​backup/​dateien 
 +  find . -xdev -type f -print0 ​ | sort -z | xargs -0 cksum > /run/cksum.backup 
 +  find . -xdev -print0 | sort -z | xargs -0 getfacl -P -n > /​run/​getfacl.backup 
 + 
 +Auf dem Original-System Checksummen für Dateien erzeugen: (hier müssen neben ''​.''​ und ''​./​boot''​ möglicherweise weitere Dateisysteme angegeben werden) 
 +  cd /​mnt/​system 
 +  find . ./boot -xdev -type f -print0 | sort -z | xargs -0 cksum > /run/cksum.orig 
 +  find . ./boot -xdev -print0 ​sort -z | xargs -0 getfacl -P -n > /​run/​getfacl.orig 
 + 
 +''/​run/​*.orig'' ​auf das Zielsystem ​kopieren 
 +  scp /run/*.orig root@server: 
 + 
 +Checksummen vergleichen 
 +  ​diff ~/cksum.orig ​/run/cksum.backup 
 + 
 +Berechtigungen vergleichen 
 +  diff ~/getfacl.orig ​/run/getfacl.backup 
 +++++ 
 +++++ ACLs und erweiterte Attribute ​
 +=== Sicherung der ACL-Dateirechte === 
 +aktuelle Versionen von ''​tar'' ​und ''​rsync'' ​erledigen ​das mit, bei älteren Systemen:
   cd /mnt/system   cd /mnt/system
-  getfacl --skip-base -P -R . > sicherung.acl+  getfacl --skip-base -P -n -R . > sicherung.acl
   scp sicherung.acl root@server:/​mnt/​backup   scp sicherung.acl root@server:/​mnt/​backup
  
-==== Sicherung der erweiterten Dateiattribute ( z.B. SELINUX ) ==== +=== Sicherung der erweiterten Dateiattribute ( z.B. SELINUX, capabilities ​) === 
-nur nötig, wenn ''​tar'' ​oder ''​rsync'' ​das nicht kann+nur nötig, wenn [[tar]] oder [[rsync]] das nicht kann
   cd /mnt/system   cd /mnt/system
   getfattr -Rh -m . -d . > sicherung.attr   getfattr -Rh -m . -d . > sicherung.attr
   scp sicherung.attr root@server:/​mnt/​backup   scp sicherung.attr root@server:/​mnt/​backup
 +++++
  
 ====== Löschen des Systems ====== ====== Löschen des Systems ======
 +(( 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 [[admin_grundlagen:​kernel#​einstellungen_zur_laufzeit|sysctl]]
 +))
 === schnell === === schnell ===
 +  wipefs -af /dev/sda
 +
 +Oder bei SSDs:
 +  blkdiscard --force /dev/sda
 +((
 +Das System lebt jetzt mit den Daten aus dem Cache etwas weiter. Cache löschen:
 +  echo 1 > /​proc/​sys/​vm/​drop_caches
 +))
 +=== sicher ===
   dd if=/​dev/​zero of=/dev/sda   dd if=/​dev/​zero of=/dev/sda
  
 ... und nach ein paar Sekunden ist das System zumindest unbrauchbar. ​ ... und nach ein paar Sekunden ist das System zumindest unbrauchbar. ​
-=== sicher ​===+Oder bei SSDs: 
 +  blkdiscard -s /dev/sda 
 + 
 +=== paranoid ​===
   dd if=/​dev/​urandom of=/dev/sda   dd if=/​dev/​urandom of=/dev/sda
  
-  wipe /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 [[https://​www.heise.de/​newsticker/​meldung/​Linux-rm-rf-soll-keine-UEFI-Systeme-mehr-kaputt-machen-3113433.html|heise]] und im entsprechenden [[https://​git.kernel.org/​pub/​scm/​linux/​kernel/​git/​torvalds/​linux.git/​commit/?​id=0389075ecfb6231818de9b0225d3a5a21a661171|Kernel-Patch]] 
  
 ====== Wiederherstellung des Systems ====== ====== Wiederherstellung des Systems ======
-Rettungssystem ​/ Knoppix ​booten+Rettungssystem booten ​(im Linuxhotel-Netz:​ PXE-Boot und ''​debian11live''​ eingeben)
  
 ===== Schritte im Rettungs-System ===== ===== Schritte im Rettungs-System =====
 ==== Wiederherstellung der Partitionierung ==== ==== Wiederherstellung der Partitionierung ====
-Partitionierung anhand der Informationen aus der gesicherten Datei ''​sicherung.parted''​ und/oder gemäß ''​etc/fstab''​ aus dem Backup wie in [[Partitionierung]] beschrieben anlegen+Partitionstabelle wiederherstellen:​ 
 +  sfdisk ​/dev/sda < sicherung.sfdisk
  
 +(( 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. ))
 ==== Wiederherstellung LVM ==== ==== Wiederherstellung LVM ====
-Partitionierung ​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+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 anlegen====
-Dateisysteme mit ''​mkfs.ext3'' ​o.ä. gemäß ''​etc/​fstab''​ aus dem Backup anlegen ​+Dateisysteme mit ''​mkfs.*''​ gemäß ''​etc/​fstab''​ aus dem Backup anlegen. Dabei wenn nötig die Dateisystem-Einstellungen aus der Sicherung berücksichtigen (UUID, ...)
 ((''/​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)) ((''/​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))
-  ​mkfs.ext3 /dev/sdaX +=== ext4 === 
-...+  ​mkfs.ext4 -U xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx ​/dev/sdaX 
 +((''​xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx''​ steht hier für die UUID aus der Sicherung)) 
 + 
 +=== xfs === 
 +  mkfs.xfs -m uuid=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx /dev/sdaX 
 +((''​xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx''​ steht hier für die UUID aus der Sicherung)) 
 + 
 +=== fat === 
 +  mkfs.vfat -i xxxxxxxx /dev/sdaX 
 +((Eine UUID die von ''​blkid''​ im Format ''​%%UUID="​066B-5CE0"​%%''​ ausgegeben wurde muss ''​mkfs.vfat''​ mit ''​066B5CE0''​ (also ohne Minus) übergeben werden))
  
 ==== Swap anlegen ==== ==== Swap anlegen ====
 ((''/​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)) ((''/​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))
-  mkswap /dev/sdaX+  mkswap ​-U xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx ​/dev/sdaX 
  
 ==== Mounten der Zielpartitionen ==== ==== Mounten der Zielpartitionen ====
-Mountpoints mit ''​mkdir''​ anlegen und Dateisysteme mit ''​mount''​ einhängen: (( evtl. mount-optionen ( z.B. acl ) beachten )) +In ''/​mnt/​backup/​dateien/​etc/​fstab''​ aufgeführte ​Mountpoints mit ''​mkdir''​ anlegen und Dateisysteme mit ''​mount''​ einhängen: (( evtl. mount-optionen ( z.B. acl ) beachten )) 
 ((''/​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)) ((''/​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))
   mkdir /tmp/system   mkdir /tmp/system
Zeile 136: Zeile 290:
   mkdir /​tmp/​system/​boot   mkdir /​tmp/​system/​boot
   mount /dev/sdaY /​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 mit rsync über ssh ==== +==== Wiederherstellen ​der Dateien ​mit rsync über ssh ==== 
-  rsync ---numeric-ids --del -e ssh root@server:/​mnt/​backup/​dateien/​ /​tmp/​system ​+  rsync -aSH --acls --xattrs ​--numeric-ids --del root@server:/​mnt/​backup/​dateien/​ /​tmp/​system ​
  
-evtl. ACLs und erweiterte Dateisystemattribute berücksichtigen+((mehr siehe [[rsync]])) (( Notlösung: Berechtigungen (teilweise) wiederherstellen,​ wenn sie nicht richtig gesichert wurden 
 +  rpm -qa | xargs rpm --setperms 
 +Todo: debian? 
 +)) 
 +=== Ubuntu === 
 +  rsync -aSH --acls --xattrs ​ --numeric-ids --del --rsync-path="​sudo rsync" user@server:/​mnt/​backup/​dateien/​ /​tmp/​system ​
  
-==== Wiederherstellen der ACL-Dateirechte ​==== +++++ ACLs und erweiterte Attribute | 
-nur nötig, wenn ''​tar''​ das nicht kann+=== Wiederherstellen der ACL-Dateirechte === 
 +nur nötig, wenn ''​rsync''​ bzw. ''​tar''​ das nicht kann 
 +  mount -o remount,acl /​tmp/​system/​
   cd /tmp/system   cd /tmp/system
   setfacl --restore sicherung.acl   setfacl --restore sicherung.acl
  
-==== Wiederherstellen der SELinux Attribute ​==== +=== Wiederherstellen der SELinux Attribute === 
-nur nötig, wenn ''​tar''​ das nicht kann+nur nötig, wenn ''​rsync''​ bzw. ''​tar''​ das nicht kann
 ( nicht erfolgreich getestet ... ) ( nicht erfolgreich getestet ... )
 +  mount -o remount,​user_xattrs /tmp/system
   cd /tmp/system   cd /tmp/system
-  ​setfacl ​-h --restore sicherung.attr+  ​setfattr ​-h --restore sicherung.attr
 oder oder
   touch /​tmp/​system/​.autorelabel   touch /​tmp/​system/​.autorelabel
- +++++ 
-==== Wiederherstellung der Dateisystem-Einstellungen ​==== +===== Bootfähig machen ​=====
-Mir ist kein automatischer Weg bekannt ... daher: +
-tune2fs .... ( UUID, Dateisystem-Label,​ Mountoptionen,​ ... ) +
-  tune2fs -U 2e92cc4e-e735-4e4f-8a0f-dc3adb42fd67 /dev/sda5 +
- +
-===== Bootloader wiederherstellen ​=====+
 ==== chroot vorbereiten ==== ==== chroot vorbereiten ====
-  mount --bind /dev  /​tmp/​system/​dev+  ​mount --rbind /dev  /​tmp/​system/​dev 
 +  mount --rbind /proc /​tmp/​system/​proc 
 +  mount --rbind /sys  /​tmp/​system/​sys 
 +  mount --rbind /run  /​tmp/​system/​run 
 +((/run ist sinnvoll bei der Verwendung von lvm oder raid)) (( 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! )) (( 
 +=== 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 /proc /​tmp/​system/​proc
-  mount --bind /sys  /​tmp/​system/​sys+  mount --bind /sys /​tmp/​system/​sys 
 +  mount --bind /run /​tmp/​system/​run 
 +)) 
 + 
 +==== 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 
 +(( ''​000f''​ ist hier nur ein Beispiel für einen veralteten Eintrag )) 
 + 
 +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"​ 
 + 
 +(( 
 +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:​ 
 +<file txt /​etc/​default/​grub>​ 
 +… 
 +GRUB_ENABLE_BLSCFG=false 
 +… 
 +</​file>​ 
 +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
  
-(( 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! ​ 
-Ich habe es schon erlebt, dass die Datei ''/​etc/​mtab''​ falsche Informationen enthält. Falls das so ist, kann man sie so ersetzen: 
-  mv /​tmp/​system/​etc/​mtab ​ /​tmp/​system/​etc/​mtab.bak 
-  cp -a /​proc/​mounts /​tmp/​system/​etc/​mtab 
-Nach dem chroot nicht vergessen, die ''/​etc/​mtab''​ wiederherzustellen:​ 
-  mv /​tmp/​system/​etc/​mtab.bak /​tmp/​system/​etc/​mtab 
 )) ))
 +=== 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
  
-==== Schritte im chroot Zielsystem ==== +== andere ​== 
-  ​chroot ​/tmp/system+  ​grub2-install /dev/sda 
 +  grub-mkconfig > /boot/grub/grub.cfg
  
-=== System wieder startfähig machen ​=== +=== grub1 / grub legacy wiederherstellen ​===
-== grub ==+
 Grub in den MBR schreiben: Grub in den MBR schreiben:
   grub   grub
Zeile 189: Zeile 464:
   grub-install --recheck --no-floppy hd0   grub-install --recheck --no-floppy hd0
  
-== grub2 == 
-  grub-install /dev/sda 
  
-Debian 6.0 +==== reboot ===
-  ​update-grub2 +chroot-Umgebung (z.B. mit ''​Strg+d''​) verlassen und 
- +  ​reboot
-= openSuSE 12.2 = +
-  ​update-bootloader --refresh+
  
 ===== Anpassungen bei geänderter Hardware oder geänderten Partitionen ===== ===== 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 ====
 +**[[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:
  
 +
 +==== 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 [[wp>​BIOS boot partition|BIOS Boot Partition]] z.B. von Block 34 bis Block 2047 vor Veränderungen schützen. ​
 +
 +((aus dem [[https://​wiki.archlinux.org/​index.php/​GUID_Partition_Table#​Convert_from_MBR_to_GPT|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.// ​
 +))
 +((
 +aus der [[http://​www.gnu.org/​software/​grub/​manual/​html_node/​BIOS-installation.html|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’. //))
 +
 +==== /boot auf separater Partition ====
 +Bei Debian mit UEFI anpassen: ''/​boot/​efi/​EFI/​debian/​grub.cfg''​
 ==== Bootloader grub ==== ==== Bootloader grub ====
 ''/​boot/​grub/​menu.lst''​ : ''/​boot/​grub/​menu.lst''​ :
Zeile 209: Zeile 504:
   * Kernel-Parameter zum root-Dateisystem ( ''​root= ...''​ )   * 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 ====
 ''/​etc/​fstab''​ : ''/​etc/​fstab''​ :
Zeile 218: Zeile 531:
 (( möglicherweise kann man ''/​etc/​mtab''​ auch einfach löschen )) (( möglicherweise kann man ''/​etc/​mtab''​ auch einfach löschen ))
 ==== Kernel-Module und initrd ==== ==== Kernel-Module und initrd ====
-Je nach Änderung muß eine neue initrd erzeugt werden und/oder die bei Booten geladenen Module müssen überarbeitet werden+Je nach Änderung muß eine neue [[admin_grundlagen:​initrd|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 
 + 
 +<file txt /​etc/​dracut.conf.d/​10-xfs.conf>​ 
 +add_drivers+="​ xfs " 
 +</​file>​ 
 +  dracut --force /​boot/​initrd-4.4.87-18.29-default 4.4.87-18.29-default 
 === CentOS 6 === === CentOS 6 ===
 in der chroot-Umgebung in der chroot-Umgebung
Zeile 227: Zeile 553:
  
 ====== Alternative Sicherungswege ====== ====== 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 ===
 +  * [[tar|Übersicht tar]]
 +  * man tar
 +
 +==== cpio über ssh ==== 
 +=== Sicherung === 
 +((Vermeidet die Probleme von tar und gzip bei Datenfehlern))
 +
 +  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: (( erfordert laufenden rsyncd auf dem Zielsystem //server// ))
 +  rsync -a --hard-links --sparse --acls --xattrs --numeric-ids --del / server::/​backup/​dateien/​
 +
 ==== Platzsparende Hardlink Backups mit rsnapshot ==== ==== Platzsparende Hardlink Backups mit rsnapshot ====
  
Zeile 252: Zeile 610:
  
   rsnapshot -t daily   rsnapshot -t daily
- 
-==== Sicherung mit tar über ssh ==== 
-  tar cz --numeric-owner --directory /mnt/system . | ssh nutzer@server "cat > /​mnt/​backup/​sicherung.tgz"​ 
- 
-Fedora 7, Centos 5: 
-  tar cz --numeric-owner --xattrs --directory /mnt/system . | ssh nutzer@server "cat > /​mnt/​backup/​sicherung.tgz"​ 
- 
-=== Dokumentation === 
-  * [[tar|Übersicht tar]] 
-  * man tar 
- 
-=== Sicherung mit tar über ssh und anschließendem entpacken === 
- 
-  cd /​pfad/​zur/​quelle && tar -cpP --atime-preserve -f - . | ssh user@server "( cd /​pfad/​zum/​ziel && tar -xpvP --atime-preserve -f - )" 
- 
-==== Sicherung mit cpio über ssh ====  
-((Vermeidet die Probleme von tar und gzip bei Datenfehlern)) 
- 
-  cd /mnt/system 
-  find -xdev -depth -print0 | cpio -o0 --format=crc | bzip2 | ssh nutzer@server 'cat > /​mnt/​backup/​sicherung.cpio.bz2'​ 
- 
-==== Wiederherstellen mit tar über ssh ==== 
-  ssh nutzer@server 'cat /​mnt/​backup/​sicherung.tgz'​ | tar xz --numeric-owner --directory /tmp/system 
- 
-==== Wiederherstellen mit cpio über ssh ====  
-  cd /tmp/system 
-  ssh nutzer@server 'cat /​mnt/​backup/​sicherung.cpio.bz2'​ | bunzip2 | cpio -dumin 
- 
-==== rsync ==== 
-Auf lokale Platte: 
-  rsync -ax --numeric-ids --del / /​mnt/​usbdisk/​root/ ​ 
- 
-Übers Netz via ssh: 
-  rsync -ax --numeric-ids --del -e ssh / server:/​mnt/​backup/​dateien 
- 
-Übers Netz via rsyncd: (( erfordert laufenden rsyncd auf dem Zielsystem //server// )) 
-  rsync -ax --numeric-ids --del / server::/​backup/​dateien/​ 
  
 ===== Problem: udev ===== ===== Problem: udev =====
-Auf modernen Linux-Installationen wird wegen [[udev]] das Verzeichnis ''/​dev''​ von einem temporären Dateisystem überdeckt. Linux benötigt ​ diese überdeckten Dateien aber beim Booten. ​+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:​ Lösungswege:​
Zeile 309: Zeile 630:
   * [[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>​
 +
 +  * Subvolumes welche gesichert werden:<​code example>
 +   /
 +   /home
 +   /opt
 +   /srv
 +   /var
 +   /root
 +   /​usr/​local
 +   /tmp
 +   /​boot/​grub2/​x86_64-efi
 +   /​boot/​grub2/​i386-pc
 +</​code>​
 +   
 +  * 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)!
 +
 +<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 receive /​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 /​mnt/​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> /mnt
 +</​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%%''​
 +
 +  * Beispiel Datei /etc/fstab nach Wiederherstellung<​code example>
 +
 +/​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
 +</​code>​
 +
 +  * 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
admin_grundlagen/systemsicherung.1348151444.txt.gz · Zuletzt geändert: 2012/09/20 14:30 von ingo_wichmann