Backup, aber wie?

Big Data verspricht auch KMU neue Erkenntnisse, mit denen sie der Konkurrenz den entscheidenden Schritt voraus sein können. Gerade kleine und mittelgrosse Firmen werden dabei Neuland betreten und merken, dass sich in der Industrie erst langsam Best Practices und klar strukturierte, bewährte Ansätze zeigen. Auf Neuland zu navigieren heisst, wie ein Pionier unterschiedliche Ansätze auszuprobieren, Fehltritte einzukalkulieren und aus den Fehlern zu lernen.


Wichtig ist: Wenn Fehler die Daten korrumpieren, müssen Firmen schnell auf einen Bestand zurücksetzen können, um ihre Big-Data-Analysen weiterzuführen. Dies sollte unabhängig von der darunter liegenden Infrastruktur gelten. Ob ein Unternehmen für Big-Data-Analysen ausschliesslich auf die Dienste eines der grossen Cloud-Provider setzt, Mischszenarien fährt, in denen es eigene Hard- und Software an Cloud-Dienste koppelt oder die wichtigsten Elemente in Eigenregie auf eigener Infrastruktur betreibt – in ­allen Szenarien sind die Risiken ähnlich.

Die Risiken

Die grösste Gefahr geht keineswegs von den Plattformen, Diensten oder der Infrastruktur aus. Hier haben die Hersteller der Applikationen und Datenbanken sowie die Cloud-Dienstleister über die Jahre ausgezeichnete Ausfallkonzepte implementiert, dank derer sie einen hochverfügbaren Betrieb ihrer Big-Data-Module garantieren können. Den grössten Einfluss hat der Faktor Mensch. Kroll Ontrack, ein Datenrettungsunternehmen, hat in einer Studie menschliche Fehler mit 84 Prozent als die wichtigste Ursache für Datenverluste benannt. Ein unbedachter Mausklick oder das System falsch konfiguriert – und schon sind wichtige Unternehmensdaten weg. Bei Big-Data-Analysen können sich Fehler schnell auf grosse Datensets auswirken.


Die Data Scientists wollen aus den Daten im Idealfall neue Erkenntnisse gewinnen. Bei all den dafür notwendigen Schritten können kleine und grosse Fehler entstehen, die Daten verfälschen, die Datenbank überlasten oder schlicht sinnlose Ergebnisse produzieren. Den Data Scientists sollte man diese Fehler zugestehen, denn schliesslich müssen sie mangels Best Practices Neues und Unerprobtes wagen – beides könnte es notwendig machen, die Big-Data-Plattform und ihre Daten in einen früheren Zustand bringen zu müssen.

Fehlen Backups, können die Folgen gravierend sein. So hat in einem Fall ein Unternehmen aus dem Retail-Bereich eine komplette Inventur des Lagerbestandes in allen Filialen veranlassen müssen, da bei den Big-Data-Analysen dieser Daten einzelne Einträge verfälscht wurden. Niemand konnte sicher sagen, welche Werte noch stimmten. Das Unternehmen hat sich danach schnell entschieden, ihre Big-Data-Datenbank per Backup zu ­sichern.


Die weiteren Risiken dürften aus anderen Anwendungsfällen bereits wohlbekannt sein. Essenzielle Teile der Infrastruktur wie die Datenbank können ausfallen oder gehackt werden. Beim Aufspielen von Updates oder Upgrades können derweil genauso Fehler passieren, welche die Big-Data-Module abstürzen lassen. In allen Fällen ist es sinnvoll, auf eine Vorversion zurückgehen zu können, um den Ausfall schnell zu überbrücken. Ein Data Scientist möchte zudem vielleicht den Ist-Zustand einer wichtigen Analyse sichern und archivieren, um sie zu einem späteren Zeitpunkt nochmal zu untersuchen.

Einstieg in die grosse Datenwelt

Die meisten KMU investieren, um erste Erfahrungen mit Big Data zu sammeln und ohne viele eigene Ressourcen zu binden, in ein Applikationsmodul der gros­sen Cloud-Service-Provider. Ob Amazon, IBM, Google oder Microsoft, jeder der Dienstleister erlaubt es dem Kunden, mit geringem Aufwand zu beginnen.

Die Provider selbst handeln nach einem Shared-Responsibility-Modell, bei dem immer ein Teil der Verantwortung für die Daten und deren Compliance beim Kunden liegt. Werden Daten verfälscht oder gehen verloren, liegt die Verantwortung auf Seiten der Kunden, diese aus einem eigenen Backup zu rekonstruieren. Immerhin bieten die Provider ihren Kunden für diesen Zweck so genannte Snapshot-basierende Backups an, die in den Anwendungsmodulen als Feature integriert sind. Jeder Cloud-Provider nutzt einen anderen Ansatz mit eigenen Regelwerken, Konsolen und Befehlen für seine Umgebung.


Nutzt ein Unternehmen also Cloud basierende Big-Data-Analysen unterschiedlicher Provider, wird sich jemand im Unternehmen mit den jeweiligen Snapshot-­Technologien auseinandersetzen und ver­stehen müssen, was bei der Wiederherstellung der jeweiligen Daten tatsächlich erreicht wird. Diesen Punkt sollte man nicht unterschätzen, schliesslich bietet die Cloud dem Kunden theoretisch die Option, für jede Aufgabe das am besten geeignete Cloud-­Modul zu wählen, im Idealfall von unterschiedlichen Anbietern. Schnell ist es geschehen, dass selbst kleine Unternehmen plötzlich die Dienste mehrerer Cloud-Provider nutzen wollen, die alle ihr eigenes Cloud-basierendes Backup-­Schema liefern.

Wer Teile der Infrastruktur selbst aufbauen will oder eine eigene autonome Big-Data-Architektur braucht, sei es nur aus Performance-Gründen, kann aus einer Reihe spezialisierter Big-Data-­Plattformen wählen. Ob Apache Cassandra, Hadoop, OpenSQL oder SAP Hana, diese Plattformen bieten ihrerseits ebenfalls Schnittstellen in die Dienste der Cloud-Provider. Und sie werden von den Cloud-Anbietern selbst als Infrastruktur vorgeschlagen oder genutzt, damit der Kunde auch Mischkonzepte aus Cloud und On Premise leicht umsetzen kann. Jede dieser Plattformen führt eine eigene Architektur ein, die dem Scale-Up- oder Scale-Out-Prinzip folgt, und besitzt eine eigene Systemcharakteristik, um hochverfügbar zu arbeiten und selbst Backups zu ermöglichen. Dazu werden in der Regel vom Hersteller Software-Schnittstellen offengelegt, über die der Backup-Anbieter direkt auf die Systeme zugreifen und dortige Abbilder der Daten und Logs abgreifen kann. Ein Backup-Anbieter muss dabei mehrere technische Tests und Hürden nehmen, um vom Plattformanbieter für diese Aufgabe zertifiziert zu werden. So ist zugesichert, dass das Zusammenspiel aus Plattform, Backup und Wiederherstellung getestet wurde und in der ­Regel reibungslos funktioniert.

Backup, aber wie?

Ob rein Cloud-basierend, im Mischbetrieb oder eine eigene lokale Implementierung, jeder dieser Big-Data-Ansätze führt eine neue Datenform ein. Diese so genannten Workloads sind sehr dynamisch, meist verteilt, gross, virtualisiert und bringen eigene Backup-Ansätze mit, die die bestehende Backup-Umgebung in viele Inseln aufsplitten und ein althergebrachtes Backup-Konzept schnell an seine Grenzen bringen.


Hadoop-Umgebungen beispielsweise teilen die Big-Data-Analyse in verschiedene Arbeitsschritte ein, auf die die Module spezialisiert sind. Diese werden in so genannten Knoten konsolidiert, die ­ihrerseits die Arbeitslast in der Fläche klug untereinander aufteilen und beim Ausfall eines Knotens deren Aufgabe komplett übernehmen. Das Backup muss diesen Architekturen und den verteilten Daten gerecht werden und seine Datenabfragen in enger Absprache mit der jeweiligen Plattform ebenfalls auf mehrere Knoten verteilen. Einmal, um keinen Knoten zu überlasten, zweitens aber, um ein Gesamtbild aller Daten zu bekommen. Denn jedes Backup-Konzept wird versagen, wenn es Plattformen nicht ihrem Charakter entsprechend unterstützt.

Wer die wilden Datenströme heute und auf lange Sicht zähmen will, sollte Hersteller auswählen, die zuerst einmal in der Lage sind, die vielen Workloads überhaupt zu sichern. Dies lässt sich anhand einfacher Checks schnell prüfen. Werden neben den klassischen Legacy-Plattformen und den virtuellen Stacks bereits moderne Workloads wie Mongo DB, HBASE, SAP Hana oder Hadoop abgedeckt? Ist der Backup-Hersteller bereits von den Herstellern der Big-Data-Plattformen zertifiziert? Wie schnell ist der Backup-Hersteller darin, neue Workloads zu unterstützen? Arbeitet der Anbieter mit den wichtigen Cloud-Providern zusammen und liefert zertifizierte Module, um mit ihnen und deren Cloud-Snapshots und Data Movern zu interagieren? Welche Historie hat er auf diesem Gebiet? Welche Strategie verfolgt er?


Das Backup-Konzept eines Herstellers muss für Big Data zudem skalieren, und zwar horizontal wie vertikal. Die Datenmengen werden weiter massiv wachsen und sich geographisch noch stärker auf verschiedenste Infrastrukturen verteilen. Der Hersteller muss in der Lage sein, an Orten, an denen sich grosse Datenmengen konzentrieren, leicht skalierbare und hochperformante Backup-Systeme zu liefern, die diese Mengen in den knappen Zeitfenstern wegschreiben können. Und sie müssen leicht in die Fläche skalieren, um den verteilten mehrstufigen Applikationen und ihren Daten folgen zu können und die Daten dem Charakter der Big-Data-­Plattform entsprechend sichern. Denn schliesslich haben Entfernung und Datenmenge massive Auswirkungen auf die Backup-Leistung.

Verantwortung verteilen

Das Backup-Konzept sollte in der Lage sein, die Verantwortung für die Big-Data-­Daten und -Workloads und ihre Wiederherstellung auf mehrere Schultern zu verteilen. Mitglieder der Data-Scientist-­Teams wollen ihre eigenen virtuellen Ressourcen kontrollieren und auf frühere Versionen zurückschalten, ohne auf die Backup-Teams angewiesen zu sein. Der Prozess sollte für die Teams in wenigen Klicks und ohne Backup-Schulung abzuwickeln sein. Sie sollen sich ja auf ihre Kernaufgabe konzentrieren und keine Zeit mit Nebenaufgaben vergeuden.


Beherrscht der Backup-Anbieter alle neuen und alten Plattformen, Workloads und die verschiedenen Big-Data-Architekturen, kann der Kunde alle Backup-­Anforderungen mit einer Software zentral abdecken und steuern. Dies wird sich massiv in den Betriebskosten des Back­ups widerspiegeln. Unter dem Strich sind all diese Eigenschaften essenziell, um heutige Big-Data-Umgebungen souverän abzudecken und zugleich dem Kunden zu garantieren, dass das Backup-­Konzept zukunftssicher ist.