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.

Vorbereitung ( auf dem Zielsystem )

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

mkdir /mnt/backup

Vorbereitung ( auf dem zu sichernden System )

df -h
mkdir /mnt/system
mount --bind / /mnt/system
mount --bind /boot /mnt/system/boot

evtl. weitere Verzeichnisse/Partitionen entsprechend der Ausgabe von df

Sicherung mit rsync über ssh

rsync -a --numeric-ids --del -e ssh /mnt/system/ root@server:/mnt/backup

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:

@admin  ALL=(ALL) NOPASSWD: ALL

Und dann lautet der Befehl zum Backup:

rsync -a --numeric-ids --del -e ssh --rsync-path="sudo rsync" /mnt/system/ user@zielsystem:/mnt/backup

RedHat / CentOS

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.

Sicherung der ACL-Dateirechte

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

cd /mnt/system
getfacl --skip-base -P -R . > sicherung.acl
scp sicherung.acl root@server:/mnt/backup

Sicherung der erweiterten Dateiattribute ( z.B. SELINUX )

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

Sicherung der Dateisystem-Einstellungen

Beispiel ext3:

tune2fs -l /dev/sdaX > sicherung.tune2fs.sdaX
scp sicherung.tune2fs.sdaX root@server:/mnt/backup

Sicherung der Partitionierung

Exakte Vorgehensweise siehe partitionierung, wenn die Wiederherstellung nicht automatisiert erfolgen muß reicht auch die Ausgabe von parted oder df

parted /dev/sda print > sicherung.parted
scp sicherung.parted root@server:/mnt/backup

alternativ

sfdisk -d /dev/sda > sicherung.sfdisk
scp sicherung.sfdisk root@server:/mnt/backup

Sicherung LVM Informationen

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

Löschen des Systems

schnell

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

… und nach ein paar Sekunden ist das System zumindest unbrauchbar.

sicher

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

Wiederherstellung des Systems

Rettungssystem / Knoppix 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

Dateisysteme anlegen

Dateisysteme mit mkfs.ext3 o.ä. gemäß etc/fstab aus dem Backup anlegen 1)

mkfs.ext3 /dev/sdaX

Swap anlegen

2)

mkswap /dev/sdaY

Mounten der Zielpartitionen

Mountpoints mit mkdir anlegen und Dateisysteme mit mount einhängen: 3) 4)

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

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

Wiederherstellen der ACL-Dateirechte

nur nötig, wenn tar das nicht kann

cd /tmp/system
setfacl --restore sicherung.acl

Wiederherstellen der SELinux Attribute

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

cd /tmp/system
setfacl -h --restore sicherung.attr

oder

touch /tmp/system/.autorelabel

Wiederherstellung der Dateisystem-Einstellungen

Mir ist kein automatischer Weg bekannt … daher:

tune2fs .... ( UUID, Dateisystem-Label, Mountoptionen, ... )

Bootloader wiederherstellen

chroot vorbereiten

mount --bind /dev  /tmp/system/dev
mount --bind /proc /tmp/system/proc

5)

Schritte im chroot Zielsystem

chroot /tmp/system

System wieder startfähig machen

grub

Grub in den MBR schreiben:

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

oder mit

grub-install --recheck --no-floppy hd0
grub2
grub-install /dev/sda

Anpassungen bei geänderter Hardware oder geänderten Partitionen

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

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= … )

/etc/fstab

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

Kernel-Module und initrd

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

udev

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

Alternative Sicherungswege

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

Sicherung mit tar über ssh

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

Fedora 7, Centos 5:

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

Dokumentation

Sicherung mit tar über ssh und anschließendem entpacken

cd /pfad/zur/quelle && tar -cpP --atime-preserve -f - . | ssh user@server "( cd /pfad/zum/ziel && tar -xpvP --atime-preserve -f - )"

Sicherung mit cpio über ssh

6)

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

Wiederherstellen mit tar über ssh

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

Wiederherstellen mit cpio über ssh

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

rsync

Auf lokale Platte:

rsync -ax --numeric-ids --delete / /mnt/usbdisk/root/ 

Übers Netz via ssh:

rsync -ax --numeric-ids --delete -e ssh / server:/mnt/usbdisk/root/

Übers Netz via rsyncd: 7)

rsync -ax --numeric-ids --delete / server::/mnt/usbdisk/root/

Problem: udev

Auf modernen Linux-Installationen wird wegen udev das Verzeichnis /dev von einem temporären Dateisystem überdeckt. Linux benötigt diese überdeckten Dateien aber beim Booten.

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 muß 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?!

Dokumentation

Software

1) , 4)
/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
2)
/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
3)
evtl. mount-optionen ( z.B. acl ) beachten
5)
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!
6)
Vermeidet die Probleme von tar und gzip bei Datenfehlern
7)
erfordert laufenden rsyncd auf dem Zielsystem server
admin_grundlagen/systemsicherung.1326991189.txt.gz · Zuletzt geändert: 2012/01/19 16:39 von sven_froebus