Warum das Kopieren von Backups kein Ersatz für die Replikation ist

Wir werden die Diskussion durch ein Beispiel etwas weniger abstrakt machen. Eine typische Backup-Strategie ist, dass Du Deine Backups jeden Tag in das Master-Backup laufen lässt (eventuell automatisch mit cron) und diese Daten periodisch außerhalb des Gebäudes (oder zumindest auf ein anderes physisches Gerät) überträgst. Lass uns zur Veranschaulichung annehmen, dass Du eine separate Festplatte außer Haus lagerst und sie wöchentlich aktualisierst.³⁵ Einmal in der Woche fügst Du die neuen Backups im Master-Backup zu den Kopien auf der externen (außerhäusigen) Platte hinzu, die Du dazu temporär holst und mit Deinem Rechner verbindest.

Das neue Backup einfach mit „cp -a`` zu kopieren ist eine schlechte Idee, weil die neu kopierten Verzeichnisse (Backups) nicht mit den auf der externen Platte befindlichen verlinkt würden.³⁶ Du kannst linkToDirs.pl verwenden, um die neuen Backups im Master-Backup mit den vorhandenen in der Backup-Kopie zu verlinken (und zu kopieren). Das Tool linkToDirs.pl ist praktisch für ad hoc Replikationen, aber nicht das beste für geplante und automatisierte.

Eine andere übliche Methode, die neuen Backups zu kopieren, ist, ein Synchronisationstool wie rsync zu verwenden. Dabei ergeben sich zwei Probleme: Erstens dauert es sehr lange, wenn Du viele Backups in Deinem Master-Backup hast und zweitens synchronisiert Du jeden Fehler im Master-Backup mit, und das ist bestimmt nicht das, was Du willst. Stell Dir vor, die Platte für den Master-Backup bekommt irgendwann einen Blockfehler in einer Datei aus einem Backup von vor einem Monat. Wenn Du nun mit z.B. rsync synchronisierst, wirst Du die defekte Datei kopieren. Im schlimmsten aller Fälle könntest Du Dir das ganze Backup zerstören (ohne zusätzliche Sicherheit zu bekommen). Wenn du die Replikation von storeBackup verwendest, haben alte Dateien nichts mit der Replikation zu tun.
ABER HALT: Was, wenn die neu kopierten Daten defekt sind, weil einige Sektoren auf der Platte reproduzierbar kaputt sind oder defekter RAM (oder etwas anderes) dazu führt, dass die Daten schon im Master-Backup defekt ankommen? Wirst Du je merken, dass (Teile von) Deinen Daten im Backup defekt sind? Das Backup Programm storeBackup.pl wird Dir dasselbe mitteilen wie rsync - nämlich nichts, weil das nicht unter ihrer Kontrolle ist. Aus diesem Grund solltest Du storeBackupCheckBackup.pl, das die Prüfsummen für alle Dateien nachrechnet, regelmäßig verwenden. Durch das Kontrollieren mit diesem Programm kannst Du Fehler in alten Backups erkennen, die Du manuell korrigieren kannst. Und Du kannst frühzeitig feststellen, ob neue Backups defekt sind. Daher empfehlen wir, storeBackupCheckBackup.pl bei neuen Backups wöchentlich und bei älteren alle paar Monate laufen zu lassen (was sehr lange dauern kann).

Wenn Du Fehler auf einer Platte entdeckst, solltest Du Dir das Problem genauer ansehen und nicht zögern, die Platte auszutauschen.

Die der Replikation von storeBackup zugrunde liegende Idee ist, die oben beschriebenen Punkte anzugehen. Eine Replikation bedeutet, dass wir denselben Zustand in zwei Lokationen haben wollen (z.B. im Master-Backup und in der Backup-Kopie). Das ist das, was wir in dem Beispiel oben mit dem Kommando cp -a getan haben. Nehmen wir an, das war das Kommando vom Montag. Nach einem Tag haben wir im Master-Backup eine Änderung (das neue Backup vom Dienstag). Für die Replikation benötigen wir nur die Unterschiede zwischen dem Backup vom Montag und dem vom Dienstag. Wenn wir einen cleveren Algorithmus hätten, der diese Unterschiede feststellt, könnten wir sie zur externen Platte transportieren und dort so ein neues Vollbackup (mit allen Links, Berechtigungen usw.) erstellen. Als Ergebnis enthielte das Master-Backup auf der externen Platte genau dieselben Daten wie das Master-Backup.

Wenn wir die externe Platte einmal pro Woche anschließen³⁷ benötigen wir einen Platz, um die Unterschiede zu den vorherigen Sicherungen zu speichern. Wir bekommen diese Deltas von Montag auf Dienstag, Dienstag auf Mittwoch usw. Wir erzeugen dann die Vollbackups auf der externen Platte mit der Backup-Kopie, z.B.:

• Backup von Dienstag $\longrightarrow$ erzeugt vom Vollbackup von Montag plus (Deltas vom Montag auf Dienstag)
• Backup von Mittwoch $\longrightarrow$ erzeugt vom Vollbackup von Dienstag plus (Deltas vom Dienstag auf Mittwoch)
• Backup von Donnerstag $\longrightarrow$ erzeugt vom Vollbackup von Mittwoch plus (Deltas vom Mittwoch auf Donnerstag)
• ...

Das bedeutet, dass wir die Deltas zwischen zwei aufeinander folgenden Backups im Master-Backup benötigen. Im Prinzip gibt es zwei Wege, diese zu ermitteln:

1. Berechnung der Unterschiede, also so etwas wie eine „inverse Deduplikation`` (storeBackup sucht nach Dateien (oder Teilen davon) mit identischem Inhalt und verhardlinkt diese).
2. Identifikation der Unterschiede direkt da, wo das Backup erzeugt wird. An dieser Stelle werden die Unterschiede ermittelt und sind bekannt.

Der zweite Weg ist der für Replikationen typischerweise verwendete, z.B. bei Replikationen von Datenbanken oder LDAP. StoreBackup verwendet ebenfalls diesen Weg um Replikationen zu erzeugen.

StoreBackup generiert Deltas zu (einem oder mehreren) existierenden Backups mit der Option lateLinks und speichert sie in einem „Delta Cache``.³⁸ (siehe Kapitel 7.6 für weiterführende Informationen dazu, wie lateLinks zu konfigurieren ist).

Die Replikations-Funktionalität von storeBackup bietet die folgenden Features:

• Die Replikation von Backups baut auf storeBackups existierender Möglichkeit auf, die Deltas zu vorherigen Backups plus die notwendigen Information für ein Vollbackup zu generieren.
• Du kannst konfigurieren, welche Serien repliziert werden sollen. Im Master-Backup muss die Anzahl der durch Replikation zu erzeugenden Kopien nicht bekannt sein. Dies ermöglicht die Entkopplung von Quelle (Master-Backup) und Ziel (Backup-Kopie).
• Die Replikation von Backups kann vollständig automatisiert werden. In Kombination mit einigen Konfigurationsdateien, die für die Replikation benötigt werden, kannst Du einfach cron (oder ähnliches) verwenden, um storeBackupUpdateBackup.pl laufen zu lassen. Du kannst auch storeBackupDel.pl verwenden, um (sehr) alte Backups in der Replikation automatisch zu löschen.
• Speichermedien mit Replikationen müssen nicht ständig angeschlossen sein. Du kannst entscheiden, ob eine oder mehrere der Replikationen permanent oder nicht permanent (so dass manueller Eingriff notwendig ist) erreichbar sind. Dies kann vom Ort abhängen, an den Du replizierst (extern über WAN oder über LAN) sowie von Deiner Backup-Strategie.
• Aus Sicherheitsgründen ist es möglich, die Replikation so aufzusetzen, dass das Master-Backup nicht direkt von den Kopien erreichbar ist (und umgekehrt).
• Die Replikation erfolgt asynchron. Das bedeutet, Du kannst Deine disk1 für Backup-Kopie Nummer 1 an geraden Wochenenden und Backup-Kopie Nummer 2 auf disk2 an ungeraden Wochenenden anschließen. Aber das Resultat sind dieselben Backups auf beiden Platten; unabhängig von Deinen Löschstrategien für jedes Backup, inklusive Master-Backup.
• Das Löschen von alten Backups auf den Backup-Kopien und dem Master-Backup kann mit demselben Tool erfolgen (storeBackupDel.pl). Insbesondere können auch unterschiedliche Löschstrategien verfolgt werden, z.B. könntest Du sehr lang zurückreichende Backups auf Deinem (langsameren) Replikationsmedien vorhalten.
• Replikationen verhalten sich wie normale Sicherungen von storeBackup. Du kannst natürlich auch eine Überprüfung des Backups mit storeBackupCheckBackup.pl auf den Replikationen laufen lassen.
• Die Implementierung ist robust. Wenn irgendetwas mit der Replikation schief läuft, (also Daten auf dem Weg zum Replikations-Backup aus welchen Gründen auch immer verloren gehen), kannst Du linkToDirs.pl verwenden, um einen neuen identischen Status (Backup Versionen) zu erzeugen und mit der Replikation fortzufahren. Du kannst das ohne alles (vom Master-Backup oder einer anderen Replikation) kopieren zu müssen. (Aber Du benötigst hierfür eine direkte IP Verbindung zwischen den betroffenen Backups / Replikationen während dieser Zeit oder Du benötigst eine Zwischenkopie). Ein weiterer Vorteil dieses Vorgehens ist, dass Du möglicherweise existierende Fehler in älteren Backups nicht von einem Backup zum anderen transportierst, wie es möglicherweise bei Verwendung von Standard-Synchronisationstools passieren würde.

Kurz gesagt, Du machst ein „normales`` Backup (ohne Replikation) mit storeBackup.pl. Du hast typischerweise eine Stelle, an der dieses Backup gespeichert wird (siehe Option backupDir). Dieses Backup wird als Master-Backup bezeichnet. Wenn die Platte (oder genauer das Dateisystem für dieses „Master-Backup``) ausfällt, verlierst Du Dein Backup und damit die Historie Deiner Daten. Es ist eine Art des Datenverlustes, die mit storeBackups Replikationsfeature vermieden werden kann.