Desaster Recovery - Software RAID1 - Bootsektor

[spektor]

Mein alter 1&1 Root Server ist gut ohne RAID ausgekommen. Für den Fall eines Desasters (Plattencrash, Hacker) habe ich die wichtigsten Dateisysteme via dd gesichert. Den Rest konventionell über tar. Dazu bootet man praktischer Weise das "Rescue System" und kann dort ungestört die Platten im ungemounteten Zustand über dd in eine Datei sichern und bei Bedarf wieder zurücksichern. Diese Datei kann man genialerweise auch über das Loopback-Device mounten, was sich in den letzten Jahren als sehr praktisch erwiesen hat.

Der neue 1&1 Root Server hat per default Softwareraid (mdadm) aktiviert. Das Sichern über dd funktioniert auch dort wie gewohnt, nur das hier /dev/mdx gesichert werden muß. Leider gibt es nach einer Rücksicherung Probleme beim booten. Die Dateisysteme an sich sind konsitent. Nur der Bootblock fehlt wohl? :roll: Natürlich habe ich bereits alle möglichen Konfigurationsvarianten in der lilo.conf und in der fstab versucht.

Über google findet man Anleitungen, die nach der Wiederherstellung ein

lilo -M /dev/sda
lilo -b /dev/sda

empfehlen. Ein

lilo -b /dev/sda

streikt bei mir mit der Fehlermeldung

"Fatal: Sorry, don't know how to handle device 0x0100"

Wie gesagt, mdadm und das Software-RAID an sich funktionieren einwandfrei. Im "Rescue System" kann ich die Dateisysteme problemlos mounten. Nur das Booten funktionier nicht. :( Ich möchte wie gewohnt /root, /var und /usr über dd sichern und nach einem Plattencrash oder einem unerwarteten Besuch auf meinem Server eine definierten Systemstand wiederherstellen.

Sollte ich von lilo auf grub umstellen?

[danu]

habe ich die wichtigsten Dateisysteme via dd gesichert

Es geht hier um Daten die zu sichern sind?

Dazu bootet man praktischer Weise das "Rescue System

wohl kaum #-o

[spektor]

habe ich die wichtigsten Dateisysteme via dd gesichert

Es geht hier um Daten die zu sichern sind?

Es geht darum, nach einem Plattencrash oder einem Hackerangriff die Serverkonfiguration in kürzester Zeit wieder herzustellen. Der Plattencrash bis bei RAID 1 nicht so kritisch, aber wenn die erste HD (Bootplatte) ausfällt, nützt einem RAID 1 auch nicht mehr. Spätestens nach einem Reboot. Bei kommerziellen UNIXen kein Problem. Aber bei einem Root-server bei einem Massenhoster schon.

Dazu bootet man praktischer Weise das "Rescue System

wohl kaum #-o

Wenn ich mir ein Rootkit oder ähnliches eingefangen habe, halte ich es für sinnvoll, ein sicheres System zu booten und einen definierten konsistente Systemkonfiguration einfach wieder herzustellen zu können. Und eventuell vorher die Dateisysteme für eine forensische Untersuchung zu sichern.

[daemotron]

Nur um ganz sicher zu gehen - Du verwendest lilo und nicht grub? (letzters ist bei den 1&1-Images schon länger default...)

Bei Grub sähe das ganze so aus:

Code: Select all

grub --no-floppy
> root (hd0,0)
> setup (hd0)
> device (hd0) /dev/sdb
> root (hd0,0)
> setup (hd0)
> quit

Device-Angabe ggf. anpassen, hier muss die zweite Platte angegeben werden!

[daemotron]

Das Sichern über dd funktioniert auch dort wie gewohnt, nur das hier /dev/mdx gesichert werden muß.

Ungut, das... dd ist dafür gedacht, Rohdaten von einem Device abzuziehen. Ein Software-RAID-Device setzt eine logische Schicht zwischen physischem Device und Daten voraus - in einem dd-Image von einem md-Device fehlen also die Meta-Informationen, die zwischen physischem und logischem Device liegen.

Wenn Du unbedingt per dd Images ziehen willst, dann sichere entweder die beiden Disks komplett (/dev/sda und /dev/sdb) oder wenigstens die Partitionen, nicht aber die md-Devices... Eleganter für ein Full-Backup gerade bei Einsatz von Software-RAID und/oder Logical Volume Mapper ist ein Backup über tar-Archive (siehe http://www.rootforum.org/wiki/howto/all ... ckup/basis)

[spektor]

Das Sichern über dd funktioniert auch dort wie gewohnt, nur das hier /dev/mdx gesichert werden muß.

Ungut, das... dd ist dafür gedacht, Rohdaten von einem Device abzuziehen. Ein Software-RAID-Device setzt eine logische Schicht zwischen physischem Device und Daten voraus - in einem dd-Image von einem md-Device fehlen also die Meta-Informationen, die zwischen physischem und logischem Device liegen.

Also bevor ich auf meinen neuen Server umgestiegen bin, habe ich einige Backup/Restore-Tests gemachet. Wenn man den Bootsektor b.z.w. die Partitionskonfiguration sichert, funktioniert das Restore auch mit der dd-Sicherung der logischen /dev/mdx RAID devices.

Partitionskonfiguration sichern

Code: Select all

# sfdisk -d /dev/sda > /root/backup/sda-0.sfdisk
# sfdisk -d /dev/sdb > /root/backup/sdb-0.sfdisk

Bootsektor im MBR sichern

Code: Select all

# dd if=/dev/sda bs=512 count=1 of=/root/backup/sda_mbr-0.dd
# dd if=/dev/sdb bs=512 count=1 of=/root/backup/sdb_mbr-0.dd

System Partitionen sichern

Code: Select all

# dd if=/dev/md1 of=/root/backup/root-10.dd
# dd if=/dev/md3 of=/root/backup/boot-10.dd
# dd if=/dev/md5 of=/root/backup/usr-10.dd
# dd if=/dev/md6 of=/root/backup/var-10.dd

Natürlich muß man beim Restore so einiges beachten. Für den Test hatte ich die Partitionen gelöscht und die Platte mit

dd if=/dev/zero of=/dev/xxx

gelöscht. Das Desaster Recovery funktionierte.

Wenn Du unbedingt per dd Images ziehen willst,

Nicht unbedingt. Bei dd bin ich mir bloß sicher, dass "alles dabei" ist. Und einen Vorteil hat die dd-Variante auch noch. Man kann die dd-Dateien elegant via loopback Device mounten.