Remote-Backups mit rsync und rdist

Wenn klassische Datensicherungsmedien nicht in Frage kommen, jedoch genügend Plattenplatz, ein lokales Netzwerk oder eine gute (und billige) Internetanbindung zur Verfügung stehen, bietet sich ein alternatives Datensicherungsszenario an: das Spiegeln sicherungswürdiger Dateien.

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.

Alles eine Frage des Wie

Was noch fehlt, ist das Wohin auf den Zielrechnern. Dies wird mit dem “Kommando” install angegeben:

install /mnt/backup;

sorgt dafür, dass die jeweiligen Daten unterhalb von /mnt/backup auf dem Zielsystem landen. Wenn nicht vorhanden, legt rdist (genau gesagt der von ihm auf dem Zielrechner aufgerufene rdistd) dieses Verzeichnis auch an. Wichtig dabei ist das Semikolon am “Kommandoende”.

Befehle wie install, die das Verhalten von rdist modifizieren, gibt es einige; wir greifen uns an dieser Stelle noch zwei weitere heraus, die von allgemeinem Backupinteresse sind: except_pat nimmt Dateien und Verzeichnisse von der Sicherung aus, die dem anschließend angegebenen Muster entsprechen.

except_pat tmp;

sorgt dafür, dass tmp-Verzeichnisse, aber auch Dateien wie wtmp oder kapitel1.tmp nicht mit gesichert werden. Mehrere Muster kann man wiederum in runden Klammern angeben, und auch reguläre Ausdrücke lassen sich zu einem gewissen Grad verwenden. So sorgt

except_pat ( \\.tgz\$ [Tt][mM][pP] );

dafür, dass alle Dateien, die auf .tgz enden (\$ steht für das Ende des Dateinamens) und alle Dateien/Verzeichnisse mit tmp in jedweder Gross-Kleinbuchstabenkombination von der Sicherung ausgenommen werden. Da der Punkt nicht als regulärer Ausdruck für ein beliebiges Zeichen, sondern als Punkt gemeint ist, muss ein \ davor, und da auch dieser wieder ein Sonderzeichen ist, wird noch ein Backslash davor gesetzt.

Der Befehl

notify pjung@linux-user.de;

wiederum sorgt dafür, dass pjung@linux-user.de eine Mail erhält, in der rdist über die verrichtete Arbeit berichtet.

Mit all diesen Optionen ausgestattet, sieht das distfile dann z.B. wie in Listing 1 aus. Kommentare werden – wie aus der Shell üblich – mit einem # eingeleitet.

Listing 1

Beispiel für ein rdist-Distfile

privat: ( ~/privat ~/briefe ) -> trish@192.168.1.249
        install /mnt/backup/privat;
         except_pat tmp;
 diplomarbeit: /home/trish/dipl -> lillegroenn.trish.de
         install ~/backup;
         except_pat ( \\.tgz\$ [Tt][mM][pP] );
         notify pjung@linux-user.de;
 # Kopieren der Netscape-Bookmarks an Ort und Stelle
 bookmarks: ~/.netscape/bookmarks.html -> lillegroenn.trish.de
        install ~/.netscape/bookmarks.html;

Zwei Seelen, ach…

Solange man den Backup-Platz in Frieden lässt, ist alles in bester Ordnung. Ab und an kommt es dennoch vor, dass man dort die eine oder andere Datei verändert und nicht möchte, dass das Backup diese Änderungen gnadenlos überschreibt. Um rdist hier ein wenig Rücksicht auf Dateien einzuflößen, die auf dem Zielsystem neuer als auf dem Quellrechner sind, kommt schlicht und einfach noch eine Option -o younger zum rdist-Aufruf hinzu.

Auch eine entgegengesetzte Politik ist möglich: Will man auf dem Backupsystem gnadenlos alles löschen, was auf dem Originalsystem nicht existiert, gibt man die Option -o remove mit auf der Kommandozeile an.

Damit ist die Grenze des Feintunings natürlich noch nicht erreicht. Die rdist-Manpage dürfte bei der Backup-Planung durchaus zur ständigen Begleiterin werden.