ICT-News Dach

Die Rolle von Business Continuity, Desaster Recovery, BackUp/Restore im Zeitalter von Big Data

Holm Landrock

Spielen Business Continuity und Desaster Recovery im Zeitalter von Big Data noch eine Rolle? Business Continuity gilt natürlich in erster Linie für geschäftskritische Applikationen. Doch wenn Self-service-BI, Advanced-BI und Big Data in den Unternehmensalltag einziehen und diese Analysen für geschäftliche Entscheidungen herangezogenen werden, so rücken die zugrundeliegenden Daten eben auch in den Fokus von Business-Continuity, Hochverfügbarkeit, Backup und Datenspiegelung.

Traditionelle, hardwarebasierende Technologien wie RAID-Verfahren und Snapshots sind nur bedingt für die Sicherung großer Datenmengen gegen Verluste und vor allem gegen Irrtümer geeignet.

Mit der Macht der Daten entwickelte sich – gerade eben in den letzten zehn Jahren – eine immer tiefgreifendere Abhängigkeit von den Daten. Zu den herkömmlichen Bedrohungsszenarien haben sich in den letzten Jahren neue gesellt, dabei vor allem Ransomware-Attacken.

Komplexer wird es bei Streaming-Big-Data-Analysen, obwohl es ja auch für diese Daten „Source und Drain“ gibt. Hier ist zunächst die Frage zu beantworten, ob die Quelldaten ein zu schützendes Gut sind oder ob Ergebnisse und Zwischenergebnisse zu sichern wären. Objekte der Hochverfügbarkeit müssen auch Streaming-Data sein. Das lässt sich vor allem damit begründen, dass möglicherweise logische Fehler (am häufigsten rein menschliche wie das versehentliche Löschen, Ändern oder Verschieben von Daten) sowie technische Fehler (Controller-Störung, Störungen von Speicher- und Übertragungsmedien) eine Berechnung verfälscht haben (siehe auch den Newsletter-Beitrag zum Thema Datenintegrität in KW27).

Sicherlich müssen nicht für alle Big-Data- und Advanced-BI-Anwendungen aufwendige Business-Continuity- und Desaster-Recovery-Konzepte installiert werden. Doch in erstaunlich vielen Fällen sind die Entscheidungen eben geschäftskritisch und unter Umständen müssen beispielsweise aus gesetzlichen oder steuerlichen Gründen Daten gespeichert werden. Produktvorausverfolgung, Dokumentationspflichten, elektronische Prozessdokumentationen bis hin zu den zurzeit gern diskutierten Gesundheitsdaten sind hier nur die prominentesten Beispiele. Das gilt dann eben auch für die Big Data.

Einige Konzepte wie hardwareseitige Redundanz, Fail-over, Ersatzsysteme, Snapshots und die synchrone Spiegelung sind mitunter nur bedingt geeignet. Denn sollten sich logische Fehler ereignen, verteilen sich diese als vermeintlich korrekte Manipulation der Daten mit dem vollen Tempo moderner IT-Infrastrukturen über alle beteiligten Systeme. Die asynchrone Spiegelung kann hier ein hilfreicher Ansatz sein.

Eine vollständige Redundanz und Sicherheit würde schlussendlich nur ein Spiegel-Data-Center liefern, was natürlich so viel kostet, wie die primäre Landschaft. An Komplexität gewinnt die Thematik noch, wenn Cloud-Strukturen beteiligt sind.

Datenvolumina und die Datenübertragung werden nach unseren Beobachtungen von den Anbietern Cloud-basierender DR-Lösungen gerne erst spät im Projekt thematisiert. Ein Grund dafür könnte der teils enorme Aufwand für Hochverfügbarkeit / Business Continuity / Desaster Recovery in der Cloud sein. Vorhandene Backup- und Restore-Implementierungen gelten als stabil, sicher, steuerbar und kontrollierbar, können jedoch rasch an physische Grenzen stoßen.

Im Rahmen von Big-Data-Projekten sollte – gegebenenfalls losgelöst vom Lösungsgeschäft – ein Assessment zu den Daten, Datenwegen und den Sicherungs-Levels stattfinden. Hier sind auch Normen, Richtlinien und Empfehlungen des Gesetzgebers bzw. von Branchenvereinigungen einzubeziehen. Das Assessment sollte zeigen, welche Verfahren – darunter beispielsweise auch dezentrale Lösungen oder Edge-bzw. Grid-Computing-Konzepte – und welche Technik zielführend sein können.