Das Thema Big Data genießt derzeit bei vielen Unternehmen höchste Priorität. Insbesondere bei denen, die die sich der zentralen, geschäftskritischen Rolle von Daten bewusst sind. Dennoch ringen viele Firmen damit herauszufinden, welche Maßnahmen am besten geeignet sind, die Daten zu managen, analysieren und zu schützen - innerhalb einer modernen IT-Architektur, versteht sich. Wer dieses Thema außen vor lässt, riskiert ausgedehnte Ausfallzeiten und Datenverlust. Letzteres kann Unternehmen schnell einige Millionen Dollar kosten.

Big-Data-Plattformen wie Hadoop, Cassandra oder HPE Vertica werden - im Gegensatz zu traditionellen Plattformen wie etwa Oracle, oder SQL, die normalerweise der Kontrolle der IT-Abteilung unterstehen - in der Regel von Entwicklern oder DevOps gemanagt.

7 Big-Data-Mythen bei Backup & Recovery

Speziell wenn es beim Thema Big Data um Maßnahmen zur Sicherung und Wiederherstellung von Daten geht, kommt es immer wieder zu konzeptionellen Missverständnissen - mit denen wir an dieser Stelle aufräumen wollen:

1. Mythos 1: Wer seine Daten mehrfach kopiert, braucht keine separaten Backup- oder Recovery-Tools für Big Data. Die meisten Big-Data-Plattformen fertigen mehrere Kopien der Daten an und distribuieren diese Kopien auf verschiedene Server. Dieses Vorgehen schützt die Daten bei Hardware-Fehlern oder -Ausfällen. Bei jeder anderen Art von Fehler - also beispielsweise Bedienfehler, versehentliche Löschungen oder Daten-Korrumpierung - droht hingegen der Datenverlust, weil sich genannte Fehler rasch auch auf die Kopien ausbreiten.

2. Mythos 2: Verloren gegangene Daten können schnell und einfach aus den Raw-Daten wiederhergestellt werden. Das funktioniert nur dann, wenn die Rohdaten auch vollständig vorhanden sind. In den allermeisten Fällen sind diese Daten aber entweder gelöscht oder nicht ohne Weiteres zugänglich. Und auch wenn die Rohdaten zur Verfügung stehen: Ein Datenverlust auf dem Level von Big Data wieder wett zu machen, kann Wochen dauern. Das wiederum frisst wertvolle Ressourcen und bedeutet ausgedehnte Ausfallzeiten für die Plattform-Nutzer.

3. Mythos 3: Das Backup von Datensätzen, die ein Petabyte oder größer sind, ist weder wirtschaftlich noch zweckmäßig. Regelmäßige und vollständige Backups von einem Petabyte Daten dauern mehrere Wochen und erfordern Infrastruktur-Ausgaben von über einer halben Million Dollar. Allerdings gibt es einige Maßnahmen, wie Sie die Ausgaben eindämmen können: Sie könnten zum Beispiel nur den wirklich geschäftskritischen Teil des Datensatzes sichern. Auch neue Backup-Techniken wie Deduplikation oder die Nutzung von Commodity-Servern können die Kosten senken und die Zeit bei der Datensicherung sparen.

4. Mythos 4: Remote-Disaster-Recovery-Kopien können als Backup fungieren. Es ist klug, Kopien von Datensätzen in einem Remote-Data-Center aufzubewahren, um beispielsweise gegen Naturkatastrophen gewappnet zu sein. Dazu werden die Daten normalerweise regelmäßig vom Data Center zum Disaster-Recovery-Data Center kopiert. Allerdings werden generell alle Veränderungen im Data Center auch an das Desaster-Recovery-Zentrum weitergegeben - also auch Datenbank- oder Applikations-Fehler. Eine Disaster-Recovery-Kopie kann also nicht als Backup zum Einsatz kommen, weil die Dateien, für einen Wiederherstellungspunkt nicht vorhanden sind.

5. Mythos 5: Ein Backup-/Recovery-Skript für Big Data zu schreiben, ist einfach. Ein Skript zu schreiben kann durchaus sinnvoll sein. Wenn Sie die Ressourcen haben, es sich um eine überschaubare Datenmenge handelt und nur eine Big-Data-Plattform zum Einsatz kommt. Allerdings streuen Unternehmen in der Regel etliche Terabyte an Daten über eine Vielzahl von Plattformen. Für diese Umgebungen ein Skript zu entwerfen, ist alles andere als leicht. Ein solches Skript muss für jede Plattform, auf der ein Backup erstellt werden soll, eigens geschrieben werden. Zudem sind die Skripte auch noch hinsichtlich ihrer Skalierbarkeit zu testen. Und wenn eine Plattform ein Update erhält, muss auch die Funktion des Skripts jedes Mal neu überprüft werden. Vom Einsatz soclher Lösungen bei neuen Features, APIs oder Datentypen einmal ganz abgesehen. Viele Unternehmen vergessen zudem, dasss ein gutes Backup-Skript für eine Big-Data-Plattform mit signifikanten versteckten Kosten und dem Bedarf an jeder Menge Expertise einhergeht. Der Wiederherstellungsprozess ist nämlich ebenfalls bedeutend schwieriger und auch fehleranfälliger, weil die richtigen Backups gefunden und an den entsprechenden Wiederherstellungspunkten wieder eingesetzt werden müssen, bevor schließlich ein Plattform-spezifischer Prozess die Daten wiederherstellen kann.

6. Mythos 6: Die Kosten für ein Backup bzw. eine Wiederherstellung bei Big Data sind sehr gering. Zusätzlich zur regelmäßigen Wartung und dem Testen von Skripten lauern weitere Zusatzkosten. Dazu gehören mehrere Kostenfaktoren. 1. Kosten für Mitarbeiter: Sie brauchen einen Verantwortlichen für das Skripting und Debugging, sowie die erfolgreiche Anfertigung von Backups; 2. Kosten für Storage: Schließlich müssen die Backups auch irgendwo gespeichert werden; 3. Kosten für Downtime: Während der Zeit, in der der Admin mit der Wiederherstellung der Daten beschäftigt ist. Insbesondere in den immer komplexer werdenden Big-Data-Umgebungen können sich diese Kosten signifikant aufsummieren.

7. Mythos 7: Snapshots sind ein effektiver Backup-Mechanismus für Big Data. Unter einem Snapshot versteht man Daten, die zu einem bestimmten Zeitpunkt "eingefroren" wurden. Manchmal werden diese Snapshots als Backups verwendet, um sich gegen User- oder Applikations-Fehler zu schützen. Bei dem Einsatz solcher Snapshots sollten Sie einige Punkte bedenken: 1.) Snapshots können genutzt werden, um den Backup-Prozess zu automatisieren. Um die Konsistenz der Backup- und Meta-Daten zu gewährleisten, sind jedoch einige spezielle Maßnahmen von Hand zu treffen. 2.) Snapshots sind dann effizient, wenn sich die Daten nicht kontinuierlich verändern. Das ist bei Big-Data-Plattformen nicht der Fall. Im Gegenteil: Die Veränderungs-Rate ist generell hoch und bestimmte Techniken wie etwa "Compaction" treiben diese noch weiter nach oben. Will man also einige aktuelle Kopien "auf Lager" haben, beanspruchen die Snapshots erheblichen Speicherplatz. 3.) Eine Datenwiederherstellung über Snapshots stellt einen langwierigen und zeitaufwändigen manuellen Prozess dar. Denn der Admin muss erst einmal die Snapshots identifizieren, die den wiederherzustellenden Datensätzen entsprechen. Jegliche Fehler bei diesem Wiederherstellungsprozess können zu permanentem Datenverlust führen.

Fazit: Kein Big Data ohne Backup & Recovery

Zusammenfassend lässt sich sagen, dass Unternehmen die Big-Data-Plattformen und -Applikationen einsetzen, sich der Notwendigkeit regelmäßiger Backups bewusst sein sollten. Die in den Plattformen integrierten Maßnahmen wie Sicherungskopien und Snapshots alleine genügen nicht, um einen standesgemäßen Datenschutz und eine hohe Datenverfügbarkeit zu gewährleisten. Die dafür notwendigen Investitionen zahlen sich aus, denn Big Data ist heute ein wesentlicher Treiber des Business Value.

Unternehmen sollte sich auch der versteckten Kosten bewusst sein, die eine selbstentwickelte Lösung zur Folge hat und die richtigen Technologien einsetzen, um ihre Recovery Point Objectioves (RPO) und Recovery Time Objectives (RTO) erfüllen zu können.

Gar keine Lösung für Backup- und Recovery-Zwecke zu haben, ist übrigens die denkbar schlechteste Option. Schließlich sind menschliche Fehler oder korrumpierte Datensätze Probleme, vor denen man niemals zu einhundert Prozent geschützt ist.

Dieser Artikel basiert auf einem Beitrag unserer US-Schwesterpublikation networkworld.com.