sfdisk -d /dev/sda > sicherung.sfdisk scp sicherung.sfdisk root@server:/mnt/backup
Dies ist eine alte Version des Dokuments!
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
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
8)
mkfs.ext3 /dev/sdaX
…
==== Swap anlegen ====
9)
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 ====
12)
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
13)
==== 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
14)
==== 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 ====
15)
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: 16)
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
sfdisk -d /dev/sda > sicherung.sfdisk scp sicherung.sfdisk root@server:/mnt/backup
/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 ähnlichrsync
die Option -x
bzw. –one-file-system
nutzen und die entsprechenden Mountpoints einzeln angeben rsync -anv --numeric-ids --del -e ssh /mnt/system/ root@server:/mnt/backup/dateien
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 ) ====
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 ===
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 ( 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
==== Dateisysteme anlegen====
Dateisysteme mit mkfs.ext3
o.ä. gemäß etc/fstab
aus dem Backup anlegen
((/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/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 ähnlichmount –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/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