Im vorherigen Kapitel wurden die Haupteigenschaften von storeBackups Replikationsfunktionalität aufgeführt. In diesem Kapitel zeigen wir ein einfaches und typisches Beispiel der Konfigurationen, die nötig sind, um Deine Backupdaten auf eine andere Platte (oder in eine andere Lokation) zu replizieren. In einem folgenden Kapitel, sehen wir noch ein fortgeschrittenes Beispiel.)
Aber zuerst solltest Du einige wichtige Konventionen und Konzepte der Replikationsfunktion von storeBackup kennen. Bei dieser Replikationsfunktionalität gibt es vier wichtige Speicherorte, deren Konzept Du verstanden haben musst. Diese vier Speicherort sind normale Verzeichnisbäume.39
Von diesen vier konzeptbedingten Stellen ist eine die mit den zu sichernden Dateien. Die anderen drei haben mit der Replikation zu tun:
Keines dieser drei Verzeichnisse darf ein Unterverzeichnis eines anderen sein. Sie sind separate Verzeichnisbäume.42
Das was wir hier „Master-Backup`` nennen, ist etwas, mit dem Du schon vertraut bist, falls Du irgendeine Art von Backup gemacht hast.43
Der nächste wichtige Speicherort für Replikationen ist die Backup-Kopie. Es ist offensichtlich - das ist der Ort, an den repliziert wird.44
Der letzte der wichtigen Speicherorte für die Replikation ist der Cache für die Deltas (und der Metadaten), der von storeBackup dazu verwendet wird, seine Replikationsfunktionalität möglichst effizient bereitzustellen. Wir bezeichnen diesen Ort als „deltaCache``. Der deltaCache existiert, da es so möglich ist, das Master-Backup (inklusive Hardlinks) unabhängig von den Backup-Kopien zu vervollständigen.
Ein weiterer wichtiger Aspekt für das Verstehen der Replikation ist, das jedes dieser drei Backup-bezogenen Verzeichnisse seine eigene Konfigurationdatei im Root-Verzeichnis45des jeweiligen Verzeichnisbaumes haben muss. Der Grund hierfür ist, dass auf diese Art mit den fixen Lokationen für die Konfigurationsdateien die Bearbeitung ohne zusätzliche Optionen (oder Problemen aus der daraus resultierenden Komplexität) mittels storeBackupUpdateBackup.pl verwaltet werden kann.
Bei einer Replikation mit storeBackup ist der Datenfluss immer:
masterBackup 
deltaCache Backup-Kopie(n).
Das „Master-Backup`` Directory enthält eine Datei namens storeBackupBaseTree.conf. Diese Konfigurationsdatei definiert, welche Backup-Serien zu deltaCache kopiert werden.
Jedes „backup copy`` Directory enthält eine Datei namens storeBackupBaseTree.conf, welches eine individuelle Konfiguration für die jeweilige Kopie ist. Sie definiert, welche Backup-Serien zu der jeweiligen Backup-Kopie kopiert werden müssen.
Das „deltaCache``-Verzeichnis enthält deltaCache.conf im Wurzelverzeichnis des Baumes. Der Sinn dieser Konfigurationsdatei ist, eine zentrale Stelle zu haben, die genau festlegt, welche Backup-Serie in welche Backup-Kopie übertragen werden soll (physische Pfade werden hierzu nicht benötigt). Diese Informationen werden von storeBackupUpdateBackup.pl verwendet, um zu entscheiden, ob das Delta eines Backups als verarbeitet registriert und später gelöscht werden kann. storeBackupUpdateBackup.pl muss wissen, wohin ein Backup kopiert werden soll und welche bereits kopiert wurden.
Diese Konfigurationsdateien enthalten einige Optionen (z.B. backupTreeName) für die Du eine eindeutige Bezeichnung wählen musst. Dieser Parameter ist lediglich der Name einer Referenz für eine andere Lokation. Es ist kein Pfad im Dateisystem oder ein aktueller Verzeichnisname. Es ist eine eindeutige Bezeichnung, die Du festlegen musst. Dieses wird weiter unten noch näher beleuchtet.
Es gibt keinen Informationsaustausch zwischen zwei unterschiedlichen Backup-Kopien. Sinnvoll ist das für den Heimanwender deshalb, weil die externe(n) Platte(n) für die Replikation nicht immer angeschlossen sein müssen, und für den professionellen Administrator, weil er aus Sicherheitsgründen kein Routing zwischen ihnen haben mag.
Jedoch willst Du vermutlich zum Verständnis des Gesamtkonzeptes der Replikation von storeBackup verstehen, wozu die Konfiguration der Replikation diese eindeutigen Backup-Bezeichnungen (die keine Verzeichnisnamen sind) benötigt. Warum wird nicht einfach der Verzeichnisname verwendet? Die Gründe, warum storeBackup eindeutige Bezeichner und keine Verzeichnisnamen verwendet, können an zwei Beispielen erläutert werden.
Stell Dir als erstes vor, jemand will zwei Backup-Kopien (Replikationen) auf zwei externen Platten erstellen, eine aktualisiert an geraden und eine an ungeraden Wochenenden. Angenommen, die Platten werden an demselben Mount-Pfad eingebunden. Der sinnvollste Weg, den Wechsel dieser beiden unterschiedlichen Kopien zu verwalten, ist der über diese eindeutigen Bezeichnungen. Stell Dir für dieses Beispiel vor, die eindeutigen Bezeichnungen wären KopieA und KopieB. Dies erlaubt storeBackup zu entscheiden, ob zu beiden repliziert wurde (kopiert und Hardlinks gesetzt), so dass es in das Unterverzeichnis processedBackup verschoben werden kann - auch wenn der Prozess unterbrochen wurde o.ä. Eine andere Implementierung würde auf diese Vorteile verzichten.
Ein anderes Beispiel ist ein Administrator, der zwei Replikationen durchführen will: Eine bleibt im Rechenzentrum und eine kommt in ein entferntes. Er setzt den Server im selben Rechenzentrum auf, der die Daten vom Delta-Cache über Mount-Punkte holt. Im entfernten Rechenzentrum kopiert er die Konfiguration und setzt den Server genauso auf. Die Verwendung von eindeutigen Bezeichnern (die entkoppelt vom Pfad sind) machen das Leben für den Administrator leichter.
Die Konfigurationsdatei von deltaCache weiß nichts über das Verzeichnis, in das die Backup-Kopie repliziert wird. Stattdessen steht in der Konfigurationsdatei nur die eindeutige Bezeichnung, was flexibler ist. Wenn Du das Verzeichnis der Backup-Kopie änderst, muss die Konfigurationsdatei vom deltaCache nicht geändert werden. Und, so wie in den oben beschriebenen Beispielen dargestellt, können zwei unterschiedliche Bezeichner auf denselben Pfad verweisen.
Du wirst also wahrscheinlich mindestens vier unterschiedliche Konfigurationsdateien für Deine storeBackup-Replikation verwenden. Diese sind die drei oben beschriebenen Dateien sowie Deine normale storeBackup Konfigurationsdatei.46
Die Verwendung von Replikationen wird von zwei Optionen von storeBackup.pl beeinflusst: --lateLinks und --otherBackupSeries.
Wenn Du Deine Backups bisher nicht mir der Option lateLinks laufen lässt und die Replikation verwenden willst, musst Du diese einschalten. Hierdurch gibt es keinen Nachteil. Sie trennt den Prozess eines Vollbackups lediglich in zwei Schritte, ohne ansonsten irgendetwas am Ergebnis zu verändern.
Du solltest auch auf die Option --otherBackupSeries in der storeBackup Konfigurationsdatei achten bzw. auf ihre Anwendung auf der Kommandozeile (z.B. 0:homeBackup im Beispiel weiter oben).
Wenn Du nur eine Serie Deiner Backups replizierst, ist es nicht möglich, diese mit anderen Serien zu verlinken! (Diese Restriktion trifft natürlich nur zu, wenn du mehrere Backup-Serien (von z.B. unterschiedlichen Rechnern) im Master-Backup hast. Eine replizierte Serie kann nicht auf eine andere Serie verweisen, die nicht in dieselbe Backup-Kopie repliziert wird. (Umgekehrt kann aber eine Serie, die nicht repliziert wird, auf beliebige Serien, die repliziert werden, verweisen.)
Diese Restriktion könnte in Zukunft entfallen. (Das bedeutet, dass die nicht referenzierbaren Dateien automatisch zu den Deltas (für deltaCache) hinzugefügt würden, wenn storeBackupUpdateBackup.pl im Master-Backup läuft.
Kurz gesagt, stelle für die ersten Replikationen sicher, dass nur Hardlinks auf die eigene Serie erzeugt werden. Alles, was im Master-Backup verlinkt wird, muss auch in jeder Backup-Kopie vorhanden sein. Wenn Du alle Serien replizierst, brauchst Du an der Hardlink-Konfiguration nichts zu ändern.
Es ist alles sehr einfach, aber nur wenn Du verstehst, was passiert. (Und natürlich ist die Konfiguration etwas komplizierter, wenn Du unterschiedliche Serien (überlappend) auf unterschiedliche Backup-Kopien spielst.)
Wenn storeBackupUpdateBackup.pl auf den Backup-Kopien läuft, wird autorepair automatisch eingeschaltet (generiert aber nur INFO und keine ERROR Meldungen).