Ihr Backup ist grün. Können Sie die Website daraus wirklich wiederherstellen?

Montagmorgen, 08:17 Uhr: Die Website liefert Fehler, die Datenbank ist beschädigt oder ein kompromittiertes System muss neu aufgebaut werden. Im Hosting-Panel steht beruhigend: Backup erfolgreich, 02:00 Uhr.

Das klingt gut. Es beantwortet aber noch nicht die entscheidende Frage: Können Sie daraus tatsächlich einen funktionsfähigen Stand wiederherstellen – mit den richtigen Daten, Zugängen, Dateien und Diensten, innerhalb einer für Ihr Geschäft akzeptablen Zeit?

Genau hier liegt der Unterschied zwischen ein Backup besitzen und wiederherstellbar sein.

CISA empfiehlt nicht nur Backups kritischer Daten, sondern ausdrücklich, deren Verfügbarkeit und Integrität regelmäßig in einem Disaster-Recovery-Szenario zu testen. AWS bietet für denselben Grund sogar geplante Restore-Tests als eigenes Backup-Feature an. Und NIST behandelt Wiederherstellung als eigenen Teil eines vollständigen Cybersecurity-Lebenszyklus.

Ein grünes Häkchen beim Backup ist deshalb ein Signal. Der Restore-Test ist der Beweis.

Mythos 1: „Der Backup-Job war erfolgreich, also ist das Backup gut.“

Ein Backup-System kann erfolgreich melden, dass es Daten geschrieben hat. Das beweist noch nicht, dass diese Daten vollständig, lesbar und unter realistischen Bedingungen wiederherstellbar sind.

Typische Überraschungen tauchen erst beim Restore auf:

• Das Archiv lässt sich öffnen, aber einzelne Tabellen oder Objekte fehlen.
• Die Datenbank ist vorhanden, aber Rollen, Rechte oder Erweiterungen fehlen.
• Das Backup gehört zu einer anderen Anwendungsversion als der Code, der gerade verfügbar ist.
• Verschlüsselungsschlüssel oder Zugangsdaten für die Wiederherstellung sind nicht mehr zugänglich.
• Der Restore funktioniert technisch, dauert aber sechs Stunden statt der angenommenen 30 Minuten.
• Die Dateien sind wieder da, doch Uploads, Suchindex, Queue oder Cron-Jobs funktionieren nicht.

PostgreSQL zeigt das Problem sehr konkret: Ein einzelner pg_dump sichert eine Datenbank, aber clusterweite Informationen wie Rollen und Tablespaces werden davon nicht automatisch mitgesichert. Für eine vollständige Wiederherstellung muss also bekannt sein, welche Bestandteile das System zusätzlich braucht.

Der Audit-Punkt lautet daher nicht „Gibt es Backups?“, sondern: Was genau wurde gesichert – und wurde genau dieser Sicherungsstand schon erfolgreich wiederhergestellt?

Mythos 2: „Die Datenbank ist die Website.“

Bei einfachen statischen Seiten vielleicht. Bei realen Websites, Shops, Portalen und SaaS-Produkten fast nie.

Eine wiederherstellbare Anwendung besteht typischerweise aus mehreren Schichten:

Daten: Datenbank, Benutzerkonten, Bestellungen, Formulareingänge, CMS-Inhalte.

Dateien: Medien-Uploads, generierte PDFs, private Dokumente, Anhänge oder andere Objekte außerhalb der Datenbank.

Anwendung: Quellcode, reproduzierbarer Build, Runtime-Versionen, Abhängigkeiten, Migrationen und Deployment-Konfiguration.

Infrastruktur: DNS, Domains, Reverse Proxy, CDN, Storage, Datenbankdienste, Queues, Worker und geplante Jobs.

Zugänge und Schlüssel: Secret-Manager-Zugriff, API-Credentials, Verschlüsselungsschlüssel, OAuth-Konfiguration, SMTP-Zugang und Zertifikate beziehungsweise deren reproduzierbare Erneuerung.

Das bedeutet nicht, dass jedes Secret als Datei in ein Backup gehört. Im Gegenteil: sensible Schlüssel brauchen eine sichere Strategie. Entscheidend ist, dass im Notfall klar ist, wie die benötigten Geheimnisse und Zugänge wieder verfügbar werden, ohne dass eine einzige Person oder ein längst gelöschter Agentur-Account zum Flaschenhals wird.

Ein Restore-Test deckt solche Abhängigkeiten sehr schnell auf.

Mythos 3: „Der Snapshot beim Hoster reicht.“

Provider-Snapshots sind praktisch. Sie können ein wichtiger Teil einer Backup-Strategie sein. Sie sollten aber nicht mit vollständiger Ausfallsicherheit verwechselt werden.

Wenn Produktion und einzige Sicherung an derselben administrativen Grenze hängen, teilen sie möglicherweise auch dieselben Risiken: kompromittierte Konten, Fehlkonfigurationen, Löschoperationen, Abrechnungsprobleme oder Störungen beim Anbieter.

CISA empfiehlt für kritische Daten offline gehaltene, verschlüsselte Backups und regelmäßige Tests. Der wichtige Gedanke dahinter ist Unabhängigkeit: Ein Vorfall in der Produktionsumgebung sollte nicht automatisch die letzte brauchbare Wiederherstellungsmöglichkeit mit zerstören können.

Für eine Website-Prüfung sind deshalb Fragen relevant wie:

• Liegen alle Sicherungen beim selben Provider und im selben Konto?
• Wer kann Backups löschen?
• Gibt es Versionierung oder unveränderliche Aufbewahrung, wo sie sinnvoll ist?
• Wie lange werden Wiederherstellungspunkte aufbewahrt?
• Was passiert, wenn das primäre Hosting-Konto gesperrt oder kompromittiert ist?
• Kann eine berechtigte zweite Person auf den Recovery-Pfad zugreifen?

Backups sind nicht nur Speicher. Sie sind eine Berechtigungs- und Abhängigkeitsarchitektur.

Mythos 4: „Im Notfall stellen wir einfach das letzte Backup wieder her.“

„Das letzte“ ist keine ausreichende Recovery-Anforderung.

Zwei Werte helfen, Erwartungen messbar zu machen:

RPO – Recovery Point Objective: Wie viel Datenverlust ist maximal akzeptabel? Wenn Bestellungen alle fünf Minuten entstehen, kann ein tägliches Backup technisch funktionieren und geschäftlich trotzdem völlig ungeeignet sein.

RTO – Recovery Time Objective: Wie lange darf es maximal dauern, bis der Dienst wieder verfügbar ist?

AWS beschreibt RPO und RTO genau als geschäftlich festzulegende Recovery-Ziele. Der entscheidende Teil ist festzulegen. Ohne Ziel lässt sich kaum beurteilen, ob die Backup-Strategie ausreichend ist.

Ein kleiner Firmenauftritt ohne Transaktionen kann andere Anforderungen haben als ein Shop, ein Kundenportal oder ein SaaS-Produkt. „Wir sichern nachts“ beantwortet weder RPO noch RTO.

Ein guter Restore-Test misst deshalb mindestens:

• Zeit bis zum Zugriff auf den richtigen Wiederherstellungspunkt,
• Dauer des eigentlichen Restores,
• notwendige manuelle Schritte,
• Zeitpunkt des jüngsten tatsächlich wiederhergestellten Datensatzes,
• Zeit bis zur technischen Funktionsfähigkeit,
• Zeit bis zur geschäftlichen Freigabe.

Erst danach wissen Sie, ob Ihr angenommenes Recovery-Ziel realistisch ist.

Mythos 5: „Restore erfolgreich“ bedeutet „Website wieder online“.

Ein Datenbank-Import mit Exit-Code 0 ist noch kein betriebsfähiges Produkt.

Nach einem Restore braucht es Funktionskontrollen. Welche davon relevant sind, hängt vom System ab. Typische Kandidaten sind:

• Startseite und wichtige Landingpages laden,
• Login und Passwort-Reset funktionieren,
• CMS-Inhalte und Medien sind vorhanden,
• Formulare werden angenommen und gespeichert,
• E-Mails werden tatsächlich versendet,
• Upload und Download funktionieren,
• Suche liefert Ergebnisse,
• Checkout oder Zahlungsübergabe funktioniert,
• Webhooks werden verarbeitet,
• Hintergrundjobs und Cron-Aufgaben laufen,
• Berechtigungen und private Inhalte bleiben privat,
• Monitoring und Error-Tracking melden wieder,
• neue Daten können nach dem Restore geschrieben werden.

Das ist der Moment, an dem ein technischer Restore zu einer geschäftlich nutzbaren Wiederherstellung wird.

Ein praktischer Restore-Test für Websites

Ein Restore-Test muss nicht mit einem Produktionsausfall beginnen. Im Gegenteil: Er sollte kontrolliert stattfinden.

1. Einen realen Wiederherstellungspunkt auswählen

Nehmen Sie nicht nur das bequemste Backup. Testen Sie einen Wiederherstellungspunkt, den Sie in einem echten Vorfall tatsächlich verwenden könnten.

Prüfen Sie Datum, Vollständigkeit, Aufbewahrung und Zugriff.

2. In eine isolierte Zielumgebung wiederherstellen

Ein Test-Restore sollte die Produktion nicht überschreiben. Verwenden Sie eine getrennte Umgebung mit kontrolliertem Netzwerkzugriff und verhindern Sie unerwünschte Seiteneffekte.

Besonders wichtig: Eine wiederhergestellte Kopie darf nicht plötzlich echte Kunden-E-Mails senden, Webhooks an Produktionspartner auslösen oder Zahlungen anstoßen.

3. Zeit stoppen

Dokumentieren Sie, wann der Test beginnt und wann der Dienst technisch sowie fachlich nutzbar ist. Nur so lässt sich das tatsächliche RTO mit dem gewünschten RTO vergleichen.

4. Datenstand prüfen

Prüfen Sie nicht nur „Datenbank vorhanden“, sondern konkrete Referenzdaten: aktuelle Inhalte, Benutzer, Bestellungen, Uploads oder andere geschäftskritische Objekte.

Vergleichen Sie den wiederhergestellten Stand mit dem erwarteten RPO.

5. Abhängigkeiten aktivieren

Können Storage, Queue, Worker, Mail, Suchdienst und externe APIs korrekt eingebunden werden? Welche Credentials fehlen? Welche Schritte sind nur im Kopf einer Person dokumentiert?

Notieren Sie jede manuelle Abhängigkeit.

6. Kernfunktionen testen

Verwenden Sie eine kurze, wiederholbare Liste kritischer Nutzerpfade. Ein Restore-Test sollte nicht nur Infrastruktur validieren, sondern beweisen, dass der Dienst benutzbar ist.

7. Ergebnis dokumentieren und Lücken beheben

Ein fehlgeschlagener Restore-Test ist unangenehm, aber wertvoll: Er findet die Lücke zu einem Zeitpunkt, an dem noch kein echter Ausfall Druck erzeugt.

Festhalten sollten Sie mindestens:

• getesteter Wiederherstellungspunkt,
• Restore-Dauer,
• festgestellte Datenlücke,
• fehlende Zugänge oder Abhängigkeiten,
• fehlgeschlagene Funktionstests,
• Verantwortliche für Korrekturen,
• Termin für den nächsten Test.

AWS Backup unterstützt genau diesen Gedanken mit planbaren, wiederkehrenden Restore-Tests und der Möglichkeit, deren Abschlusszeit zu verfolgen. Auch wenn Sie AWS nicht verwenden, ist das Prinzip übertragbar: Recovery sollte ein überprüfbarer Prozess sein, kein einmal geschriebenes Notfall-Dokument.

Was Website-Pflichtencheck dabei prüfen würde

Bei einem technischen Website-Pflichtencheck würden wir nicht behaupten, ein vorhandenes Backup-System sei automatisch schlecht oder gut. Wir würden die Wiederherstellbarkeit anhand der tatsächlichen Architektur betrachten.

Dazu können je nach System gehören:

• vorhandene Backup-Quellen und Wiederherstellungspunkte,
• Umfang: Datenbank, Dateien, Konfiguration und externe Abhängigkeiten,
• Aufbewahrung und administrative Trennung,
• dokumentierte RPO- und RTO-Ziele,
• Restore-Anleitung und Verantwortlichkeiten,
• Ergebnisse früherer Restore-Tests,
• Zugriff auf Domains, DNS, Hosting und Secrets,
• post-restore Funktionstests,
• erkennbare Single Points of Failure im Recovery-Prozess.

Das Ergebnis sollte keine 40-seitige Katastrophenfantasie sein. Es sollte eine einfache Frage beantworten:

Wenn dieses System heute ausfällt: Was brauchen wir, wer kann es tun, welchen Stand bekommen wir zurück – und wissen wir das, weil wir es getestet haben?

Wenn diese Antwort heute nur aus „der Hoster macht Backups“ besteht, ist ein kontrollierter Restore-Test einer der wertvollsten nächsten Wartungsschritte.