Erschienen im Linux-Magazin 04/2002

Server schnell und kostengünstig spiegeln Server-Spiegelei Conny Dittmann

Was tun beim Totalausfall eines Servers? Ein Backup-Server, der die Daten vorhält, ist gut. Besser ist es, wenn er im Notfall alle netzrelevanten Dienste übernimmt. Mit Rsync und der richtigen Strategie ist schnell eine Lösung gezaubert.

Wir alle kennen das alte Lied der Datensicherung und wie wichtig das alles eigentlich ist. Beim Kunden mögen wir das unbeliebte Thema mit einiger Berechtigung auf die dortigen Systemadministratoren abwälzen, aber die gibt es oftmals nicht. Doch was ist mit dem eigenen Datenbestand? Wie schützt man die Daten vor dem eigenen Chef?

Einfache Lösungen sind Bandlaufwerke und CD-Brenner. Bandwechsler haben nur dann Sinn, wenn sie alle Daten aufnehmen können (Komplettsicherung). Ein Backup auf CD erfordert einen CD-Brenner. An Automatisierung ist in diesem Fall ohnehin nicht zu denken, da man ständig Diskjockey spielen muss.

Bandlaufwerke brauchen viel Zeit

Die heutigen Datenmengen machen also den schnellen Umgang mit den Sicherungsmedien viel zu langwierig. Ein Produktivsystem einzig aus Datensicherungsbeständen wiederherstellen ist äußerst zeitraubend, wie jeder weiß, der das schon tun musste.

Bei einem kompletten Ausfall der Plattensysteme ist das erneute Hochfahren der Hardware mit gut einem Arbeitstag zu veranschlagen. Eine rudimentäre OS-Installation und das Zurückspielen der Daten von Band beanspruchen Zeit und Nerven, selbstredend sind immer diverse Kleinigkeiten von Hand nachzubearbeiten. Alles in allem: ein Ausfall von mindestens einem Arbeitstag á zwölf Stunden - eher mehr.

Mit einer - wenn es ganz sicher sein soll, auch zusätzlichen - Sicherung auf Festplatte geht es schneller. Eine zweite Platte im gleichen Rechner schützt dann zwar vor vielen Fällen menschlichen Versagens oder einem Plattencrash, aber nicht vor einem ausgefallenen Netzteil.

Fast schon perfekte Lösung

Als Königsweg zum schnellen Wiederherstellen gilt gemeinhin: einen Backup-Server einrichten, der alle bewahrenswerten Daten in Zweitausfertigung vorhält. Mit Rsync und etwas Überlegung ist aber weit mehr möglich. Mit diesem Tool können wir wie im Folgenden beschrieben eine funktionsfähige Kopie unseres eigentlichen Servers einrichten (DNS, NIS, NFS, SMB).

Für Firmen, die keine 100-Prozent-Verfügbarkeit benötigen, ist dies ein effizienter und kostengünstiger Weg zu einem ordentlichen Notfallsystem. Es ist schon in einem kleinen Netz mit 10 MBit und einem Rechner mit genügend Plattenplatz praktikabel einzusetzen. Hinzu kommt, dass in verschiedenen Partitionen mehrere Server des Netzwerks gespiegelt werden können.

Eine Rotation oder Generationssicherung - wie mit Bandlaufwerken üblich - scheitert auf Festplatte meist, weil dazu oft der Platz fehlt. Das Interessante an einer Sicherung auf Platte ist hingegen die Geschwindigkeit der Datensicherung sowie die Einfachheit des Zurücksicherns von einzelnen Dateien.

Komplett oder inkrementell?

Da sich viele Daten auf der Platte überhaupt nicht mehr verändern, ist es nicht wirklich sinnvoll, etwa die Geschäftsvorfälle von 1995 oder Download-Verzeichnisse mit Treibern und Updates jedes Mal mit in die Datensicherung einzubeziehen. Wer seine Dateien in verschiedenen Bearbeitungsversionen parat haben will, löst dieses Problem allerdings nicht über ein inkrementelles Backup, sondern besser über eine Versionskontrollsoftware wie CVS.

Konkreter Anlass für die hier beschriebene Lösung war die Einrichtung des RAID-Controllers in einem laufenden Produktivsystem, die eine möglichst kurze Downtime verursachen sollte. Die Erfahrung lehrt, dass bei derlei Systemarbeiten immer etwas passieren kann. Bei auftretenden Problemen am Produktivsystem geht in der Firma nichts mehr. Rumstehende Kollegen, wegen der Lohnkosten tobende Chefs und unglückliche Kunden, die nicht supportet werden können, kosten Geld oder zumindest den guten Ruf.

Auszug aus >>lilo.conf<<:

01 #
02 image = /boot/vmlinuz
03   root = /dev/hda6
04   label = NIVRAM
05
06 #
07 image = /boot/vmlinuz
08   root = /dev/hda7
09   label = MARVIN-Ersatz
10
11 #
12 image = /boot/vmlinuz
13   root = /dev/hda8
14   label = ARTHUR-Ersatz
15 #
16 image = /boot/vmlinuz
17   root = /dev/hdc2
18   label = ZAPHOD-Ersatz

Neue Hardware droht - besser vorsorgen

Gesucht war also ein einfacher Weg, um möglichst ohne große Zusatzkosten genau dieses Problem zu lösen - und mit etwas Glück ein paar weitere auch noch, die irgendwann in der Zukunft lauern. Perfektion war nicht angestrebt, dafür Schnelligkeit und Kostendämpfung. Was muss eine solche Lösung im Einzelnen alles können?

• Sowohl Komplettsicherung als auch inkrementelle Sicherung
• Berücksichtigung der Timestamps und der Rechtestruktur
• Verschlüsselte Übertragung (zwingend)
• Komprimierte Übertragung (schön zu haben)
• Muss im Batchbetrieb laufen können (Cronjob)

Da Marvin unser zentraler Server ist, bot sich als Spiegel-Server-Name Nivram an. Der Rechner dazu war im Netz bereits vorhanden, versah aber keine wirklich wichtigen Aufgaben, lediglich das Modem wird für einige wenige Kunden von ihm bedient.

Es werden alle Konfigurationen der auf Marvin laufenden Netzwerkdienste so übernommen, dass sie nach einem Reboot aktiv sind. Bei den ersten Tests merkte keiner der Entwickler, dass er auf dem Notfall-Marvin arbeitete, noch nicht mal die Geschäftsleitung bekam etwas mit. Der neue Spiegel-Server bediente sofort alle im Netz relevanten Dienste. Dabei bootet Nivram seine eigene Installation und fährt die für den Marvin-Ersatz nötigen Dienste hoch.

Spezielle Backup-Lösungen kranken immer daran, dass die damit erstellten Bänder nur mit genau dieser Software zu lesen sind. In den meisten Fällen steht jedoch diese Software nach einem Datencrash nicht zur Verfügung. Da loben wir uns die altbekannten Tools wie »tar«, »dd«, »cpio« oder »vi«, die immer auf jedem Unix verfügbar sind. Wird von Diskette gebooteten, ist mit diesen bewährten Tools ein System wieder ins Leben zurückzuholen.

Eines dieser kleinen feinen Werkzeuge ist Rsync, entwickelt unter anderem von Paul Mackeras und Andrew Tridgell aus dem Samba-Team[1]. Alle anderen Dienste haben im Vergleich dazu enorme Nachteile. Mit FTP überträgt man Passwort und Daten im Klartext übers Netz, zudem sind FTP-Client-Programme selten in der Lage, die Zeitstempel zu beachten oder inkrementell nur die aktuell geänderten Daten zu übertragen. Vom automatischen Löschen im Zielverzeichnis vorhandener Dateien, die aber auf den Quellverzeichnissen nicht mehr vorhanden sind, ganz zu schweigen.

Klein, stark, schnell und sicher - einfach Rsync

Das Secure-Copy-Programm »scp« verschlüsselt zwar Daten und Passwörter, ist aber für einen Datenabgleich ebenfalls nicht zu gebrauchen, das unverschlüsselte Pendant dazu - »rcp« - sollte schon gar nicht in die engere Wahl gezogen werden. Rsync hingegen beherrscht den verschlüsselten Datenabgleich über Ssh und erfüllt all unsere Wünsche hinsichtlich inkrementeller Datensicherung und anderer Kleinigkeiten. Voraussetzungen für unseren Spiegel-Server sind also ein installiertes Ssh und Rsync. Mit Rsync ist Folgendes möglich:

• Sicherung eines Verzeichnisses in ein anderes
• Sicherung eines Verzeichnisses auf einen anderen lokalen Rechner
• Remote Sicherung auf ein mehrere hundert Kilometer entferntes System
• Remote Sicherung getunnelt durchs Internet
• Komplettsicherung eines Servers auf einen anderen (im Folgenden beschrieben)
• Komprimierte Datenübertragung
• Verschlüsselte Datenübertragung

Am einfachsten erschien es unter den gegebenen Bedingungen, die Daten erst komplett und dann inkrementell auf dem Backup-Server zu sichern und diesen bei Bedarf als zu simulierenden Server via Lilo zu rebooten.

Das ist sicherlich keine so ganz der reinen Lehre entsprechende Lösung, sie führt aber schnell und problemlos wieder zu einer arbeitsfähigen Umgebung. Vor allem kann so ein kleiner Reboot auch dann durchgeführt werden, wenn der - möglicherweise einzige - Admin gerade nicht verfügbar ist.

Gehversuche im lokalen Sandkasten

Rsync kennt eine Unzahl von Schaltern, ein Blick in die Man-Pages ist deshalb unverzichtbar. Wichtige Schalter sind:

• »a«, »--archive«
• »v«, »--verbose«
• »r«, »--recursiv«
• »R«, »--relative«
• »--exclude aardvark-folder«
• »--delete« löscht auf dem Zielsystem Dateien, die auf dem Quellsystem nicht mehr existent sind.

Der einfachste Fall: Das Verzeichnis »~/nase« soll als Backup auf eine andere, unter »/mnt/backup« gemountete Partition kopiert werden.

$ rsync -av --delete --exclude
  "geheim.txt"  nase /mnt/backup

Mit dem Exclude-Flag ist es möglich Rsync mitzuteilen, dass es auf alle Dateien verzichten soll, die wie hier im Beispiel »geheim.txt« heißen. Das Flag ist jedoch auch auf Muster anwendbar, die weitgehend denen der Shell entsprechen, und kann die Informationen über auszuschließende Dateien auch aus einem File beziehen. Doch jetzt sind wir vorsichtiger und machen zunächst einen Trockentest mit dem Schalter »-n« (Dry-run, also nicht wirklich ausführen):

$ rsync -rn nase /mnt/backup

Jetzt wird's ernst

Wenn wir uns auf das lokale Spiegeln von Daten beschränken könnten, wären wir hier schon fertig, doch das Ziel ist eine Sicherung auf einem anderen Rechnersystem. Wenn sich die User-Namen auf Quell- und Zielrechner unterscheiden, ist Letzterer mit einem nachstehenden »@« vor der Adresse des Remoterechners anzugeben. Zum Abschluss muss noch ein Doppelpunkt gesetzt werden, hinter dem das Zielverzeichnis stehen kann - oder auch nichts, wenn wir mit dem entfernten Homeverzeichnis zufrieden sind.

Das sind wir jedoch nicht, da ein eigener Mountpoint für die Sicherung benutzt werden muss, um das gespiegelte Verzeichnissystem später zu mounten. Versuchen wir es einfach:

$ rsync -av --delete nase
  conny@backup.linux-server.de:~/backup

Da auf dem entfernten Rechner aus Sicherheitsgründen hoffentlich keine »r«-Dienste mehr laufen, sondern lediglich ein »sshd«, sollte es dabei eine Fehlermeldung geben.

Um Rsync zum Übertragen via Secure Shell zu bewegen, gibt es die Optionen »-e« (execute) oder »--rsh« (Ersatz für »rsh«). Die erste will das »ssh«-Kommando nach einem Leerzeichen, die letzte nach einem Gleichheitszeichen sehen (»--rsh=ssh«):

$ rsync -av --delete -e ssh
  nase conny@backup.linux-server.de:

Eine wirklich praktische Sache ist das komprimierte Übertragen von Dateien mit der Option »-z«. Das spielt nun, da unsere Daten übers Netz gehen, durchaus eine Rolle:

$ rsync -avz --delete -e ssh nase
  conny@backup.linux-server.de:~/backup
conny@backup.linux-server.de's password:
Passwort
building file list ... done
      

Nun zur wirklichen Welt: Marvin ist der zu sichernde Server. Alles außer »/proc«, »/lost+found«, »/mnt/cdrom« sowie allen externen Mountpoints ist zu sichern. Nivram nimmt die Daten von Marvin in eine große Partition auf, die mit ihrer Nettokapazität über der von Marvins Gesamtbedarf liegt.

Auf Nivram werden zwei (oder mehr) Linux-Installationen eingerichtet: die von Nivram (»hda6 /« und »hda1 /boot«) selber und die Marvin-Notfall-Umgebung (»hda7 /marvin/root« und »hda2 /marvin/boot«). Nach der Installation wird Marvin mit Rsync komplett auf Nivram gespiegelt. Beim ersten Mal kann das abhängig von Datenmenge und Netzlast einige Stunden dauern. Nun lassen sich verschiedene Verhaltensweisen einstellen:

• Auf dem Quellsystem gelöschte Dateien auch auf Zielsystem löschen
• Auf dem Quellsystem veränderte Dateien auf dem Zielsystem in nur einer Generation vorhalten. »Dateiname .doc« wird zu »Dateiname.doc~« (das ist natürlich keine wirkliche Versionsverwaltung)
• Gelöschte Dateien und Verzeichnisse auf dem Zielsystem erhalten

Der letzte Punkt ist eine ganz persönliche Entscheidung, da ich hier etwas paranoid bin: Lieber ein lebender Feigling als ein toter Held. Mit »find / -name '*~' -exec 'rm ' {} '; '« wird man den »~«-Alptraum los.

Der folgende Befehl sichert dann Marvins Daten:

$rsync -e ssh -abRvz --exclude "/cdrom" U
--exclude "/lost+found"  --exclude "/proc" /U root@nivram.magrathea.de:/marvin/root/rsync

Auf Nivram sind einige symbolische Links anzulegen, damit der Notfall-Marvin mit den Konfigurationsdateien des echten Marvin beim Booten bedient wird. Wie die Links aussehen müssen, ist genau zu überlegen, da sie ja nicht von Nivram, sondern vom gespielten Marvin benutzt werden. Hier kommen relative Links unterhalb von »/marvin /root« zum Einsatz, da dieser Pfad einen anderen Mountpoint bekommt (nämlich »/« ), wenn vom Notfall-System gebootet wird (siehe Abbildung 1). An dieser Stelle muss aber jeder für sich noch mal genau überlegen, wie sich die Systeme zu verhalten haben. Im Kasten "Symlinks für Dienste" sind die Links für diesen speziellen Fall zu finden.

Bereits der erste Test, Marvin abzuschalten und den frisch gespiegelten Nivram als Marvin-Notfall zu booten, funktionierte auf Anhieb und ohne Probleme. Sollten einzelne Dateien von Nivram zurück zu Marvin kopiert werden, geht das am einfachsten mit FTP oder Samba. Für die komplette Rücksicherung vom Notfall-Marvin kommt natürlich wieder Rsync zum Einsatz.

Abbildung 1: So sieht die Konfiguration des Spiegel-Servers für mehrere Netz-Server im Einzelnen aus. Jeder zu sichernde Rechner kommt dabei in eine gesonderte Partition.

Mach es rund mit einem Skript

Leider ist Rsyncs Rattenschwanz an Schaltern und Optionen viel zu anfällig für Vertipper, richtig rund wird es also erst mit einem kleinen Skript, das vom Cron-Dienst gesteuert automatisch die Datensicherung ausführt. Damit ist auch eine Failover-Lösung mit ganz geringem Aufwand möglich: Nivram testet die Lebenszeichen von Marvin und anderer Server via Cronjob und bei diagnostiziertem Exitus erfolgt automatisch der Versand von Mail/SMS an den Admin. Nivram führt ein »lilo -D gestorbener Server« aus und veranlasst anschließend ein Reboot, um die Identität des Verblichenen zu übernehmen. Je nach Einstellung kann das System binnen zehn Minuten wieder online sein.

Externe Datenlagerung und weitere Möglichkeiten

Da das so wunderbar klappte und das inkrementelle Sichern sich als durchweg sehr schnell herausstellte, wurden die Tests erweitert. Die Zentrale in Hannover und das Büro in Prerow sind 400 Kilometer voneinander entfernt. Der für diesen Test vorbereitet Rechner wurde zuvor in der Zentrale gespiegelt, so dass nur noch inkrementell über ISDN gesichert werden musste.

Das Risiko eines Daten-GAUs - etwa durch Brand oder Diebstahl - wird durch eine entfernte Sicherung enorm verringert. Selbstredend ist diese Funktionalität ebenfalls auf dem Weg übers Internet nutzbar. Auch die Kosten liegen in vertretbaren Grenzen. Die Geschwindigkeit hängt von der Anzahl der gebündelten ISDN-Leitungen ab.

Diese Lösung hat den großen Vorteil, dass sie genug Raum für weitere Optimierungen lässt. Ein wirkliches Failover wäre beispielsweise zu erreichen, wenn Nivram ohne Reboot einfach die Dienste des ausgefallenen Servers übernimmt. Eine andere sinnvolle Möglichkeit wäre es, einzelnen Nutzern per Samba den Zugriff auf ihre Backup-Dateien zu erlauben. (uwo)

Copyright © 2002 Linux New Media AG

Copyright © 2002 Linux New Media AG

Dieser Online-Artikel kann Links enthalten, die auf nicht mehr vorhandene Seiten verweisen. Wir ändern solche "broken links" nur in wenigen Ausnahmefällen. Der Online-Artikel soll möglichst unverändert der gedruckten Fassung entsprechen.