Firewalls können versagen. Sicherheitslücken können übersehen werden. Administratoren können Fehler machen. Hardware kann ausfallen. Und trotz EDR, Netzwerksegmentierung und aktueller Sicherheitsupdates kann Ransomware irgendwann einen Weg in die Infrastruktur finden.

Deshalb gehört zu einer belastbaren Cybersecurity-Strategie immer eine zweite Verteidigungslinie:

Backup und Disaster Recovery.

Die entscheidende Frage lautet nicht nur:

„Wie verhindern wir einen Ausfall?“

Sondern ebenso:

„Wie schnell und zuverlässig können wir danach wieder arbeiten?“

Gerade im Zusammenhang mit NIS-2 ist diese Fähigkeit von zentraler Bedeutung. Cyberresilienz bedeutet schließlich nicht, dass niemals etwas passiert. Sie bedeutet auch, dass eine Organisation auf Störungen vorbereitet ist, deren Auswirkungen begrenzen und ihre wesentlichen Dienste wiederherstellen kann.

Ein funktionierendes Backup ist dabei unverzichtbar.

Aber ein Backup allein ist noch lange kein Disaster-Recovery-Konzept.

Backup und Disaster Recovery sind nicht dasselbe

Zunächst müssen zwei Begriffe unterschieden werden.

Backup

Ein Backup ist eine zusätzliche Kopie von Daten oder Systemzuständen, mit deren Hilfe Informationen nach Verlust, Beschädigung oder Manipulation wiederhergestellt werden können.

Gesichert werden können beispielsweise:

• Dateien,
• Datenbanken,
• virtuelle Maschinen,
• Server,
• Konfigurationen,
• Verzeichnisdienste,
• Anwendungen,
• Container-Daten,
• Netzwerkgerätekonfigurationen.

Disaster Recovery

Disaster Recovery, kurz DR, beschreibt dagegen den gesamten Prozess zur Wiederherstellung der IT nach einem schwerwiegenden Ereignis.

Dazu gehören beispielsweise:

• Wiederherstellungsreihenfolge,
• Ersatzsysteme,
• Verantwortlichkeiten,
• Kommunikationswege,
• Abhängigkeiten,
• Wiederanlaufzeiten,
• technische Wiederherstellungsverfahren.

Ein Backup beantwortet also die Frage:

„Haben wir unsere Daten noch?“

Disaster Recovery beantwortet:

„Wie bekommen wir damit unseren Betrieb wieder zum Laufen?“

1. Zuerst wissen, was überhaupt gesichert werden muss

Ein häufiger Fehler besteht darin, Backupsoftware zu installieren und anschließend einfach „alle Server“ zu sichern.

Doch nicht alle Systeme sind gleich wichtig.

Eine Organisation sollte zunächst bestimmen:

• Welche Geschäftsprozesse sind kritisch?
• Welche Systeme unterstützen diese Prozesse?
• Welche Daten werden dafür benötigt?
• Welche Systeme hängen voneinander ab?
• Wie lange darf ein System ausfallen?
• Wie viel Datenverlust ist akzeptabel?

Damit wird Backup zu einem Bestandteil des Risikomanagements.

Ein öffentliches Informationssystem kann möglicherweise 24 Stunden ausfallen.

Ein zentrales Authentifizierungssystem vielleicht nur wenige Stunden.

Ein hochkritisches Produktionssystem möglicherweise nur Minuten.

Backupstrategien sollten sich deshalb am tatsächlichen Schutzbedarf orientieren.

2. RPO und RTO verstehen

Zwei zentrale Begriffe im Disaster Recovery sind RPO und RTO.

Recovery Point Objective – RPO

Das RPO beschreibt vereinfacht:

Wie viel Datenverlust können wir maximal akzeptieren?

Beispiel:

Eine Datenbank wird alle vier Stunden gesichert.

Kommt es kurz vor der nächsten Sicherung zu einem Totalausfall, könnten theoretisch fast vier Stunden Daten verloren gehen.

Das RPO beträgt in diesem vereinfachten Beispiel:

RPO = 4 Stunden

Bei besonders wichtigen Systemen könnte dagegen gelten:

RPO = 15 Minuten

Die Sicherungsstrategie muss entsprechend angepasst werden.

Recovery Time Objective – RTO

Das RTO beschreibt:

Wie lange darf die Wiederherstellung maximal dauern?

Beispielsweise:

RTO = 8 Stunden

Das bedeutet:

Der betreffende Dienst soll spätestens acht Stunden nach dem Ausfall wieder verfügbar sein.

RPO und RTO sind deshalb keine technischen Spielereien.

Sie verbinden die Anforderungen des Geschäfts- beziehungsweise Verwaltungsbetriebs mit der technischen Backup- und Wiederherstellungsstrategie.

3. Die 3-2-1-Regel

Eine der bekanntesten Grundregeln für Backups lautet:

3-2-1

Sie bedeutet:

3 Kopien der Daten

Die produktiven Daten plus zwei zusätzliche Kopien.

2 unterschiedliche Speichermedien beziehungsweise Speicherarten

Dadurch soll verhindert werden, dass ein einzelner technischer Fehler sämtliche Kopien betrifft.

1 Kopie außerhalb des primären Standorts

Dadurch bleiben Daten beispielsweise bei Brand, Überschwemmung oder einem Totalausfall des Rechenzentrums verfügbar.

Vereinfacht:

Produktivdaten
     │
     ├── Backup 1 → lokales Backup-System
     │
     └── Backup 2 → externer Standort / Cloud / Offline

Die klassische 3-2-1-Regel ist weiterhin eine gute Grundlage.

Gegen moderne Ransomware reicht sie allein jedoch nicht immer aus.

4. Von 3-2-1 zu 3-2-1-1-0

In modernen Backupkonzepten wird deshalb häufig eine erweiterte Variante verwendet:

3-2-1-1-0

Dabei kommen zwei Anforderungen hinzu.

Die zusätzliche 1 steht für eine Kopie, die beispielsweise offline, air-gapped oder unveränderbar gespeichert wird.

Die 0 steht für:

0 ungeprüfte beziehungsweise unbemerkte Fehler bei der Wiederherstellbarkeit.

Der Gedanke dahinter ist entscheidend.

Ein Unternehmen kann drei Kopien seiner Daten besitzen. Wenn Ransomware jedoch Zugriff auf alle drei Kopien erhält und diese verschlüsselt oder löscht, hilft die Anzahl der Kopien wenig.

Die Backupstrategie muss deshalb auch einen Angriff auf die Backups selbst berücksichtigen.

5. Immutable Backups

Hier kommen Immutable Backups ins Spiel.

Immutable bedeutet:

unveränderbar.

Ein einmal gespeichertes Backup kann während eines definierten Zeitraums weder verändert noch gelöscht werden – idealerweise auch nicht durch ein kompromittiertes Administratorkonto.

Beispielsweise:

Backup erstellt
      │
      ▼
Immutable Storage
      │
      ├── Änderung: blockiert
      ├── Überschreiben: blockiert
      └── Löschen: blockiert

Das ist besonders bei Ransomware entscheidend.

Moderne Angreifer versuchen häufig nicht mehr ausschließlich, Produktivdaten zu verschlüsseln.

Sie suchen gezielt nach:

• Backupservern,
• Backup-Repositories,
• NAS-Systemen,
• Hypervisoren,
• Zugangsdaten zur Backup-Infrastruktur,
• Cloud-Backups.

Denn ein Unternehmen ohne funktionierende Backups lässt sich wesentlich stärker unter Druck setzen.

6. Backup-Infrastruktur separat absichern

Ein Backupserver sollte deshalb nicht einfach ein weiterer Server im normalen Administrationsnetz sein.

Die Backup-Infrastruktur verdient einen besonders hohen Schutz.

Sinnvolle Maßnahmen können beispielsweise sein:

• getrennte Administratorkonten,
• MFA,
• Netzwerksegmentierung,
• separate Backup-Netze,
• restriktive Firewallregeln,
• minimale Berechtigungen,
• unveränderbare Speicher,
• separate Zugangsdaten,
• Überwachung der Backup-Infrastruktur.

Besonders problematisch wäre beispielsweise:

Domain Admin
     │
     ├── Zugriff auf Server
     ├── Zugriff auf Hypervisor
     └── Zugriff auf alle Backups

Wird dieses Konto kompromittiert, besitzt der Angreifer möglicherweise gleichzeitig Zugriff auf Produktion und Wiederherstellung.

Besser ist eine Trennung der Sicherheitsdomänen.

7. Ein Snapshot ist kein Backup

Snapshots sind praktisch.

Besonders bei virtuellen Maschinen ermöglichen sie beispielsweise vor bestimmten Änderungen eine schnelle Rückkehr zu einem vorherigen Zustand.

Trotzdem gilt:

Snapshot ≠ Backup

Ein Snapshot hängt häufig weiterhin vom ursprünglichen Storage beziehungsweise der ursprünglichen Plattform ab.

Fällt diese aus oder wird sie kompromittiert, kann auch der Snapshot verloren sein.

Snapshots können deshalb eine Backupstrategie ergänzen.

Sie sollten sie aber nicht ersetzen.

8. Backuparten sinnvoll kombinieren

Je nach Infrastruktur kommen verschiedene Backupverfahren infrage.

Vollbackup

Alle ausgewählten Daten werden vollständig gesichert.

Vorteile:

• einfache Wiederherstellung,
• vollständiger Sicherungsstand.

Nachteile:

• hoher Speicherbedarf,
• längere Backupdauer.

Inkrementelles Backup

Nach einem Vollbackup werden nur die seit der jeweils letzten Sicherung veränderten Daten gespeichert.

Vorteile:

• geringer Speicherbedarf,
• schnelle Sicherung.

Die Wiederherstellung kann jedoch komplexer sein.

Differenzielles Backup

Gesichert werden alle Änderungen seit dem letzten Vollbackup.

Dadurch entsteht ein Mittelweg zwischen Vollbackup und inkrementeller Sicherung.

Welche Methode optimal ist, hängt unter anderem von Datenmenge, RPO, RTO, Infrastruktur und verwendeter Backupsoftware ab.

9. Verschlüsselung der Backups

Backups enthalten häufig nahezu den gesamten Datenschatz einer Organisation.

Deshalb müssen sie nicht nur vor Löschung geschützt werden.

Auch Vertraulichkeit spielt eine Rolle.

Backupdaten sollten abhängig vom Schutzbedarf verschlüsselt werden:

• bei der Übertragung,
• auf dem Backup-Speicher,
• bei externen Kopien,
• in der Cloud,
• auf transportablen Datenträgern.

Dabei entsteht allerdings eine neue kritische Abhängigkeit:

die Schlüsselverwaltung.

Ist das Backup perfekt verschlüsselt, aber nach einem Totalausfall niemand mehr in der Lage, den notwendigen Schlüssel zu beschaffen, wurde aus einer Sicherheitsmaßnahme ein Wiederherstellungsproblem.

Schlüssel und Wiederherstellungsinformationen müssen deshalb ebenfalls in die Notfallplanung einbezogen werden.

10. Backups überwachen

„Der Backupjob ist grün“ ist erfreulich.

Es bedeutet aber lediglich, dass die Backupsoftware glaubt, ihre Aufgabe erfolgreich abgeschlossen zu haben.

Backupfehler sollten deshalb aktiv überwacht werden.

Interessante Kennzahlen sind beispielsweise:

• erfolgreiche Sicherungen,
• fehlgeschlagene Sicherungen,
• Sicherungsdauer,
• Datenvolumen,
• ungewöhnliche Veränderungen,
• verfügbare Speicherkapazität,
• letzte erfolgreiche Sicherung,
• letzter erfolgreicher Restoretest.

Besonders auffällige Änderungen können sicherheitsrelevant sein.

Wenn beispielsweise das tägliche Änderungsvolumen plötzlich massiv steigt, könnte dies auf ungewöhnliche Vorgänge hinweisen.

11. Restoretests – das Backup muss beweisen, dass es funktioniert

Eine der wichtigsten Regeln lautet:

Ein Backup, das niemals wiederhergestellt wurde, ist nur eine Hoffnung.

Deshalb gehören regelmäßige Restoretests zwingend zu einem professionellen Backupkonzept.

Ein Test kann beispielsweise folgendermaßen aussehen:

Backup auswählen
      │
      ▼
isolierte Testumgebung
      │
      ▼
Restore durchführen
      │
      ▼
System starten
      │
      ▼
Anwendung prüfen
      │
      ▼
Datenintegrität prüfen
      │
      ▼
Ergebnis dokumentieren

Dabei sollte nicht ausschließlich geprüft werden, ob eine einzelne Datei wiederhergestellt werden kann.

Für kritische Systeme sollte regelmäßig die vollständige Wiederherstellung getestet werden.

12. Restoretests realistisch gestalten

Ein echter Disaster-Recovery-Test sollte möglichst realistische Fragen beantworten.

Beispielsweise:

• Können wir einen kompletten Server wiederherstellen?
• Können wir eine Datenbank konsistent zurückholen?
• Funktioniert die Anwendung danach?
• Sind Berechtigungen korrekt?
• Funktionieren Schnittstellen?
• Wie lange dauert der Restore tatsächlich?
• Können wir unser definiertes RTO einhalten?

Denn zwischen:

„Laut Dokumentation dauert das zwei Stunden.“

und

„Wir haben es getestet und benötigen tatsächlich sieben Stunden.“

besteht ein erheblicher Unterschied.

Nur Tests liefern belastbare Werte.

13. Abhängigkeiten beim Wiederanlauf berücksichtigen

Eine Anwendung besteht häufig nicht aus einem einzigen Server.

Beispielsweise:

DNS
 │
 ▼
Active Directory
 │
 ▼
Datenbank
 │
 ▼
Applikationsserver
 │
 ▼
Webserver
 │
 ▼
Clients

Wird zuerst der Applikationsserver wiederhergestellt, obwohl DNS, Authentifizierung und Datenbank fehlen, bringt das wenig.

Deshalb benötigt Disaster Recovery eine definierte Wiederanlaufreihenfolge.

Diese sollte bereits vor einem Notfall dokumentiert werden.

14. Notfallpläne erstellen

Ein Notfallplan sollte konkrete Handlungsanweisungen enthalten.

Nicht:

„Bei Serverausfall IT informieren.“

Sondern beispielsweise:

• Wer stellt einen Notfall fest?
• Wer aktiviert den Notfallplan?
• Wer gehört zum Krisenteam?
• Wer darf Systeme abschalten?
• Wer entscheidet über Restoremaßnahmen?
• Welche Systeme werden zuerst wiederhergestellt?
• Wo befinden sich Backups?
• Wie erfolgt die Kommunikation?
• Welche externen Dienstleister werden benötigt?
• Welche Kontaktdaten gelten außerhalb der Geschäftszeiten?

Wichtig ist außerdem:

Der Notfallplan darf nicht ausschließlich auf einem Fileserver liegen, der im Notfall möglicherweise gerade verschlüsselt wurde.

Eine geschützte Offline- oder anderweitig unabhängige Kopie ist daher sinnvoll.

15. Ransomware verändert den Wiederherstellungsprozess

Nach einem gewöhnlichen Hardwaredefekt lautet die Strategie häufig:

Defektes System ersetzen → Backup zurückspielen → weiterarbeiten.

Nach einem Ransomware-Angriff ist das komplizierter.

Denn zunächst muss geklärt werden:

Ist das Backup überhaupt sauber?

Angreifer können sich Tage oder Wochen in einer Infrastruktur bewegen, bevor die eigentliche Verschlüsselung beginnt.

Ein Backup von gestern kann deshalb zwar unverschlüsselt sein, aber bereits:

• Malware,
• kompromittierte Konten,
• manipulierte Konfigurationen,
• persistente Zugänge

enthalten.

Deshalb muss bei der Wiederherstellung nach einem Cyberangriff auch der Zeitpunkt der Kompromittierung berücksichtigt werden.

16. Nicht blind in die kompromittierte Umgebung zurückspielen

Nach einem schweren Cyberangriff kann eine isolierte Wiederherstellungsumgebung sinnvoll sein.

Beispielsweise:

Immutable Backup
       │
       ▼
isolierte Recovery-Zone
       │
       ▼
Malware-Prüfung
       │
       ▼
Integritätsprüfung
       │
       ▼
System härten
       │
       ▼
Produktivfreigabe

Dadurch wird verhindert, dass kompromittierte Systeme unkontrolliert wieder in die produktive Infrastruktur gelangen.

Bei größeren Sicherheitsvorfällen können Forensik und Incident Response zusätzlich Einfluss darauf haben, welche Systeme wann wiederhergestellt werden.

17. Clean-Room-Recovery

Für besonders kritische Infrastrukturen kann eine sogenannte Clean-Room- beziehungsweise Clean-Recovery-Strategie sinnvoll sein.

Dabei wird eine isolierte, vertrauenswürdige Wiederherstellungsumgebung vorbereitet.

Dort können Systeme aus Backups wiederhergestellt und überprüft werden, bevor sie erneut produktiv eingesetzt werden.

Das Ziel lautet:

Nicht einfach möglichst schnell wieder online gehen – sondern möglichst sicher.

Denn ein schneller Restore einer weiterhin kompromittierten Umgebung führt schlimmstenfalls direkt zum nächsten Sicherheitsvorfall.

18. Kommunikation im Notfall

Disaster Recovery ist nicht ausschließlich eine technische Aufgabe.

Bei einem großflächigen Ausfall müssen möglicherweise informiert werden:

• Geschäftsführung beziehungsweise Behördenleitung,
• Informationssicherheit,
• Datenschutz,
• Fachbereiche,
• Beschäftigte,
• externe Dienstleister,
• Kunden oder Bürger,
• zuständige Behörden.

Kommunikationswege müssen deshalb auch dann funktionieren, wenn zentrale IT-Systeme ausgefallen sind.

Wenn beispielsweise Exchange, Teams, Active Directory und das Intranet gleichzeitig nicht verfügbar sind, kann ein Notfallplan, der ausschließlich auf diese Systeme setzt, problematisch werden.

Alternative Kommunikationswege gehören daher ebenfalls zur Notfallvorsorge.

19. Backup- und Recovery-Dokumentation

Für jedes kritische System sollten wichtige Informationen dokumentiert werden.

Beispielsweise:

System:
Verantwortlicher:
Kritikalität:

RPO:
RTO:

Backupverfahren:
Backupintervall:
Aufbewahrungsdauer:
Backupstandort:
Immutable: Ja / Nein

Wiederherstellungsverfahren:
Abhängigkeiten:
Wiederanlaufreihenfolge:

Letzter Restoretest:
Ergebnis:
Gemessene Wiederherstellungszeit:

Damit wird aus „Wir haben Backups“ ein nachvollziehbarer Prozess.

20. Backupstrategie regelmäßig überprüfen

Eine Backupstrategie ist niemals endgültig fertig.

Infrastrukturen verändern sich ständig.

Neue Server kommen hinzu.

Anwendungen wandern in die Cloud.

Datenbanken werden vergrößert.

Neue Fachverfahren entstehen.

Systeme werden virtualisiert oder containerisiert.

Deshalb sollte regelmäßig geprüft werden:

Sichern wir eigentlich noch alles, was heute wichtig ist?

Ein perfektes Backupkonzept von 2024 kann 2026 erhebliche Lücken besitzen, wenn die Infrastruktur inzwischen verändert wurde.

Praktische NIS-2-Checkliste für Backup und Disaster Recovery

Backup

☐ Sind alle kritischen Systeme und Daten identifiziert?

☐ Sind RPO und RTO definiert?

☐ Existieren mehrere Sicherungskopien?

☐ Befindet sich mindestens eine Kopie außerhalb des primären Standorts?

☐ Existiert eine offline, air-gapped oder unveränderbare Kopie?

☐ Werden Backupdaten angemessen verschlüsselt?

Sicherheit

☐ Ist die Backup-Infrastruktur vom Produktivnetz ausreichend getrennt?

☐ Werden separate Administrationskonten verwendet?

☐ Ist MFA eingerichtet, soweit technisch möglich?

☐ Können kompromittierte Produktivadministratoren Backups löschen?

☐ Werden Zugriffe auf die Backup-Infrastruktur protokolliert?

Überwachung

☐ Werden fehlgeschlagene Backupjobs automatisch erkannt?

☐ Werden Verantwortliche alarmiert?

☐ Wird die Speicherkapazität überwacht?

☐ Wird die letzte erfolgreiche Sicherung kontrolliert?

Restore

☐ Werden Wiederherstellungen regelmäßig getestet?

☐ Werden vollständige System-Restores durchgeführt?

☐ Wird die tatsächliche Wiederherstellungszeit gemessen?

☐ Werden Restoretests dokumentiert?

☐ Kann das definierte RTO tatsächlich eingehalten werden?

Disaster Recovery

☐ Existiert ein dokumentierter Notfallplan?

☐ Ist eine Wiederanlaufreihenfolge definiert?

☐ Sind Systemabhängigkeiten dokumentiert?

☐ Sind Verantwortlichkeiten eindeutig geregelt?

☐ Existieren alternative Kommunikationswege?

☐ Ist der Notfallplan auch bei Ausfall der IT erreichbar?

Ransomware

☐ Existieren unveränderbare oder offline gespeicherte Backups?

☐ Ist die Backup-Infrastruktur gegen kompromittierte Administratorkonten geschützt?

☐ Gibt es ein Verfahren zur Prüfung wiederhergestellter Systeme?

☐ Ist eine isolierte Recovery-Umgebung vorgesehen?

☐ Wird berücksichtigt, dass auch ältere Backups bereits kompromittiert sein können?

Backup und Disaster Recovery gehören zu den wichtigsten Elementen einer resilienten IT-Infrastruktur.

Die entscheidende Erkenntnis lautet:

Ein Backup ist erst dann wertvoll, wenn es zuverlässig wiederhergestellt werden kann.

Die 3-2-1-Regel schafft eine solide Grundlage. Moderne Bedrohungen wie Ransomware machen jedoch zusätzliche Maßnahmen erforderlich. Immutable oder offline gespeicherte Sicherungen, getrennte Administrationsstrukturen und geschützte Backup-Infrastrukturen werden zunehmend wichtiger.

Ebenso entscheidend sind regelmäßige Restoretests.

Organisationen sollten nicht vermuten, dass ihre Wiederherstellung funktioniert.

Sie sollten es wissen.

Dafür müssen RPO und RTO definiert, Wiederanlaufreihenfolgen dokumentiert und realistische Notfallübungen durchgeführt werden.

Besonders nach Ransomware-Angriffen gilt außerdem:

Wiederherstellung bedeutet nicht einfach Zurückkopieren.

Systeme müssen auf Vertrauenswürdigkeit geprüft und gegebenenfalls in einer isolierten Recovery-Umgebung aufgebaut werden.

Ein nachhaltiger Backup- und Disaster-Recovery-Prozess lässt sich deshalb folgendermaßen zusammenfassen:

Identifizieren → Sichern → Schützen → Überwachen → Wiederherstellen → Testen → Dokumentieren → Verbessern

Denn die entscheidende Frage nach einem Cyberangriff lautet nicht, ob irgendwo ein Backup existiert.

Sondern:

Können wir damit unsere kritischen Systeme sicher und rechtzeitig wieder in Betrieb nehmen?