Systembackup per tar / dd

[doublem]

Hallo,

ich möchte meinen Rootserver (LAMP) mit dem jeweiligen Installationsstand sichern, um ihn in einem Worst-Case-Senario schnell wiederherstellen zu können.

Da ich keine Remote-Konsole bei dem Provider habe, fällt dass Sichern über dd raus weil ich die Partitionen dafür unmounten müsste, oder?

Geht es nicht auch mit tar?

Code: Select all

tar cvpjf backup.tar.bz2 --exclude=/proc --exclude=/tmp --exclude=/dev --exclude=/lost+found --exclude=/backup.tar.bz2 --exclude=/mnt --exclude=/sys /

Schließlich würde im Falle eines Restore der selbe Rechner mit der gleichen Hardware zum Einsatz kommen, sodaß nur das tar über die frische Installation entpackt werden müsste.

Liege ich da richtig?

Danke.

[daemotron]

Zunächst: Für ein Backup mit dd ist nicht zwingend eine Remote Console von Nöten, ein Rettungssystem tut's in der Regel auch (Hauptsache ein System, das in einer Memory Disk gebootet läuft).

Natürlich lassen sich die benötigten Daten für ein Desaster Recovery auch ohne dd sichern - allerdings gibt es da ein paar Dinge zu beachten:

• Sockets, Named Pipes und PID-Files möchte man nach Möglichkeit vom Backup ausschließen
• Ob man /dev von der Sicherung ausschließen kann, hängt davon ab, ob man udev benutzt oder nicht (ohne udev werden nicht alle device nodes beim Booten automatisch angelegt!)
• Vor einer Systemsicherung mit tar sollten bestimmte Dienste gestoppt werden (insbesondere MySQL, PostgreSQL & Co, aber auch MTA, MDA und MRA - je nach verwendetem Format für die Mailboxen (Cyrus und MBox sind da besonders übel)), da das Backup für deren Datendateien sonst inkonsistent wird

Für ein Desaster Recovery benötigt man aber neben dem Tar-Archiv mit den Dateien auch noch Informationen zur Partitionierung und zum Bootloader. Ersteres lässt sich leicht sichern (vorausgesetzt, man benutzt weder LVM noch mdadm o. ä. - dann muss man doch etwas kreativer werden):

Code: Select all

sfdisk -d /dev/sda > sda.dump

Die Partitionierung von /dev/sda kann jetzt ganz einfach wieder hergestellt werden:

Code: Select all

dd if=/dev/zero of=dev/sda bs=512 count=1
sfdisk /dev/sda < sda.dump

Ob GRUB im MBR installiert ist (bei Linux sollte das standardmäßig so sein), kann man mit notfalls so feststellen:

Code: Select all

dd if=/dev/sda bs=440 count=1 | strings | grep -i grub

Wenn in der letzten ausgegebenen Zeile GRUB steht, ist GRUB auch im MBR installiert. GRUB lässt sich dann mit grub-install wieder im MBR installieren (auch hier wieder vorsicht, wenn ein Software RAID genutzt wird - dann sollte GRUB im MBR beider Platten landen).

Damit lässt sich eigentlich ein kaputt gegangenes System wieder herstellen (Worst Case: Plattentausch). Allerdings ist es manchmal hilfreich, auch Informationen zur Netzwerk-Konfiguration separat gesichert zu haben. Daher lege ich mir immer noch zusätzlich die Ausgabe von ifconfig <Gerät> und einen Dump der Routing-Tabelle (unter Linux mit route -n zu bekommen) ins Backup - man kann ja nie wissen...

[doublem]

Danke Dir für die ausführliche Hilfestellung!

Noch 3 kleine Nachfragen:

Wie kann ich die Sockets und Named Pipes ausschließen?

Nutzt OpenSuse 11.3. standardmäßig udev?

Wäre bei unkomprimierten Systembackups vielleicht rsync die bessere Lösung?

[daemotron]

Wie kann ich die Sockets und Named Pipes ausschließen?

Indem Du die Liste der zu sichernden Files mit find erstellst, z. B.

Code: Select all

tar -cjpvf mein-backup.tar.bz2 `find . -type d -o -type f -o -type l`

Nutzt OpenSuse 11.3. standardmäßig udev?

Code: Select all

ps auxww | grep -i udev
dmesg | grep -i udev

Wäre bei unkomprimierten Systembackups vielleicht rsync die bessere Lösung?

Jaein. Reines rsync ist IMHO für Backups nicht so gut geeignet (keine Historisierung), aber es gibt Backup-Tools, die auf Basis des rsync-Algorithmus inkrementelle Backups machen (z. B. duplicity).

[doublem]

Vielen Dank nochmal!