Mit RPO und RTO bestimmt die Geschäftsführung über Service Level

Unternehmensservices sind nur so gut wie Ihre Ausfallzeit

| Redakteur: Rainer Graefen

Eine gute Konzeptionierung von Backup&Restore kann den Einsatz von Hochtechnologie überflüssig machen.

Das Kopieren von Dateien und Datenbanken auf ein Bandlaufwerk, ist schon immer nur die erste Hälfte einer Datensicherung gewesen. Dieses Backup darf sogar mal fehlschlagen – solange das zu sichernde System „läuft“.

Ist das wichtige Produktivsystem dagegen havariert, sollte allerdings der letzte Sicherungsanker halten, was die Backup-Industrie zum Ziel hat: den Restore, die sichere Wiederherstellung aller beim Backup kopierten Dateien.

Das Wiederherstellen aller Daten ist nur in wenigen Fällen sinnvoll

Ein Backup war früher zwingend mit einem Medienbruch verbunden. Die Anwendungsdaten auf dem Festplattenverbund werden dann auf ein Bandlaufwerk kopiert. Das Tape-Medium lässt sich entfernen und Offline lagern, so dass die wichtige Kopie im Katastrophenfall einen räumlichen Abstand hat.

Der Medienbruch hat allerdings zwingend zur Folge, dass Daten, die während des Kopiervorgangs auf dem Produktivsystem erzeugt werden, verloren sind. Das gilt in geringerem Umfang auch für Kopieraktionen zwischen Festplatten. Und nicht zuletzt der zeitliche Abstand zwischen zwei Snapshots, markiert einen Datenverlust, wenn der zweite Snapshot, aus welchen Gründen auch immer, nicht durchführbar ist.

Die Storage-Industrie hat diese Problematik in das Akronym RPO, Recovery Point Objective, gepackt. Anders ausgedrückt: der Anwender wird mit der Frage konfrontiert, wie viel er es sich kosten lassen will, den Datenverlust klein zu halten. Mit millionenteuren Transaktionssystemen und gespiegelten Rechenzentren, lässt sich der potenzielle Datenverlust gegen Null drücken. Im Normalfall ist die Datenmenge, die pro Zeiteinheit in einem Unternehmen erstellt wird, der Ausgangspunkt für die technische Backup-Maßnahme.

Der RPO ist, sie haben es gemerkt, nur die erste Hälfte des Backup&Restore-Problems. Auch für die zweite Hälfte hat sich die Storage-Industrie drei Buchstaben einfallen lassen: RTO, Recovery Time Objective und ist die Kurzform für die Ausfallzeit eines Services, zum Beispiel des E-Mail-Servers. Manche sprechen auch von der Wiederanlauf-Dauer.

Die langwierige Rückkehr zum Normalzustand

Wer denkt, dass ein zwei Stunden dauerndes Backup auf Tape auch in zwei Stunden wieder auf den Server zurückkopiert ist, irrt schwer. Das liegt nicht an der mangelnden Geschwindigkeit von Tape, sondern an vielen, auch organisatorischen Datails. Die erste zu beantwortende Frage ist die: Wer ist dafür zuständig zu sagen, dass das Backup wieder eingespielt werden soll?

Ist der Tatbestand der „Katastrophe“ entschieden, hängt die Zeitdauer für die Wiederinbetriebnahme des Service von der Schwere des Fehlers ab. Im schlimmsten Fall ist die Hardware auszutauschen. Danach erfolgt die Installation des Betriebssystem. Die Verbindung zum Tape-Laufwerk ist herzustellen und alle Daten von dort auf den neuen Server zu kopieren.

Sind Datenbanken involviert, muss ein Recovery durch geführt werden, damit sich die Daten wieder in einem konsistenten Zustand befinden. Abhängig von der Datenmenge im Redo-Speicher, kann dieser Vorgang viel Zeit in Anspruch nehmen. Die Verwendbarkeit ist mit einigen frischen Dateneingaben zu bestätigen.

Eventuell ist nun zu klären, ob der Datenverlust mit dem Nacherheben der Daten zu beseitigen ist und ob sich die Kosten für diese Nacharbeit in einem bezahlbaren Rahmen bewegen. Alternativ ist zu prüfen, ob man per Snapshot, Replikation oder Spiegelung auf einem früherem Betriebszustand aufsetzen sollte. Ganz zum Schluss sollte offiziell der Betrieb wieder freigegeben werden.

Die wichtigen Services zuerst

Die Definition einer Zeitspanne in der die Daten nicht durch ein Backupverfahren geschützt sind (RPO) und die Zeitspanne, die man ohne finanzielle Verluste überstehen könnte (RTO), sind die großen Klammern beim Backup&Restore. Da es in größeren Firmen nur selten um einen einzigen Server geht, wäre es sinnvoll, RPO und RTO für jeden unternehmenskritischen Service gesondert zu überlegen und in dieser Konzeptionierungsphase auch die Abhängigkeiten von Services einfließen zu lassen. Was nützt eine funktionierende IT, wenn man sich nicht am System anmelden kann. In Zeiten der Servervirtualisierung entstehen zudem physische Abhängigkeiten, da schon heute von einigen Dutzend virtuellen Maschinen auf einem Server auszugehen ist.

Erst wenn diese Informationen gesammelt sind, sollte das technische Design überlegt werden. Backup&Restore mit einer Standardlösung „erschlagen“ zu wollen, die zwar theoretisch 500 GByte pro Stunde transportiert, ist fahrlässig, da die Server- und Speichervirtualisierung einige neue Flaschenhälse bereithält, die jede Standardlösung unterlaufen werden.

Kommentare werden geladen....

Was meinen Sie zu diesem Thema?

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 30292360 / Restore-Software)