Das Wichtigste in 60 Sekunden / tl;dr
- Ein Backup ist nur eine Kopie. Ein Notfallplan beschreibt zusätzlich Verantwortliche, Reihenfolge, Zugänge, Prüfungen und Kommunikation.
- RPO beantwortet: Wie viel Datenverlust ist vertretbar? RTO beantwortet: Wie schnell muss der Dienst wieder nutzbar sein?
- Die 3-2-1-Regel ist ein guter Start: drei Kopien, zwei unterschiedliche Medien oder Systeme, eine Kopie getrennt vom Primärstandort. Für Ransomware braucht es zusätzlich Schutz vor Löschen und Überschreiben.
- Ein grüner Backup-Job beweist keine Wiederherstellbarkeit. Erst ein dokumentierter Restore-Test zeigt, ob Daten, Konfiguration, Abhängigkeiten und Zeitvorgaben zusammenpassen.
- Bei Cloud-Diensten bleiben Dateninventar, Zugang, Export, Geheimnisse und der getestete Rückweg eine eigene Aufgabe. Das SLA des Anbieters ersetzt keinen eigenen Restore-Nachweis.
Quellen: BSI: Schritt für Schritt zur Datensicherung · BSI IT-Grundschutz-Kompendium: Datensicherung und Wiederherstellung
01
Ein Backup ist nur eine Wette auf die Vergangenheit
Ein Backup beantwortet zunächst nur eine Frage: Welche Datenkopie existiert? Im Ernstfall zählen weitere Fragen: Ist die Kopie sauber, erreichbar und lesbar? Welche Infrastruktur wird zuerst benötigt? Wer darf den Restore starten und wer bestätigt, dass der Dienst wieder funktioniert?
Genau deshalb ist ein Backup kein Notfallplan. Ein Notfallplan verbindet Kopien mit einem überprüften Ablauf. Er macht aus einem Versprechen im Dashboard einen Weg zurück in einen arbeitsfähigen Zustand.
Backup
Eine zusätzliche Kopie von Daten oder Zuständen. Sie ist die Grundlage, aber noch kein Beweis für einen funktionierenden Restore.
Replikation
Eine laufende oder nahezu laufende Spiegelung. Sie reduziert Ausfallzeit, kann aber Fehler, Verschlüsselung oder Löschung genauso schnell mitkopieren.
Wiederherstellung
Der kontrollierte Weg von einem vertrauenswürdigen Sicherungspunkt zu einem wieder nutzbaren System inklusive Prüfung und Übergabe.
Die drei Begriffe werden im Alltag oft vermischt. Für die Planung sollten sie getrennt dokumentiert und getestet werden.
02
Was muss im Ernstfall zuerst zurückkommen?
Bevor technische Werkzeuge ausgewählt werden, braucht es ein kleines, belastbares Inventar. Ohne Prioritäten wird im Notfall zuerst das lauteste Problem bearbeitet, nicht unbedingt das wichtigste.
Geschäftskritische Dienste
Welche Anwendung stoppt Umsatz, Produktion, Support oder gesetzliche Abläufe, wenn sie ausfällt?
Daten und Zustände
Welche Daten müssen zurückkommen, welche können neu erzeugt werden und welche dürfen nicht fehlen?
Abhängigkeiten
Identität, DNS, Zertifikate, Secrets, Datenbanken, Queues, Drittanbieter und Netzwerkzugang gehören in dieselbe Karte.
Verantwortliche
Für jeden Dienst gibt es eine Person mit Stellvertretung, die Priorität, Restore und fachliche Prüfung bestätigen kann.
Manueller Übergang
Welche begrenzte Ersatzlösung hält den Betrieb am Laufen, während ein nachgelagerter Dienst wiederhergestellt wird?
Der kleinste sinnvolle Start
Nimm ein einziges wichtiges System. Schreibe auf, wo Daten und Konfiguration liegen, wer den Restore auslösen darf, welche Abhängigkeiten zuerst gebraucht werden und woran der Fachbereich „wieder nutzbar“ erkennt. Das ist schon ein prüfbares erstes Runbook.
03
RPO und RTO machen den Notfall messbar
Zwei einfache Zielwerte verhindern unklare Erwartungen. Sie sind keine Garantie, sondern überprüfbare Planungsziele.
RPO: Recovery Point Objective
Wie weit darf der wiederhergestellte Datenstand hinter dem Ausfall zurückliegen? Ein RPO von 15 Minuten bedeutet: maximal ungefähr 15 Minuten neue Daten dürfen fehlen.
RTO: Recovery Time Objective
Wie lange darf es dauern, bis der Dienst wieder in einem vereinbarten nutzbaren Zustand ist? „Server läuft“ und „Mitarbeitende können arbeiten“ sind nicht immer dasselbe.
| Beispiel | Ziel | Woran prüfen? |
|---|---|---|
| Auftragsannahme | RPO 15 min | Letzte Buchung und abhängige Daten sind höchstens 15 Minuten alt. |
| Internes Archiv | RPO 24 h | Der letzte Tagesstand ist vorhanden und lesbar. |
| Kundenportal | RTO 2 h | Login, Kernfunktion und Datenzugriff funktionieren innerhalb von zwei Stunden. |
Wenn ein Ziel nicht gemessen wird, ist es nur eine Hoffnung. Ein Restore-Test sollte die echte Dauer und den tatsächlichen Datenstand festhalten.
04
3-2-1 ist der Startpunkt, nicht das Ende
Das BSI beschreibt die 3-2-1-Idee als robuste Orientierung für Datensicherungen. Sie reduziert das Risiko, dass ein einzelner Fehler alle Kopien gleichzeitig trifft.
3 Kopien
Mindestens drei verfügbare Datenstände, einschließlich des Primärbestands. Mehrere Generationen helfen gegen unbemerkte Fehler.
2 Medien oder Systeme
Nicht jede Kopie hängt am gleichen Storage, Konto oder Berechtigungsmodell. Unterschiedliche Fehlerdomänen sind wichtiger als ein anderes Dateiverzeichnis.
1 getrennte Kopie
Eine Kopie liegt logisch oder physisch getrennt. Offline, unveränderbar oder mit getrennten Zugangsdaten erschwert sie das gemeinsame Löschen.
- Backup-Administratoren und Produktiv-Administratoren verwenden nicht automatisch dieselbe Identität.
- Löschen und Überschreiben sind begrenzt, protokolliert und, wo sinnvoll, durch Aufbewahrungsfristen geschützt.
- Mindestens eine Kopie ist gegen laufende Produktionszugänge und typische Ransomware-Pfade isoliert.
- Fehler, fehlgeschlagene Jobs, ungewöhnliche Löschungen und fehlende Kapazität erzeugen eine bearbeitete Warnung, nicht nur eine Logzeile.
- Verschlüsselung schützt die Kopie, aber Schlüssel und Wiederherstellungszugang dürfen nicht im selben zerstörbaren Bereich liegen.
Wichtig bei Ransomware
Eine Spiegelung ist kein Schutz, wenn sie die Verschlüsselung oder Löschung sofort übernimmt. Für den Restore braucht es einen bekannten, vertrauenswürdigen und ausreichend alten Sicherungspunkt.
05
Wiederherstellung braucht ein Runbook
Im Stress sollten Menschen nicht aus verstreuten Chat-Nachrichten rekonstruieren müssen, was zuerst zu tun ist. Ein Runbook darf unvollständig beginnen, muss aber real getestet und nach jedem Test verbessert werden.
1. Ausbreitung stoppen
Betroffene Systeme isolieren, verdächtige Zugänge sperren und keine Kopie überschreiben, bevor der Sachverhalt geklärt ist.
2. Fakten sichern
Zeitpunkt, betroffene Versionen, bekannte Symptome und verfügbare Sicherungspunkte dokumentieren. Vermutungen werden als Vermutungen markiert.
3. Vertrauensbasis herstellen
Identität, Netzwerk, Betriebssystem, Container oder Plattform in einer bereinigten Reihenfolge bereitstellen.
4. Daten in Abhängigkeitsreihenfolge laden
Zuerst Basisdienste und Datenbanken, dann Anwendungen und zuletzt abhängige Integrationen. Jeder Schritt bekommt ein sichtbares Prüfergebnis.
5. Fachlich validieren
Ein Fachverantwortlicher prüft echte Kernabläufe, Berechtigungen, Datenfrische und externe Übergaben. Ein gestarteter Prozess ist noch kein betriebsbereiter Dienst.
6. Übergabe und Nachbeobachtung
Betrieb kontrolliert Logs, Fehler und Datenflüsse weiter. Offene Einschränkungen und nächste Schritte werden an Nutzer und Leitung kommuniziert.
Technische Miniatur
Ein Restore-Befehl ist immer umgebungsspezifisch. Als Dokumentationsmuster kann ein Runbook etwa einen Zielstand und eine isolierte Testumgebung festhalten:
restore --environment=staging --point=2026-08-18T02:00Z --verify-checksums
Das ist kein allgemeiner Befehl und kein Ersatz für Berechtigungsprüfung, Malware-Analyse oder fachliche Abnahme.
06
Ein Restore-Test ist die eigentliche Qualitätsprüfung
Das BSI fordert regelmäßige Funktionstests und die Überprüfung, ob gesicherte Daten einwandfrei und in angemessener Zeit zurückgespielt werden können. Ein Test darf deshalb nicht bei „Backup-Datei existiert“ enden.
Tabletop-Test
Menschen gehen einen Ausfall anhand des Runbooks durch. Dabei werden Zuständigkeiten, Kontakte und fehlende Informationen sichtbar.
Teil-Restore
Ein repräsentativer Dienst, eine Datenbank oder ein Mandant wird in eine isolierte Umgebung zurückgespielt und fachlich geprüft.
Wiederanlaufprobe
Ein möglichst realistischer Ablauf misst Reihenfolge, Dauer, manuelle Schritte, Datenfrische und die Rückkehr in den Betrieb.
- Gemessene Zeit bis zum ersten nutzbaren Dienst und bis zur vollständigen Übergabe.
- Tatsächlicher Datenstand im Vergleich zum vereinbarten RPO.
- Manuelle Schritte, fehlende Zugänge, kaputte Abhängigkeiten und unklare Entscheidungen.
- Nachweis, dass der Sicherungspunkt lesbar, fachlich plausibel und nicht nur formal vorhanden ist.
- Konkrete Korrekturen mit verantwortlicher Person und erneutem Testtermin.
Wenn ein Test nur das Backup-Produkt grün färbt, aber keine Anwendung mit echten Prüfdaten startet, ist die Wiederherstellbarkeit noch nicht belegt.
07
Cloud und Verantwortung: Der Anbieter nimmt dir nicht alles ab
Managed Backup und Cloud-Snapshots können sinnvoll sein. Sie ändern aber nicht die Fragen nach Daten, Konfiguration, Zugang, Aufbewahrung, Abhängigkeiten und dem Rückweg in eine nutzbare Umgebung.
Anbieter prüfen
Welche Verfügbarkeit, Aufbewahrung, Regionen, Isolation, Wiederherstellungsoptionen und Supportzeiten sind tatsächlich vertraglich beschrieben?
Kundenseite dokumentieren
Welche Daten, Secrets, Konfigurationen, Images, Zertifikate und externen Integrationen müssen zusätzlich exportiert oder neu aufgebaut werden?
Rückweg testen
Kann ein Dienst in einem anderen Konto, einer anderen Region oder einer alternativen Umgebung mit einem bekannten Stand wieder anlaufen?
Fragen, die vor dem Ernstfall beantwortet sein sollten
- Wer darf einen Restore auslösen, wenn das zentrale Identitätssystem ausfällt?
- Wie wird ein Sicherungspunkt ausgewählt, wenn der Zeitpunkt der Kompromittierung unklar ist?
- Welche Kosten und Wartezeiten entstehen bei einem großen Datenexport?
- Wie werden gelöschte Konten, Schlüssel und Konfigurationen wiederhergestellt?
08
Was ich für Bestandssysteme konkret nachrüste
Für bestehende Software, Apps und interne Tools ist oft kein kompletter Neubau nötig. Der erste sinnvolle Schritt ist ein kleiner, überprüfbarer Wiederherstellungspfad.
Bestandsaufnahme
Systeme, Daten, Abhängigkeiten und Verantwortlichkeiten in einer übersichtlichen Wiederanlaufkarte festhalten.
Zielwerte
RPO und RTO gemeinsam mit den fachlich Verantwortlichen definieren und in testbare Kriterien übersetzen.
Restore-Test
Einen repräsentativen Sicherungspunkt in einer isolierten Umgebung wiederherstellen, messen und die Abweichungen dokumentieren.
Runbook und Nachrüstung
Fehlende Exportwege, getrennte Zugänge, Aufbewahrung, Warnungen und wiederholbare Schritte technisch ergänzen.
Das ist technische Umsetzung und Vorbereitung. Eine 24/7-Notfallbereitschaft, Forensik oder ein festes SLA sind separate Leistungen und müssen ausdrücklich vereinbart werden.
09
Die 10-Punkte-Checkliste
Wenn mehrere Antworten „weiß ich nicht“ lauten, ist das kein Grund für Panik. Es ist ein klarer Plan für die nächste Verbesserung.
- Kritische Systeme und Daten sind inventarisiert.
- Für jeden kritischen Dienst sind RPO und RTO festgelegt.
- Abhängigkeiten wie Identität, DNS, Secrets und Datenbanken sind dokumentiert.
- Es existieren mehrere Generationen und getrennte Fehlerdomänen.
- Mindestens eine Kopie ist gegen direkte Löschung oder Überschreibung geschützt.
- Backup-Warnungen werden aktiv bearbeitet und nicht nur gesammelt.
- Restore-Zugänge funktionieren auch bei Ausfall des normalen Administrationswegs.
- Ein Restore wurde mit repräsentativen Daten in einer isolierten Umgebung getestet.
- Die fachliche Abnahme prüft echte Kernprozesse, nicht nur laufende Server.
- Das Runbook hat Verantwortliche, Stellvertretung, Zeitmessung und einen nächsten Testtermin.
10
Häufige Fragen
Ist ein Cloud-Backup ausreichend?
Nicht automatisch. Es kann eine wichtige Schicht sein, aber Daten, Konfiguration, Identität, Secrets, Abhängigkeiten, Export und der tatsächliche Restore müssen zusätzlich betrachtet und getestet werden.
Ist Replikation dasselbe wie Backup?
Nein. Replikation hilft bei Verfügbarkeit, kann aber fehlerhafte Änderungen, Verschlüsselung oder Löschung mitnehmen. Ein Backup braucht unabhängige, ältere und geschützte Stände.
Wie oft sollte ein Restore getestet werden?
Das hängt von Kritikalität und Veränderung ab. Die feste Regel „einmal irgendwann“ reicht nicht. Nach Architekturänderungen, neuen Backup-Zielen oder kritischen Updates sollte erneut getestet werden.
Darf der Backup-Administrator dieselben Rechte wie der Produktionsadministrator haben?
Das ist riskant. Getrennte Identitäten, begrenzte Rechte und geschützte Aufbewahrung reduzieren das Risiko, dass ein kompromittierter Produktionszugang alle Kopien löscht.
Was tun, wenn der Sicherungspunkt selbst kompromittiert sein könnte?
Nicht blind zurückspielen. Systeme isolieren, Fakten sichern, mehrere ältere Stände prüfen und bei Verdacht auf Angriff eine geeignete Incident- oder Forensik-Unterstützung einbeziehen.
11
Offizielle Quellen und technische Grundlagen
Verwendete Primärquellen, zuletzt geprüft am 18. August 2026.