rsync -anv --numeric-ids --del -e ssh /mnt/system/ root@server:/mnt/backup
Dies ist eine alte Version des Dokuments!
Inhaltsverzeichnis
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 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
Sicherung der Dateien 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.
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
Swap anlegen
mkswap /dev/sdaY
Mounten der Zielpartitionen
Mountpoints mit mkdir anlegen und Dateisysteme mit mount einhängen: 4)
5)
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, … )
tune2fs -U 2e92cc4e-e735-4e4f-8a0f-dc3adb42fd67 /dev/sda5
Bootloader wiederherstellen
chroot vorbereiten
mount --bind /dev /tmp/system/dev mount --bind /proc /tmp/system/proc mount --bind /sys /tmp/system/sys
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
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
/etc/mtab
/etc/mtab :
Neue Partitionsnummern, Software-RAID und Logical Volumes beachten
8)
Kernel-Module und initrd
Je nach Änderung muß eine neue initrd erzeugt werden und/oder die bei Booten geladenen Module müssen überarbeitet werden
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
Platzsparende Hardlink Backups mit rsnapshot
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
- man tar
Sicherung mit tar über ssh und anschließendem entpacken
cd /pfad/zur/quelle && tar -cpP --atime-preserve -f - . | ssh user@server "( cd /pfad/zum/ziel && tar -xpvP --atime-preserve -f - )"
Sicherung mit cpio über ssh
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: 10)
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:
- Beim Backup das Verzeichnis
/devexplizit angeben. Die wichtigsten Gerätedateien sollten auch darin enthalten sein. - Auf das Orginalsystem kann man mit
mkdir /tmp/system && mount –bind / /tmp/systemzugreifen. Die Sicherung muß man dann mittar 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
/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/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/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/mtabNach dem chroot nicht vergessen, die
/etc/mtab wiederherzustellen:mv /tmp/system/etc/mtab.bak /tmp/system/etc/mtab
/etc/mtab auch einfach löschen 