next up previous contents
Nächste Seite: Grundlegende Konzepte vor Verwendung Aufwärts: Replikation von Backups Vorherige Seite: Einstieg mit storeBackups Replication   Inhalt

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.35 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.36 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ßen37 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.:

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``.38 (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:

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.


next up previous contents
Nächste Seite: Grundlegende Konzepte vor Verwendung Aufwärts: Replikation von Backups Vorherige Seite: Einstieg mit storeBackups Replication   Inhalt
Heinz-Josef Claes 2014-04-20