Das automatische Backup lief seit zwei Jahren. Am Tag des Ausfalls wusste niemand, wie man wiederherstellt: fehlerhafter Snapshot, beschädigte Datenbank, DNS zeigte immer noch auf den alten Server. „Wir hatten Backups“ – ja. Kein Wiederherstellungsplan.
Dieses Szenario wiederholt sich, sobald ein Team Kopie und Kontinuität verwechselt. Ein PRA (Disaster Recovery Plan) beantwortet konkrete Fragen: Wie lange können Sie ohne Service auskommen (RTO), wie viele Daten können Sie verlieren (RPO), wer macht was, in welcher Reihenfolge und wie informiert man Kunden und Partner. Die vom Host angebotenen Backups sind nur ein Baustein – nicht der Plan. Kreuzen Sie mit Der Mythos der 99,99 %: SLA-Credits ersetzen niemals eine Organisation, die weiß, wie sie wieder auf die Beine kommt.
Definieren Sie Geschäfts-RTO und RPO
RTO und RPO werden nicht nach technischem Gespür ausgewählt. Sie spiegeln eine geschäftliche Risikotoleranz wider: Umsatzeinbußen, Unfähigkeit zur Rechnungsstellung, Vertragsbruch gegenüber einem B2B-Kunden. Beginnen Sie mit einer einfachen Tabelle, die Sie mit dem Produktmanager oder der Geschäftsleitung validieren.
| Website | Indikativer RPO | Indikativer RTO |
|---|---|---|
| E-Commerce | 15 Min. – 1 Std. | 1–4 Std. |
| B2B-SaaS | 5–15 Min. | < 1 Std. |
| Unternehmenswebsite | 24 Stunden | 4–24 Std. |
| Blog | 24 Stunden | 48 Stunden |
Ein RPO von einer Stunde impliziert eine stündliche Sicherung oder sogar binäre Protokolle, wenn die Datenbank dies zulässt. Eine vierstündige RTO erfordert ein dokumentiertes Verfahren und eine zuvor getestete Wiederherstellung – kein erster Versuch unter Stress an einem Sonntagabend. Wenn niemand eine vollständige Wiederherstellung geplant hat, handelt es sich bei der angezeigten RTO um eine Schätzung.
Minimale Architektur und Rolle des Hosts
Die 3-2-1-Regel bleibt die Grundlage: drei Kopien, zwei Medien, eine Offsite. Machen Sie eine vollständige Bestandsaufnahme: Code in Git, Datenbank, hochgeladene Dateien, DNS-Einträge, Geheimnisse und Zertifikate. Schreiben Sie ein nummeriertes Runbook: das den Host aufruft, das den DNS umschaltet, das die wiederhergestellte Datenbank validiert – siehe redirects domaine für die Switchover-Traps.
Bereiten Sie eine Wiederherstellungsumgebung vor: kalter VPS, fertiges Image oder zweiter dokumentierter Host. Planen Sie die externe Kommunikation über eine im Voraus verfasste Statusseite und Vorfallmeldungen. Der Host stellt häufig Snapshots bereit; Sie müssen die Datenbank exportieren, eine Offsite-Kopie verschlüsseln, die Wiederherstellung testen und ein sekundäres DNS-Failover verwalten, wenn das Problem dies erfordert.
Testen Sie die Restaurierung: der einzige Beweis, der zählt
Ein Backup, das nie wiederhergestellt wurde, ist ein Versprechen. Führen Sie jedes Quartal eine vollständige Übung durch: Wiederherstellung beim Staging, Überprüfung der Uploads, Anwendungsverbindungstest, Echtzeitmessung. Beachten Sie die Unterschiede zwischen der gemessenen Dauer und der angekündigten RTO.
Hier treten typische Fehler auf: Backup-Plugin, das das „Uploads“-Verzeichnis ausschließt, Snapshot zu alt, inkompatible PHP-Version auf dem Wiederherstellungsserver, fehlende Geheimnisse im Tresor. Korrigieren Sie den Prozess nach jeder Übung – nicht nur den imaginären Zusammenbruch.
Switchover, DNS und zweiter Host
Bei kritischen Standorten reduziert ein zweiter Host oder eine vorkonfigurierte Wiederherstellungszone die RTO. Die DNS-Umstellung bleibt die Schwachstelle: hohe TTL, Resolver-Cache, Zertifikate an den alten Server gebunden. Dokumentieren Sie den Ablauf: TTL-Reduzierung am Tag vor einer geplanten Änderung, A/AAAA-Umschaltung, HTTPS-Prüfung, Rollback bei Fehlschlag.
Ein Cold-Standby kostet weniger als ein Hot-Standby, verlängert aber die Zeit bis zur Wiederinbetriebnahme. Die Wahl wird auf der Grundlage des akzeptierten RTO und des Budgets getroffen – nicht auf der Grundlage des technischen Egos des Teams.
Der Gipfel: Sicherheit gewährleistet; Nur die Wiederherstellung beweist
Entscheide dich und gehe ohne blinden Fleck voran
Beginnen Sie mit der Festlegung eines RTO und eines RPO pro kritischem Dienst, die mit dem Unternehmen validiert werden. Automatisieren Sie anschließend Offsite-Backups und führen Sie eine Bestandsaufnahme der Geheimnisse und Abhängigkeiten. Planen Sie einen vierteljährlichen Wiederherstellungstest und notieren Sie die tatsächlich beobachtete Dauer. Vergleichen Sie Gastgeber, die ihre Snapshots und Verfahren über das Verzeichnis dokumentieren. Ziehen Sie einen zweiten Host oder Wiederherstellungsbereich in Betracht, wenn der finanzielle oder Reputationsrisiko die Kosten der Redundanz übersteigt.
Häufig gestellte Fragen
Was ist der Unterschied zwischen Backup- und Wiederherstellungsplan?
Backup kopiert Daten. Der Wiederherstellungsplan legt fest, wer was wiederherstellt, in welchem Zeitraum, mit welchem akzeptablen Verlust und wie fortgefahren werden soll, wenn der Host nicht verfügbar ist. Ohne ein schriftliches und geprüftes Verfahren bleibt die Kopie am Tag der Krise theoretisch.
Reichen die automatischen Backups des Hosts aus?
Nein, nicht allein. Häufigkeit, Aufbewahrung und Wiederherstellung sind nicht immer vertraglich garantiert. Es sind eine externe Kopie, ein vierteljährlicher Test und ein dokumentiertes Verfahren erforderlich – siehe CGV-Hosting.
Welcher RTO/RPO für eine E-Commerce-Site?
Indikativ: RPO weniger als eine Stunde für Aufträge, RTO weniger als vier Stunden für die Wiederaufnahme des Handels – zu kalibrieren auf Basis des pro Stunde verlorenen Umsatzes. Ein Showcase-Blog verträgt oft 24 Stunden; Ein tagsüber blockierter Korb kostet viel mehr.
Wird ein zweiter Host benötigt?
Für kritische Standorte ja: DNS-Failover, Standby-Infrastruktur, validiertes Runbook. Kosten stehen im Verhältnis zum Risiko. Bei Shared Services ist ein zweiter Host nicht zwingend erforderlich, wenn eine lange RTO akzeptabel bleibt – sofern dies explizit vorausgesetzt wird.
Ein Backup, das Sie nie wiederhergestellt haben, ist ein Versprechen. Eine PRA ist das Versprechen, das gegen eine Stoppuhr gehalten wird.