Ein Backup ist noch kein Recovery-Plan: Haben Sie die Wiederherstellung wirklich getestet?

Im Hosting-Dashboard steht seit Monaten jeden Morgen ein grünes Häkchen: Backup erfolgreich.

Dann geht die Website kaputt.

Die Datenbank ist beschädigt, ein Update hat Dateien überschrieben oder ein kompromittierter Account hat Inhalte verändert. Jetzt zeigt sich, ob „Backup vorhanden“ tatsächlich bedeutet, dass die Website wiederhergestellt werden kann.

Oft sind das zwei verschiedene Aussagen.

CISA empfiehlt nicht nur regelmäßige, geschützte Backups, sondern ausdrücklich, deren Verfügbarkeit und Integrität in einem Disaster-Recovery-Szenario zu testen. NIST behandelt Tests und Übungen ebenfalls als eigenen Bestandteil der Notfallplanung. Und selbst Managed-Backup-Dienste wie AWS Backup bieten inzwischen geplante Restore-Tests an, weil ein erfolgreicher Sicherungslauf allein nicht beweist, dass eine Wiederherstellung funktioniert.

Die wichtigste Frage lautet deshalb nicht:

„Haben wir Backups?“

Sondern:

„Können wir aus einem realen Backup eine funktionierende Website wiederherstellen – und wissen wir, wie lange das dauert?“

Backup-Erfolg und Wiederherstellbarkeit sind unterschiedliche Dinge

Ein Backup-Job kann technisch erfolgreich sein und trotzdem im Ernstfall scheitern.

Typische Gründe:

• Die Datenbank wurde gesichert, aber Uploads oder Konfigurationsdateien fehlen.
• Dateien sind vorhanden, aber die passende Datenbankversion ist nicht mehr bekannt.
• Das Archiv lässt sich herunterladen, aber nicht entschlüsseln.
• Zugangsdaten für Backup-Speicher oder Registrar liegen nur im ausgefallenen Passwortsystem.
• Die Sicherung enthält die Anwendung, aber keine DNS-, E-Mail-, Cron-, Queue- oder Proxy-Konfiguration.
• Das Backup ist intakt, aber die Wiederherstellungsanleitung ist veraltet.
• Die Wiederherstellung funktioniert technisch, dauert aber zwölf Stunden, obwohl das Geschäft maximal zwei Stunden Ausfall verkraftet.

Gerade bei WordPress ist die Trennung sehr konkret: Die offizielle WordPress-Dokumentation weist darauf hin, dass eine Website aus Dateien und Datenbank besteht und dass ein Dateibackup die Datenbank normalerweise nicht mit sichert. Themes, Plugins und Uploads können also vorhanden sein, während Beiträge, Einstellungen, Nutzer oder andere Daten fehlen – oder umgekehrt.

Ein Restore-Test prüft deshalb nicht nur das Archiv. Er prüft, ob die Gesamtkette wieder zusammengesetzt werden kann.

RPO und RTO machen aus „irgendwann wieder online“ ein Ziel

Zwei Begriffe helfen dabei, Recovery messbar zu machen.

Recovery Point Objective (RPO) beschreibt, bis zu welchem Zeitpunkt Daten nach einem Ausfall wiederhergestellt werden müssen. Vereinfacht: Wie viel Datenverlust ist tolerierbar?

Wenn ein Shop maximal 30 Minuten Bestellungen verlieren darf, reicht ein tägliches Datenbankbackup offensichtlich nicht.

Recovery Time Objective (RTO) beschreibt, wie lange ein System höchstens nicht verfügbar sein darf, bevor die Auswirkungen unakzeptabel werden.

Wenn eine Buchungsseite nach vier Stunden wieder online sein muss, ist ein Restore-Prozess, der erst nach einem Support-Ticket am nächsten Werktag beginnt, kein passender Recovery-Plan.

NIST verwendet RPO und RTO ausdrücklich zur Planung von Backup- und Wiederherstellungsstrategien. Für kleine Websites müssen daraus keine Enterprise-Prozesse werden. Zwei klare Zahlen sind aber viel hilfreicher als „wir sichern regelmäßig“.

Die acht häufigsten Red Flags bei Website-Backups

1. Niemand hat je einen vollständigen Restore durchgeführt

Das ist der Klassiker.

Das Backup-Plugin meldet Erfolg. Der Hoster zeigt 30 Wiederherstellungspunkte. Aber niemand hat einen davon jemals in eine leere Umgebung zurückgespielt.

Dann wissen Sie nicht, ob das Backup vollständig, lesbar, kompatibel und praktisch nutzbar ist.

2. Backup und Produktion liegen im selben Fehlerbereich

Wenn Website, Datenbank und Backups unter demselben Account, demselben Storage oder denselben Zugangsdaten hängen, kann ein einzelner Vorfall alles gleichzeitig treffen.

CISA empfiehlt deshalb unter anderem offline beziehungsweise anderweitig geschützte, verschlüsselte Backups und weist darauf hin, dass Angreifer gezielt versuchen können, erreichbare Backups zu löschen oder zu verschlüsseln.

Das bedeutet nicht, dass jedes kleine Unternehmen Tape-Laufwerke braucht. Es bedeutet: Ein Backup sollte nicht nur eine weitere Datei sein, die dieselbe kompromittierte Identität löschen kann.

3. Es wird nur „Content“ gesichert, nicht die Betriebsumgebung

Eine Website besteht selten nur aus HTML und Datenbank.

Zum Wiederanlauf können außerdem gehören:

• DNS-Zonen und Domainzugang,
• TLS-Konfiguration,
• Reverse-Proxy- oder CDN-Regeln,
• Umgebungsvariablen und Secrets,
• Cronjobs und Worker,
• Object Storage,
• E-Mail-DNS und Versandkonfiguration,
• Redirects,
• Webhooks,
• Suchindexe,
• Infrastruktur-Code,
• externe API-Schlüssel und Integrationen.

Nicht alles muss in dasselbe Backup. Aber für jedes Teil muss klar sein, woher es im Recovery-Fall wiederkommt.

4. Die Dokumentation setzt Wissen voraus, das nur eine Person hat

„Restore macht normalerweise Alex“ ist keine belastbare Anleitung.

Ein guter Runbook-Test beginnt idealerweise mit jemandem, der das System kennt, aber den Restore nicht täglich macht. Wenn die Person nach zehn Minuten fragen muss, welches Backup gemeint ist, wo die Encryption Keys liegen oder welcher DNS-Eintrag zuerst geändert werden soll, wurde wertvolles Wissen gefunden – allerdings zu spät.

5. Der Restore wird nur bis „Server startet“ getestet

Eine wiederhergestellte Website ist nicht automatisch funktionsfähig.

Nach dem Restore sollten echte Kernpfade geprüft werden, zum Beispiel:

• Startseite und wichtige Landingpages,
• Login und Passwort-Reset,
• Formulare und Benachrichtigungen,
• Checkout oder Buchung,
• Upload und Download,
• interne Suche,
• Cronjobs und Queues,
• API-Integrationen,
• Admin-Bereich,
• Analytics oder Monitoring, soweit vorgesehen.

AWS Backup trennt deshalb Restore-Test und optionale Validierung: Ein erfolgreich erzeugtes Restore-Objekt kann anschließend mit eigenen Prüfungen validiert werden. Für Websites sollte dieselbe Denkweise gelten.

6. Restore-Zeit wird nie gemessen

Ein Restore kann funktionieren und trotzdem das RTO verfehlen.

Stoppen Sie deshalb die Zeit: von „Incident erklärt“ bis „kritischer Dienst validiert wieder verfügbar“. Enthalten sein sollten auch Wartezeiten für Storage, DNS, Provider-Support, Schlüsselzugriff und manuelle Prüfungen.

Erst dann kennen Sie Ihre tatsächliche Wiederanlaufzeit.

7. Es gibt keine saubere Entscheidung, welcher Recovery Point verwendet wird

Der neueste Snapshot ist nicht immer automatisch der richtige.

Bei einem kompromittierten System kann der jüngste Backup-Stand die Manipulation bereits enthalten. Bei einer fehlerhaften Migration kann die Datenbank zwischen mehreren Zuständen liegen.

Ein Restore-Plan sollte deshalb klären:

• Welche Wiederherstellungspunkte existieren?
• Wie weit reicht die Historie?
• Wie erkennt man den letzten vertrauenswürdigen Stand?
• Welche Daten müssen nach dem Restore nachgezogen oder rekonstruiert werden?

8. Nach einem erfolgreichen Test wird nichts dokumentiert

Ein Restore-Test ist keine Prüfung, die man „besteht“ und dann vergisst.

NIST empfiehlt Tests mit klaren Zielen und Erfolgskriterien sowie die Dokumentation der Ergebnisse und Lessons Learned. Genau das ist für kleine Teams nützlich: Was dauerte länger als erwartet? Welche Credentials fehlten? Welcher Schritt war unklar? Welche Abhängigkeit war nicht dokumentiert?

Der nächste Test sollte diese Probleme nicht wiederfinden.

Ein pragmatischer Restore-Drill für kleine Websites

Sie brauchen dafür keinen künstlichen Totalausfall der Produktion.

Schritt 1: Einen realen Recovery Point auswählen

Nehmen Sie ein echtes Backup aus dem normalen Sicherungsprozess – nicht ein speziell für den Test erzeugtes „sauberes“ Archiv.

Damit testen Sie das System, auf das Sie sich im Ernstfall tatsächlich verlassen würden.

Schritt 2: In eine isolierte Umgebung wiederherstellen

Nutzen Sie eine getrennte Testdomain oder ein isoliertes Netzwerk. Verhindern Sie, dass die restaurierte Instanz echte E-Mails versendet, Webhooks auslöst, Zahlungen anstößt oder Suchmaschinen indexierbare Kopien sehen.

Schritt 3: Daten und Dateien getrennt verifizieren

Bei CMS-Systemen prüfen Sie explizit, ob Datenbank, Uploads, Themes/Plugins oder Anwendungscode sowie relevante Konfigurationen zum gleichen sinnvollen Zustand gehören.

Schritt 4: Secrets und externe Abhängigkeiten bewusst behandeln

Ein Backup sollte nicht blind alle Produktions-Secrets in eine Testumgebung kippen. Gleichzeitig muss dokumentiert sein, wie im echten Recovery-Fall neue oder vorhandene Credentials sicher bereitgestellt werden.

Schritt 5: Kernfunktionen validieren

Definieren Sie vorab fünf bis zehn Funktionen, ohne die die Website geschäftlich nicht „wiederhergestellt“ ist. Testen Sie diese wie ein Nutzer und – wo sinnvoll – technisch über Healthchecks oder automatisierte Tests.

Schritt 6: Zeit und Datenalter messen

Notieren Sie:

• Alter des verwendeten Recovery Points,
• tatsächlich verlorenes Datenfenster,
• Dauer bis zum ersten erreichbaren System,
• Dauer bis zu einer validierten Kernfunktion,
• Dauer bis zur vollständigen Freigabe.

Damit werden RPO und RTO überprüfbar.

Schritt 7: Runbook aktualisieren

Jede Überraschung wird zur Änderung: fehlender Zugang, falscher Pfad, manuelle SQL-Anpassung, vergessener DNS-Schritt, nicht dokumentierter Provider.

Ein guter Restore-Test produziert nicht nur eine funktionierende Testseite. Er produziert eine bessere nächste Wiederherstellung.

Automatisieren, wo es sich lohnt

Nicht jeder Restore muss monatlich von Hand durchgeführt werden.

Cloud-Plattformen können Restore-Tests planen, temporäre Ressourcen erstellen und die Restore-Dauer messen. AWS Backup dokumentiert genau diesen Ansatz und unterstützt zusätzlich eine nachgelagerte Validierung.

Auch bei kleineren Setups lässt sich einiges automatisieren:

• regelmäßigen Restore in eine isolierte Umgebung,
• Datenbank-Import prüfen,
• Startseite und Health-Endpunkte testen,
• Kern-URLs mit Smoke Tests aufrufen,
• Dateibestand oder Checksummen plausibilisieren,
• Laufzeit protokollieren,
• Testressourcen anschließend wieder entfernen.

Automatisierung ersetzt jedoch nicht jede Übung. Ein technischer Restore kann grün sein, während niemand weiß, wer im Incident DNS ändern, Kunden informieren oder Zugang zum Registrar herstellen soll.

Darum braucht es beides: wiederholbare technische Tests und gelegentliche menschliche Recovery-Drills.

Was Website-Pflichtencheck prüfen würde

Bei einem Backup- und Recovery-Check geht es nicht nur darum, ob irgendwo eine ZIP-Datei liegt.

Geprüft werden können unter anderem:

• welche Systeme und Daten tatsächlich gesichert werden,
• Backup-Frequenz und Aufbewahrungsdauer,
• Trennung von Produktion und Backup-Speicher,
• Schutz vor versehentlichem oder kompromittiertem Löschen,
• Verschlüsselung und Zugriffsmodell,
• Datenbank-, Datei- und Medienvollständigkeit,
• Wiederherstellung von CMS-, Hosting- und Infrastrukturkomponenten,
• dokumentierte RPO- und RTO-Ziele,
• vorhandene Restore-Runbooks,
• benötigte Credentials und externe Abhängigkeiten,
• tatsächliche Restore-Dauer,
• Validierung geschäftskritischer Nutzerpfade,
• Monitoring und Dokumentation früherer Tests.

Das Ziel ist kein perfektes Disaster-Recovery-Handbuch für eine kleine Unternehmenswebsite. Das Ziel ist viel einfacher:

Wenn morgen etwas kaputtgeht, soll die erste echte Wiederherstellung nicht gleichzeitig der erste Test Ihres Backups sein.

Ein grünes Backup-Häkchen ist beruhigend. Ein nachweislich erfolgreicher Restore ist belastbar.