Linuxhotel Wiki

Wie ging das nochmal?

Benutzer-Werkzeuge

Webseiten-Werkzeuge

Zuletzt angesehen: • chrony • volumes • netzwerk • swap • systemsicherung • sss • journald • distributionen • xdm • samba
admin_grundlagen:systemsicherung

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen der Seite angezeigt.

Link zu der Vergleichsansicht

Beide Seiten, vorherige ÜberarbeitungVorherige Überarbeitung
Nächste Überarbeitung		Vorherige Überarbeitung
admin_grundlagen:systemsicherung [2012/06/21 13:08] – ingo_wichmannadmin_grundlagen:systemsicherung [2025/11/28 11:53] (aktuell) – [Sicherung der Dateisystem-Einstellungen] ingo_wichmann
Zeile 2: Zeile 2:
 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.  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. 
  
-===== Vorbereitung ( auf dem Zielsystem )=====+Abschätzen, wie viel Platz benötigt wird: 
 +  df -Thlx tmpfs -x devtmpfs 
 +-> Summe der Daten auf persistenten, lokalen Dateisystemen 
 + 
 +===== Vorbereitung Zielsystem ===== 
 + 
 +==== Platz schaffen ====
 evtl. Platz schaffen wie in [[Plattenplatz]], [[Partitionierung]] und [[lvm]] beschrieben evtl. Platz schaffen wie in [[Plattenplatz]], [[Partitionierung]] und [[lvm]] beschrieben
-  mkdir /mnt/backup+  mkdir -p /mnt/backup/dateien
  
-===== Vorbereitung ( auf dem zu sichernden System )===== +==== SSH Zugriff als root ==== 
-  df -h +Root Passwort setzen, sofern nicht bekannt/verfügbar: 
-  mkdir /mnt/system +  passwd root
-  mount --bind / /mnt/system +
-  mount --bind /boot /mnt/system/boot +
-evtl. weitere Verzeichnisse/Partitionen entsprechend der Ausgabe von ''df''+
  
-==== Sicherung der ACL-Dateirechte ==== +<file txt /etc/ssh/sshd_config.d/root.conf> 
-nur nötig, wenn ''tar'' oder ''rsync'' das nicht kann +PermitRootLogin yes 
-  cd /mnt/system +</file>
-  getfacl --skip-base -P -R . > sicherung.acl +
-  scp sicherung.acl root@server:/mnt/backup+
  
-==== Sicherung der erweiterten Dateiattribute ( z.B. SELINUX ) ==== +  systemctl restart ssh.service
-nur nötig, wenn ''tar'' oder ''rsync'' das nicht kann +
-  cd /mnt/system +
-  getfattr -Rh -m . -d . > sicherung.attr +
-  scp sicherung.attr root@server:/mnt/backup+
  
 +++++  Alternativ: sudo und ssh-Schlüssel |
 +Zielverzeichnis ''/mnt/backup'' muss dem Nutzer gehören:
 +  chown nutzerXX /mnt/backup
  
-==== Sicherung der Dateisystem-Einstellungen ==== +  * [[sudo]] einrichten, falls noch nicht passiert  
-Beispiel ext3: +  * einen [[ssh]]-Schlüssel beim Benutzer root hinterlegen 
-  tune2fs -l /dev/sdaX > sicherung.tune2fs.sdaX +++++ 
-  scp sicherung.tune2fs.sdaX root@server:/mnt/backup+===== 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 ==== ==== Sicherung der Partitionierung ====
-Exakte Vorgehensweise siehe [[partitionierung]], wenn die Wiederherstellung nicht automatisiert erfolgen muß reicht 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 +Mehr zur Vorgehensweise siehe [[Partitionierung]]. ))
- +
-  sfdisk -d /dev/sda > sicherung.sfdisk +
-  scp sicherung.sfdisk root@server:/mnt/backup+
  
 ==== Sicherung LVM Informationen ==== ==== Sicherung LVM Informationen ====
 +  vgcfgbackup -f sicherung.vg.%s
   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 
  
-==== Sicherung der Dateien mit rsync über ssh ==== +==== Sicherung anderer Storage Informationen ==== 
-  rsync -a --numeric-ids --del -e ssh /mnt/system/ root@server:/mnt/backup+  * [[admin_grundlagen:raid|Software RAID]] 
 +  * drbd 
 +  * [[lpi2:iscsi|iSCSI]] 
 +  * ...
  
-(( +==== Sicherung der Dateisystem-Einstellungen ==== 
-Zweiter Aufruf, um zu sehen ob alle Dateien kopiert wurden: +=== Von welchen Dateisystemen müssen Einstellungen gesichert werden? === 
-  rsync -anv --numeric-ids --del -e ssh /mnt/system/ root@server:/mnt/backup+  lsblk -f 
 +oder 
 +  df -Thlx tmpfs -x devtmpfs -x efivarfs 
 +-> 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)) 
 + 
 +== xfs == 
 +  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)) 
 + 
 +== btrfs == 
 +btrfs läßt sich ggf. nur umständlich (Subvolumes, usw.) 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 )) 
 + 
 +Die UUID des Dateisystems erhält man mit ''blkid''. 
 + 
 +  btrfs subvolume list / >sicherung.sda3.subvolumes 
 + 
 +== 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 ==== 
 + 
 +  scp sicherung.* root@server:/mnt/backup/notebookXY 
 + 
 +==== 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 /… 
 + 
 +((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 -axzRSHAX --numeric-ids --del / /boot/ /boot/efi/ … root@server:/mnt/backup/notebookXY/dateien 
 )) ))
-=== 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+=== mit rsync über ssh Dateien kopieren === 
 +Auf Quell- und Zielsystem muss rsync installiert sein. Alternativ kann man auch [[#tar_ueber_ssh|tar über ssh]] verwenden.  
 + 
 +++++ Ubuntu ohne SSH 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: 
 + 
 +  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> 
 + 
 +Der Benutzer muss in der Gruppe //sudo// sein
  
 Und dann lautet der Befehl zum Backup:  Und dann lautet der Befehl zum Backup: 
-  rsync -a --numeric-ids --del -e ssh --rsync-path="sudo rsync" /mnt/system/ user@zielsystem:/mnt/backup+  rsync -azSH --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.  
 +++++ 
 + 
 +  rsync -azSH --acls --xattrs --numeric-ids --del /mnt/system/ root@server:/mnt/backup/notebookXY/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 === 
 +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 [[dateirechte#beispielungewollter_eigentuemerwechsel_bei_backup_und_restore|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 | 
 + 
 +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 
 +  getfacl --skip-base -P -n -R . > sicherung.acl 
 +  scp sicherung.acl root@server:/mnt/backup 
 + 
 +=== Sicherung der erweiterten Dateiattribute ( z.B. SELINUX, capabilities ) === 
 +nur nötig, wenn [[tar]] oder [[rsync]] das nicht kann 
 +  cd /mnt/system 
 +  getfattr -Rh -m . -d . > sicherung.attr 
 +  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 ''debian12live'' eingeben) 
 + 
 +(UEFI-Bootmenü: Meistens F12; auf TUXEDO F7)
  
 ===== Schritte im Rettungs-System ===== ===== Schritte im Rettungs-System =====
 +==== Sicherungs-Dateien zurückkopieren ====
  
 +  scp root@server:/mnt/backup/sicherung.* /tmp
  
 ==== 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 +=== 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 ((''/dev/sdaX'' ist hier nur ein Beispiel für das root-Device. Liegt das /-Dateisystem auf einem Logical Volume, dann heißt das root-Device ''/dev/mapper/xxx'' oder ähnlich)) +Dateisysteme mit ''mkfs.*'' gemäß ''etc/fstab'' aus dem Backup anlegen. Dabei wenn nötig die Dateisystem-Einstellungen aus der Sicherung berücksichtigen (UUID, ...) 
-  mkfs.ext3 /dev/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)) 
-...+=== 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)) 
 + 
 +=== btrfs === 
 + 
 +Es müssen alle Subvolumes wieder angelegt werden. Beispiel für openSUSE:
  
 +  mkfs.btrfs -U xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx /dev/sdaX
 +  mount /dev/sdaX /mnt
 +  btrfs subvolume create /mnt/@
 +  btrfs subvolume create /mnt/@/var
 +  …
 +  umount /mnt
 ==== Swap anlegen ==== ==== Swap anlegen ====
-((''/dev/sdaY'' ist hier nur ein Beispiel für das boot-Device. Liegt das /boot-Dateisystem auf einem Logical Volume, dann heißt das boot-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/sdaY+  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 das root-Device. 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
   mount /dev/sdaX /tmp/system   mount /dev/sdaX /tmp/system
 +  # bei openSUSE mount -o subvol=@ /dev/sdaX /tmp/system
  
   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 …
  
-… +Bei btrfs-Subvolumes:
-==== Wiederherstellen mit rsync über ssh ==== +
-  rsync -a --numeric-ids --del -e ssh root@server:/mnt/backup/ /tmp/system +
  
-evtl. ACLs und erweiterte Dateisystemattribute berücksichtigen+  mount -o subvol=@/var /dev/sdaW /tmp/system/var 
 +  … 
 +==== Wiederherstellen der Dateien mit rsync über ssh ==== 
 +  rsync -azSH --acls --xattrs --numeric-ids root@server:/mnt/backup/notebookXY/dateien/ /tmp/system 
  
-==== Wiederherstellen der ACL-Dateirechte ==== +((mehr siehe [[rsync]])) (( Notlösung: Berechtigungen (teilweise) wiederherstellen, wenn sie nicht richtig gesichert wurden 
-nur nötig, wenn ''tar'' das nicht kann+  rpm -qa | xargs rpm --setperms 
 +Todo: debian? 
 +)) 
 + 
 +++++ ACLs und erweiterte Attribute | 
 +=== 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 --bind /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 / Ubuntu: 
 +  grub-install 
 + 
 +SuSE (ab 15.4):  
 +  grub2-install 
 +  shim-install 
 + 
 +CentOS / Rocky (ab 9): 
 + 
 +''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=1 
 +  efibootmgr --create --disk "$boot_device" --part "$esp_partition_id" --label "$efi_label" --loader "/EFI/$distro/shimx64.efi" 
 + 
 +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 und kernel-install von Hand: 
 +  grubby --info DEFAULT 
 +  source /etc/default/grub 
 +  grubby --update-kernel ALL --args "$GRUB_CMDLINE_LINUX" --title "Rocky Linux" 
 + 
 +grub-config neu erzeugen 
 +  grub2-mkconfig --update-bls-cmdline -o /boot/grub2/grub.cfg 
 +  dnf -y reinstall grub2-common 
 + 
 +(( 
 +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 dem bind-mount 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 168: Zeile 479:
   grub-install --recheck --no-floppy hd0   grub-install --recheck --no-floppy hd0
  
-== grub2 == 
-  grub-install /dev/sda 
  
-  update-grub +==== reboot ==== 
-(( evtl. nur bei debian ))+chroot-Umgebung (z.B. mit ''Strg+d'') verlassen und 
 +  reboot
  
 ===== 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 und 9]]**
 +
 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 185: Zeile 519:
   * 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 194: Zeile 546:
 (( 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 203: Zeile 568:
  
 ====== 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 229: Zeile 626:
   rsnapshot -t daily   rsnapshot -t daily
  
-==== Sicherung mit tar über ssh ==== +===== Problem: udev ===== 
-  tar cz --numeric-owner --directory /mnt/system . | ssh nutzer@server "cat > /mnt/backup/sicherung.tgz"+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.
  
-Fedora 7, Centos 5: +Lösungswege:
-  tar cz --numeric-owner --xattrs --directory /mnt/system . | ssh nutzer@server "cat > /mnt/backup/sicherung.tgz"+
  
-=== Dokumentation === +  - Beim Backup das Verzeichnis ''/dev'' explizit angeben. Die wichtigsten Gerätedateien sollten auch darin enthalten sein. 
-  * [[tar|Übersicht tar]] +  - 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. 
-  * man tar+
  
-=== Sicherung mit tar über ssh und anschließendem entpacken ===+FRAGE: das müsste doch durch die bind-mounts nach /mnt/system gelöst sein, oder?!
  
-  cd /pfad/zur/quelle && tar -cpP --atime-preserve -f - . | ssh user@server "( cd /pfad/zum/ziel && tar -xpvP --atime-preserve -f - )"+Antwort: richtig
  
-==== Sicherung mit cpio über ssh ====  +====== Dokumentation ====== 
-((Vermeidet die Probleme von tar und gzip bei Datenfehlern))+  * [[http://www.linux-magazin.de/Artikel/ausgabe/2002/04/rsync/rsync.html]] 
 +====== Software ====== 
 +  * [[http://www.dirvish.org]] 
 +  * [[http://www.mondorescue.org/]] 
 +  * [[http://www.partimage.org/Main_Page]]
  
-  cd /mnt/system +====== Backup / Bare-Metal Restore Suse Linux ======
-  find -mount -depth -print0 | cpio -o0 --format=crc | bzip2 | ssh nutzer@server 'cat > /mnt/backup/sicherung.cpio.bz2'+
  
-==== Wiederherstellen mit tar über ssh ==== +Diese Anleitung beschreibt die Sicherung und Wiederherstellung eines Suse Linux Systems mit BTRFS Dateisystem.
-  ssh nutzer@server 'cat /mnt/backup/sicherung.tgz' | tar xz --numeric-owner --directory /tmp/system+
  
-==== Wiederherstellen mit cpio über ssh ====  +Getestet wurde diese Anleitung auf einem Suse Leap 15.x im Dezember 2022 auf einem Tuxedo Laptop mit NVME Speicher.
-  cd /tmp/system +
-  ssh nutzer@server 'cat /mnt/backup/sicherung.cpio.bz2' | bunzip2 | cpio -dumin+
  
-==== rsync ==== +===== Sicherung (aka Backup) =====
-Auf lokale Platte: +
-  rsync -ax --numeric-ids --delete / /mnt/usbdisk/root/ +
  
-Übers Netz via ssh: +  * 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. 
-  rsync -ax --numeric-ids --delete -e ssh / server:/mnt/usbdisk/root/+  * Schritt 1: Erstellen eines Subvolumes, welches die zu sichernden Snapshots aufnimmt<code example> 
 +btrfs subvol create .backup 
 +</code>
  
-Übers Netz via rsyncd: (( erfordert laufenden rsyncd auf dem Zielsystem //server// )) +  * 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> 
-  rsync -ax --numeric-ids --delete / server::/mnt/usbdisk/root/+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>
  
-===== Problem: udev ===== +  * Subvolumes welche gesichert werden:<code example> 
-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. +   / 
 +   /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)!
  
-Lösungswege:+<code example> 
 +ls -1 -d /.backup/* | xargs btrfs send  | ssh -C nutzerXX@192.168.1.2XX "cat > notebookXX.btrfs" 
 +</code>
  
-  - Beim Backup das Verzeichnis ''/dev'' explizit angeben. Die wichtigsten Gerätedateien sollten auch darin enthalten sein. +  * Hiermit ist die Sicherung abgeschlossen. Die Backup-Snapshots können nun wieder entfernt werden<code example> 
-  - Auf das Orginalsystem kann man mit ''mkdir /tmp/system && mount --bind / /tmp/system'' zugreifen. Die Sicherung muß man dann mit ''tar czpf /dev/st0 --numeric-owner --directory /tmp/system .'' starten. +btrfs subvol delete /.backup/root-fs 
 +btrfs subvol delete /.backup/usr-local 
 +btrfs subvol delete /.backup/srv 
 +... 
 +btrfs subvol delete /.backup 
 +</code>
  
-FRAGE: das müsste doch durch die bind-mounts nach /mnt/system gelöst sein, oder?! 
  
-====== Dokumentation ====== +===== System-Verlust simulieren (der spassige Teil) ===== 
-  * [[http://www.linux-magazin.de/Artikel/ausgabe/2002/04/rsync/rsync.html]] + 
-====== Software ====== +  * System "zerstören", indem das Unix-System-Root (USR) Verzeichnis gelöscht wird (am besten aus einer grafischen Sitzung heraus)<code example> 
-  * [[http://www.dirvish.org]] +rm -rf /usr 
-  * [[http://www.mondorescue.org/]] +</code> 
-  * [[http://www.partimage.org/Main_Page]]+ 
 +  * 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.1340284122.txt.gz · Zuletzt geändert: 2012/06/21 13:08 von ingo_wichmann