Ein Backup ist erst dann gut, wenn die Wiederherstellung funktioniert

Das Backup-Dashboard zeigt jeden Morgen einen grünen Haken. Datenbank gesichert. Dateien kopiert. Aufbewahrung aktiv.

Dann fällt die Website aus – und plötzlich stellt sich heraus, dass niemand weiß, wie aus diesen Dateien wieder ein funktionierendes System wird.

Ein Backup beantwortet nur die Frage, ob Daten irgendwo abgelegt wurden. Ein Restore-Test beantwortet die wichtigere Frage: Kann das Unternehmen daraus unter realistischen Bedingungen seine Website wiederherstellen?

Der gefährliche Irrtum: „Das Backup läuft automatisch“

Automatisierung ist sinnvoll, aber ein erfolgreicher Job kann viele Probleme verdecken:

• Die Sicherung enthält die Datenbank, aber nicht die hochgeladenen Dateien.
• Die Dateien sind vorhanden, aber die Verschlüsselungsschlüssel fehlen.
• Das Backup liegt im selben Kundenkonto wie die Produktion.
• Ein beschädigtes Archiv wird trotzdem als erfolgreich hochgeladen.
• Die Datenbank lässt sich importieren, passt aber nicht zur installierten Anwendungsversion.
• DNS, Umgebungsvariablen, Cronjobs, Mail-Konfiguration oder externe Speicher fehlen.
• Der Restore funktioniert nur mit dem Wissen einer einzelnen Person.

CISA empfiehlt, kritische Daten offline beziehungsweise getrennt und verschlüsselt zu sichern und die Verfügbarkeit sowie Integrität der Backups regelmäßig in einem Disaster-Recovery-Szenario zu testen. NIST behandelt Backup, Wiederherstellung und das Testen von Notfallplänen ebenfalls als zusammengehörige Kontrollen.

Der Kern ist simpel: Eine Sicherung, die nie wiederhergestellt wurde, ist eine Annahme.

Was bei modernen Websites tatsächlich gesichert werden muss

„Die Website“ ist selten nur ein Verzeichnis und eine Datenbank. Abhängig vom System gehören dazu:

Anwendungsdaten

• Datenbank und Transaktionsdaten
• CMS-Inhalte
• Benutzerkonten und Berechtigungen
• Formulareinsendungen
• Bestellungen, Buchungen oder Mandatsdaten
• Medien und Uploads

Technische Konfiguration

• Umgebungsvariablen und Secrets
• Webserver-, Proxy- und CDN-Konfiguration
• DNS-Dokumentation
• Cronjobs und Queues
• Redirects und Sicherheitsheader
• Storage-Buckets und Zugriffsregeln
• E-Mail-Provider und Webhooks

Wiederaufbaubare Software

Quellcode sollte im Repository liegen, aber das allein garantiert keinen reproduzierbaren Betrieb. Benötigt werden außerdem festgelegte Abhängigkeitsversionen, Datenbankmigrationen, Deployment-Anweisungen, Infrastrukturdefinitionen und kompatible Runtime-Versionen.

Ein Restore scheitert häufig nicht an der großen Datenbankdatei, sondern an einem kleinen fehlenden Baustein, der nie Teil des Backup-Konzepts war.

RPO und RTO ohne Management-Sprech

Wie viele Daten dürfen verloren gehen? Das Recovery Point Objective beschreibt den maximal vertretbaren Datenverlust. Bei einer statischen Unternehmensseite können 24 Stunden akzeptabel sein. Bei Bestellungen, Buchungen oder Nutzeraktivität kann bereits eine Stunde zu viel sein.

Wie lange darf die Website ausfallen? Das Recovery Time Objective beschreibt die tolerierbare Wiederherstellungszeit. Ein Backup kann vollständig und trotzdem geschäftlich unbrauchbar sein, wenn die Wiederherstellung drei Tage dauert.

Diese Ziele bestimmen Sicherungsfrequenz, Prioritäten, benötigte Zugänge und die Häufigkeit realistischer Übungen.

Ein realistischer Restore-Test in sieben Phasen

1. Ein konkretes Ausfallszenario wählen

Testen Sie nicht abstrakt „das Backup“. Wählen Sie beispielsweise vollständigen Serververlust, versehentliche Datenbanklöschung, ein kompromittiertes CMS, ein fehlerhaftes Deployment oder eine nicht erreichbare Agentur. Das Szenario bestimmt, welche bestehenden Ressourcen beim Test nicht benutzt werden dürfen.

2. Eine saubere Zielumgebung bereitstellen

Die Wiederherstellung sollte nicht über die laufende Produktion geschrieben werden. Nutzen Sie eine isolierte Umgebung mit kontrollierten Zugängen. So prüfen Sie den tatsächlichen Wiederaufbau, ohne produktive Daten zu gefährden.

3. Das Backup unabhängig validieren

Kontrollieren Sie vor dem Import:

• Existiert das erwartete Backup?
• Ist es vollständig und innerhalb des benötigten Zeitfensters?
• Stimmen Dateigröße, Prüfsumme oder Integritätsprüfung?
• Kann es mit den dokumentierten Schlüsseln entschlüsselt werden?
• Ist die Version eindeutig einem System und Zeitpunkt zuordenbar?

Ein grüner Jobstatus ist kein Integritätsnachweis.

4. System und Daten wiederherstellen

Bauen Sie Anwendung, Datenbank, Uploads und Konfiguration nach Runbook auf. Dokumentieren Sie jeden manuellen Schritt, jede fehlende Berechtigung und jede Information, die nur durch Erinnerung verfügbar war.

5. Nicht nur die Startseite testen

Ein HTTP-Status 200 beweist keine erfolgreiche Wiederherstellung. Prüfen Sie Login und Rollen, Formulare, Dateiabrufe, E-Mail-Versand, Hintergrundjobs, Zahlungs- oder CRM-Verbindungen, Weiterleitungen, Canonicals sowie Consent-Einstellungen.

6. Datenstand und Konsistenz prüfen

Stichproben sollten zeigen, ob Datensätze, Dateien und Beziehungen zusammenpassen. Eine Datenbank kann erfolgreich importiert sein, während Medien fehlen, Migrationen nicht angewendet wurden oder externe IDs zur falschen Umgebung zeigen.

7. Zeit, Lücken und Entscheidungen dokumentieren

Am Ende zählen nicht nur „bestanden“ oder „fehlgeschlagen“, sondern tatsächliche Wiederherstellungsdauer, letzter wiederherstellbarer Datenstand, fehlende Secrets, manuelle Sonderkenntnisse, ungetestete Abhängigkeiten und notwendige Verbesserungen mit Verantwortlichen und Termin.

Red Flags in bestehenden Backup-Konzepten

• Backups liegen ausschließlich beim gleichen Hosting-Anbieter.
• Produktion und Sicherungen nutzen dasselbe Administratorkonto.
• Niemand erhält Alarme bei fehlgeschlagenen Sicherungen.
• Es gibt keine unveränderliche oder getrennte Kopie.
• Backup-Verschlüsselung ist aktiv, aber Schlüsselwiederherstellung wurde nie getestet.
• Das Aufbewahrungsfenster ist kürzer als die Zeit, in der Fehler typischerweise entdeckt werden.
• Datenbank und Uploads werden ohne Konsistenzstrategie getrennt gesichert.
• Das Runbook verweist auf ehemalige Mitarbeitende.
• Der letzte Restore-Test war „bei der Einrichtung“.

Wie oft sollte getestet werden?

Eine universelle Zahl gibt es nicht. Sinnvoll ist eine risikobasierte Staffelung: automatische Integritätskontrolle nach jeder Sicherung, regelmäßige Test-Restores einzelner Datenbestände und vollständige Wiederherstellungsübungen für kritische Systeme wiederkehrend sowie nach größeren Änderungen an Hosting, CMS, Datenbank, Verschlüsselung oder Zuständigkeit.

Je dynamischer und geschäftskritischer die Website, desto weniger sollte der erste vollständige Restore während eines echten Ausfalls stattfinden.

Was Website-Pflichtencheck prüfen würde

Ein Backup- und Recovery-Check betrachtet die vollständige Kette:

• Umfang, Frequenz und Aufbewahrung
• Trennung von Produktion und Sicherungen
• Verschlüsselung, Schlüsselzugriff und Berechtigungen
• Integritätsprüfung und Alarmierung
• Datenbank, Uploads, Konfiguration und externe Dienste
• dokumentierte RPO- und RTO-Ziele
• Wiederherstellungs-Runbook
• tatsächlicher Test in isolierter Umgebung
• Funktion kritischer Nutzerwege nach dem Restore
• Verantwortlichkeit und Verbesserungsplan

Das Ziel ist kein weiteres grünes Dashboard. Das Ziel ist der Nachweis, dass eine Website nach Datenverlust, Fehlkonfiguration oder Infrastruktur-Ausfall wieder betriebsfähig werden kann.

Backups beruhigen. Restore-Tests beweisen. Wer die Wiederherstellung nie vollständig durchgeführt hat, besitzt möglicherweise viele Dateien – aber noch keinen belastbaren Wiederanlaufplan.