Ein Backup ist noch keine Wiederherstellbarkeit. Entscheidend ist, ob ein geschäftskritischer IT-Service nach einer Störung innerhalb einer bestimmten Zeit und definierten Verlustgrenzen in einen sicheren, technisch funktionsfähigen und fachlich konsistenten Zustand zurückkehrt. Dafür müssen Geschäftsverantwortliche, Architektur und Betrieb dieselben Ziele verfolgen – und deren Erreichung regelmäßig testen. Backups allein helfen jedenfalls nicht!

Warum 3-2-1 notwendig ist

Eines Tages (das war 2023) bekam ich keine E-Mails mehr und meine handgestrickte Homepage war nicht erreichbar. Genauso wenig erreichbar war der Hoster, weder per Mail noch per Telefon. Ich witzelte noch, dass wohl dort ein Meteorit eingeschlagen hätte. Doch tatsächlich war es für die Firma ein Desaster: Das Unternehmen war Opfer eines Cyberangriffs, der sämtliche Systeme verschlüsselt und lahmgelegt hatte. Betroffen waren nicht nur die virtuellen Maschinen, sondern auch deren Backups! Die Wiederherstellung dauerte Wochen. Ein Kunde meldete Schäden in Millionenhöhe.

Ein Betroffener stellte fest: “Backups allein nützen nichts, diese können genauso vom Schadcode befallen sein.” Diese Erkenntnis ist Bestandteil der goldenen Regel der Datensicherung. Die 3-2-1-Regel besagt, dass es 3 Kopien der Daten auf 2 verschiedenen Medien geben muss, von denen sich 1 an einem anderen Ort befinden muss. Dabei wird “3 Kopien” unterschiedlich verstanden, meist als Gesamtzahl (also 1 Original plus 2 echte Kopien), jedoch schreibt der Storage-Experte Curtis Preston in seinem Buch Modern Data Protection (O’Reilly 2021, S.43), in dem er die Regel gleichsam zur Definition von “Backup” erhebt: “three additional versions of your data”. Es sollten auch 2 physisch verschiedene Medien sein. Die Bedingung “1 an einem anderen Ort” ist sowohl geografisch als auch logisch gemeint. Es sollte keinen direkten Weg von dem gesicherten Bereich zum Bereich der Sicherungen geben, denn sonst werden die Backups (wie in meinem Fall) gleich mit erbeutet. Man spricht auch von dem Air-Gap, der die Backups so trennen muss, dass der Angreifer ihn nicht überspringen kann.

Warum 3-2-1 nicht ausreicht

Wenn die Daten schließlich nach der goldenen 3-2-1-Regel und zusätzlich noch auf einem WORM (Write Once Read Many)-Speicher unveränderlich gesichert sind, ist dann alles unter einem guten Stern? Nein – leider reicht das noch immer nicht. Die Frage ist: Wurde die Wiederherstellung, also das Hochziehen der Infrastruktur, das Einspielen der Backups, der Neustart der Services schon mal getestet? Selbst wenn das DevOps-Team antwortet: “Ja klar, das ist kein Thema, denn wir machen schon längst Infrastructure as Code!”, fehlt noch was. Wurde getestet, wie die Software mit dem Datenverlust umgeht? Sie mag technisch lauffähig sein, aber die Gefahr ist groß, dass sich das verteilte System in einem fachlich inkonsistenten Gesamtzustand befindet. Ist sichergestellt, dass dann nichts Unerwartetes passiert? Könnten, zum Beispiel, die letzten Bestellungen der Kunden verloren sein, und sie erhalten weder Ware noch eine E-Mail mit einer Entschuldigung? Wissen wir überhaupt noch, wer schon bezahlt hat? Oder noch schlimmer: Könnten die Bestellungen zwar gerettet, aber die Zustellungsdaten verloren sein? Muss jemand ins Lager laufen, um zu verhindern, dass die Ware noch einmal verschickt wird? Der Neustart kann so zu einem Gang durch die Hölle werden.

3-2-1 is not enough: Data inconsistency after recovery DE

Störung - Notfall - Krise

Es müssen nicht einmal ein Ransomware-Angriff oder ein Feuer im Rechenzentrum (wie zum Beispiel 2025 in Korea) sein, die zu einem Notfall führen. Ein Bug in einem Synchronisationsservice oder ein schlichter Bedienfehler kann bereits der Auslöser sein. Eine eigentlich beherrschbare Störung kann sich in einer komplexen Servicelandschaft schnell ausbreiten und wichtige Geschäftsprozesse beeinträchtigen oder vollständig zum Erliegen bringen. Die Störung hat sich zu einem Notfall ausgewachsen. Was dann zu tun ist, hat man sich hoffentlich vorher überlegt, denn wenn man einen Notfall und keinen Plan hat, ist man in der Krise. Das ist der Kern der Definition nach BSI-Standard 200-4 Business Continuity Management (BCM), das sich mit der Frage befasst, wie auf eine Störung oder den Ausfall von zeitkritischen Geschäftsprozessen angemessen zu reagieren ist. Das Stufenmodell der Schadensereignisse (Störung, Notfall, Krise) hilft auch, die sich überschneidenden Bereiche Backup/Restore und Disaster Recovery genauer zu differenzieren. Der wesentliche Unterschied besteht nicht so sehr darin, dass andere Infrastrukturebenen betroffen sind, sondern dass sich zum Beispiel versehentlich gelöschte Daten innerhalb des “normalen” Betriebs durch geeignete Restore-Prozesse zurückholen lassen. Disaster Recovery beinhaltet neben allerlei anderen Notfallmaßnahmen einen Wiederanlauf zu einem Notfallbetrieb, damit die wichtigsten Geschäfte möglichst rasch weitergehen können. Die Rückkehr zum Normalbetrieb wird dagegen als Wiederherstellung bezeichnet. Wiederanlauf und Wiederherstellung können sequentiell oder parallel ablaufende Aktivitäten sein.

3-2-1 is not enough: BSI Model of incident classification DE

Business-Impact-Analyse

Ein zentrales Mittel des BCM ist die Business-Impact-Analyse (BIA), die untersucht, welche Geschäftsprozesse zeitkritisch sind und ab wann deren Ausfälle nicht tolerierbare Auswirkungen haben. Die BIA liefert als Ergebnis verschiedene Kennzahlen, für die Prozesse selbst aber daran anknüpfend auch für die von den Prozessen benötigten Softwaresysteme (im BCM nur grob als “Ressourcen der Kategorie IT“ angesehen). Diese Kennzahlen haben die bekannten Namen Maximum Tolerable Period of Disruption (MTPD), Recovery Time Objective (RTO) oder Recovery Point Objective (RPO). Sie geben an, wie schnell ein System wieder anlaufen muss (zum Beispiel innerhalb von 4 Stunden) und wie viel Information oder Daten verloren gegangen sein darf (zum Beispiel Benutzerkommentare des letzten Tages oder Bestellungen, die dem Kunden gegenüber noch nicht bestätigt wurden). Die Wiederherstellbarkeit oder Wiederherstellungsfähigkeit (je nachdem, ob man es als Qualitätsmerkmal oder als capability betrachten möchte) lässt sich definieren als

die Fähigkeit eines IT-Services oder Softwaresystems, nach einer Störung innerhalb definierter Zeit- und Datenverlustgrenzen (RTO, RPO) einen festgelegten Betriebszustand fachlich konsistent wiederherzustellen.

Wiederherstellbarkeit

An dieser Stelle gibt es im Unterschied zur durchdachten Lehrbuchwelt in der Realität einen Bruch. Die BIA ist vom Konzept her ein Top-Down-Ansatz, das bedeutet, sie leitet Anforderungen als Kennzahlen ausgehend von der Business-Architektur über die Enterprise-Architektur bis hinunter zur IT-Architektur weiter. In diesem Idealbild weiß der Administrator aufgrund der Kritikalität der Geschäftsprozesse, welche Kombination aus Voll-Backups und inkrementellen Backups, Snapshots sowie kontinuierlich gesicherten Transaktionsprotokollen benötigt wird und ob nur diskrete Sicherungsstände oder eine Point-in-Time Recovery erforderlich sind, und natürlich welche Aufbewahrungszeiten (retention) konfiguriert werden müssen. In der Praxis sieht es aber oft anders aus. Wahrscheinlich werden von den DevOps-Kollegen Fragen aufkommen wie: “Muss ich für Apache Kafka eigentlich auch Backups machen, oder können die Topics verloren gehen?” Oder: “Entscheidet über die Backups nicht der Datenbank Service Provider?” Das fehlende Glied in der Kette ist dann möglicherweise schlicht die fehlende Anforderung in der Softwarearchitektur. Hand aufs Herz: wurde bei Ihnen die Wiederherstellbarkeit überhaupt als Anforderung formuliert, zum Beispiel als klassische Systemanforderung:

“Das System muss so ausgelegt und betrieben werden, dass es nach einer Störung oder einem Ausfall innerhalb der durch den RTO-Wert festgelegten Zeit in den definierten Betriebszustand wiederhergestellt werden kann. Der Wiederherstellungspunkt darf dabei höchstens um den durch den RPO-Wert festgelegten Zeitraum vor dem Eintritt der Störung liegen.”

Gerne auch als User Story:

“Als Service Owner eines geschäftskritischen IT-Services möchte ich, dass das System nach einer Störung oder einem Ausfall innerhalb des festgelegten RTO-Wertes in den definierten Betriebszustand wiederhergestellt werden kann und der wiederhergestellte Datenstand höchstens um den festgelegten RPO-Wert vor dem Störungszeitpunkt liegt, damit der unterstützte Geschäftsprozess innerhalb der tolerierbaren Unterbrechungs- und Datenverlustgrenzen fortgesetzt werden kann.”

Wenn keine Anforderung zur Wiederherstellbarkeit explizit an die Software gestellt ist, dann kann man nicht erwarten, dass ein Wiederanlauf gelingen wird. Denn: wo keine Anforderung, da keine Umsetzung! Ist das Unglück geschehen, werden nachträgliche Vorwürfe, es seien “allgemein anerkannte Regeln der Technik” nicht beachtet worden, oder Diskussionen über ein besseres Risikomanagement, auch nicht mehr helfen.

Nur mit Tests

Konkrete Anforderungen haben noch eine weitere Auswirkung: sie erzwingen entsprechende Tests. Nun können die Applikationseigner gegenüber den verantwortlichen Entscheidern argumentieren, dass ausreichend Zeit und Ressourcen für Restore- und Wiederanlauftests eingeplant werden müssen. Es ist ein weit verbreitetes Problem, dass keine hinreichend realistische Testumgebung zur Verfügung steht. Insbesondere die Herstellung und Pflege von Testdaten ist in der Regel sehr aufwändig. Und schließlich muss ja nicht nur getestet werden, wie ein System wiederhergestellt werden kann, sondern die Effekte der Datenverluste und der Inkonsistenzen des verteilten Systems sind schwer vorhersehbar. Ohne aussagekräftige und belastbare Tests ist man nicht vorbereitet.

Nach diesem Rundflug sehen wir, dass das Themenfeld Wiederherstellbarkeit, Disaster Recovery, Backup/Restore und Datenkonsistenz nicht nur auf einer Ebene behandelt werden kann, sondern eine Gesamtaufgabe für die Organisation darstellt:

Die Geschäftsarchitektur muss mit einer BIA Anforderungen in Form von MTPD, RTO, RPO bereitstellen
Die Wiederherstellbarkeit muss in der Architektur als Anforderung verankert und mit den Kennzahlen konkretisiert sein
Nur mit den entsprechenden Anforderungen kann man erwarten, dass die Software entsprechend implementiert und betrieben wird
Die goldene 3-2-1-Regel für Backups muss umgesetzt werden
Der Wiederanlauf muss mit einem hinreichend produktionsnahen und mit realistischen Testdaten gefüllten Testsystem erprobt werden. Dafür sind ausreichend Mittel einzuplanen.

Übrigens: meine Homepage kam zurück. Nicht nur, weil ein Backup existierte, sondern weil ich sie unabhängig wiederherstellen konnte - einfach per FTP. Wie sieht Ihr Plan aus?

Abkürzungen und Begriffe

In diesem Bereich gibt es viele Fachbegriffe und Abkürzungen, daher bietet das BSI einen eigenen Glossar an.

BCM: Business Continuity Management (deutsch: Notfallmanagement)
BIA: Business-Impact-Analyse
BSI: Bundesamt für Sicherheit in der Informationstechnik
FTP: File Transfer Protocol
MTPD: Maximum Tolerable Period of Disruption (deutsch: maximal tolerierbare Ausfallzeit)
RPO: Recovery Point Objective (deutsch: maximal zulässiger Datenverlust)
RTO: Recovery Time Objective (deutsch: geforderte Wiederanlaufzeit (WAZ))