Backup ist kein Disaster Recovery: was ein grünes Dashboard nicht beweist

Drei Plantypen in NIST SP 800-34 und wo Backup einzuordnen ist

Ein Backup bewahrt Kopien von Daten auf; Disaster Recovery bringt lauffähige Systeme zurück, meist an einem Ausweichstandort und innerhalb einer Wiederanlaufzeit, die das Unternehmen festgelegt hat. Die NIST Special Publication 800-34 Revision 1 unterscheidet drei Plantypen, die die meisten Organisationen als einen einzigen behandeln.

NIST SP 800-34 Rev. 1, Abschnitte 2.2 und 3.4.2 sowie das Glossar. In der Struktur von NIST ist Backup ein Bestandteil eines Plans.

Abschnitt 3.2.1 definiert die Zahlen: Der RTO ist „die maximale Zeitspanne, die eine Systemressource nicht verfügbar sein kann“, bevor die Auswirkung nicht mehr hinnehmbar ist, der RPO der Punkt, „auf den Daten von Mission- und Geschäftsprozessen wiederhergestellt werden können“. Unser Leitfaden zu RPO und RTO erklärt, wie man sie festlegt. NIST stellt Backup auch auf die Kostenkurve: Je kürzer der RTO, „desto teurer ist die Umsetzung der Wiederherstellungslösungen“, während ein System mit geringer Auswirkung und längerem RTO „ein weniger kostspieliges einfaches Bandbackup einsetzen könnte“.

AWS teilt dasselbe Feld in vier Strategien wachsender Fähigkeit: Backup and Restore, Pilot Light, Warm Standby und Multi-Site Active/Active. Backup and Restore ist die erste: AWS nennt sie „einen geeigneten Ansatz zur Abmilderung von Datenverlust oder Datenbeschädigung“ und ergänzt, dass sie mit in andere AWS-Regionen replizierten Daten auch eine regionale Katastrophe abfedern kann. Kopien an anderer Stelle bewahren die Daten; die Wiederherstellungszeit hängt trotzdem vom Neuaufbau der Umgebung und von der Wiederherstellung in diese Umgebung ab. Auf derselben Seite heißt es: „Wie oft Sie Ihr Backup laufen lassen, bestimmt Ihren erreichbaren Wiederherstellungspunkt.“ Die Backup-Frequenz legt den RPO fest und sagt nichts über den RTO. ISO 22301:2019 deckt dasselbe Feld ab, der Text der Klauseln steht jedoch hinter einer Bezahlschranke, die Definitionen hier stammen daher von NIST.

Was ein Backup nicht wiederherstellt

Ein Backup-Job erfasst Daten. Eine funktionierende IT-Umgebung braucht außerdem, was die Daten nutzbar macht: Identität, Schlüssel, Geheimnisse, die Management-Ebene und die Reihenfolge, in der Systeme starten dürfen. Jeder Punkt unten stammt aus der Dokumentation des jeweiligen Herstellers.

Identität. Der Leitfaden des Herstellers zur Wiederherstellung einer Active-Directory-Gesamtstruktur ist ein Verfahren aus fünf Schritten, und ein Backup liefert einen Teil von Schritt drei. Sie stellen je Domäne „einen beschreibbaren Domänencontroller aus dem Backup“ wieder her, wobei bei einem physischen Controller das Netzwerkkabel abgezogen bleibt, und führen darauf zwei Wiederherstellungen gleichzeitig aus: eine nicht autoritative Wiederherstellung der Verzeichnisdatenbank und eine autoritative Wiederherstellung von SYSVOL. Die übrigen Schritte erledigen Sie von Hand: Sie übernehmen die domänen- und gesamtstrukturweiten Betriebsmasterrollen, räumen die Metadaten jedes Controllers auf, den Sie nicht wiederherstellen, heben den verfügbaren RID-Pool um 100.000 an und setzen das krbtgt-Passwort zweimal zurück, denn „der Passwortverlauf von krbtgt umfasst zwei Passwörter“, und nach einem einzelnen Zurücksetzen bleibt ein gefälschtes Ticket gültig.

Der Aufräumschritt zählt auf, was das Backup nie enthielt. Ausgehende Vertrauensstellungen: „Diese externen Vertrauensstellungen werden nicht automatisch aus Backups wiederhergestellt.“ Die DNS-Konfiguration wird von Hand zurückgesetzt, und die Namenseinträge aller nicht wiederhergestellten Controller werden gelöscht. Alles nach dem Wiederherstellungspunkt, denn hinzugefügte Objekte und „Aktualisierungen (etwa Passwortänderungen) … gehen verloren“. Und zwei Details widersprechen den meisten Aufbewahrungs­richtlinien: Der Leitfaden empfiehlt, aus „Backups wiederherzustellen, die einige Tage vor … dem Ausfall erstellt wurden“, und das Backup selbst verfällt: Bei aktiviertem Papierkorb ist seine Lebensdauer „der Wert deletedObjectLifetime oder der Wert tombstoneLifetime, je nachdem, welcher kleiner ist“.

Schlüssel und Geheimnisse. Das PKI-Team desselben Herstellers hat im April 2010 dokumentiert, dass auf seinen Serverversionen 2008 und 2008 R2 ein Systemstatus-Backup den privaten Schlüssel der Zertifizierungsstelle überhaupt nicht erfasst hat. Nehmen Sie das Prinzip, nicht die Version: Der Schlüssel braucht ein bewusstes, getrennt geprüftes Backup, und eine ohne ihn wiederhergestellte Zertifizierungsstelle ist eine neue Zertifizierungsstelle. Cloud-Schlüsseldienste haben ihre eigene Variante davon: Prüfen Sie, ob Ihr Dienst einen ganzen Schlüsseltresor in einem einzigen Vorgang sichern kann und ob sich ein Backup außerhalb des Abonnements und der Region wiederherstellen lässt, aus denen es stammt, denn ein Plan, dessen Zweck es ist, diese Region zu verlassen, kann keine Backups nutzen, die an sie gebunden sind.

Die Management-Ebene. Ein dateibasiertes Backup des vCenter Server enthält Konfiguration, Inventar und historische Daten der Appliance, aber seine Wiederherstellung bedeutet eine Neubereitstellung. Broadcom beschreibt, dass „eine neue vCenter-Server-Appliance bereitgestellt und die Daten aus dem dateibasierten Backup“ dorthin kopiert werden, wofür zuerst ein funktionierender ESXi-Host zum Bereitstellen nötig ist; und wo vCenter High Availability im Einsatz war, kommt die Wiederherstellung ohne sie zurück: „Sie müssen den Cluster neu aufbauen.“ Ein Teil der Management-Ebene muss also bereits laufen, bevor sich die Management-Ebene wiederherstellen lässt. Ein Verfahren von Broadcom für den Verlust von vCenter und allen zugehörigen ESXi-Hosts zugleich haben wir nicht gefunden.

Die Reihenfolge. NIST SP 800-34 hält in Abschnitt 3.2.3 fest, dass „Prioritätsstufen festgelegt werden können, um Wiederherstellungsaktivitäten in eine Abfolge zu bringen“; die Durchführungs­verordnung (EU) 2024/2690 macht daraus für die von ihr erfassten Einrichtungen eine Pflicht, denn Buchstabe (e) der vorgeschriebenen Planinhalte lautet wörtlich „Reihenfolge der Wiederherstellung der Betriebsabläufe“. Die Reihenfolge entscheidet, ob überhaupt etwas starten kann: Identität und Namensauflösung kommen vor den Datenbanken, die sich gegen sie authentifizieren, und die Management-Ebene kommt vor den Maschinen, die sie einplant. Netzwerkkonfiguration und Lizenzserver gehören auf dieselbe Liste, auch wenn wir kein Herstellerdokument gefunden haben, das dies klar ausspricht; der nächstliegende Bezugspunkt ist daher Buchstabe (g), „erforderliche Ressourcen, einschließlich Sicherungen und Redundanzen“.

Wie lange eine vollständige Wiederherstellung dauert: die Rechnung

Die Wiederherstellungszeit entsteht aus drei Faktoren, die kein Dashboard zeigt: Bytes geteilt durch Durchsatz, die Zahl der Systeme und die Tiefe der Abhängigkeiten. AWS veröffentlicht dieselbe Rechnung für eine Übertragung von 82 TB; die Tabelle unten ist unsere eigene Division.

Unsere Rechnung: 82.000.000 MB geteilt durch die Dauerrate, in Dezimaleinheiten. Die Snowball-Edge-Dokumentation von AWS druckt dieselbe Division für ein 82-TB-Gerät; ihre Zeilen für 400, 200 und 100 MB/s stimmen mit unseren überein, die für 800, 60, 30 und 10 MB/s nicht. Eine Übertragungsrechnung, kein Wiederherstellungs-Benchmark für ein Backup-Produkt.

Bei 100 MB/s, einer respektablen Dauerrate auf einem Pfad der 1-GbE-Klasse, dauert die Übertragung von 82 TB 9,49 Tage, bevor eine einzige Maschine startet. Dieses Verhältnis rechnen wir selbst hoch: 500 TB bei dauerhaften 400 MB/s sind rund 14,5 Tage reine Datenbewegung; das ist unsere Rechnung, keine Angabe von AWS. Zum Beispiel ergeben dreihundert virtuelle Maschinen mit im Schnitt 273 GB Plattenplatz etwa 82 TB, also 2,37 Tage bei 400 MB/s und 9,49 bei 100, bevor sich jemand anmeldet. Die Rate wird vom langsamsten Element im Pfad bestimmt: GitLabs Post-mortem von 2017 hält eine Datenbankkopie fest, die „rund 18 Stunden“ dauerte, weil die Quelle auf etwa 60 Mbit/s gedrosselt war, rund 7,5 MB/s, langsamer als die unterste Zeile oben.

Der zweite Faktor ist die Stückzahl, die Atlassian im April 2022 live gemessen hat: rund 48 Stunden für einen Stapel Instanzen und rund 12 Stunden für eine einzelne Instanz, nachdem das Team mitten im Vorfall neue Werkzeuge gebaut hatte, über 883 Instanzen von 775 Kunden hinweg. Archivstufen fügen dann eine Wartezeit hinzu, bevor das erste Byte wandert. Amazon S3 Glacier Flexible Retrieval schließt Standardabrufe typischerweise in 3 bis 5 Stunden ab und Massenabrufe in 5 bis 12; im Deep Archive dauern Standardabrufe typischerweise bis zu 12 Stunden und Massenabrufe bis zu 48, und einen beschleunigten Abruf gibt es dort gar nicht. Liegt die einzige saubere Kopie im Deep Archive, planen Sie allein für den Abruf bis zu 12 Stunden beim Standardabruf und bis zu 48 Stunden beim Massenabruf ein, bevor die Wiederherstellung beginnen kann.

Ein wiederhergestelltes System läuft nicht unbedingt sofort mit voller Leistung. AWS dokumentiert, dass ein aus einem Snapshot erzeugtes Volume während der Initialisierung „erhöhte E/A-Latenz und verringerte Leistung“ zeigen kann und die volle Leistung erst erreicht, „wenn alle Speicherblöcke heruntergeladen und geschrieben sind“. Instant Recovery, das Veeam und andere Backup-Produkte anbieten, lässt eine Workload direkt aus der Backup-Datei mit verringerter Leistung laufen, bis sie auf den Produktionsspeicher migriert ist.

Mit unserem Disaster-Recovery-Service starten Ihre Systeme aus Replikaten an einem Ausweichstandort in Tier-III-Rechenzentren der EU. Nennen Sie uns, welche Systeme zuerst laufen müssen und wie lange jedes ausfallen darf; wir antworten innerhalb eines Werktages.

Ransomware macht das Backup zum Ziel

Alles bisher Gesagte setzt voraus, dass das Backup selbst unangetastet bleibt. Am deutlichsten zeigt die Fallarbeit bei Vorfällen, dass Angreifer gezielt gegen Backups vorgehen. M-Trends 2026, im März 2026 von Mandiant und Google Cloud aus über 500.000 Stunden Untersuchungen des Jahres 2025 veröffentlicht, sagt über Ransomware-Betreiber, dass sie „aktiv die Fähigkeit zur Wiederherstellung zerstören“. Beobachtet wurden Betreiber, darunter die Akteure hinter Akira und Qilin, die „Backup-Infrastruktur, Identitätsdienste und Management-Ebenen der Virtualisierung“ angriffen und Backup-Objekte aus dem Cloud-Speicher löschten: genau die drei Dinge, die ein grünes Dashboard nicht abdeckt. Die mediane Verweildauer lag bei 14 Tagen, nach 11 im Jahr davor.

Die Umfragezeilen geben wieder, was die Befragten über ihre eigene Erfahrung gesagt haben, keine Messungen.

Die Zeilen von Sophos und Veeam wirken widersprüchlich, messen aber Verschiedenes: Sophos fragt, ob überhaupt Daten zurückkamen, Veeam wie viele. Zusammen gelesen haben fast alle Befragten einen Teil ihrer Daten wiederhergestellt, und weniger als jeder Dritte hat alle Daten zurückbekommen. In demselben Sophos-Datensatz von 2024 zahlten Organisationen mit kompromittierten Backups fast doppelt so oft, 67 Prozent gegen 36, und ihre medianen Wiederherstellungskosten lagen achtmal höher.

Die erweiterte Regel 3-2-1-1-0 greift diesen Punkt auf. Veeam formuliert 3-2-1 als drei Kopien, zwei Medienarten und mindestens eine außer Haus, schreibt sie nur „den frühen 2000er-Jahren“ zu, ohne einen Urheber zu nennen, und erweitert sie zu 3-2-1-1-0: eine Kopie „an einem unveränderlichen oder per Air Gap getrennten Ort“ und „null Backup-Fehler dank automatischer Integritätsprüfungen und regelmäßiger Wiederherstellungs­tests“. Die letzte Ziffer verlangt Wiederherstellungs­tests; ein Backup-Satz, aus dem nie wiederhergestellt wurde, erfüllt die Regel also nicht. Das britische National Cyber Security Centre nannte 2019 den Grund für die Kopie außer Haus: Ransomware hat „die angeschlossenen USB- und Netzwerkspeicher mit den Datensicherungen“ verschlüsselt, weshalb „niemals alle Backups gleichzeitig angeschlossen“ sein sollten.

Immutability deckt einen Teil des verbleibenden Risikos ab, mit dokumentierten Grenzen. Bei Amazon S3 Object Lock lässt sich der Governance-Modus von jeder Identität umgehen, die das Bypass-Recht besitzt; gegen ein kompromittiertes Konto mit diesem Recht schützt er also nicht. Der Compliance-Modus ist absolut, bis auf einen Punkt: „Die einzige Möglichkeit, ein Objekt … vor Ablauf seines Aufbewahrungsdatums zu löschen, ist, das zugehörige AWS-Konto zu löschen.“ Drei weitere Grenzen ergeben sich aus unserer eigenen Überlegung, nicht aus Herstellertexten: Immutability bewahrt, was geschrieben wurde, einschließlich der Systeme, in die während einer Verweildauer von 14 Tagen bereits eine Hintertür eingebaut wurde, und der Daten, die vor dem Backup-Lauf verschlüsselt wurden; die Sperre läuft ab; und sie sagt nichts über den Wiederherstellungsdurchsatz oder darüber, ob es ein Ziel zum Wiederherstellen gibt. Die Mechanik steht in unserem Beitrag dazu, wovor unveränderliche Backups schützen. Immutability steht für eine der fünf Ziffern von 3-2-1-1-0.

Wiederherstellungs­tests in NIS2 und der Verordnung (EU) 2024/2690

Der ausführlichste EU-Text ist die Durchführungs­verordnung, nicht die Richtlinie. Die Durchführungs­verordnung (EU) 2024/2690 der Kommission gilt nur für die in ihrem Artikel 1 genannten Einrichtungen (DNS-Diensteanbieter, TLD-Namenregister, Anbieter von Cloud-Computing-Diensten und Rechenzentrumsdiensten, Betreiber von Inhaltszustellnetzen, Anbieter verwalteter Dienste und verwalteter Sicherheitsdienste, Anbieter von Online-Marktplätzen, Online-Suchmaschinen und Plattformen für Dienste sozialer Netzwerke sowie Vertrauensdienste­anbieter); jede andere Organisation im Anwendungsbereich von NIS2 ist an das nationale Gesetz gebunden, das Artikel 21 der Richtlinie (EU) 2022/2555 umsetzt, und welcher Text für Sie gilt, ist von Ihrer Rechtsabteilung zu bestätigen. Die Richtlinie wirkt über nationales Recht, und die nationale Umsetzung kann im Detail abweichen: In Österreich gilt seit 1. Oktober 2026 das NISG 2026 (BGBl. I Nr. 94/2025), in Deutschland seit 6. Dezember 2025 das NIS-2-Umsetzungs- und Cybersicherheits­stärkungs­gesetz (BGBl. 2025 I Nr. 301). Als technische Checkliste ist die Verordnung dennoch der klarste Text, den wir gefunden haben; ihr Punkt 4.1.1 bezieht den Plan auf „Artikel 21 Absatz 2 Buchstabe c der Richtlinie (EU) 2022/2555“. Nummer 4.2.6 ist die Klausel zur erprobten Wiederherstellung: Einrichtungen „führen regelmäßige Tests der Wiederherstellung von Sicherungskopien und Redundanzen durch, um sicherzustellen, dass sie bei der Wiederherstellung zuverlässig sind und alle Kopien, Verfahren und Kenntnisse abdecken, die nötig sind, um eine wirksame Wiederherstellung durchzuführen“. Von diesen dreien erscheinen nur die Kopien auf einem Backup-Dashboard. Verfahren heißt ein Runbook, das jemand anderes als sein Verfasser ausführen kann; Kenntnisse heißt Menschen, die Nummer 4.2.1 als „Personal“ neben Betriebsstätten, Netz- und Informationssystemen nennt.

Die Backup-Anforderungen in 4.2.2 eignen sich als Checkliste: Wiederherstellungs­zeiten; vollständige und genaue Kopien „einschließlich Konfigurationsdaten“; Speicherung an Orten, „die sich nicht im selben Netz wie das System sowie in ausreichend großer Entfernung befinden, um Schäden durch einen Notfall am Hauptstandort zu vermeiden“; Zugriffskontrollen; die Wiederherstellung von Daten; Aufbewahrungsfristen. Buchstabe (b) nennt Konfigurationsdaten ausdrücklich, und Buchstabe (c) ist die Außer-Haus-Hälfte von 3-2-1, geschrieben ins EU-Recht. Nummer 4.2.3 ergänzt regelmäßige Integritätsprüfungen.

Bei der Häufigkeit weichen die Texte voneinander ab. Punkt 4.1.4 sagt, der Notfallplan „wird in geplanten Zeitabständen sowie bei erheblichen Sicherheitsvorfällen oder wesentlichen Änderungen der Betriebsabläufe oder der Risiken getestet, überprüft“ und, soweit angemessen, aktualisiert. Wie oft unter NIS2 zu testen ist und was die Leitlinie der ENISA ergänzt, behandelt unser Leitfaden zu den Anforderungen von NIS2 an Backup und Business Continuity.

NIST SP 800-84 ist streng mit dem Vokabular: Eine Tabletop-Übung ist diskussionsbasiert, bei einer funktionalen Übung nehmen die Beteiligten „ihre Aufgaben in einer simulierten Betriebsumgebung“ wahr, und „der Begriff ‚Test‘ ist für das Prüfen von Systemen oder Systemkomponenten reserviert“, nicht für das Üben von Plänen. AWS formuliert es operativ in der Anforderung REL13: „Üben Sie den Wiederherstellungsweg, um zu prüfen, dass Sie die Wiederherstellung in der festgelegten Zeit in den festgelegten Zustand schaffen“, denn „die einzige Fehlerbehebung, die funktioniert, ist der Weg, den Sie häufig testen“. AWS Backup bietet die Überwachung der Dauer von Wiederherstellungsjobs als Funktion an, und die Wiederherstellungsdauer ist ein Beleg für den RTO, ein erfolgreiches Backup dagegen nicht. Nach einem Einbruch ergänzt NIST SP 800-61 Revision 3 zwei Prüfungen: die Wiederherstellungsressourcen „auf Kompromittierungsindikatoren, Dateibeschädigung und andere Integritätsprobleme vor der Nutzung“ und die wiederhergestellten Ressourcen, wobei „die Ursachen vor dem Produktiveinsatz“ zu beheben sind. Keine der beiden Prüfungen steht auf einem Backup-Bericht; beide gehören zu einem Design für Cyber-Resilienz.

Unser Disaster-Recovery-Service führt planmäßige Test­wiederherstellungen in einer isolierten Umgebung durch, mit einem Bericht darüber, was hochgekommen ist, wie schnell und was zu beheben ist. Schreiben Sie uns, welche Wiederherstellungs­zeiten Sie bisher gemessen haben; das erste Gespräch ist kostenlos.

Wo die Backups vorhanden waren und die Wiederherstellung trotzdem scheiterte

Jeder Fall unten stammt aus dem veröffentlichten Bericht der Organisation selbst oder aus der Aussage ihres Vorstandsvorsitzenden vor dem US-Senat. Presseberichte werden nicht verwendet.

Die British Library bestätigt in ihrer eigenen Analyse vom März 2024, dass „brauchbare Backup-Quellen gefunden wurden, die nicht betroffen waren“, und formuliert dann die These dieses Artikels aus Sicht des Opfers: „Wir sind vorübergehend dadurch behindert, dass es keine brauchbare Infrastruktur gibt, auf der wir sie wiederherstellen könnten.“ Der Angreifer hatte es bewusst auf den Unterbau abgesehen, mit einer Vorgehensweise, die „die Zerstörung von Servern zur Behinderung der Systemwiederherstellung“ einschloss, und einige Schlüsselsysteme „können nicht in der Form zurückgebracht werden, in der sie vor dem Angriff bestanden“. Den Zeitbedarf bestimmte die Infrastruktur, nicht die Daten: „Die Abhängigkeit von Altinfrastruktur ist der wichtigste Faktor für die Dauer“ der Wiederherstellung.

Bei GitLab fielen die Backups aus, ohne dass es jemand bemerkte. Das Post-mortem zum Ausfall vom 31. Januar 2017 zählt fünf Backup- und Replikationsmechanismen auf, von denen keiner ein brauchbares aktuelles Backup hervorbrachte: „Der S3-Bucket war leer, und nirgends war ein aktuelles Backup zu finden.“ Die Ursache war ein Versionsunterschied, „pg_dump 9.2, während unsere Datenbank auf PostgreSQL 9.6 läuft“, und niemand wusste davon, weil die Fehlermeldungen des Cron-Jobs per E-Mail verschickt wurden und „DMARC nicht aktiviert“ war, sodass sie abgewiesen wurden. Rund 5.000 Projekte, 5.000 Kommentare und 700 neue Benutzerkonten waren endgültig verloren.

Atlassian hatte ausgezeichnete Backups und trotzdem eine langsame Wiederherstellung. Die Analyse hält fest, dass die Datenbanken eine Wiederherstellung auf „jeden beliebigen ‚Point in Time‘ … innerhalb der Aufbewahrungsfrist der Backups (30 Tage)“ erlaubten. Die Daten waren verfügbar, die Orchestrierung für ihre Wiederherstellung jedoch nicht: „Wir hatten nicht die Möglichkeit, eine große Menge von Kundeninstanzen auszuwählen und alle ihre miteinander verbundenen Produkte wiederherzustellen.“ 775 Kunden waren über bis zu 14 Tage betroffen, und die Analyse sagt es unverblümt: „Während dieses Vorfalls haben wir unseren RTO verfehlt, aber unseren RPO eingehalten.“

Change Healthcare ist ein Fall, in dem die Rücksicherung nicht der Weg zurück war. In seiner Aussage vor dem Finanzausschuss des US-Senats am 1. Mai 2024 erklärte der Vorstandsvorsitzende von UnitedHealth, das kompromittierte Portal habe „keine Multi-Faktor-Authentifizierung“ gehabt und „Ransomware wurde neun Tage später ausgerollt“. Der Aussage zufolge begann das Team, „die Technologieinfrastruktur von Change Healthcare von Grund auf neu aufzubauen“. Nach unserer Lesart ist nach einer Kompromittierung dieser Tiefe das Wiederherstellungsziel selbst nicht vertrauenswürdig. Die Aussage nennt keine Ausfallzeit und geht nicht auf Backups ein.

Bei Norsk Hydro und Maersk hatte die Wiederherstellung kein eindeutiges Enddatum. Hydros eigener Bericht zum ersten Quartal 2019 beziffert die Auswirkung des Angriffs vom März auf 300 bis 350 Millionen NOK in diesem Quartal und schätzt „rund 200 bis 250 Millionen NOK“ für das zweite. Maersks eigene Veröffentlichungen beziffern die Wirkung von NotPetya auf 250 bis 300 Millionen USD, die „Umsatzausfälle, IT-Wiederherstellungskosten und außerordentliche Kosten“ umfassen. Die vielzitierten operativen Zahlen zu diesem Wiederaufbau stammen aus Bemerkungen des Verwaltungsratsvorsitzenden auf einem Podium im Januar 2018, stehen in keiner von uns auffindbaren Veröffentlichung von Maersk und werden hier nicht gedruckt.

Was ein Wiederherstellungsplan enthält und eine Backup-Richtlinie nicht

Für die erfassten Einrichtungen hat der Verordnungsgeber die Gliederung bereits geschrieben, und sie taugt für jeden als Checkliste. Die Durchführungs­verordnung (EU) 2024/2690 zählt in Punkt 4.1.2 auf, was der Plan enthalten muss:

1. Zweck, Umfang und Adressaten
2. Rollen und Verantwortlichkeiten
3. wichtige Kontakte sowie interne und externe Kommunikationskanäle
4. Bedingungen für die Aktivierung und Deaktivierung des Plans
5. Reihenfolge der Wiederherstellung der Betriebsabläufe
6. Wiederherstellungs­pläne für einzelne Betriebsabläufe, einschließlich der Wiederherstellungs­ziele
7. erforderliche Ressourcen, einschließlich Sicherungen und Redundanzen
8. Wiederherstellung und Wiederaufnahme der Tätigkeiten aus vorübergehenden Maßnahmen

Prüfen Sie Ihre Wiederherstellungsunterlagen gegen diese Liste und gegen sechs Dinge, die sie voraussetzt: eine datierte, gemessene Zeit bis zur Wiederaufnahme des Betriebs für Ihre wichtigsten Geschäftsprozesse, gewonnen aus einer Übung und nicht aus der Erfolgsquote von Backup-Jobs; das Ziel, in das Sie wiederherstellen, konkret benannt (welche Hosts, in welchem Netz und wer bestätigt, dass es sauber ist, bevor irgendetwas startet); ein Identitäts-Runbook mit ausgeschriebenen Schritten der Gesamtstruktur-Wiederherstellung und den Personen, die sie ausführen dürfen; die Verwahrung des privaten Schlüssels der Zertifizierungsstelle und der Geheimnisse, die das Backup nicht enthält; einen Plan zur Neubereitstellung der Hypervisor-Management-Ebene, weil der Hersteller eine Neubereitstellung dokumentiert und keine Wiederherstellung; und die Abhängigkeitsreihenfolge mit dem, was auf was wartet.

Was wir tun

Im Rahmen unseres Disaster-Recovery-Service legt unser Engineering-Partner Vixen.UNO gemeinsam mit Ihnen die kritischen Systeme, die Zielwerte für RPO und RTO je Systemstufe und die Katastrophenszenarien fest; das Ergebnis ist ein Continuity-Plan, nicht nur Kopien. Die Replikation läuft mit Veeam zu einem Ausweichstandort in Baltnetas Tier-III-Rechenzentren in Litauen, mit planmäßigen Test­wiederherstellungen. Eurokommerz hält den Vertrag und liefert die Hardware.

FAQ