Mit dem benötigten Ergebnis beginnen
Ein Backupplan beginnt mit zwei Fragen: Welche Daten müssen zurückkehren, und wann muss die Anwendung wieder nutzbar sein? Ein redaktioneller Auftritt benötigt andere Prioritäten als ein Bestellprozess. Diese Anforderungen stammen vom Betreiber. Erst danach wird geprüft, welche Sicherungsverfahren und Dienstleistungen sie erfüllen können.
Das NIST-Glossar zum Recovery Point Objective beschreibt den benötigten Datenzeitpunkt nach einem Ausfall. Das Recovery Time Objective betrachtet den tolerierbaren Zeitraum der Wiederherstellungsphase. Für das eigene Projekt werden daraus konkrete Anforderungen. Sie sind noch keine Zusage des Providers und kein aus einem Tarifnamen ableitbares SLA.
Schreiben Sie die Auswirkungen eines Datenverlusts auf: Welche Inhalte müssten neu erstellt, welche Geschäftsvorgänge abgeglichen werden? Dadurch wird der Sicherungsbedarf verständlicher als durch eine pauschale Forderung nach „regelmäßigen Backups“.
Den gesicherten Umfang eindeutig festhalten
WordPress benötigt Dateien und Datenbank. Die offizielle Backupdokumentation behandelt beide Bestandteile. Für das eigene Projekt ergänzt die Bestandsliste Konfigurationen, externe Datenquellen und gegebenenfalls weitere Dienste. Eine Sicherung des Webroots enthält nicht automatisch jeden Geschäftsdatenbestand.
Ordnen Sie jedem wichtigen Bestand eine tatsächliche Sicherung zu. Notieren Sie Verfahren, Speicherort und verfügbare Stände im geschützten Betriebsdokument. Fragen Sie bei einem Managed-Angebot nach Aufbewahrung, Ausführung und Wiederherstellungsweg. Eine beworbene Speichermenge beschreibt das Budget, beantwortet aber noch nicht diese Prozessfragen.
| Bestand | Benötigter Nachweis |
|---|---|
| Website-Dateien | Enthaltene Verzeichnisse und lesbares Archiv |
| Datenbank | Passender Sicherungszeitpunkt und erfolgreicher Import |
| Konfiguration | Zuordnung ohne offen ausgegebene Geheimnisse |
| Externe Daten | Eigenes Verfahren des zuständigen Systems |
Den Restore auf das richtige Projekt begrenzen
Eine gemeinsame Serverumgebung enthält möglicherweise mehrere unabhängige Projekte. Eine Wiederherstellung muss deshalb einen beschriebenen Scope haben. Wenn nur eine Website betroffen ist, sollten aktuelle Daten anderer Kunden bewusst erhalten bleiben. Prüfen Sie, welche Wiederherstellungsebenen das konkrete Verfahren unterstützt und welche Schritte dafür nötig sind.
Ein Snapshot und eine projektweise Sicherung können unterschiedliche Zwecke haben. Ihre Bezeichnungen allein sagen nicht, ob ein bestimmter Kundenbestand getrennt zurückkehren kann. Klären Sie dies für Agenturumgebungen ausdrücklich. Eine pauschale Serverrückkehr kann fachlich weitreichender sein als der gewünschte Eingriff.
Bei Shops berücksichtigen Sie außerdem externe Vorgänge seit dem Sicherungszeitpunkt. Ein Zahlungsdienst kann einen neueren Stand haben als die zurückgespielte Anwendung. Die technische Wiederherstellung und der fachliche Datenabgleich sind deshalb getrennte Aufgaben. Beide brauchen eine zuständige Person.
Eine Probe in einer abgegrenzten Umgebung ausführen
Eine Restoreprobe prüft, ob das Verfahren tatsächlich benutzt werden kann. Wählen Sie eine geeignete geschützte Umgebung und einen identifizierbaren Sicherungsstand. Legen Sie vorab fest, wer Dateien und Datenbank zurückspielt und wer die Anwendung abnimmt. Die Probe verändert keine fremden Projekte.
- Gewünschten Sicherungsstand und enthaltenen Scope bestätigen.
- Archiv und Datenbank in der vorgesehenen Probeumgebung wiederherstellen.
- Konfiguration passend zur Probe behandeln.
- Anmeldung, Inhalte und wichtige Nutzerwege prüfen.
- Ergebnisse, Dauer und fehlende Schritte dokumentieren.
Reale Außenwirkungen werden gezielt ausgeschaltet oder auf Testverbindungen umgestellt. Ein wiederhergestellter Prüfshop soll keine echten Nachrichten oder Aufträge versenden. Die benötigten Maßnahmen ergeben sich aus seinen Schnittstellen. Der Stagingratgeber hilft bei dieser Abgrenzung.
Ein Protokoll mit ehrlichen Zuständen führen
Notieren Sie Datum, Sicherungsstand, Probeumgebung und verantwortliche Personen. Beschreiben Sie anschließend die tatsächlich ausgeführten Prüfungen. „Backup vorhanden“ und „Anmeldung nach Restore geprüft“ sind unterschiedliche Nachweise. Kennzeichnen Sie fehlende Schritte sichtbar, damit sie später ergänzt werden können.
Eine erfolgreich ausgeführte Probe zeigt ein Ergebnis unter ihren dokumentierten Bedingungen. Sie garantiert nicht automatisch dieselbe Dauer in jeder Störung. Datenumfang, verfügbare Umgebung und notwendige fachliche Abgleiche können sich verändern. Benötigte Zusagen müssen gesondert vereinbart werden. Für transaktionale Business-Anwendungen sollte das Protokoll insbesondere den getesteten Datenzeitpunkt enthalten.
Speichern Sie keine Passwörter oder unnötigen persönlichen Daten im offenen Bericht. Ein Verweis auf den geschützten Zugangsvorgang und eine klare Zuordnung genügen. Das Protokoll muss auch von einer Vertretung verstanden werden können.
Änderungen als Anlass für eine neue Prüfung nutzen
Eine Sicherungsstrategie kann nach einem großen Import, einer neuen Anwendung oder einer veränderten Schnittstelle unvollständig werden. Nutzen Sie solche Änderungen als Anlass für einen Abgleich. Prüfen Sie Umfang, Speicherbedarf und Zuständigkeiten. Auch ein neues Teammitglied muss den Restoreprozess erreichen und verstehen können.
Regeln Sie außerdem, wer auf eine fehlgeschlagene Sicherung reagiert. Ein geplantes Verfahren braucht eine Rückmeldung über seine tatsächliche Ausführung. Bleibt diese Aufgabe ungeklärt, kann ein lange unbemerkter Fehler alle späteren Annahmen entwerten. Die Zuständigkeitsmatrix hält Prüfung und Bearbeitung fest.
Der Abschluss der Hostingabnahme nennt den letzten tatsächlich geprüften Sicherungs- und Wiederherstellungsstand. Diese Information ist präziser als eine allgemeine Versicherung, dass Daten sicher seien. Sie zeigt, worauf das Team seine nächste Entscheidung stützen kann.
Vor einer umfangreichen Änderung wird der geeignete Sicherungsstand gesondert bestätigt. Ein nächtliches Archiv kann beispielsweise älter sein als die kurz vorher eingegangenen Inhalte. Entscheiden Sie, ob ein zusätzlicher Stand benötigt wird und wer ihn erstellt. Die Sicherung gehört dabei außerhalb eines öffentlich zugänglichen Downloads abgelegt. Ihr Vorhandensein ist kein Grund, sie zusammen mit normalen Medien auszuliefern.
Auch die benötigten Wiederherstellungsinformationen sollen verfügbar bleiben, wenn die laufende Website nicht erreichbar ist. Eine Beschreibung, die ausschließlich im betroffenen System liegt, hilft dann nur eingeschränkt. Speichern Sie das Betriebsdokument an einem passenden geschützten Ort und prüfen Sie den Zugang der berechtigten Vertretung. Dadurch wird die Dokumentation Teil des ausführbaren Verfahrens.