Ein erfolgreiches Backup beweist für sich genommen nicht, dass eine Anwendung den Betrieb wieder aufnehmen kann. Es kann ein Schlüssel, eine externe Abhängigkeit, die zur Datenbank gehörenden Dateien oder eine Anleitung fehlen, die festlegt, in welcher Reihenfolge sie wiederherzustellen sind. Mit Disaster-Recovery-Tests für PHP-Anwendungen lässt sich der gesamte Prozess überprüfen, bevor ein Datenverlust oder eine Datenbeschädigung dazu zwingt, ihn unter Zeitdruck auszuführen.
Ziel ist nicht die Zusicherung, dass es niemals zu Unterbrechungen kommt, sondern Erkenntnisse darüber zu gewinnen, was sich wiederherstellen lässt, wie lange es dauert und welche Hindernisse noch bestehen. Damit der Test nützlich ist, müssen sein Umfang festgelegt, die Umgebung isoliert, sowohl die Infrastruktur als auch das Verhalten der Anwendung validiert und Verantwortliche für erforderliche Verbesserungen benannt werden.
Ein Backup zu überprüfen ist nicht dasselbe wie den Dienst wiederherzustellen
Eine Backup-Prüfung kann bestätigen, dass eine Datei vorhanden ist, ihre Größe plausibel erscheint oder ein Tool sie lesen kann. Das ist eine wertvolle Kontrolle, unterscheidet sich aber von der Wiederherstellung der erforderlichen Komponenten und dem Nachweis, dass die Anwendung mit ihnen funktioniert.
Eine vollständige Wiederherstellung kann eine Datenbank, von Benutzern hochgeladene Dateien, Code und Konfiguration sowie Dienste wie Warteschlangen, Objektspeicher, Cache oder geplante Aufgaben umfassen. Sie kann außerdem von DNS, Zertifikaten, Berechtigungen, PHP-Erweiterungen und externen Diensten abhängen. Fehlt eines dieser Elemente oder ist es nicht mit den übrigen abgestimmt, kann das Backup gültig sein, ohne dass der Dienst tatsächlich wiederhergestellt ist.
Es empfiehlt sich, für jede Anwendung zu definieren, was „wiederhergestellt“ bedeutet. Das kann heißen, dass der PHP-Prozess startet, autorisierte Benutzer sich anmelden und einen kritischen Ablauf abschließen können oder dass Hintergrundaufträge wieder verarbeitet werden. Eine sichtbare Startseite reicht als einziges Kriterium nicht aus.
Umfang und Erfolgskriterien vor Beginn festlegen
Dokumentiere das zu prüfende Szenario, zum Beispiel den Verlust einer Datenbank, beschädigte Dateien oder die Nichtverfügbarkeit einer gesamten Umgebung. Es ist nicht nötig, alle Vorfälle in einer einzigen Sitzung zu simulieren. Ein klar abgegrenztes Szenario macht sichtbar, welche Komponenten wiederhergestellt werden müssen und welche Komponenten ausdrücklich nicht Teil der Übung sind.
Vereinbare mit den Bereichen Business, Technologie und Betrieb überprüfbare Kriterien. Zu den praktischen Fragen gehören:
- Welche Funktionen müssen wieder verfügbar sein und welche können warten?
- Bis zu welchem Zeitpunkt wäre eine Wiederherstellung der Daten akzeptabel und welcher Verlust von Änderungen wäre tolerierbar?
- Wie lange darf der Dienst unterbrochen sein, bevor die Auswirkungen nicht mehr akzeptabel sind?
- Welche Abhängigkeiten gehören zur Wiederherstellung und welche werden durch sichere Ersatzsysteme abgebildet?
- Wer genehmigt die Durchführung, validiert das Ergebnis und kommuniziert Probleme?
Recovery-Point-Ziel (RPO) und Recovery-Time-Ziel (RTO) können dazu dienen, Toleranzen für Datenverlust und Betriebsunterbrechungen auszudrücken. Sie müssen entsprechend den Anforderungen und Möglichkeiten des jeweiligen Dienstes vereinbart werden; einen allgemeingültigen Wert gibt es nicht. Der Test ermöglicht den Vergleich der beobachteten Zeiten und des Datenstands mit diesen Zielen, ohne ein einzelnes Ergebnis als künftige Garantie darzustellen.
Eine isolierte und sichere Umgebung vorbereiten
Führe die Wiederherstellung in einer von der Produktion getrennten Umgebung durch und setze Kontrollen ein, die verhindern, dass der Test echte Daten verändert oder Nachrichten an Kunden sendet. Isoliere nach Möglichkeit die Netzwerke und blockiere oder ersetze Integrationen, die Zahlungen auslösen, E-Mails versenden, Ereignisse veröffentlichen oder externe Systeme ändern könnten. Informiere die Beteiligten darüber, dass es sich um einen Test handelt.
Wiederhergestellte Daten können sensible Informationen enthalten. Wende die geltenden Richtlinien für Zugriff, Aufbewahrung und Datenschutz an und begrenze, wer wie lange auf die Umgebung zugreifen kann. Verwende keine Zugangsdaten aus der Produktion erneut. Verwalte Testgeheimnisse kontrolliert und prüfe, ob sie durch wiederhergestellte Dateien in Protokollen, Repositories oder öffentlich zugänglichen Verzeichnissen offengelegt werden.
Dokumentiere die Ausgangsbedingungen: Datum und Zeitpunkt des Backups, erforderliche Code- und Konfigurationsversionen, verfügbare Ressourcen sowie Unterschiede zwischen Test- und Produktionsumgebung. Eine andere PHP-Version, fehlende Erweiterungen oder abweichende Berechtigungen können das Ergebnis beeinflussen. Diese Abweichungen müssen festgehalten und dürfen nicht mit einem Erfolg oder Fehler des Backups verwechselt werden.
Alle erforderlichen Komponenten wiederherstellen
Befolge das dokumentierte Verfahren, auch wenn du einen schnelleren Weg kennst. Schließlich wird geprüft, ob die Anweisungen ausreichen, damit eine andere Person den Dienst wiederherstellen kann. Halte die Reihenfolge und Dauer jedes Schritts, manuelle Befehle, getroffene Entscheidungen und alle ungeplanten Eingriffe fest.
Eine mögliche, an die jeweilige Architektur anzupassende Reihenfolge ist: Infrastruktur und Konfiguration wiederherstellen, Datenbank und Dateien wiederherstellen, die kompatible Codeversion bereitstellen und die erforderlichen Abhängigkeiten anbinden. Prüfe in PHP je nach Bedarf die Konfiguration des Webservers und von PHP-FPM, erforderliche Erweiterungen, Umgebungsvariablen, Schreibberechtigungen und geplante Aufgaben. Kontrolliere auch Warteschlangen, Objektspeicher und Worker-Prozesse, sofern die Anwendung von ihnen abhängt.
Führe Migrationen oder Prozesse zur Datenrekonstruktion nicht automatisch aus, ohne ihre Auswirkungen auf eine wiederhergestellte Kopie zu kennen. Vergewissere dich, dass die Zugangsdaten ausschließlich auf Testdienste verweisen und Cron-Aufgaben keine externen Auswirkungen haben. Ist für die Wiederherstellung ein manueller Eingriff erforderlich, halte ihn als Teil der tatsächlichen Dauer und als möglichen Verbesserungspunkt fest.
Integrität und Verhalten prüfen, nicht nur den Start
Die Prüfungen sollten Daten und funktionale Abläufe abdecken. Beginne mit technischen Kontrollen: Verbindung zur Datenbank, Prozessstatus, verfügbarer Speicherplatz, Fehlerprotokolle und Antwort interner Dienste. Prüfe anschließend, ob gespeicherte Dateien und Verweise zusammenpassen und wichtige Beziehungen oder Einschränkungen der Datenbank weiterhin konsistent sind.
Wähle Abfragen und Abläufe, die für die tatsächliche Nutzung der Anwendung repräsentativ sind. Prüfe zum Beispiel, ob sich ein bekanntes Objekt finden, ein Testkonto anmelden und ein Vorgang ohne externe Auswirkungen abschließen lässt. Gibt es hochgeladene Dateien, prüfe, ob sie sich abrufen und ihren Datensätzen zuordnen lassen. Gibt es Warteschlangen, prüfe, ob ausstehende Aufträge sich wie vorgesehen verhalten und nicht versehentlich doppelt verarbeitet werden.
Bewahre genügend Nachweise auf, um die Bewertung zu wiederholen: Abfrageergebnisse, ausgeführte Schritte, beobachtete Fehler sowie Start- und Endzeit. Der Vermerk „funktioniert“ reicht nicht aus. Lege vorab fest, welche Prüfungen den Test bestehen lassen und welche ein Ausschlusskriterium sind. Eine Anwendung, die antwortet, aber unvollständige Daten anzeigt oder kritische Vorgänge nicht verarbeitet, darf nach strengeren Kriterien nicht als wiederhergestellt gelten.
Ergebnisse messen, Probleme beheben und sinnvoll regelmäßig testen
Miss die Zeit vom vereinbarten Start bis zur Erfüllung der Wiederherstellungskriterien und nicht nur die Dauer der Datenbankwiederherstellung. Wenn es der Analyse hilft, trenne Wartezeit, automatisierte Arbeit, manuelle Schritte und Validierung voneinander. Vergleiche das Ergebnis mit den vereinbarten Zielen und identifiziere nicht erfüllte Annahmen, etwa fehlende Berechtigungen oder veraltete Dokumentation.
Der Bericht sollte Umfang, wiederhergestellten Zeitpunkt, Ergebnis jeder Prüfung, gemessene Zeiten, Vorfälle, Entscheidungen und Verantwortliche für Korrekturmaßnahmen enthalten. Priorisiere Maßnahmen, die Hindernisse beseitigen: wiederholbare Schritte automatisieren, Anleitungen aktualisieren, Berechtigungen korrigieren, Abhängigkeiten überprüfen oder die Backup-Strategie verbessern. Lege Folgetermine fest und wiederhole den betroffenen Teil, um zu prüfen, ob die Korrektur das Problem behoben hat.
Die Häufigkeit hängt vom Risiko, Änderungen an der Architektur und den betrieblichen Möglichkeiten ab. Eine häufige teilweise Wiederherstellung – zum Beispiel einer Datenbank oder von Dateien – kann mit vollständigen Wiederherstellungsübungen und unterschiedlichen Szenarien kombiniert werden. Es empfiehlt sich außerdem, den Test nach wesentlichen Änderungen am Backup-System, an der Infrastruktur oder an den Abhängigkeiten zu wiederholen. Ein erfolgreicher Test liefert Erkenntnisse zu einem konkreten Szenario unter bestimmten Bedingungen; er garantiert nicht das Ergebnis aller künftigen Vorfälle.
