Periodische Replikation mit Veritas Access

Wenn Daten ständig miteinander abgeglichen werden, kommt eine Continuous Data Replication zum Einsatz – es besteht eine kontinuierliche Verbindung. Was aber, wenn täglich etwa Daten aus Niederlassungen an das zentrale Rechenzentrum überspielt werden müssen? Hier kommt die episodische Replikation mit Veritas Access zum Zuge. Damit müssen weder einzelne Veränderungen der Dateien in einer exakten Reihenfolge aktualisiert werden, noch muss die Konsistenz der Informationen gewährleistet sein. Die Terminierung dieser Aufgabe erfolgt unabhängig von den zeitkritischeren Sicherungsstreams der Anwendungen, die ihrerseits kontinuierlich und synchron erfolgen müssen. Eine episodische Replikation wirkt sich besonders im Netzwerk ressourcensparend aus.

Grafik: Veritas

Für eine terminierbare Replizierung sind zwei miteinander verbundene Access-Systeme der gleichen Version notwendig – mit einer eigens konfigurierten virtuellen IP-Adresse (VIP) und einem gemeinsamen Schlüssel zur Authentifizierung des Quellsystems (Source) und des Zielmediums (Destination).

Zur Vorbereitung legen Sie zunächst auf dem Quellsystem in der Replication Unit eine Liste der zu kopierenden Informationsbestände fest. Hier finden sich Angaben über das File-System, die Unterverzeichnisse sowie über jede einzelne Datei. Was nicht zu sichern ist, kann auch in einer Exclusion Unit gesammelt werden. Anschließend werden die Metadaten überprüft, um den nötigen Umfang der Änderungen auch auf Blockebene zu erkennen. Gegebenenfalls lassen sich nur einzelne Blöcke ändern.

Im nächsten Schritt verbinden Sie über die Source die Zieleinheit. Durch die Befehle “episodic auth config” und “episodic auth bind” werden die nötigen Authorisations-Keys abgefragt und die zu nutzende IP-Adresse des Ziels mitgeteilt. Nach Austausch der Schlüssel werden Verzeichnisse und Dateien auf der Destination angelegt und die Übertragung beginnt. Storage Checkpoints auf Source und Destination überprüfen den Erfolg. Sie helfen Ihnen bei späteren Rollbacks oder einer notwendigen Wiederherstellung.

Die Jobs lassen sich zu jeder Zeit für andere wichtigere Aufgaben unterbrechen. Eine neue Sicherung startet stets erst nach Abschluss der alten. Sie ist sowohl bei einem geplanten Failover – weil ein System offline gehen muss – als auch bei einem ungeplanten Failover möglich. Ein Reporting können Sie mit “replication episodic job stats <job_name>” einsehen.