Premium WordPress-Wartung · by Frontend GmbH
Wie oft sollte ein Disaster-Recovery-Plan aktualisiert werden?
Die Antwort.
Ein Disaster-Recovery-Plan sollte regelmäßig sowie nach wesentlichen technischen, organisatorischen oder personellen Änderungen geprüft und aktualisiert werden. Auch ein tatsächlicher Vorfall oder Restore-Test ist Anlass, Kontakte, Reihenfolge, Zeitziele und Abhängigkeiten anzupassen. Kritische Zugänge und Ansprechpartner sollten häufiger auf Gültigkeit geprüft werden.
Abhängig vom vereinbarten Umfang aktualisieren wir die technischen Wiederanlaufangaben Ihrer Website nach relevanten Änderungen und planen weitergehende Notfallübungen mit Ihnen.
Aktualisieren, wenn sich die Realität ändert
Ein jährlicher Review ist ein sinnvoller organisatorischer Anker, reicht nach wesentlichen Änderungen aber nicht aus. Der Plan muss die aktuelle Systemlandschaft und Erreichbarkeit abbilden.
- Nach Hoster-, Domain- oder Architekturwechsel.
- Nach Einführung wichtiger Plugins, Shops oder Schnittstellen.
- Bei personellen Wechseln und geänderten Zugriffsrechten.
- Nach jedem Test oder echten Vorfall anhand der gewonnenen Erkenntnisse.
Änderungen, die sofort eine Planprüfung auslösen
Ein neuer Zahlungsdienst, Hosterwechsel, neues CDN, andere Domainverwaltung oder Wechsel verantwortlicher Personen verändert den Wiederanlaufweg direkt. Auch nach einem echten Vorfall oder Test wird geprüft, wo Zeit verloren ging. Ein kurzer ereignisbezogener Review hält den Plan aktuell; eine umfassendere Übung kann zusätzlich in einem zur Kritikalität passenden Rhythmus vereinbart werden.
Ereignisse lösen Aktualisierung sofort aus
Hoster-, Domain-, CDN- oder Zahlungsdienstwechsel verändern den Wiederanlaufweg unmittelbar. Gleiches gilt für neue verantwortliche Personen, geänderte Rechte oder neue geschäftskritische Funktionen. Solche Änderungen werden nicht bis zum nächsten Kalendertermin aufgeschoben.
Zusätzlich ist ein regelmäßiger Review sinnvoll, dessen Rhythmus sich nach Kritikalität und Veränderung richtet. Nach Übung oder echtem Vorfall werden Wartezeiten und fehlende Informationen ausgewertet. Kontakte lassen sich häufiger prüfen als ein vollständiger technischer Wiederanlauf. So bleibt der Plan aktuell, ohne ein pauschales Intervall als ausreichend zu behaupten.
Verwandte Fragen.
Wie erstellt man einen vollständigen Disaster-Recovery-Plan?
Ein Disaster-Recovery-Plan definiert Systeme, Verantwortliche, verfügbare Sicherungen, Wiederanlaufreihenfolge, Zugänge, Kommunikationswege und zulässigen Datenverlust.
Was passiert, wenn keine aktuelle Sicherung vorhanden ist?
Ohne aktuelle Sicherung muss geprüft werden, welcher ältere Stand nutzbar ist und welche Daten aus Logs, externen Systemen, E-Mails oder Exporten rekonstruiert werden können.
Welche Informationen gehören in einen Wiederanlaufplan?
Ein Wiederanlaufplan enthält Ansprechpartner, Hosting- und Domainzugänge, Backup-Speicherorte, Wiederherstellungsreihenfolge, Abhängigkeiten, DNS- und SSL-Informationen, externe Dienste, Testkriterien und Kommunikationswege.
Wie sichert man SMTP- und API-Konfigurationen?
SMTP- und API-Konfigurationen werden ohne Klartextgeheimnisse dokumentiert; Schlüssel und Passwörter liegen getrennt in einem sicheren Geheimnis- oder Passwortspeicher.
Ihre Website-Betreuung klären.
Beschreiben Sie uns Ihre Website und Ihr Anliegen. Im Gespräch legen wir fest, welche Betreuung Sie benötigen.