- Disaster Recovery ist nicht das Backup, sondern der dokumentierte Plan, wie aus einem Backup innerhalb einer festgelegten Zeit wieder eine funktionierende Website entsteht.
- Zwei Kennzahlen bestimmen jeden Notfallplan: RTO (wie lange darf die Seite ausfallen?) und RPO (wie viel Datenverlust ist akzeptabel?). Ohne diese Zielwerte ist jeder Plan nur eine Wunschliste.
- Totalausfälle kommen selten durch Fehler im eigenen System, sondern durch Serverausfall beim Hoster, Ransomware, Hoster-Insolvenz oder versehentliches Löschen. Jedes Szenario verlangt ein anderes Vorgehen.
- Der Notfallplan muss vor dem Ausfall fertig sein und von jemandem durchführbar sein, der das System nicht täglich bedient.
Einen Serverausfall merken Shopbetreiber oft zuerst, wenn ein Kunde anruft und fragt, ob die Seite vielleicht gerade offline ist. Ab diesem Moment zählt jede Minute: Wo ist das letzte funktionsfähige Backup? Wer kann es einspielen? Auf welchem Server? Disaster Recovery für Websites gibt auf alle diese Fragen eine dokumentierte Antwort, bevor der Ausfall eintritt. Dieser Ratgeber zeigt, wie ein solcher Plan aufgebaut ist, was RTO und RPO in der Praxis bedeuten, und in welcher Reihenfolge eine WordPress-Website nach einem Totalausfall wieder online kommt.
Was Disaster Recovery von Backup unterscheidet
Der Unterschied ist praktisch und groß. Eine Backup-Datei auf einem externen Speicher nutzt wenig, wenn im Ernstfall unklar ist, auf welchen Server sie eingespielt werden soll, wer Zugriff auf die Zugangsdaten hat, und ob der Restore-Vorgang überhaupt einmal erprobt wurde. Das Bundesamt für Sicherheit in der Informationstechnik hält im Baustein DER.4 Notfallmanagement des IT-Grundschutz-Kompendiums genau das fest: Eine Notfallplanung, die nur auf Papier besteht und nie getestet wurde, kann im Schadensfall nicht als verlässlich angesehen werden.
Disaster Recovery ist also nicht eine Funktion, die man einschaltet, sondern ein Prozess, der folgende Fragen vor dem Ausfall beantwortet:
- Wie lange darf die Website maximal ausfallen?
- Wie viel Datenverlust ist akzeptabel?
- Wer führt die Wiederherstellung durch, wenn die übliche Ansprechperson nicht erreichbar ist?
- Wo liegt das Backup, und wie kommt man daran?
- Auf welchem System wird wiederhergestellt?
- Wie wird während des Ausfalls mit Kunden kommuniziert?
Eine vollständige Backup-Strategie, die den Rahmen für Disaster Recovery legt, beschreibt der Ratgeber WordPress-Backup-Strategie: Der 3-2-1-Plan. Dieser Artikel baut darauf auf und behandelt den Schritt nach dem Backup: den Wiederanlauf.
RTO und RPO: die zwei Kennzahlen, die alles bestimmen
Der BSI-Standard 200-4 zum Business Continuity Management definiert diese beiden Kennzahlen als zentrale Planungsgrößen. RTO steht für Recovery Time Objective und bezeichnet die geforderte Wiederanlaufzeit: Wie lange darf ein System maximal ausfallen, bevor der Schaden für das Unternehmen nicht mehr akzeptabel ist? RPO steht für Recovery Point Objective und bezeichnet den maximal zulässigen Datenverlust: Wie weit darf das letzte funktionierende Backup zurückliegen?
| Kennzahl | Definition (BSI 200-4) | Beispiel Website | Konsequenz für die Backup-Strategie |
|---|---|---|---|
| RTO (Recovery Time Objective) | Geforderte Wiederanlaufzeit: maximale Ausfallzeit bis zur Wiederherstellung | „Die Seite muss in 4 Stunden wieder laufen.“ | Ausweich-Hosting und vorbereitete Restore-Prozedur nötig |
| RPO (Recovery Point Objective) | Maximal zulässiger Datenverlust, gemessen rückwärts vom Ausfall | „Wir dürfen maximal 24 Stunden an Daten verlieren.“ | Tägliche Sicherung ist Pflicht, für Shops stündliche DB-Sicherung sinnvoll |
| RTA (Recovery Time Actual) | Erreichbare Wiederanlaufzeit: was der Plan tatsächlich liefert | Test zeigte: Restore dauert 2,5 Stunden | RTA muss kleiner sein als RTO, sonst Plan nachbessern |
Was bedeuten diese Zahlen konkret? Ein Onlineshop mit 3.000 Euro Tagesumsatz kann einen RTO von vier Stunden plausibel begründen. Ein Unternehmenswebsite ohne direkte Transaktionen toleriert unter Umständen 24 Stunden. Ein Arztpraxis-Terminbuchungssystem darf vielleicht eine Stunde ausfallen. Die Zielwerte sind keine universellen Standards, sondern eine Entscheidung über Risikotoleranz und Budget.
Entscheidend ist, dass die tatsächliche Wiederanlaufzeit, also das, was der Plan im Ernstfall liefert, kleiner ist als der RTO-Zielwert. Das prüft man durch einen echten Restore-Test, nicht durch Schätzungen.
Die vier Totalausfall-Szenarien
Vier Szenarien verursachen den Großteil der echten Totalausfälle. Wer seinen Plan danach ausrichtet, ist auf praktisch jeden Ernstfall vorbereitet.
Szenario 1: Serverausfall beim Hoster
Im November 2025 standen Tausende Kunden der deutschen Hoster Hosting.de und Webland plötzlich ohne Website da. Bei Hosting.de fielen ab dem 27. November Core-Switches aus, was Routing-Probleme für alle gehosteten Systeme auslöste. Bei Webland scheiterte eine geplante Server-Migration, gefolgt von einem erneuten Speicher-Cluster-Ausfall. Manche Kunden waren über eine Woche offline. Borns IT-Blog dokumentierte den Vorfall: Kunden konnten während des Ausfalls weder auf ihre Systeme zugreifen noch zuverlässig an Informationen kommen, weil auch die Statusseite des Hosters selbst offline war.
Was half: Wer eine externe Backup-Kopie hatte und ein vorbereitetes Ausweich-Hosting, konnte seine Seite innerhalb weniger Stunden auf einem anderen Server wieder hochfahren. Wer ausschließlich auf Hoster-interne Backups gesetzt hatte, wartete auf die Wiederherstellung durch den Hoster, ohne Einfluss auf den Zeitplan.
Szenario 2: Ransomware und Datenverschlüsselung
Ransomware verschlüsselt Dateien auf dem befallenen System, und zwar nicht sofort, sondern oft nach einer Inkubationszeit von Tagen bis Wochen. Das hat eine kritische Konsequenz für Backups: Wurden die Sicherungen in dieser Zeit regelmäßig erstellt, sind auch sie möglicherweise kompromittiert. Das BSI stellt im Baustein DER.4 klar, dass für Ransomware-Szenarien mindestens ein hinreichend altes, offline gelagertes Backup nötig ist, das nicht vom infizierten System aus erreichbar war.
Der Unterschied zu anderen Ausfällen: Nach einem Ransomware-Angriff darf nicht einfach das letzte Backup eingespielt werden, ohne vorher sicherzustellen, dass es sauber ist. Zudem müssen Zugangsdaten rotiert werden, bevor das System wieder online geht, weil Angreifer sie möglicherweise abgegriffen haben. Zur spezifischen Behandlung gehackter Sites beschreibt der Ratgeber Website gehackt: Der Notfallplan in fünf Schritten das nötige Vorgehen.
Szenario 3: Hoster-Insolvenz
Meldet ein Hosting-Anbieter Insolvenz an, übernimmt ein Insolvenzverwalter die Geschäfte. Er kann auf Anfrage zur Herausgabe verpflichtet sein, soweit der Hoster keine eigenen Rechte an den Inhalten beansprucht. Der Prozess dauert jedoch, läuft bürokratisch und ist nicht planbar. Wer kein externes Backup hatte, ist auf die Kooperation des Insolvenzverwalters angewiesen. Wer eines hatte, kann sofort umziehen.
Die Verbraucherzentrale weist darauf hin, dass Kunden bei einer Unternehmensinsolvenz ihre Ansprüche beim Insolvenzverwalter anmelden müssen, aber eine Erstattung vorausgezahlter Hosting-Gebühren aus der Insolvenzmasse oft nur teilweise oder gar nicht erfolgt. Wer eine externe Backup-Kopie hat, die vom Hoster unabhängig ist, muss auf diesen Prozess nicht warten.
Szenario 4: Menschlicher Fehler
In der Praxis ist versehentliches Löschen eine der häufigsten Ursachen für akuten Datenverlust: eine falsche Datenbankabfrage, ein Update, das die Datenbank leert, ein Agentur-Mitarbeiter, der den falschen Server leert. Der Vorteil gegenüber anderen Szenarien: Das System selbst ist meist intakt, es fehlen nur Daten. Der Nachteil: Wenn das letzte Backup vor dem Fehler liegt und der Fehler erst spät bemerkt wird, ist der Verlust entsprechend groß.
Für dieses Szenario ist RPO die entscheidende Kennzahl. Je kürzer der Backup-Rhythmus, desto weniger Daten gehen verloren. Für aktive Shops mit laufenden Bestellungen sind stündliche Datenbanksicherungen kein Luxus.
Was ein Notfallplan-Dokument enthalten muss
Ein Notfallplan ist ein Dokument, das von einer Person durchführbar sein muss, die das System nicht täglich bedient. Das ist das wichtigste Qualitätskriterium. Wer beim Schreiben denkt „das weiß ich ja auswendig“, hat noch keinen Plan, sondern nur eine Checkliste für sich selbst.
Das BSI beschreibt im IT-Grundschutz-Kompendium folgende Pflichtbestandteile für einen Notfallplan:
| Bestandteil | Was dort dokumentiert wird | Warum unverzichtbar |
|---|---|---|
| Zuständigkeiten | Wer trifft Entscheidungen, wer führt aus, wer wird informiert? | Ohne klare Verantwortung verliert man Zeit mit Absprachen |
| Zugangsdaten-Inventar | Hosting-Panel, FTP/SFTP, Datenbankzugang, Domain-Registrar, CDN, E-Mail-Provider | Im Ausfall hat niemand Zeit zu suchen |
| Backup-Inventar | Wo liegt welches Backup, wie alt ist es, wie ruft man es ab? | Backup nützt nichts, wenn man es nicht findet |
| Ausweich-System | Welcher Hoster als Ausweich, Login, Tarif, vorbereitet oder Schritt-für-Schritt | Entscheidungszeit im Notfall auf null reduzieren |
| Wiederanlauf-Prozedur | Exakte Schrittfolge mit Screenshots oder Screencast, DNS-Umschaltung, Test-URLs | Ausführbar ohne Systemkenntnisse |
| RTO/RPO-Zielwerte | Festgelegte Ziele, gegen die der Plan bewertet wird | Ohne Zielwerte kein Erfolgsmaßstab |
| Kommunikationsplan | Wen benachrichtigt man wann, welche Statusmeldung geht an Kunden? | Professioneller Umgang mit dem Ausfall bewahrt Vertrauen |
| Test-Protokoll | Wann wurde der Plan zuletzt getestet, Ergebnis, nächster Test-Termin | Ungetestete Pläne sind nicht belastbar |
Das Dokument gehört nicht auf dem Produktivserver gespeichert. Ein ausgefallener Server kann das Dokument nicht ausliefern. Sinnvolle Speicherorte sind ein Passwort-Manager mit sicherer Notiz, ein Cloud-Speicher, auf den mehrere Personen zugreifen können, oder ein ausgedrucktes Exemplar in einem gesicherten Büro.
Wiederanlauf-Reihenfolge: Schritt für Schritt
Wenn der Ernstfall eingetreten ist, zählt eine klare Abfolge. Hektische Parallelarbeit, bei der jemand an Dateien herumfummelt, während jemand anderes am DNS dreht, kostet Zeit und schafft neue Fehler.
- Umfang feststellen. Ist die gesamte Website ausgefallen oder nur ein Teil? Ist die Datenbank erreichbar? Ist der Server technisch online, aber das CMS defekt? Die Diagnose bestimmt den Weg. Ein Dienst wie Down For Everyone Or Just Me beantwortet in Sekunden, ob die Seite weltweit nicht erreichbar ist.
- Ursache grob eingrenzen. Liegt der Fehler beim Hoster (Statusseite prüfen), bei DNS (nslookup auf der Kommandozeile), beim CMS oder bei einem Update? Zwei Minuten Diagnose sparen oft eine Stunde falsche Maßnahmen.
- Entscheidung: reparieren oder wiederherstellen. Lässt sich die Ursache in unter einer Stunde beheben? Wenn ja, reparieren. Wenn nein oder wenn unsicher, sofort das jüngste funktionierende Backup einspielen. Unter Zeitdruck am laufenden System zu experimentieren verlängert Ausfälle erfahrungsgemäß.
- Ausweich-Server vorbereiten. Wenn der Primärserver nicht nutzbar ist, beim Ausweich-Hoster einen Tarif anlegen oder reaktivieren, Domainzuordnung vorbereiten.
- Backup-Dateien übertragen. WordPress-Dateien via FTP/SFTP auf den Zielserver übertragen. Laut WordPress Developer Documentation umfasst ein vollständiges Restore: den gesamten wp-content-Ordner (Themes, Plugins, Uploads), die wp-config.php, die .htaccess sowie den Datenbankdump.
- Datenbank importieren. Leere Datenbank auf dem Zielserver anlegen, SQL-Dump per phpMyAdmin oder WP-CLI importieren. Falls der Datenbankname oder die Zugangsdaten abweichen, in der wp-config.php anpassen.
- DNS umschalten. A-Record der Domain auf die IP-Adresse des neuen Servers zeigen lassen. TTL vorab auf 300 Sekunden reduzieren, falls das geplant war, beschleunigt die Propagation erheblich. Realistisch: DNS-Umschaltungen dauern in der Praxis 15 Minuten bis mehrere Stunden, abhängig von der vorherigen TTL-Einstellung.
- Funktionstest. Via hosts-Datei oder Staging-URL prüfen, ob WordPress korrekt läuft, bevor der DNS umgeschaltet ist. Formulare testen, Warenkorb testen, Anmeldung testen.
- Cache leeren. CDN-Cache invalidieren, WordPress-Cache-Plugins leeren, damit keine veralteten Seiten ausgeliefert werden.
- Monitoring prüfen. Das Uptime-Monitoring auf neue Server-IP umstellen, Alerts bestätigen.
Ausweich-Hosting: wenn der primäre Server nicht mehr existiert
Für kleine und mittlere Websites ist ein vollständiges Hot-Standby-System, das jederzeit synchron läuft, in der Regel unverhältnismäßig teuer. Eine realistischere Variante ist das vorab dokumentierte Ausweich-Szenario: Man weiß, bei welchem Hoster man im Notfall bucht, hat einen Account angelegt, und der Prozess ist einmal erprobt.
Kriterien für die Ausweich-Hoster-Wahl:
- Anderer Anbieter als der primäre Hoster und anderes Rechenzentrum
- PHP-Version kompatibel mit dem WordPress-Setup
- Datenbankimport per phpMyAdmin oder WP-CLI möglich
- Buchung und Bereitstellung innerhalb von 30 Minuten realistisch
- Keine Mindestlaufzeit, damit der Vertrag wieder gekündigt werden kann, sobald der primäre Server wieder läuft
Wer DSGVO-konforme Backups hostet, muss beim Ausweich-Hoster darauf achten, dass der Serverstandort innerhalb der EU liegt und eine Auftragsverarbeitungsvereinbarung abgeschlossen wird, sobald personenbezogene Daten (Kundendaten, Kontaktformular-Einträge) auf dem System liegen.
Eine hilfreiche Vorbereitung: Einmal einen Test-Restore auf dem Ausweich-Hoster durchführen, auch wenn alles läuft. Das zeigt, ob die Prozedur stimmt und wie lange sie wirklich dauert, also ob der RTO-Zielwert erreichbar ist.
Kommunikation im Notfall
Kurze Ausfälle unter 15 Minuten werden oft gar nicht aktiv kommuniziert. Ab einer Stunde Ausfall ist eine kurze Statusmeldung in sozialen Medien oder per E-Mail sinnvoll. Kanäle, die dafür in Frage kommen: Social Media, Newsletter, eine Statusseite auf einer Subdomain eines anderen Servers, eine vorab formulierte Antwortmail für eingehende Anfragen.
Der Inhalt der Meldung sollte kurz und ehrlich sein: „Unsere Website ist derzeit nicht erreichbar. Wir arbeiten an der Wiederherstellung und sind erreichbar unter [E-Mail oder Telefon]. Stand: [Uhrzeit].“ Keine Spekulationen über die Ursache, keine Versprechen über den Wiederanlauf-Zeitpunkt, den man noch nicht kennt.
Für Onlineshops gilt zusätzlich: Wenn Bestellungen in der Ausfallzeit technisch nicht möglich waren, sollte das transparent kommuniziert werden. Wenn Daten möglicherweise verloren gegangen sind und es sich um personenbezogene Daten handelt, greift die DSGVO-Meldepflicht nach Artikel 33 DSGVO: eine Meldung an die zuständige Datenschutzbehörde binnen 72 Stunden nach Bekanntwerden des Vorfalls.
Ein Beispiel aus der Praxis
In einem Projekt, das wir 2024 begleitet haben, fiel ein WooCommerce-Shop für einen Dienstleister im Handwerk plötzlich komplett aus. Der Hoster hatte ein technisches Problem im Rechenzentrum, das er nicht innerhalb von vier Stunden beheben konnte. Die Konsequenz war erheblich: Der Shop war der einzige Kanal für Angebots-Anfragen, und der Betreiber hatte keinen Notfallplan.
Die Wiederherstellung dauerte 14 Stunden, obwohl das Backup vorhanden war. Der Domain-Registrar war ein anderer Anbieter als der Hoster, und die Zugangsdaten dafür lagen nirgendwo griffbereit. Kein Ausweich-Hoster war vorbereitet. Das Backup war vorhanden, aber nie getestet worden. Der erste Restore-Versuch scheiterte wegen einer PHP-Versionsinkompatibilität auf dem Notfall-Server.
Mit einem vorbereiteten Notfallplan hätte der Restore in unter drei Stunden erledigt sein können. Die Differenz von elf Stunden kostete den Betreiber mehrere Kundengespräche, die nicht stattgefunden haben, und ein verlorenes Angebot von einem Interessenten, der die Website mehrfach nicht erreichte und zur Konkurrenz wechselte.
Das Dokument, das nach diesem Vorfall erstellt wurde, passt auf zwei Seiten. Es enthält: alle Zugangsdaten im Passwort-Manager verlinkt, den Namen des vorab gebuchten Ausweich-Hosters mit Login-URL, die exakte Schritt-für-Schritt-Prozedur für den WordPress-Restore, und die Mobilnummer des Webentwicklers. Das war alles, was gebraucht wurde.
Notfallplan-Checkliste
Diese Punkte können Sie heute durchgehen. Wer alle zehn mit Ja beantwortet, ist auf die häufigsten Szenarien vorbereitet.
- Sind RTO und RPO für Ihre Website schriftlich festgelegt?
- Liegt ein externes Backup (außerhalb des primären Servers) vor, das maximal so alt ist wie Ihr RPO?
- Sind alle Zugangsdaten (Hosting, FTP, Datenbank, Registrar, CDN, E-Mail) zentral und für mindestens zwei Personen erreichbar gespeichert?
- Ist ein Ausweich-Hoster dokumentiert, und wurde die Bereitstellung dort einmal erprobt?
- Liegt eine schriftliche Wiederanlauf-Prozedur vor, die jemand ohne WordPress-Kenntnisse ausführen könnte?
- Wurde der komplette Restore-Prozess in den letzten zwölf Monaten einmal testweise durchgeführt?
- Ist ein Uptime-Monitoring aktiv, das innerhalb von fünf Minuten alarmiert?
- Gibt es eine vorab formulierte Statusmeldung für Kunden bei Ausfall?
- Ist die TTL der Domain-DNS-Einträge auf einen niedrigen Wert (300–600 Sekunden) gesetzt, um DNS-Umschaltungen zu beschleunigen?
- Wurde der Notfallplan nach dem letzten Hoster- oder Passwortwechsel aktualisiert?
- Disaster Recovery ist der Prozess, kein Tool. Das Backup ist nur der Rohstoff, der Plan ist der Weg zurück.
- RTO und RPO vor dem Ausfall festlegen: Sie bestimmen, wie aufwendig der Plan sein muss und ob er im Ernstfall reicht.
- Der Notfallplan muss getestet sein. Eine Sicherung, die nie zurückgespielt wurde, ist kein verlässliches Backup.
- Wer seinen Notfallplan an einen Wartungspartner delegiert, muss vertraglich sicherstellen, dass dieser Partner auch die Zugangsdaten kennt und die Prozedur erprobt hat.
Häufige Fragen
Was ist der Unterschied zwischen Backup und Disaster Recovery?
Ein Backup ist eine Datenkopie. Disaster Recovery ist der vollständige, dokumentierte und getestete Prozess, mit dem aus dieser Datenkopie innerhalb einer festgelegten Zeit wieder eine funktionierende Website entsteht. Backups ohne DR-Plan geben nur eine trügerische Sicherheit.
Was bedeuten RTO und RPO?
RTO (Recovery Time Objective) ist die maximale Ausfallzeit, die ein Unternehmen tolerieren kann, bevor der Schaden nicht mehr akzeptabel ist. RPO (Recovery Point Objective) ist der maximale Datenverlust, gemessen rückwärts vom Ausfall: Wie alt darf das letzte Backup sein? Beide Begriffe stammen aus dem BSI-Standard 200-4 zum Business Continuity Management und gelten auch für kleine Websites.
Muss ich ständig einen zweiten Hosting-Vertrag laufen haben?
Nein. Für kleine und mittlere Websites reicht es, einen Ausweich-Hoster zu dokumentieren, dort einen Account anzulegen und den Restore-Prozess einmal zu testen. Im Notfall bucht man dann kurzfristig einen Tarif. Wichtiger als ein laufender zweiter Vertrag ist ein externes Backup, das sofort verfügbar ist.
Wie lange dauert ein vollständiger WordPress-Restore?
Für eine typische WordPress-Website unter einem Gigabyte Gesamtgröße liegt die Restore-Zeit bei 30 bis 90 Minuten, wenn alle Zugangsdaten verfügbar sind und der Prozess einmal erprobt wurde. Hinzu kommen bis zu mehrere Stunden für die DNS-Propagation nach einer Hoster-Umschaltung, falls die TTL nicht vorab angepasst wurde. Ohne Vorbereitung und Restore-Test sind sechs bis 14 Stunden bis zum Wiederanlauf realistisch.
Was tun, wenn der Hoster insolvent wird und ich kein externes Backup habe?
In diesem Fall muss der Insolvenzverwalter kontaktiert werden. Er ist verpflichtet, Kundendaten auf Anfrage herauszugeben, sofern der Hoster keine eigenen Rechte an den Inhalten hat. Dieser Prozess dauert jedoch, ist nicht planbar und endet nicht immer mit einem vollständigen Daten-Export. Schon ein einmaliges externes Backup pro Woche hätte die vollständige Abhängigkeit vom Insolvenzprozess vermieden.
Wie oft sollte der Notfallplan getestet werden?
Mindestens einmal jährlich, bei Websites mit regelmäßigen Änderungen oder kritischer Funktion besser quartalsweise. Ein Test bedeutet, den kompletten Restore auf einer separaten Umgebung tatsächlich durchzuführen, nicht nur zu prüfen, ob ein Backup vorhanden ist. Das BSI hält im IT-Grundschutz-Baustein DER.4 fest, dass ein ungetesteter Plan nicht als verlässlich angesehen werden kann.
Gilt die DSGVO-Meldepflicht auch bei einem Serverausfall ohne Datenverlust?
Eine Meldepflicht nach Artikel 33 DSGVO entsteht nur bei einer Verletzung der Sicherheit personenbezogener Daten. Ein reiner Ausfall ohne Datenverlust und ohne unberechtigten Zugriff löst keine Meldepflicht aus. Wenn im Rahmen des Vorfalls jedoch Daten verloren gehen oder unberechtigter Zugriff möglich war, beginnt die 72-Stunden-Frist ab dem Zeitpunkt, an dem dies bekannt wird.