30.05.2014 (Doc Storage)
4.5 von 5, (8 Bewertungen)

Revolution oder Evolution: Wird das Backup obsolet?

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

Stellen Sie Ihre Frage
Doc. tec. Storage beantwortet alle Ihre technischen Fragen zu Storage, Backup & Co.

Stellen Sie Ihre Frage an: DocStorage@speicherguide.de
Kommentare (1)
02.06.2014 - LHL

Jup. Volle Zustimmung.
Zudem ist Datensicherung auch für Recovery-Fälle nötig, bei denen durch logische Fehler in der Anwendung oder menschliche (administrative) Fehler Daten zerstört wurden, was auch durch Redundanz in der Speicherinfrastruktur nicht abgefangen werden kann, da die Fehler einfach mitsynchronisiert werden.


Mehr von Doc. tec. Storage 12.04.2019 Dateisysteme für den PByte-Bereich

Datenberge jenseits des PByte-Bereichs, Cloud-Anbindungen und Analytics-Szenarien stellen Dateiysteme vor neue Herausforderungen. Der Markt bietet einige Optionen wie GPFS, Gluster FS, OneFS oder QF2. Worauf gilt es zu achten?


05.04.2019 Neuordnung des Storage-Tiering

Nachdem sich Flash und SSDs mittlerweile auch in mehrere Leistungsklassen unterteilen, steht die Technik nicht mehr nur für Tier 0. 15k-HDDs scheinen vor dem Aus zu stehen. Gilt dies auch für alle SAS-Platten? Wie sieht die Neuordnung des Storage-Tiering aktuell aus?


15.03.2019 30 Jahre World Wide Web: Was gibt es zu feiern?

Das World Wide Web feiert seinen 30. Geburtstag. Ohne dem Internet ist unser heutiges Leben nicht mehr vorstellbar. Für Doc Storage hat das Netz aber auch genug Schattenseiten. An Regulierungen bzw. an das vom Erfinder erhoffte bessere Internet, glaubt er nicht.


08.03.2019 Datenanordnung im RAID 10 mit 8 Platten

In einem Server wird ein RAID 10 mit acht Festplatten unter Windows 2008 R2 betrieben. Nun ist ein Laufwerk ausgefallen. Da sich nur wenige Daten auf den HDDs befinden, besteht die Möglichkeit, dass die defekte Platte eventuell gar keine Daten enthält?


22.02.2019 Welcher RAID-Level für welche Anwendung?

Gibt es eigentliche eine Faustregel, welches RAID-Level für welche Anwendung am besten geeignet ist? Ich denke da zum Beispiel an Datenbanken mit sehr vielen Zugriffen bei relativ kleinen Datenmengen oder an Webserver und als Extrem auf der anderen Seite Bild-Datenbanken, Audio-Server beim Rundfunk, Video-Archive mit sehr hohen Datenvolumen.


15.02.2019 Was sagt DWPD über SSDs aus?

Im Zusammenhang mit (Enterprise-)SSDs wird oft die Qualitätsgröße DWPD (Drive Writes Per Day) genutzt. Meist wird die Angabe auch für einen Zeitraum von fünf Jahren spezifiziert. Was sagt DWPD genau aus und mit welcher Standard-Lebensdauer darf man rechnen?

powered by
Boston Server & Storage Solutions Datacore Software
Fujitsu Technology Solutions GmbH Seagate Technology
N-TEC GmbH FAST LTA AG