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 [2011/10/27 15:27]
ingo_wichmann [Mounten der Zielpartitionen]
admin_grundlagen:systemsicherung [2024/02/23 17:11] (aktuell)
ingo_wichmann [UEFI]
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 ===== 
 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 
 + 
 +=== 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 ===== 
 +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 
 + 
 +((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 
 + 
 +Mehr zur Vorgehensweise siehe [[Partitionierung]]. )) 
 + 
 +==== Sicherung LVM Informationen ==== 
 +  vgcfgbackup -f sicherung.vg 
 +  pvdisplay > sicherung.pvdisplay 
 +  vgdisplay > sicherung.vgdisplay 
 +  lvdisplay > sicherung.lvdisplay 
 + 
 +==== Sicherung anderer Storage Informationen ==== 
 +  * [[admin_grundlagen:​raid|Software RAID]] 
 +  * drbd 
 +  * [[lpi2:​iscsi|iSCSI]] 
 +  * ... 
 + 
 +==== 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 
 +((''/​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 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
  
-===== Vorbereitung ( auf dem zu sichernden System )===== +==== Sicherung der Dateien ​===
-  df -h+=== 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''​+und/oder 
 +  mount --bind /boot/efi /​mnt/​system/​boot/​efi 
 +und möglicherweise weitere: 
 +  mount --bind ...
  
-==== Sicherung 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+
  
-=== Ubuntu ​=== +=== mit rsync über ssh Dateien kopieren ​=== 
-Unter **Ubuntu** gibt es defaultmäßig kein root Passwort! +Auf Quell- und Zielsystem ​muss rsync installiert sein. Alternativ kann man auch [[#​tar_ueber_ssh|tar über ssh]] verwenden. ​
-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+== 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 
 + 
 +== 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: 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+  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
  
-==== Sicherung der ACL-Dateirechte ==== +== andere Distributionen (bei denen root ein Passwort hat) == 
-nur nötig, wenn ''​tar''​ oder ''​rsync''​ das nicht kann +  ​rsync -aSH --acls --xattrs --numeric-ids --del /​mnt/​system/ ​root@server:/​mnt/​backup/dateien 
-  ​cd /​mnt/​system +(( 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. ))
-  getfacl ​--skip-base --R . > sicherung.acl +
-  scp sicherung.acl ​root@server:/​mnt/​backup+
  
-==== Sicherung der erweiterten Dateiattribute ( z.B. SELINUX ) ==== +=== Plausibilitätsprüfung ​=== 
-nur nötig, wenn ''​tar''​ oder ''​rsync''​ das nicht kann +Die wichtigsten Fragen sind: 
-  ​cd /mnt/system +  ​* sind alle Dateien angekommen? -> Dateien auf Original und Backup zählen 
-  ​getfattr ​-Rh -m . -d . > sicherung.attr +  ​* 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 Originalund Backupsystem beachten 
-  ​scp sicherung.attr root@server:/​mnt/​backup+  ​* 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
  
-==== Sicherung der Dateisystem-Einstellungen ==== +== Sind die Berechtigungen korrekt? ​== 
-Beispiel ext3: +  ​* einfach mal mit ''​ls ​-l''​ stichprobenartig nachschauen
-  ​tune2fs ​-l /dev/sdaX > sicherung.tune2fs.sdaX +
-  scp sicherung.tune2fs.sdaX root@server:/​mnt/​backup+
  
 +== 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 |
  
-==== Sicherung der Partitionierung ==== +Auf dem Zielsystem Checksummen für Backup-Dateien erzeugen: 
-Exakte Vorgehensweise siehe [[partitionierung]],​ wenn die Wiederherstellung nicht automatisiert erfolgen muß reicht auch die Ausgabe von ''​parted''​ oder ''​df''​ +  ​cd /mnt/backup/​dateien 
-  ​parted ​/dev/sda print sicherung.parted +  find . -xdev -type f -print0 ​ | sort -z | xargs -0 cksum /run/cksum.backup 
-  ​scp sicherung.parted root@server:​/mnt/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
  
-alternativ+''/​run/​*.orig''​ auf das Zielsystem kopieren 
 +  scp /run/*.orig root@server:​
  
 +Checksummen vergleichen
 +  diff ~/​cksum.orig /​run/​cksum.backup
  
-  sfdisk ​-/dev/sda > sicherung.sfdisk +Berechtigungen vergleichen 
-  scp sicherung.sfdisk ​root@server:/​mnt/​backup+  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 ​LVM Informationen ==== +=== Sicherung ​der erweiterten Dateiattribute ( z.B. SELINUX, capabilities ) === 
-  ​pvdisplay > sicherung.pvdisplay +nur nötig, wenn [[tar]] oder [[rsync]] das nicht kann 
-  ​vgdisplay > sicherung.vgdisplay +  ​cd /mnt/system 
-  lvdisplay ​> sicherung.lvdisplay +  ​getfattr -Rh -m . -d . > sicherung.attr 
-  scp sicherung.pvdisplay sicherung.vgdisplay sicherung.lvdisplay ​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
  
-====== ​Wiederherstellung des Systems ====== +=== Gefahr der Beschädigung der Hardware ​===
-Rettungssystem / Knoppix booten+
  
-===== Schritte im Rettungs-System =====+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 ======
 +Rettungssystem booten (im Linuxhotel-Netz:​ PXE-Boot und ''​debian11live''​ eingeben)
 +
 +===== 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, ...) 
-  mkfs.ext3 /dev/sda5 +((''/​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))
  
 ==== Swap anlegen ==== ==== Swap anlegen ====
-  ​mkswap /dev/sda6+((''/​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 ​-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))
   mkdir /tmp/system   mkdir /tmp/system
   mount /dev/sdaX /tmp/system   mount /dev/sdaX /tmp/system
Zeile 112: 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 ​der Dateien ​mit rsync über ssh ==== 
-==== Wiederherstellen mit rsync über ssh ==== +  rsync -aSH --acls --xattrs ​--numeric-ids --del root@server:/​mnt/​backup/dateien/ /​tmp/​system ​
-  rsync ---numeric-ids --del -e ssh root@server:/​mnt/​backup/​ /​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,​ ... ) +
- +
-===== 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 /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
 +
 +))
 +=== 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
  
-(( nicht unbedingt 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! ))+== 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 157: Zeile 464:
   grub-install --recheck --no-floppy hd0   grub-install --recheck --no-floppy hd0
  
-== grub2 == + 
-  grub-install /dev/sda+==== reboot ​==== 
 +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]]**
 +
 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 171: 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''​ :
 Neue Partitionsnummern,​ Software-RAID und Logical Volumes beachten Neue Partitionsnummern,​ Software-RAID und Logical Volumes beachten
  
 +==== /etc/mtab ====
 +''/​etc/​mtab''​ :
 +Neue Partitionsnummern,​ Software-RAID und Logical Volumes beachten
 +(( 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 === 
 +in der chroot-Umgebung 
 +  mkinitrd --force /​boot/​initramfs-2.6.32-220.el6.x86_64.img 2.6.32-220.el6.x86_64
  
 ==== udev ==== ==== udev ====
Zeile 182: 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 208: Zeile 611:
   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 überdecktLinux 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 1Erstellen 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 2von 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 -/tmp .backup/tmp 
 +... 
 +ls -l /.backup 
 +</code>
  
-===== Problemudev ===== +  * Subvolumes welche gesichert werden:<code example> 
-Auf modernen Linux-Installationen wird wegen [[udev]] das Verzeichnis ​''​/dev'' ​von einem temporären Dateisystem überdecktLinux 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 übertragenDas Dateisystem auf dem Zielsystem muss genügend freien Speicher aufweisen um das Backup aufzunehmenDer 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''​ zugreifenDie 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 (ggfGerä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.1319729275.txt.gz · Zuletzt geändert: 2011/10/27 15:27 von ingo_wichmann