F

Spiegelung für Disaster-Recovery-Tests unterbrechen

Die Spiegelung sollte während Disaster-Recovery-Tests abgeschaltet werden. Nur so ist zu überprüfen, ob auch die richtigen Daten gespiegelt werden.

Dieser Artikel behandelt

Sichere Datenspeicherung

Warum sollten Spiegelungen im Rahmen Ihrer Disaster-Recovery-Tests unbedingt unterbrochen werden?

Bei der Spiegelung (Mirroring) werden Daten zwischen zwei Festplattenspeichern repliziert, normalerweise innerhalb eines lokalen Speicherverbunds. Eng verwandt damit ist die Replikation. Dabei handelt es sich um denselben Prozess, aber über größere Entfernungen per WAN. In der Regel wird die Spiegelung als synchron angesehen und die Replikation als asynchron (da die entfernungsbedingte Latenz zu Datendeltas beziehungsweise Unterschieden zwischen lokalem und entferntem Datenspeicher führt).

Bei korrekter Ausführung erfolgt die Spiegelung zwar fast in Echtzeit, doch Kopieren viele Speicher-Arrays nach dem Schreiben und nicht während des Schreibvorgangs. Tatsächlich ist es so, dass Daten auf Array Nr. 1 gespeichert und dann durch eine Software des Arrays über eine schnelle Datenverbindung mit hoher Bandbreite auf ein nahes, identisches Array Nr. 2 kopiert werden. Auch durch den Umstand, dass man sowohl auf dem Primär- als auch dem Spiegel-Array an die Technik desselben Anbieters gebunden ist, werden die Kosten der Spiegelung bei dieser Vorgehensweise in die Höhe getrieben.

Doch das eigentliche Problem ist ein ganz anderes. Ein kleines Softwareunternehmen, 21st Century Software, weist schon seit ein paar Jahren in seinen Präsentationen darauf hin: Es werden mehrere Kunden als Beispiel gezeigt, die davon überzeugt waren, ihre Hardware spiegele die richtigen Daten. Sie mussten dann aber festzustellen, dass eigentlich gar keine Daten gespiegelt worden waren. Das ist meistens dann der Fall, wenn die Datenträger des Arrays, auf dem die Daten liegen, von einem Servicetechniker des Anbieters oder einem Storage-Administrator reorganisiert werden und niemand den Disaster-Recovery-Koordinator davon in Kenntnis setzt. Unterbricht man nicht regelmäßig während des Disaster-Recovery-Testprozesses die Spiegelung, so fällt das Problem möglicherweise gar nicht auf – bis tatsächlich der Notfall eintritt.

Und warum unterbricht dann nicht einfach jeder seine Spiegelung und schaut nach? Ganz einfach: Weil es enormen Aufwand bedeutet. Man muss Anwendungen stilllegen, den Cache von Datenträger 1 leeren, den Inhalt auf den Spiegel-Datenträger 2 replizieren, dann alles abschalten und anschließend einen dateiweisen Vergleich zwischen den beiden Datenträgern durchführen. Das kostet nicht nur den Operator Zeit, sondern frisst auch die Kapazitäten der Produktionsanwendungen. Außerdem ist es nicht gesagt, dass die Spiegelung nach dem Systemneustart wieder problemlos anläuft.

Bei der Remote-Replikation gibt es zwar auch einige dieser Probleme, doch kann man immerhin unter Umständen auf Datendeltas prüfen, ohne gleich den Replikations-Prozess stilllegen zu müssen. Dafür kommt es dort im Zusammenhang mit Latenz und Jitter zu zahlreichen anderen Schwierigkeiten. Sie müssen stets darauf achten, dass Sie über einen wiederherstellbaren Datenspeicher verfügen.

Artikel wurde zuletzt im Januar 2014 aktualisiert

Pro+

Premium-Inhalte

Weitere Pro+ Premium-Inhalte und andere Mitglieder-Angebote, finden Sie hier.

Erfahren Sie mehr über Sichere Datenspeicherung

0 Kommentare

Älteste Beiträge 

Passwort vergessen?

Kein Problem! Tragen Sie Ihre E-Mail-Adresse unten ein. Wir werden Ihnen eine E-Mail mit Ihrem Passwort schicken.

Ihr Passwort wurde an die folgende E-Mail-Adresse gesendet::

- GOOGLE-ANZEIGEN

SearchSecurity.de

SearchNetworking.de

SearchEnterpriseSoftware.de

SearchDataCenter.de

Close