Anzeige
Anzeige

Wie viel Backup braucht das Rechenzentrum

Neue, hochleistungsfähige Technologien mit zahlreichen Funktionen bringen Hochverfügbarkeit in Rechenzentren. Darüber hinaus verändern Replikationen an Zweitstandorte und eine wachsende Always-On-Mentalität die Sicherungsstrategien. Manch IT-Manager könnte darüber nachdenken, wie sinnvoll sein Backup noch ist.

Deduplizierungs-Appliance DXi6702 (Bild: Quantum)Deduplizierungs-Appliance DXi6702 (Bild: Quantum)Backup schien schon immer das ungeliebte Stiefkind der IT. Die Budgets nie groß genug, der Sicherungszeitraum immer am Limit und die Verantwortlichen immer in der Bringschuld, falls es zu Systemausfällen und Datenverlusten kommt. Um bei der Datensicherung nicht nur auf einem Bein zu stehen, haben viele Unternehmen zusätzliche Strategien wie Hochverfügbarkeitskonzepte und Replikationspläne entwickelt, um ihre Geschäftstüchtigkeit nonstop aufrecht zu halten. Mit der stetig wachsenden Erwartung stets verfügbare Daten an jedem Ort zu haben, werden diese Sicherungspraktiken immer wichtiger.

Wer bei einem Systemausfall oder Datenverlusten auf ein Zweitsystem mit identischen Datensätzen zugreifen kann, hat scheinbar eigentlich keinen Bedarf mehr an einem Backup. Das klassische Backup durch Redundanzen, Always-on und mehrfach verteilte Informationsbestände zu ersetzen liegt nahe, ist aber nur auf den ersten Blick eine verlockende Option, dem Backup-Aufwand zu entgehen.

Anzeige

Doppelt hält besser – schon seit Jahren

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 zirka 100 Kilometern synchron zu halten, so dass am zweiten Standort mit demselben Datenbestand weitergearbeitet werden konnte. Inzwischen, mit verbesserter Netzwerktechnologie, hat sich dieser Wert von 100 Kilometer auf unter 5 Millisekunden geändert, was in der Realität um die 200 Kilometer 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.

Mittlerweile sind diese Funktionen auch in kleineren Umgebungen möglich, da bereits Einstiegssysteme oder Lösungen für den kleineren Mittelstand Replikation und Hochverfügbarkeit mittels redundanter Komponenten und Systemkopplung ermöglichen. Meist reichte diesen Unternehmen einfach ein klassisches Backup, aber auch hier liegen die Anforderungen mittlerweile bei 24/7-Verfügbarkeit. Es stellt sich die Frage, ob die herkömmliche Datensicherung nicht ausgedient hat und nun andere Strategien erforderlich sind.

Replizieren allein reicht nicht

Failover-Schwenks, Zweitstandorte, Replikation: All dies sind wichtige Mechanismen für eine dauerhafte Verfügbarkeit von Daten und somit des Geschäfts. Ein Backup können diese Verfahren aber nicht wirklich ersetzen. Denn zum einen 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.

Zum anderen 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.

Nicht zuletzt darf der IT-Manager nicht vergessen, dass die beiden genannten Vorgänge auch für den Rückfall ins Primärrechenzentrum gewährleistet sein müssen, um dort wieder problemlos nach Behebung der Fehler weiterarbeiten zu können. Darüber hinaus 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. Schlussendlich heißt das, dass eine zweite Datensicherung notwendig ist, um einen konsistenten Datenbestand vorzuhalten, da aus einer Replikation nur bedingt alle Informationen wiederhergestellt werden können.

Fehler im Microcode mit Backups vermeiden

Der Verlust einiger weniger Daten, IOPS oder kleinere Inkonsistenzen sind sicher nicht zu dramatisch anzusehen. Sie erfordern im Zweifel Aufwand, der mit Zeit verbunden ist. IT-Verantwortliche sollten wissen, was auf sie zukommt und ihre Speicherlandschaften so planen, dass entsprechende Auswände einkalkuliert sind und die Technik keine Überraschungen parat hat.

Das Vermeiden von Microcode-Fehlern ist allerdings das wichtigste Argument für ein regelmäßiges Backup. Dies sollte genau zwei Kriterien erfüllen: Es muss 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.

Und trotz aller Automatismen und Regeln passieren solche Fehler noch immer, auch den größten Unternehmen 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. Und Firmen, die hier vorsorgen sowohl mit Backup als auch mit HA, denen kann das eine so egal wie das andere sein.

Auch Virtualisierung ist kein Allheilmittel

Ein gewisses Maß an Datensicherheit lässt sich auch durch Virtualisierung erreichen. Hier gibt es zum Beispiel 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 ließen sich die Zeitaufwände bei inkonsistenten Daten und ähnlichem vermeiden. 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 herkömmliche Datensicherung – sprich das Backup – ist also noch lange nicht vom Aussterben bedroht. Es muss nur andere Arten von Ausfällen abpuffern. Solange wir in Rechenzentren von Menschen entworfene, gebaute und programmierte Systeme einsetzen, ist Always-On keine Mentalität, sondern ein Hype, dem die Unternehmen glauben folgen zu müssen. Jedes Rechenzentrum, jede Maschine, jede Anwendung benötigt Service-Zeiten. Und das wird auf absehbare Zeit auch so bleiben.