Zum halben Preis

Wie das Backup aussehen soll, liegt auf der Hand: Klein soll es sein, weil das nicht nur Platz spart, sondern auch Zeit beim Recovery. Leicht handhabbar soll es sein, denn wer es braucht, steht meist ohnehin schon unter Zeitdruck. Ohne Hilfsmittel soll es sich im Idealfall lesen lassen – dann muss man nach einem Desaster nicht erst auch noch die Backupsoftware installieren und konfigurieren, bevor die Rücksicherung starten kann. Schnell soll es sein, damit auch bei größeren Datenmengen das verfügbare Zeitfenster genügt und im Fall der Fälle die Störung nicht länger als nötig dauert.

Doch einen Tod, so scheint es, muss man dafür sterben: Inkrementelle und differenzielle Backups fallen klein und schnell aus, weil sie nur geänderte Files erfassen. Die Wiederherstellung aber erweist sich als kompliziert, denn dafür muss man mehrere Sicherungen in richtiger Reihenfolge einspielen. Andererseits lassen sich Vollbackups einfacher handhaben: Sie enthalten alles Nötige am Stück und bringen es in einer Aktion zurück auf den Rechner – dafür sind sie jedoch groß und langsam. Dieselbe Kalamität entsteht beim Backup-Format: Einfache Kopien kommen ohne weitere Software aus, brauchen aber ebenso so viel Platz wie das Original und transportieren dabei nicht einmal zusätzliche Metadaten (wie etwa eine Kennung des verwendeten Mediums). Platz sparen können dagegen spezielle (nicht selten proprietäre) Backupdateien – aber nur um den Preis des Nachteils, dass man für ihre Wiederherstellung in der Regel zusätzliche Software benötigt.

Vorteile bündeln

Alles Gute scheint nie beisammen, aber eine Technik bringt doch zumindest etliche Vorteile unter einen Hut. Das funktioniert so: Beim ersten Backup handelt es sich um eine normale 1:1-Kopie, also ein Vollbackup. In das zweite Backup kopiert die Sicherungssoftware aber nur noch die Dateien, die sich gegenüber dem ersten Durchgang verändert haben. Für alle Files, die gleich geblieben sind – normalerweise die überwiegende Mehrheit – schreibt das Backup nur einen Hardlink. Das Spiel setzt sich mit jedem weiteren Backup so fort: Solange sich eine Datei nicht ändert, verlinkt die Sicherungssoftware sie lediglich (Abbildung 1).

Abbildung 1: Das Prinzip von Ccollect: Was sich nicht ändert, ist auch nur einmal da. Damit man die Daten trotzdem aus vielen Sicherungen so erreichen kann, als wären sie in jede einzelne kopiert worden, setzt die Software Hardlinks.

Der Vorteil leuchtet sofort ein: Über den Hardlink anstelle der Kopie erreicht man die Daten ebenso direkt und schnell, der Link belegt im Unterschied zur Kopie aber so gut wie keinen Platz. Das zeitaufwendige Vervielfältigen entfällt für die allermeisten Dateien. So kann man es sich ohne weiteres leisten, jede Sicherung als bequem wiederherstellbares Vollbackup anzulegen, das – nach einer einzigen Komplettsicherung – trotzdem nicht mehr Raum belegt und nicht mehr Zeit kostet als ein inkrementelles Backup. Und als Zugabe lassen sich die gesicherten Dateien auch noch ohne gesonderte Software mit Bordmitteln restaurieren.

Das Verfahren birgt jedoch auch einen Nachteil: Kopien erzeugen Redundanz und damit Sicherheit, weil man – wenn auch mit Abstrichen – immer auch noch auf die Vorgängerversion zurückgreifen kann. Hardlinks kennen nur eine Datei – ist die physisch korrumpiert, sind sämtliche Instanzen unbrauchbar. Anders übrigens bei einem logischen Fehler, der sich in eine Version der Datei einschleicht: Er würde das weitere Verlinken unterbrechen und im nächsten Schritt eine echte Kopie erzwingen.

Ein solches System zu programmieren klingt in mancher Hinsicht komplizierter, als es tatsächlich ist. Denn glücklicherweise beherrscht Rsync [1], ein in der ganzen Unix-Welt und in allen Linux-Distributionen verbreitetes Kopierwerkzeug, den Trick mit den Hardlinks von Haus aus. Allerdings fällt es nicht sonderlich intuitiv: rsync -help gibt 144 Zeilen aus, so gut wie jede beschreibt eine andere Option. Wer sich stattdessen ein Konfigurationsfile wünscht, das an zentraler Stelle alle Parameter verwaltet, und ein Tool steuert, das die komplexe Syntax der Kommandozeilenaufrufe vor dem Anwender verbirgt, der wird gleich mehrfach fündig.

Backups mit Ccollect

Ein Beispiel für ein auf Rsync aufbauendes Backup-Utility ist etwa die Perl-Applikation Rsnapshot [2], eine weitere Alternative bietet das Shellskript ccollect[3] von Nico Schottelius, um das es hier gehen soll. Es geht in einigen Punkten über Rsnapshot hinaus, beispielsweise indem es eigene Exclude-Listen pro Quelle verwaltet, auf Wunsch vor- und nachgeschaltete Skripte startet oder Backup-Prozesse parallelisieren kann.

Alle Konfigurationsfiles sammelt Ccollect in einem Verzeichnis. Als Vorgabe dient dazu /etc/ccollect, die Umgebungsvariable $CCOLLECT_CONF kann aber auch einen anderen Ort vorgeben. Dort gibt es ein Unterverzeichnis sources, das wiederum Verzeichnisse für jede Quelle eines Backups beherbergt. In einem solchen Directory finden sich eine Reihe von Files mit sprechenden Namen: destination enthält den Namen des Zielverzeichnisses für das Backup, source eine Aufzählung der Quellverzeichnisse (im einfachsten Fall nur /). Ein Quellverzeichnis darf übrigens niemals ein Softlink sein, damit kann Rsync nicht umgehen – Softlinks enthalten darf es aber schon.

Ccollect sichert nicht nur lokale Filesysteme, sondern auf Wunsch auch die entfernter Rechner, von wo es sich die Daten abholt. Auch Backups auf entfernte Server beherrscht das Tool seit kurzem, doch bringt das ein Sicherheitsrisiko mit sich: Bei der gewählten Architektur wäre dafür eine Schreibberechtigung des zu sichernden Clients auf dem Server nötig. Wer einen Client in seine Gewalt brächte, hätte so zugleich den Backup-Server kompromittiert.

Möchten Sie Verzeichnisse eines Rechners auf eine lokal eingehängte externe Harddisk sichern, dann sollten Sie mindestens den Mountpunkt der Platte ausklammern – sonst läuft sie infolge rekursiver Sicherung garantiert über. Dafür gibt es die Datei exclude, die eine Liste auszuschließender Verzeichnisse und Dateien enthält. Sie gestattet auch die Verwendung der üblichen Shell-Platzhalter, also beispielsweise Ausdrücke wie /proc/* oder *.bak. Die beiden Files pre_exec und post_exec steuern Aktionen vor und nach dem eigentlichen Backup: Auf diesem Weg ließe sich etwa eine Datenbank für die Zeit des Backup stilllegen und anschließend wieder hochfahren.

Die Existenz einer Datei mit dem Namen delete_incomplete weist Ccollect an, unvollständige Backups zu löschen. Ließen Sie ein abgebrochenes Backup nämlich stehen, müsste die nachfolgende Sicherung jedes in ihr fehlende File als neu betrachten und es kopieren statt verlinken. Auch das sprengt schnell die vorausberechneten Kapazitätsreserven. Schließlich bewirkt das leere File summary, dass Ccollect am Ende eine kleine statistische Übersicht produziert.

Neben der Quellenangabe benötigt Ccollect unbedingt eine weitere Konfigurationsoption: das Intervall. Dahinter verbirgt sich ein Label für ein Backup und eine Vorgabe, wie viele Sicherungen mit diesem nämlichen Label insgesamt vorzuhalten sind. Diese Anzahl und auch die Namen der Intervalle definieren Sie selbst, indem Sie in $CCOLLECT_CONF/defaults/intervals beziehungsweise /etc/ccollect/defaults/intervals Dateien mit dem Namen der geplanten Intervalle anlegt. Jede dieser Dateien enthält eine Ziffer, die der Anzahl bewahrenswerter Sicherungen mit dieser Auszeichnung entspricht, also etwa daily, Inhalt: 28, monthly, Inhalt: 12, weekly, Inhalt: 4. So behält man aus jedem Monat ein Backup – aus dem letzten Monat aber jede Tagessicherung plus jeweils eine Wochensicherung.