Leserfrage: Neue, hochleistungsfähige Technologien mit zahlreichen Funktionen bringen Hochverfügbarkeit in viele Rechenzentren. Darüber hinaus verändern Replikationen an Zweitstandorte und eine wachsende Always-On-Mentalität die Sicherungsstrategien. Backup war schon immer ein ungeliebtes Stiefkind der IT. Stirbt das klassische Backup aus?

Antwort Doc Storage:

Die Technologien, die für eine mehrfache synchrone Speicherung von Daten an entfernten Standorten notwendig sind, sind gar nicht so neu. Große Hersteller haben diese bereits in der zweiten Hälfte der 90er Jahre eingeführt, unter anderem um die damals aufkommenden Regelungen von Basel II im Bankenbereich erfüllen zu können. Schon zu dieser Zeit war es möglich, zwei Speichersysteme auf eine Distanz von ca. 100 km synchron zu halten, so dass am zweiten Standort mit demselben Datenbestand weitergearbeitet werden konnte. Inzwischen, mit verbesserter Netzwerktechnologie, hat sich dieser Wert von 100 km auf unter 5 Millisekunden geändert, was in der Realität um die 200 km bedeutet. Da heutzutage im Enterprise- und hochwertigen Midrange-Bereich mehr als zwei Arrays gekoppelt werden können, lässt sich auch mehr als eine Kopie der Produktionsdaten an entfernten Standorten anfertigen, so dass auch nach Ausfall eines Rechenzentrums mit geschützten Beständen weitergearbeitet werden kann. Hiermit lässt sich »Always On« durchgängig unterstützen.

Und jetzt kommen - wie immer - die »Aber«: Erstens sind die Dateien bei Übernahme der Produktion in einen zweiten Standort tatsächlich synchron, das bedeutet, dass viele Dateien, Datenbanken oder andere Informationstypen im geöffneten Zustand auf den Datenträgern stehen. Somit müssen diese auf der Sekundärseite nachbearbeitet und wieder zugriffsfähig gemacht werden. Das ist ein nicht unerheblicher Aufwand, der bei den meisten Failover-Szenarien nicht bedacht wird. Zweitens befinden sich im Moment des Umschaltens in den anderen Standort noch I/Os auf der Leitung, die zwar bereits im Rechner als gesendet gelten, aber im Primärsystem noch nicht geschrieben wurden. Nach dem Failover muss also das fehlende »Acknowledge«-Paket vom Primärsystem eine Anforderung desselben Blockes vom Rechner auslösen, um diesen I/O regelrecht in die Datei bzw. den Datensatz schreiben zu können. Passiert dies nicht, ist der I/O verloren und die Datei bzw. der Datensatz ist inkonsistent und somit unbrauchbar.

Und drittens müssen die beiden genannten Vorgänge auch für den Rückfall ins Primärrechenzentrum gewährleistet sein, um dort wieder problemlos nach Behebung der Fehler weiterarbeiten zu können. Viertens kann es im schlimmsten Falle zu einem Fehler des Microcodes der verwendeten Arrays kommen. Das würde bedeuten, dass im selben Moment oder in einem sehr engen Zeitraum alle verwendeten Systeme die Produktion einstellen und nicht mehr verwendbar sind.

Erstens, Zweitens und Drittens sind nicht schlimm, weil nur Aufwand und damit mit Zeit verbunden. Wenn man weiß, was auf einen zukommt, und das erwarte ich einfach von einem Betreiber einer solchen Speicherlandschaft, dann plant man die hiermit verbundenen Aufwände ein und lässt sich nicht von der Technik überraschen. Viertens allerdings ist das einzig verbliebene Argument für ein regelmäßiges Backup. Dies muss genau zwei Kriterien erfüllen: es muss (nicht es sollte) auf einem anderen Systemtyp erfolgen als auf dem Produktionsarray. Nicht im Array selbst - aufgrund der beschriebenen Szenarien sind weder physikalische Clones noch logische Snapshots im schlimmsten Falle als Sicherung zu gebrauchen. Und es muss einen sofort nach Kopie zugriffsfähigen Stand der Produktionsdaten enthalten, der keine Nachbearbeitung mehr erfordert. Nur eine solche Infrastruktur und Logik gewährleistet den schnellsten Weg zurück in die Produktion, wenn tatsächlich auf allen verwendeten Arrays nichts mehr geht und komplett neue Systeme aufgesetzt werden müssen.

Ich möchte jetzt keine Leserbriefe bekommen nach dem Tenor »das passiert doch heutzutage nicht mehr«. Doch, das passiert. Und es passiert den größten und denen mit den besten Datenschutz- und Recovery-Strategien. Moderne Arrays sind die bei weitem komplexesten Maschinen mit den umfangreichsten Betriebssystemen in der EDV, weder ein Mainframe noch irgendwelche Serverfarmen im virtualisierten Bereich kommen dort heran. Dass etwas kaputtgehen kann, ist nicht die Frage. Nur das »wann« und das »was« stehen zur Diskussion.

Ach ja - und nur um die Leserbriefe aus der virtualisierten Ecke der EDV abzufangen: ja, es gibt die Möglichkeit, aus mehreren Standorten gleichzeitig auf dasselbe logische Volumen zuzugreifen. Und es gibt die Möglichkeit, dieses logische Volumen synchron zu spiegeln und damit die Produktion auch mit geöffneten Dateien oder Datensätzen sofort und ohne Unterbrechung fortzusetzen. Damit wären Erstens, Zweitens und Drittens um den Schrecken des Zeitaufwandes reduziert. Was diese Infrastrukturen nicht können, ist das gleichzeitige Versagen gleicher Typen von Speichersystemen auszuschließen. Und für diesen Fall benötigen wir immer noch das klassische Backup.

Die Antwort lautet also: nein, das Backup ist beileibe nicht ausgestorben oder obsolet. Es muss nur andere Arten von Ausfällen abpuffern. Und - nur um neue Leserbriefe zu provozieren: solange wir in Rechenzentren von Menschen entworfene, gebaute und programmierte Systeme einsetzen, ist Always On keine Mentalität, sondern ein durch Marketing-Abteilungen geschürter Irrweg. Jedes Rechenzentrum, jede Maschine, jede Anwendung benötigt Service-Zeiten. Und das wird auf absehbare Zeit auch so bleiben.

Gruß
Doc Storage