Der Job war erfolgreich. Funktioniert auch die Wiederherstellung?
Am Montag fehlen dem kleinen Betrieb Kundenunterlagen. Die Backupsoftware meldet für die Nacht „erfolgreich“. Beim Wiederherstellen zeigt sich: Die Datenbankdateien wurden im laufenden Betrieb ungeeignet kopiert, die Anwendungskonfiguration fehlt und das verschlüsselte externe Backup lässt sich ohne den verlorenen Schlüssel nicht öffnen. Das Problem ist nicht der Status des letzten Jobs. Es fehlt ein nachgewiesener Weg zurück zu einem nutzbaren Dienst.
Backup ist die geplante Sicherung eines wiederherstellbaren Datenbestands. Restore ist das Zurückspielen. Erst die umfassendere Wiederherstellung verbindet Daten, passende Software, Konfiguration, Identitäten und abhängige Dienste wieder zu einem funktionierenden Betrieb. Ein Sicherungsplan muss deshalb beantworten: Was wird gesichert, gegen welche Ausfälle, wie lange, durch wen und wie wird das Ergebnis geprüft?
Datenverlust entsteht durch versehentliches Löschen, falsche Skripte, defekte Datenträger, Brand, Diebstahl oder Schadsoftware. Auch eine unbemerkte Beschädigung kann erst Wochen später auffallen. Das BSI behandelt Backup und Restore im Baustein CON.3 Datensicherungskonzept gemeinsam. Diese Sicht ist für Privathaushalte ebenso nützlich wie für Administratoren: Eine zweite Datei irgendwo ist noch kein belastbarer Wiederherstellungsplan.
RAID, Synchronisierung und Snapshot lösen andere Probleme.
Ein RAID verteilt oder spiegelt Daten über mehrere Datenträger. Je nach Verfahren kann es den Ausfall einzelner Laufwerke überbrücken. Wenn eine Anwendung Dateien löscht oder verschlüsselt, wird diese Änderung aber ebenfalls auf dem RAID wirksam. Ein Controllerfehler, Diebstahl des ganzen Systems oder ein Brand kann mehrere Laufwerke gleichzeitig betreffen. Verfügbarkeit bei einem Laufwerksausfall ersetzt daher keine zeitlich getrennte Sicherung.
Synchronisierung hält mehrere Orte auf demselben Stand. Sie ist praktisch für die Arbeit auf mehreren Geräten, kann aber auch Löschungen und fehlerhafte Änderungen übertragen. Manche Dienste bieten Versionen und Wiederherstellung an. Das muss anhand von Aufbewahrungsdauer, Löschrechten und Recovery tatsächlich geprüft werden. Ein synchronisierter Ordner allein gewährleistet keine unabhängige Rückkehr zu einem älteren Zustand.
Ein Snapshot hält einen Zustand eines Speichers oder einer virtuellen Maschine zu einem Zeitpunkt fest. Häufig werden unveränderte Blöcke mit dem Original geteilt. Das macht Rücksprünge schnell, lässt aber eine gemeinsame Abhängigkeit vom Speicher bestehen. Wenn derselbe Administrator alle Snapshots löschen kann, helfen sie außerdem wenig gegen ein übernommenes Administratorkonto. Ein auf unabhängigen Speicher replizierter und geschützt aufbewahrter Snapshot kann Teil einer Backupstrategie sein; das Wort „Snapshot“ allein belegt diese Unabhängigkeit nicht.
Bei Virtualisierung und Proxmox sind VM-Snapshot, VM-Backup und unabhängige Aufbewahrung deshalb auseinanderzuhalten. In Docker Compose gilt das genauso für Volumes: Sie überleben die Neuerstellung eines Containers, aber nicht automatisch den Verlust des Hosts. Weder das Kopieren eines Images noch eine Compose-Datei sichert die darin genutzten Geschäftsdaten.
Voll, inkrementell und differenziell: Was braucht der Restore?
Ein Vollbackup enthält den gesamten ausgewählten Bestand. Ein inkrementelles Backup sichert Änderungen seit dem letzten relevanten Sicherungspunkt. Eine klassische Kette benötigt für den Restore das Vollbackup und alle anschließenden benötigten Inkremente. Ein differenzielles Backup enthält Änderungen seit dem letzten Vollbackup; für den gewählten Zustand werden das Vollbackup und die passende Differenz benötigt. Moderne Produkte können Blöcke deduplizieren oder synthetische Vollbackups bilden. Deshalb ist die konkrete Katalog- und Kettenlogik wichtiger als der Name im Menü.
Ein kleiner Sicherungsjob bedeutet nicht automatisch einen schnellen Restore. Eine lange Kette kann zusätzliche Lesezugriffe und Abhängigkeiten erzeugen. Ein fehlendes Kettenglied oder ein beschädigter Katalog kann die Wiederherstellung verhindern. Auch Backup-Metadaten, Wiederherstellungssoftware und Zugangsinformationen müssen verfügbar sein. Die Dokumentation darf nicht ausschließlich auf dem gerade ausgefallenen Dateiserver liegen.
Versionierung erhält mehrere Zustände. Aufbewahrung muss sowohl den erwarteten Zeitraum bis zur Fehlerentdeckung als auch verfügbare Kapazität und fachliche Anforderungen berücksichtigen. Eine tägliche Überschreibung nur einer Sicherung kann einen alten unbemerkten Fehler sehr zuverlässig konservieren. Zu lange oder unkontrollierte Aufbewahrung vergrößert dagegen Datenbestand und Zugriffsrisiko. Backup und revisionsgerechte Archivierung sind unterschiedliche Aufgaben; diese Lernstrecke legt keine verbindlichen gesetzlichen Aufbewahrungsfristen fest.
Unabhängigkeit zählt mehr als die Anzahl der Kopien.
Die 3-2-1-Regel ist eine Planungsheuristik: drei Datenkopien einschließlich des produktiven Bestands, zwei unterschiedliche Medien beziehungsweise sinnvoll getrennte Speichertechniken und eine Kopie an einem anderen Ort. Sie ist ein Ausgangspunkt für Fragen nach gemeinsamen Ausfällen, keine mathematische Sicherheitsgarantie. Zwei USB-Platten im selben Schrank schützen nicht gegen den Brand des Raums. Zwei Cloudordner unter demselben vollständig berechtigten Konto können denselben Angreiferzugang teilen.
Offsite bedeutet räumlich getrennt. Offline bedeutet für den betrachteten Zeitraum nicht über die produktiven Systeme erreichbar. Beides ist nicht dasselbe. Ein externes, ständig beschreibbares Netzlaufwerk kann bei einem Angriff erreichbar bleiben. Rotierende Datenträger verlangen dokumentierte Wechsel, sicheren Transport und geschützte Lagerung. Ein über Wochen vergessener Wechsel verschlechtert den tatsächlichen Wiederherstellungspunkt.
Immutable Backups sollen Änderungen oder Löschungen während einer festgelegten Aufbewahrung verhindern. Entscheidend sind die tatsächlichen Kontrollen: Kann ein kompromittierter Administrator die Sperre aufheben, die Aufbewahrung verkürzen oder das ganze Konto zerstören? Schreibende Sicherungsjobs, Löschung und Verwaltung sollten getrennte Rollen und Konten erhalten. Änderungen an Schutzfristen und ungewöhnliche Löschversuche müssen auffallen. Unveränderlichkeit schützt weder vor einem schon falsch gesicherten Datenbestand noch vor dem Ablauf einer zu kurzen Frist.
Verschlüsselung schützt Sicherungen bei verlorenen Medien oder unberechtigtem Lesen. Sie verhindert nicht automatisch ihre Löschung. Entschlüsselungsschlüssel brauchen getrennte, zugriffsgeschützte und im Notfall erreichbare Aufbewahrung einschließlich eines geprüften Ersatzwegs. Nur auf dem gesicherten Server gespeicherte Schlüssel erzeugen einen Zirkelschluss. Auch alte Sicherungen benötigen noch die zugehörigen Schlüsselversionen. Starke Anmeldung und MFA gehören an Backupverwaltung und Recovery-Konten; Kryptografie erklärt die verschiedenen Schutzaufgaben.
RPO begrenzt Datenverlust, RTO die Zeit bis zum nutzbaren Betrieb.
Das Recovery Point Objective (RPO) beschreibt den maximal tolerierbaren Datenverlust als Zeitspanne. Es beantwortet: Wie weit dürfen wir im Datenstand zurückfallen? Das Recovery Time Objective (RTO) beschreibt die angestrebte Zeit bis zur Wiederherstellung des vereinbarten Betriebs. Es beantwortet: Wie lange darf dieser Dienst ausfallen? Beide Werte werden aus Auswirkungen und Abhängigkeiten abgeleitet. Sie sind Ziele, keine durch die Installation einer Backupsoftware zugesicherten Ergebnisse.
Ein Beispiel: Um 14:20 Uhr fällt ein Dienst aus. Der letzte nachweislich wiederherstellbare Stand ist von 14:00 Uhr. Der Datenverlust beträgt bis zu 20 Minuten. Bei einem vereinbarten RPO von 30 Minuten wäre dieses konkrete Szenario innerhalb des Ziels. Wäre der letzte Job unbrauchbar und nur der Stand von 12:00 Uhr verfügbar, wäre es deutlich verfehlt. Ein Job alle 30 Minuten beweist also nicht allein ein RPO von 30 Minuten; Laufzeit, Fehler, Übertragung und Prüfung müssen berücksichtigt werden.
Für ein RTO von vier Stunden zählt nicht nur das Kopieren. Angenommen, Erkennen und Entscheiden benötigen 30 Minuten, eine saubere Zielumgebung 45 Minuten, Datenübertragung 60 Minuten, Konsistenz- und Funktionstest 45 Minuten und die kontrollierte Freigabe 30 Minuten. Das sind zusammen 210 Minuten oder dreieinhalb Stunden. Der Puffer beträgt nur 30 Minuten. Eine zusätzlich ausgefallene Identitätsverwaltung oder fehlende Hardware kann ihn sofort verbrauchen. Das RTO muss Ende zu Ende geprüft werden, einschließlich relevanter Abhängigkeiten und vereinbartem Startpunkt der Messung.
Ein abgestimmter Plan für vier zusammengehörige Systeme.
Der fiktive Betrieb betreibt Dateiserver, Linux-Anwendung, Kundendatenbank und Netzwerkkomponenten. Die folgenden Werte sind beispielhafte Planungsannahmen. Fachverantwortliche müssen sie für ihren Betrieb bestätigen; sie sind keine universellen Empfehlungen. Der durchgängige Kundenprozess hängt an der Datenbank und Anwendung. Seine Wiederanlaufzeit beträgt daher nicht einfach den kleinsten Tabellenwert.
| Bestand | Beispielziele | Verfahren und Aufbewahrung | Nachweis |
|---|---|---|---|
| Dateiserver | RPO 4 h; RTO 8 h | Versionierte Stände alle 2 h; unabhängig extern spätestens 1 h nach dem Datenzeitpunkt verfügbar. Lokal 30 Tage; extern 2-h-Stände 7 Tage, zusätzliche Tagesstände 90 Tage | Monatlich ausgewählte Dateien samt Rechten; vierteljährlich komplette Freigabe |
| Linux-Anwendung | Konfigurations-RPO 24 h und nach Freigaben; Dienst-RTO 4 h | Täglich konsistente Konfiguration und Artefaktreferenz; zusätzlich nach Releases, jeweils 30 Versionstage | Monatlicher Neuaufbau mit passender Version und Datenbankverbindung |
| Kundendatenbank | RPO 30 min; Datenbank-RTO 3 h | Geeignetes Basisbackup plus laufende Logarchivierung; Übertragungslücke überwachen, 30 Tage gemeinsam aufbewahren | Wöchentlich isolierter Restore auf gewählten Zeitpunkt, fachliche Datentests |
| Netz- und Serverkonfiguration | RPO 24 h und nach Änderungen; Basisdienste-RTO 1 h | Täglich und nach freigegebenen Änderungen; 30 Versionstage plus dokumentierte Meilensteine | Monatliche Lesbarkeitsprüfung; vierteljährlicher Test im isolierten Ersatzaufbau |
Alle genannten Sicherungsbestände erhalten eine verschlüsselte unabhängige Kopie. Die häufigeren Datenbanklogs müssen ebenfalls rechtzeitig dorthin gelangen; eine ausschließlich tägliche externe Kopie würde das 30-Minuten-Ziel bei Verlust des Standorts nicht erfüllen. Die zweistündlichen Dateistände müssen auch am unabhängig administrierten Offsite-Ziel spätestens eine Stunde nach ihrem logischen Datenzeitpunkt nachweislich verfügbar sein. Unter diesen vereinfachten Annahmen bleibt der jüngste externe Datenstand weniger als drei Stunden alt und damit innerhalb des Vier-Stunden-Ziels, auch beim Standortverlust. Die Verzögerung umfasst Jobdauer und Übertragung; ihr Überschreiten erfordert eine Reaktion. Unveränderliche Aufbewahrung und getrennte Zugänge schützen diese Kopie zusätzlich. Bei einem Sicherheitsvorfall kann der letzte nachweislich saubere Stand trotzdem älter sein; dann muss eine tatsächliche RPO-Verfehlung ausdrücklich benannt werden.
Die Reihenfolge lautet im Beispiel: sichere Infrastruktur und erforderliche Identitäten bereitstellen, Datenbank wiederherstellen, passende Anwendung samt Konfiguration anbinden, Dateifreigaben prüfen und den gesamten Kundenprozess testen. Netzwerk-RTO von einer Stunde und Datenbank-RTO von drei Stunden dürfen dabei nicht gedankenlos addiert werden, wenn das Dienst-RTO vier Stunden beträgt. Parallelisierbare Arbeit und echte Abhängigkeiten müssen in einem Ablaufplan mit Verantwortlichen sichtbar werden. Ein Test klärt, ob die Zeitplanung realistisch ist.
Datenbankdateien im laufenden Betrieb einfach zu kopieren kann einen inkonsistenten Zustand erzeugen. Verwende das für die konkrete Datenbank dokumentierte Verfahren: beispielsweise einen transaktionskonsistenten logischen Export oder ein korrekt koordiniertes Basisbackup mit benötigten Transaktionslogs. Bei PostgreSQL repräsentiert pg_dump einen konsistenten Zustand einer Datenbank; mehrere getrennte Dumps sind dadurch nicht automatisch zeitlich aufeinander abgestimmt. Anwendungsdateien, externe Objekte und Konfiguration müssen zum gewählten Datenstand passen. Ein VM-Snapshot ohne geeignete Anwendungskoordination beweist diese Konsistenz nicht.
Ein Restore-Test prüft einen Dienst, nicht nur eine Prüfsumme.
Für eine sichere Übung reichen erfundene Dokumente und synthetische Datensätze in einem getrennten Testprojekt. Verändere keine Produktivdateien und setze keine Malware oder echte Verschlüsselungsangriffe ein. Stelle aus einem ausgewählten Sicherungspunkt in ein neues Ziel wieder her. Die Testumgebung darf keine produktiven Benachrichtigungen versenden, echte Zahlungen auslösen oder sich versehentlich als produktiver Server im Netz melden.
Prüfe zuerst Zugriff, Katalog, vollständige Kette und Entschlüsselung. Danach folgen Dateiinhalte, Rechte, Datenbankkonsistenz, passende Anwendungsversion und ein fachlicher Test: Kann ein synthetischer Auftrag geöffnet werden, stimmen seine Positionen, lässt er sich im Test weiterverarbeiten? Prüfsummen erkennen Änderungen an gesicherten Dateien, beweisen aber weder fachliche Vollständigkeit noch Schadsoftwarefreiheit. Eine lesbare Datenbank kann ebenfalls einen falschen fachlichen Stand enthalten.
Das Protokoll nennt verwendete Sicherung, Datenstand, Testumgebung, Start- und Endzeiten, verantwortliche Person, Prüfschritte, Ergebnis und offene Abweichungen. Miss sowohl technische Restorezeit als auch Zeit bis zur Freigabe. Wiederhole relevante Tests nach Änderungen an Backupsoftware, Schlüsseln, Datenbank oder Infrastruktur. Ein älteres bestandenes Protokoll lässt sich nicht ungeprüft auf eine veränderte Umgebung übertragen. Linux-Serverbetrieb ergänzt die dafür notwendige Dokumentation und Überwachung.
Bei Ransomware zuerst Schaden begrenzen und koordiniert handeln.
Ransomware kann Daten verschlüsseln und Systeme unbenutzbar machen. Angreifer können vorher Daten stehlen und mit Veröffentlichung drohen; das wird häufig als doppelte Erpressung bezeichnet. Ein erfolgreicher Restore behebt den Ausfall, macht aber einen Datenabfluss nicht rückgängig. Auch die Ursache, gestohlene Zugänge und möglicherweise verbliebene Angreiferzugänge müssen untersucht werden.
Bei auffällig umbenannten Dateien, Erpressernachrichten oder ungewöhnlichen Schreibvorgängen gilt der vorbereitete Meldeweg: zuständige IT beziehungsweise Incident-Verantwortliche, Leitung und erforderliche externe Fachhilfe informieren. Nutze bei vermutetem Zugriff auf die Kommunikation einen bekannten unabhängigen Kanal. Dokumentiere Zeitpunkt, Beobachtung und bereits erfolgte Maßnahmen. Betroffene Systeme werden nach Notfallplan rasch vom Netz isoliert, beispielsweise durch zuständige Administration am Switch oder über eine geeignete Isolationsfunktion. Backupzugänge und weitere möglicherweise betroffene Systeme gehören in die Lagebewertung.
Nicht pauschal alle Geräte ausschalten, löschen oder neu installieren. Flüchtige Speicherinhalte und Protokolle können für die Untersuchung verloren gehen. CISA behandelt Abschalten als Ausweichmaßnahme, wenn eine Netztrennung nicht möglich ist und weitere Ausbreitung verhindert werden muss. Die zuständigen Fachleute wägen Eindämmung und Beweisbewahrung ab. Halte betroffene Datenträger und relevante Logs geschützt; sichere forensische Kopien nicht improvisiert auf dem einzigen noch intakten Backupmedium.
Der Notfallplan benennt auch Datenschutz, erforderliche Meldungen, Versicherungs- und Strafverfolgungskontakte passend zur Organisation und Rechtslage. Hier werden dafür keine universellen Fristen erfunden. Eine Lösegeldzahlung garantiert weder vollständige Entschlüsselung noch Löschung gestohlener Daten oder das Ende des Angreiferzugangs. Eine Erpresserzusage ist kein Wiederherstellungsnachweis.
Für den Wiederanlauf werden bekannte saubere Systeme in einer getrennten Umgebung aufgebaut. Der ausgewählte Sicherungspunkt muss vor der relevanten Kompromittierung liegen und auf Eignung geprüft werden; das Datum vor sichtbarer Verschlüsselung genügt nicht. Einfallstor, Persistenz und betroffene Konten werden bearbeitet, Zugänge und erforderliche Schlüssel kontrolliert erneuert. Erst nach Sicherheitsprüfung, Daten- und Funktionstests sowie dokumentierter Freigabe werden Systeme kontrolliert wieder verbunden und beobachtet. Firewallregeln und Segmentierung unterstützen diese Trennung, ersetzen aber nicht die Untersuchung.
Den Rückweg nachvollziehbar prüfen
Aufgabe 1: Erfüllt eine externe Tageskopie ein RPO von 30 Minuten?
Die Datenbank archiviert Logs alle zehn Minuten lokal. Extern liegt nur der nächtliche Stand von 02:00 Uhr. Um 14:20 Uhr geht der gesamte Standort verloren. Die aktuelle lokale Sicherung ist nicht erreichbar. Welcher Datenverlust droht?
Lösung
Mit dem externen Stand fehlen bis zu zwölf Stunden und 20 Minuten. Die lokalen Zehn-Minuten-Logs helfen in diesem Ausfallszenario nicht, wenn sie zusammen mit dem Standort verloren sind. Ein RPO von 30 Minuten benötigt eine geeignete unabhängige Sicherung einschließlich aller erforderlichen Logs innerhalb dieses Zeitrahmens sowie die Überwachung ihrer tatsächlichen Wiederherstellbarkeit.
Aufgabe 2: Reicht „Dateien zurückkopiert“ für die Freigabe?
Nach einem Ransomwareverdacht wurden Daten auf denselben bisher ungeprüften Server zurückgespielt. Die Dateien lassen sich öffnen. Der Plan sieht einen sofortigen Anschluss an das Büronetz vor. Was fehlt?
Lösung
Es fehlen Untersuchung und Eindämmung des Zugangs, die Bewertung betroffener Identitäten, eine bekannte saubere Zielumgebung und die Prüfung des Sicherungspunkts. Lesbarkeit beweist weder Schadsoftwarefreiheit noch fachliche Konsistenz. Der Restore muss in einer getrennten Umgebung inklusive Anwendung und Abhängigkeiten geprüft und anschließend ausdrücklich freigegeben werden. Ein ungeprüfter Anschluss kann die wiederhergestellten Daten erneut gefährden.
Quellen und fachlicher Stand
Fachlich geprüft am . Alle Zeitziele und Aufbewahrungswerte sind bewusst fiktive Planungsbeispiele. Es werden keine Dateien verändert oder verschlüsselt.
- BSI IT-Grundschutz, CON.3 Datensicherungskonzept, Edition 2023: Abgrenzung von RAID, Einflussfaktoren, Sicherungsplan, Aufbewahrung, Zugriffsschutz und regelmäßige Wiederherstellungstests, insbesondere CON.3.A4 sowie A12–A15. Der hier zitierte Editionsstand wird ausdrücklich benannt.
- CISA und Partner: #StopRansomware Guide, Fassung September 2023; Veröffentlichungsseite mit Revisionsdatum 19.10.2023: unabhängige Sicherungen, vorbereitete Reaktion, Isolation, Beweisbewahrung und saubere Wiederherstellung.
- PostgreSQL 19: SQL Dump: Konsistenz eines Datenbankexports und Grenzen bei mehreren Datenbanken. Für andere Datenbanksysteme sind deren eigene Sicherungsverfahren maßgeblich.