Linuxhotel Wiki

Wie ging das nochmal?

Benutzer-Werkzeuge

Webseiten-Werkzeuge


admin_grundlagen:systemsicherung

Dies ist eine alte Version des Dokuments!


Komplettsicherung des Systems

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

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

df -hlx tmpfs -x devtmpfs

→ Summe der Daten auf persistenten, lokalen Dateisystemen

Vorbereitung Zielsystem

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

mkdir -p /mnt/backup/dateien

Ubuntu

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

chown nutzerXX /mnt/backup

Debian (ab 8)

Entweder

  • sudo einrichten und wie unter Ubuntu beschrieben vorgehen.
  • einen ssh-Schlüssel beim Benutzer root hinterlegen oder
  • root das Anmelden mit Passwort erlauben 1)

Sicherung

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

Sicherung der Partitionierung

Mehr zur Vorgehensweise siehe partitionierung. Wenn die Wiederherstellung nicht automatisiert erfolgen muss, reicht auch die Ausgabe von parted

parted /dev/sda print > sicherung.parted

Ubuntu:

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

andere Distributionen (bei denen root ein Passwort hat):

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

2)

Sicherung LVM Informationen

pvdisplay > sicherung.pvdisplay
vgdisplay > sicherung.vgdisplay
lvdisplay > sicherung.lvdisplay

alternativ mit

vgcfgbackup -f sicherung.vg

Ubuntu:

scp sicherung.pvdisplay sicherung.vgdisplay sicherung.lvdisplay nutzer@server:/mnt/backup

andere Distributionen (bei denen root ein Passwort hat):

scp sicherung.pvdisplay sicherung.vgdisplay sicherung.lvdisplay root@server:/mnt/backup

Sicherung anderer Storage Informationen

Sicherung der Dateisystem-Einstellungen

Von welchen Dateisystemen müssen Einstellungen gesichert werden?

lsblk -f

→ alle persistenten, lokalen Dateisysteme müssen gesichert werden

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

3)

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

4)

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

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

5)

Sicherung der Dateien

Einhängen der Dateisysteme unter /mnt/system

In der Ausgabe von df -hT -x tmpfs -x devtmpfs die Mountpoints aller persistenten, lokalen Dateisysteme identifizieren und unterhalb von /mnt/system bind-mounten:

mkdir /mnt/system
mount --bind / /mnt/system
mount --bind /boot /mnt/system/boot
...

6)

mit rsync über ssh Dateien kopieren

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

und diese Zeile ergänzen:

%sudo  ALL=(ALL) NOPASSWD: ALL

Der Benutzer muss in der Gruppe sudo sein

Und dann lautet der Befehl zum Backup:

rsync -aH --xattrs --acls --numeric-ids --del --rsync-path="sudo rsync" /mnt/system/ user@zielsystem:/mnt/backup/dateien
Debian
andere Distributionen (bei denen root ein Passwort hat)
rsync -aH --acls --xattrs --numeric-ids --del /mnt/system/ root@server:/mnt/backup/dateien

7) 8) 9)

erweiterte Attribute und ACLs mit tar und rsync

RedHat's Versionen von tar und rsync können mit ACLs und erweiterten Dateiattributen umgehen, bei Debian ab Version 8. Dazu die Optionen –xattrs ( tar ) oder –xattrs –acls ( rsync ) angeben.

Plausibilitätsprüfung

Die wichtigsten Fragen sind:

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

Einfache Lösung:

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

Optional, 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

Sicherung der ACL-Dateirechte

nur nötig, wenn tar oder rsync das nicht kann

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

schnell

wipefs -af /dev/sda

Oder bei SSDs:

blkdiscard /dev/sda

sicher

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

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

blkdiscard -s /dev/sda

paranoid

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

… und laaaange warten

Wiederherstellung des Systems

Rettungssystem ( z.B. knoppix, pmagic ) booten

Schritte im Rettungs-System

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

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 10) In Knoppix muss dazu zuerst lvm2 gestartet werden:

service lvm2 start

Dateisysteme anlegen

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

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

12)

oder

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

13)

oder

mkfs.vfat -i xxxxxxxx /dev/sdaX

14)

Swap anlegen

15)

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

Mounten der Zielpartitionen

In /mnt/backup/dateien/etc/fstab aufgeführte Mountpoints mit mkdir -p anlegen und Dateisysteme mit mount einhängen: 16) 17)

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

Wiederherstellen der Dateien mit rsync über ssh

18)

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

evtl. ACLs und erweiterte Dateisystemattribute berücksichtigen 19)

Ubuntu

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

Wiederherstellen der ACL-Dateirechte

nur nötig, wenn rsync bzw. tar das nicht kann

mount -o remount,acl /tmp/system/
cd /tmp/system
setfacl --restore sicherung.acl

Wiederherstellen der SELinux Attribute

nur nötig, wenn rsync bzw. tar das nicht kann ( nicht erfolgreich getestet … )

mount -o remount,user_xattrs /tmp/system
cd /tmp/system
setfattr -h --restore sicherung.attr

oder

touch /tmp/system/.autorelabel

Bootloader wiederherstellen

chroot vorbereiten

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

20)

bei UEFI-Systemen:

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

Schritte im chroot Zielsystem

chroot /tmp/system /bin/bash

Bootloader wiederherstellen: entweder grub2 oder grub

grub2 wiederherstellen

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

grub1 / grub legacy wiederherstellen

Grub in den MBR schreiben:

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

oder mit

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

reboot

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

reboot

Anpassungen bei geänderter Hardware oder geänderten Partitionen

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. Statt fdisk also gdisk oder parted benutzen.

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

21) 22)

Bootloader grub

/boot/grub/menu.lst :

Neue Partitionsnummern beachten, wichtig sind z.B.

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

Bootloader grub2

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

Neue Partitionsnummern beachten, wichtig sind z.B.

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

BIOS -> UEFI

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

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

/etc/fstab

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

/etc/mtab

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

Kernel-Module und initrd

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

dracut (CentOS 7 / openSuSE 42.1)

in der chroot-Umgebung

dracut --force /boot/initrd-4.4.87-18.29-default 4.4.87-18.29-default

CentOS 6

in der chroot-Umgebung

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

udev

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

Alternative Sicherungswege

tar über ssh

Sicherung

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

Bei älteren Distributionen (SuSE bis SLES 11, Debian bis 7 und sehr alten RedHat)

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

Wiederherstellen

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

Dokumentation

cpio über ssh

Sicherung

24)

cd /mnt/system
find -xdev -depth -print0 | cpio -o0 --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

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: 25)

rsync -ax --numeric-ids --del / server::/backup/dateien/

Installation mit

apt-get install rsnapshot

Konfiguration unter:

/etc/rsnapshot.conf

Dabei wichtig:

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

Testen der Config

rsnapshot configtest

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

rsnapshot -t daily

Problem: udev

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

Lösungswege:

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

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

Antwort: richtig

Dokumentation

Software

1)
/etc/ssh/sshd_config
PermitRootLogin yes
2)
alternativ
sfdisk -d /dev/sda > sicherung.sfdisk
scp sicherung.sfdisk root@server:/mnt/backup
3) , 4) , 5) , 11) , 15)
/dev/sdaX ist hier nur ein Beispiel für ein Speichergerät ( Partition, LVM, …). Liegt das Dateisystem auf einem Logical Volume, dann heißt das Device /dev/mapper/xxx oder ähnlich
6)
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
7)
mehr zu rsync, u.a. wie man hier rsync auch ohne root-Rechte benutzen kann
8)
mehr zu ssh
9)
wenn man ein Art Fortschrittsbalken haben will: progress installieren und progress -wm ausführen während rsync läuft.
10)
IDs der Physical Volumes herausfinden:
less ~/sicherung.vg
Physical Volumes anlegen:
pvcreate -ff --zero y --restorefile ~/sicherung.vg --uuid I6oYXy-pdNv-gXH3-Prf8-azlo-zwQr-Srm8wX /dev/sdaX
...
Name der Volume Group herausfinden:
less ~/sicherung.vg
Volume Group und Logical Volumes wiederherstellen:
vgcfgrestore -f ~/sicherung.vg centos_notebook17
12) , 13)
xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx steht hier für die UUID aus der Sicherung
14)
Eine UUID die von blkid im Format UUID="066B-5CE0" ausgegeben wurde muss mkfs.vfat mit 066B-5CE0 (also ohne Minus) übergeben werden
16)
evtl. mount-optionen ( z.B. acl ) beachten
17)
/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
18)
mehr siehe rsync
19)
Notlösung: Berechtigungen (teilweise) wiederherstellen, wenn sie nicht richtig gesichert wurden
rpm -qa | xargs rpm --setperms
Todo: debian?
20)
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
21)
aus dem archlinux-Wiki: Keep in mind that if your Boot-Manager is GRUB, it needs a BIOS Boot Partition. If your MBR Partitioning Layout isn't too old, there is a good chance that the first partition starts at sector 2048 for alignment reasons. That means at the beginning will be 1007 KiB of empty space where this bios-boot partition can be created. To do this, first do the mbr→gpt conversion with gdisk as described above. Afterwards, create a new partition with gdisk and manually specify its position to be sectors 34 - 2047, and set the EF02 partition type.
22)
aus der GRUB Doku: When creating a BIOS Boot Partition on a GPT system, you should make sure that it is at least 31 KiB in size. (GPT-formatted disks are not usually particularly small, so we recommend that you make it larger than the bare minimum, such as 1 MiB, to allow plenty of room for growth.) You must also make sure that it has the proper partition type. Using GNU Parted, you can set this using a command such as the following:
parted /dev/disk set partition-number bios_grub on
If you are using gdisk, set the partition type to ‘0xEF02’. With partitioning programs that require setting the GUID directly, it should be ‘21686148-6449-6e6f-744e656564454649’.
23)
möglicherweise kann man /etc/mtab auch einfach löschen
24)
Vermeidet die Probleme von tar und gzip bei Datenfehlern
25)
erfordert laufenden rsyncd auf dem Zielsystem server
admin_grundlagen/systemsicherung.1547833607.txt.gz · Zuletzt geändert: 2019/01/18 17:46 von ingo_wichmann