Sicherheitsspiegelung

Sie sind die Stars eines jeden großen Rechenzentrums: die Roboter, die die Bandlaufwerke kommerzieller Data-Storage-Anlagen bestücken. Während Speicherplatz dort keine Mangelware ist, bleibt es kleineren Anwendern meist nicht erspart, die Masse zu sichernder Daten zu sondieren und nur von einer Auswahl tatsächlich Kopien anzufertigen.

Ein anderes Prinzip dieser zentralen Datensicherungssysteme kann man sich jedoch ohne Weiteres abschauen: Direkt am Storage-Server hängen vielleicht ein paar dicke Serverrechner. Wenn Arbeitsrechner im Nebenraum, vom anderen Ende des Uni-Campus oder von der Kundenfirma im Stadtzentrum gesichert werden sollen, wandern die sicherungswürdigen Daten über LAN, Dialup- oder Standleitung zum Storage-System.

Datengefährt gesucht

Das Stichwort heißt Remote-Backup, und das lässt sich auch dann durchführen, wenn man über ein kleines LAN oder genügend Platz auf einem anderen Rechner im Internet verfügt. Einzige Bedingung ist, dass auf dem Backuprechner eine Serversoftware läuft, die es erlaubt, sich auch von entfernten Rechnern einzuloggen.

Heutzutage wird das ein SecureShell-Server (sshd) sein. Auf einigen Maschinen findet man auch noch den Remote-Shell-Dämonen rshd, doch da dann die Datenübertragung unverschlüsselt vonstatten geht, sollte man dies nur in einem gut abgesicherten LAN in Betracht ziehen, in dem man allen Teilnehmer(inne)n vertraut.

Zum Spiegeln der Daten, wie man den Vorgang nennt, bei dem von Originaldaten synchrone Kopien auf getrennten Medien abgelegt werden, kommen zwei Programme in Frage: rdist und rsync. Das originale rdist selbst wird nicht mehr aktiv weiter entwickelt; allerdings existieren Projekte wie freerdist (http://freshmeat.net/projects/freerdist/), die zumindest Letzte-Änderungsdaten aus der jüngeren Vergangenheit aufweisen können. An der Funktionalität wird sich so wohl auch in Zukunft nicht viel ändern, was durchaus auch ein Vorteil sein kann.

Bei rsync (http://rsync.samba.org/rsync/) sind die Autoren reger dabei. Dieses Programm hat zudem den Vorteil, dass es bei Dateien, die sich geändert haben, nur die Unterschiede überträgt, während rdist in diesem Fall die komplette Datei neu sendet. Will man das Übertragungsvolumen so gering wie möglich halten, ist das ein wichtiges Entscheidungskriterium.

Ansonsten hängt es eher vom individuellen Geschmack ab, welches Helferlein man wählt. Keines von beiden war bislang ernsthaft das Ziel von GUI-Programmierer/innen, sodass man sich ohnehin mit der zuweilen gewöhnungsbedürftigen Syntax herum schlagen muss.

Da wir rsync mit dem Answer Girl in Heft 04/2001, S. 44ff. einen ausführlichen Artikel gewidmet haben, der auch auf der Heft-CD und im WWW unter http://www.linux-user.de/ausgabe/2001/04/045-answergirl/answergirl.html nachzulesen ist, beschränken wir uns im Folgenden auf das "Konkurrenzprodukt".

Remote distribuiert

Bevor man ans Konfigurieren der Datenspiegelung gehen kann, gilt es zunächst einmal, sicher zu stellen, dass rdist nicht nur auf dem System mit den zu sichernden Daten installiert ist, sondern auch auf dem Zielsystem. Dort muss sich zwar nicht der rdist-Client befinden, doch auf jeden Fall der rdist-Dämon rdistd, denn der wird aufgerufen, wenn es an den Datenabgleich geht.

Liegt rdistd auf dem Zielaccount nicht im Suchpfad, notiert man sich am besten, wo er denn zu finden ist.

Auf dem Rechner mit den zu duplizierenden Daten nimmt man dann auf der Kommandozeile den rdist-Clienten zur Hand. Der will zunächst nur den Pfad zum SecureShell-Clienten ssh wissen und ggf. Namen und Pfad seiner Konfigurationsdatei:

/tmp$ rdist -P `which ssh` -f ~/distfile

Will sich der rdistd auf dem Zielsystem nicht ohne genaue Pfadangabe finden lassen, so kommt noch die Option -p /pfad/zu/backuprechners/rdistd hinzu.

Liegt eine Datei namens distfile oder Distfile im aktuellen Verzeichnis, darf man die -f-Option auch weglassen:

~$ rdist -P /usr/bin/ssh

Diese Datei hat es jedoch in sich, denn sie enthält alle Angaben darüber, was wie wohin dupliziert werden soll. Dabei sind mehrere Einträge möglich, sodass man unterschiedliche Kopierregeln für verschiedene Verzeichnisse angeben kann: Wer will, kann so die Daten der Diplomarbeit auf einem Uni-Account backupen, während die Liebesbriefe doch lieber auf dem Zweitrechner im heimischen LAN gesichert werden sollen.

Jeder Eintrag beginnt zunächst mit einer Bezeichnung für die folgende Regel und einem Doppelpunkt. Erstere kann beliebig gewählt werden, darf aber nur ein Wort ohne Leerzeichen sein. Anschließend folgt die Angabe, was kopiert werden soll. Das können Verzeichnisse oder auch einzelne Dateien sein. Handelt es sich um mehrere, durch Leerzeichen getrennte Angaben, müssen alle gemeinsam von einem runden Klammerpaar eingeschlossen werden.

Anschließend folgt ein stilisierter Pfeil, ->, der auf die Adresse des Zielrechners zeigt. Hat man auf dem anderen System einen anderen Usernamen, schreibt man den wie bei einer Mailadresse davor. In dem Fall trennt ein @ User- und Hostnamen voneinander.

Somit besagt ein distfile folgenden Inhalts …

privat: ( ~/.netscape/bookmarks.html \
           ~/privat \
           ~/briefe ) -> trish@192.168.1.249
 diplomarbeit: /home/trish/dipl -> lillegroenn.trish.de

…, dass die Verzeichnisse ~/privat und ~/briefe samt den Netscape-Bookmarks auf dem Account von trish auf dem Rechner mit der IP-Adresse 192.168.1.249 landen sollen, während das Verzeichnis /home/trish/dipl mit allen Unterverzeichnissen auf den Rechner lillegroenn.trish.de geschaufelt werden soll.