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 -h

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

mkdir -p /mnt/backup/dateien

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

chown nutzerXX /mnt/backup

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

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

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

¹⁾

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

alternativ mit

vgcfgbackup -f sicherung.vg

lsblk

oder

df -h

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

²⁾

xfs_admin -l /dev/sdaX  > sicherung.xfs_admin.sdaX

³⁾

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

evtl. weitere Verzeichnisse/Partitionen entsprechend der Ausgabe von df bzw. lsblk

⁴⁾

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

^{5) 6) 7)}

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 -a --numeric-ids --del -e ssh --rsync-path="sudo rsync" /mnt/system/ user@zielsystem:/mnt/backup/dateien

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.

die gezeigten Verfahren sind nicht genau

⁸⁾ mkfs.ext3 /dev/sdaX … ==== Swap anlegen ==== ⁹⁾ mkswap /dev/sdaX ==== Mounten der Zielpartitionen ==== Mountpoints mit mkdir anlegen und Dateisysteme mit mount einhängen: ^{10) 11)} 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/dateien/ /tmp/system evtl. ACLs und erweiterte Dateisystemattribute berücksichtigen === Ubuntu === rsync -a –numeric-ids –del -e ssh –rsync-path=„sudo rsync“ user@server:/mnt/backup/dateien/ /tmp/system ==== Wiederherstellen der ACL-Dateirechte ==== nur nötig, wenn 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 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 ==== Wiederherstellung der Dateisystem-Einstellungen ==== Mir ist kein automatischer Weg bekannt … daher: tune2fs …. ( UUID, Dateisystem-Label, Mountoptionen, … ) tune2fs -U xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx /dev/sda5 mkswap -U yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy /dev/sda6 ===== Bootloader wiederherstellen ===== ==== chroot vorbereiten ==== mount –rbind /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 == = Debian 6.0 = grub-install /dev/sda update-grub2 = openSuSE 12.2 = grub2-install /dev/sda update-bootloader –refresh ===== 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 ¹⁴⁾ ==== 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 === * Übersicht tar * 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 -xdev -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 –del / /mnt/usbdisk/root/ Übers Netz via ssh: rsync -ax –numeric-ids –del -e ssh / server:/mnt/backup/dateien Übers Netz via rsyncd: ¹⁶⁾ rsync -ax –numeric-ids –del / server::/backup/dateien/ ===== 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 /dev explizit angeben. Die wichtigsten Gerätedateien sollten auch darin enthalten sein. - 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 ====== * 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