So überprüfen Sie Backups in PHP-Anwendungen

Ein Backup bietet nur dann Schutz, wenn es die Wiederherstellung eines Dienstes in einem bekannten Zustand, innerhalb einer akzeptablen Zeit und ohne Einführung neuer Fehler ermöglicht. Eine Sicherungsdatei, die vorhanden ist, ohne Warnungen erstellt wurde oder in einen anderen Speicher übertragen wurde, beweist weder, dass sie wiederhergestellt werden kann, noch, dass sie alle erforderlichen Komponenten enthält oder dass die PHP-Anwendung mit diesen Daten funktioniert.

Die Frage wie man Backups in PHP-Anwendungen überprüft muss mit wiederholbaren Wiederherstellungstests beantwortet werden. Das Ziel besteht nicht nur darin, eine Datenbank wiederherzustellen: Es geht darum, einen konsistenten Dienst wiederherzustellen, seine Geschäftsregeln zu überprüfen und Nachweise aufzubewahren, die es ermöglichen, das Verfahren vor einem tatsächlichen Vorfall zu korrigieren.

Ein vorhandenes Backup garantiert keine mögliche Wiederherstellung

Wiederherstellungsfehler treten häufig aufgrund ausgelassener Abhängigkeiten auf. Eine Datenbank kann korrekt wiederhergestellt werden, nur um später festzustellen, dass von Benutzern hochgeladene Dateien, Schlüssel zum Entschlüsseln von Informationen, Umgebungsvariablen oder Konfigurationen externer Dienste fehlen. Es kann auch vorkommen, dass das Backup beschädigt ist, das technische Konto keine Berechtigungen zur Wiederherstellung besitzt oder sein Format nicht mit der Zielinfrastruktur kompatibel ist.

Es empfiehlt sich, zwei operative Ziele zu unterscheiden:

• Recovery Point Objective (RPO): maximal akzeptierte Datenmenge, die verloren gehen darf, gemessen ab dem letzten wiederherstellbaren Zustand.
• Recovery Time Objective (RTO): maximal akzeptierte Zeit, um den Dienst wieder in einen betriebsfähigen Zustand zu versetzen.

Beide Ziele bestimmen die Häufigkeit der Backups, die Aufbewahrung, die Nutzung von Transaktionsprotokollen und die Gestaltung der Tests. Ein nächtliches Backup kann für einen sich kaum ändernden Katalog ausreichen, nicht jedoch für Transaktionen, die auf einen Zeitpunkt nahe dem Vorfall zurückgeführt werden müssen. Im letzteren Fall muss der Plan eine Point-in-Time-Wiederherstellung vorsehen, sofern die Datentechnologie und ihre Konfiguration dies zulassen.

Erstellen Sie ein wiederherstellbares Inventar, nicht nur einen Daten-Dump

Das Inventar muss beschreiben, welche Elemente den Mindestzustand der Anwendung bilden und wo sie gesichert werden. In einer PHP-Anwendung ist die Datenbank in der Regel zentral, aber nur selten die einzige persistente Komponente.

• Transaktionsdaten: relationale Datenbanken, Dokumente, relevante Migrationsdateien und, sofern zutreffend, für die Point-in-Time-Wiederherstellung erforderliche Protokolle.
• Persistente Dateien: Anhänge, Bilder, Exporte, generierte Dokumente und alle außerhalb der Datenbank gespeicherten Inhalte.
• Konfiguration: Laufzeitparameter, Domains, Speicherpfade, E-Mail-Konfiguration, Zahlungsdienste und API-Verbindungen. Versionierter Code hilft, ersetzt jedoch nicht die Betriebskonfiguration.
• Geheimnisse: Verschlüsselungsschlüssel, Anmeldedaten, Zertifikate, Tokens und Session-Secrets. Sie müssen über einen kontrollierten Mechanismus wiederhergestellt werden, nicht in Berichte oder Repositories kopiert werden.
• Asynchrone Verarbeitung: Queues, geplante Jobs, Consumer und Wiederholungsrichtlinien. Es muss entschieden werden, ob ausstehende Nachrichten wiederhergestellt, verworfen oder sicher neu erstellt werden.
• Abgeleitete Daten: Caches, Suchindizes, materialisierte Views, Vorschaubilder oder Aggregate. Sie sind normalerweise nicht die Quelle der Wahrheit, aber ihre Neuerstellung kann vor dem Betrieb erforderlich sein.

Dokumentieren Sie für jedes Element Eigentümer, Speicherort, Wiederherstellungsmethode, Abhängigkeiten und Sensitivität. Wenn ein Secret nicht kontrolliert wiederhergestellt oder rotiert werden kann, ist das Verfahren nicht vollständig.

Definieren Sie Szenarien und wählen Sie den Wiederherstellungspunkt

Nicht alle Vorfälle erfordern dieselbe Reaktion. Ein versehentlich gelöschter Datensatz, eine massive Beschädigung, eine Schwachstelle, die Daten verändert hat, und ein vollständiger Ausfall der Umgebung erfordern unterschiedliche Verfahren. Das Definieren von Szenarien verhindert, dass eine vollständige Wiederherstellung angewendet wird, obwohl eine begrenzte Korrektur ausreichen würde, oder dass kontaminierte Daten wiederhergestellt werden, weil ein Zeitpunkt nach dem Problem gewählt wurde.

Zu testende Szenarien

• Wiederherstellung eines Datensatzes oder einer begrenzten Datenmenge durch Export, Audit oder Wiederherstellung in einer temporären Instanz.
• Wiederherstellung einer vollständigen Datenbank aus einem konsistenten Backup.
• Wiederherstellung zu einem Zeitpunkt vor dem Vorfall mithilfe von Transaktionsprotokollen, wenn diese Fähigkeit vorhanden ist.
• Wiederherstellung eines vollständigen Dienstes: Daten, Dateien, Konfiguration, Secrets, Anwendung und Hilfsprozesse.
• Neuerstellung von Indizes, Caches und anderen abgeleiteten Daten, ohne die Quelle der Wahrheit zu verändern.

Legen Sie vor der Wiederherstellung den Zielzeitpunkt fest und dokumentieren Sie den in Kauf genommenen Datenverlust. Wenn beispielsweise ein Backup von 02:00 Uhr wiederhergestellt wird, kann jede spätere Operation einen Abgleich mit anderen legitimen Quellen erfordern, etwa Zahlungsprotokollen oder Drittsystemen. Dieser Zustand darf nicht so dargestellt werden, als enthielte er Transaktionen, die er nicht enthält.

Beachten Sie eine Wiederherstellungsreihenfolge, die Nebeneffekte begrenzt

Eine kontrollierte Wiederherstellung benötigt Isolierung und eine klare Abfolge. Die Testumgebung darf keine echten E-Mails versenden, keine Zahlungen ausführen, keine Produktionsintegrationen aufrufen und keine Queues mit dem aktiven Dienst teilen. Verwenden Sie für diesen Test sichere Anmeldedaten und Ziele.

1. Bereiten Sie die Zielinfrastruktur vor: Netzwerk, Speicher, Version der Datenbank-Engine, Berechtigungen und ausreichende Kapazität.
2. Stellen Sie Konfiguration und Secrets über den autorisierten Kanal wieder her oder bereit. Überprüfen Sie, dass die erforderlichen Verschlüsselungsschlüssel dem Zustand der wiederhergestellten Daten entsprechen.
3. Stellen Sie die Datenbank und die persistenten Dateien wieder her. Notieren Sie Zeitstempel, Backup-Identifikatoren sowie verwendete Befehle oder Aufgaben.
4. Stellen Sie die kompatible Anwendungsversion bereit. Das Deployment installiert das Softwareartefakt; es bedeutet nicht automatisch, dass es für Benutzer verfügbar gemacht wird.
5. Führen Sie Migrationen nur aus, wenn sie durch das Szenario gerechtfertigt sind. Eine irreversible Migration kann den Vergleich mit dem ursprünglichen Zustand erschweren oder die wiederhergestellten Daten unangemessen verändern.
6. Lassen Sie Consumer, geplante Aufgaben und Integrationen mit externen Auswirkungen deaktiviert, bis die Validierungen abgeschlossen sind.
7. Erstellen Sie abgeleitete Daten neu und aktivieren Sie Prozesse schrittweise, wobei Duplikate, Fehler und Wiederholungen überwacht werden.

Queues erfordern besondere Aufmerksamkeit. Die Reaktivierung eines Consumers vor der Validierung des Zustands kann doppelte Benachrichtigungen versenden, Vorgänge wiederholen oder Nachrichten verarbeiten, die nicht mehr zu den wiederhergestellten Daten passen. Die Richtlinie muss festlegen, welche Nachrichten aufbewahrt, welche verworfen und wie doppelte Ausführung verhindert wird.

Validieren Sie die technische und geschäftliche Konsistenz

Dass eine Anwendung mit HTTP 200 antwortet, beweist nicht, dass sie wiederherstellbar ist. Die Prüfungen müssen technische Integrität, funktionales Verhalten und Einschränkungen der Domäne kombinieren. Automatisieren Sie stabile Validierungen, damit sie nach jedem Test wiederholt werden können.

• Vergleichen Sie die Anzahl relevanter Entitäten mit den für den Wiederherstellungspunkt erwarteten Werten: Benutzer, Bestellungen, Rechnungen, Dateien oder Ereignisse.
• Suchen Sie nach fehlerhaften Referenzen zwischen Datenbank und Objektspeicher: Datensätze, die auf fehlende Dateien verweisen, oder Dateien ohne bekannten Eigentümer.
• Überprüfen Sie Einschränkungen, Beziehungen, Kodierung, Zeitzonen und ID-Sequenzen, wenn sie neue Schreibvorgänge beeinflussen.
• Führen Sie funktionale Abläufe mit einem Testkonto aus: Authentifizierung, Lesen von Daten, kontrollierte Erstellung eines Datensatzes und Zugriff auf eine geschützte Datei.
• Überprüfen Sie Rollen und Berechtigungen. Ein falsch wiederhergestelltes Secret kann Zugriffe verhindern oder, schlimmer noch, Privilegien erweitern.
• Überprüfen Sie ausstehende, fehlgeschlagene oder blockierte Jobs und stellen Sie sicher, dass ihre Wiederaufnahme keine unzulässigen externen Aktionen erzeugt.

Anwendungstests müssen angemessen geschützte Daten verwenden. Wenn personenbezogene Daten in eine isolierte Umgebung kopiert werden, wenden Sie die entsprechenden Kontrollen für Zugriff, Aufbewahrung und Datenminimierung an. Verwenden Sie nach Möglichkeit maskierte Daten für Validierungen, die keine identifizierbaren Informationen erfordern.

Behandeln Sie Caches, Indizes und abgeleitete Daten als rekonstruierbare Komponenten

Ein Cache sollte nicht der einzige Speicherort für Informationen sein, die zur Wiederherstellung des Dienstes erforderlich sind. Invalidieren Sie nach der Wiederherstellung der Quelle der Wahrheit Caches, die Werte vor dem wiederhergestellten Zeitpunkt enthalten könnten. Ermöglichen Sie anschließend ihr kontrolliertes Aufwärmen oder führen Sie eine explizite Generierung aus, falls diese vorhanden ist.

Suchindizes und andere abgeleitete Speicher müssen als solche identifiziert werden, bevor sie gelöscht oder neu generiert werden. Die Neuerstellung muss von den wiederhergestellten Daten ausgehen und überprüfbare Metriken liefern: Anzahl indexierter Dokumente, Fehler, ausstehende Elemente und Testabfragen. Wenn ein Index sensible Felder speichert, sind auch seine Berechtigungen und seine Aufbewahrungsrichtlinie Teil der Validierung.

Machen Sie jeden Test zu einem operativen Nachweis

Das Testen einer Wiederherstellung in einer isolierten Umgebung muss eine geplante Aktivität sein, keine Improvisation während einer Krise. Weisen Sie Verantwortliche zu, die das Verfahren ausführen, beobachten, fachlich validieren und Änderungen am Verfahren genehmigen. Messen Sie tatsächliche Zeiten je Phase statt Schätzungen.

Bewahren Sie nach jeder Übung einen kurzen und nützlichen Nachweis auf:

• getestetes Szenario, Datum, Verantwortlicher und gewählter Wiederherstellungspunkt;
• Identifikator und Alter jedes verwendeten Backups;
• Versionen und relevante Konfiguration des Ziels, ohne Secrets offenzulegen;
• beobachtete Zeit für Wiederherstellung, Validierung und Neuerstellung abgeleiteter Daten;
• Ergebnis der Konsistenzkontrollen und funktionalen Tests;
• Vorfälle, getroffene Entscheidungen, in Kauf genommener Datenverlust und Korrekturmaßnahmen.

Überprüfen Sie das Verfahren, wenn sich das Datenschema, der Dateispeicher, die Secrets, die Integrationen, die Queue-Architektur oder der Deployment-Prozess ändern. Historische Nachweise ermöglichen es, festzustellen, dass das RTO nicht mehr eingehalten wird, ein Backup keine Komponente mehr enthält oder eine Abhängigkeit manuell geworden ist.

Fehler, die eine Backup-Strategie ungültig machen

Nur die Datenbank wiederherzustellen ist der sichtbarste Fehler, aber nicht der einzige. Häufige Risiken sind auch, nicht zu überprüfen, ob das Backup korrekt abgeschlossen wird, von nur einem Speicherort abhängig zu sein, die Point-in-Time-Wiederherstellung nicht zu prüfen, Umgebungen zu vermischen, Berechtigungen des wiederherstellenden Kontos auszulassen und das Verfahren nur im Wissen einer Person zu belassen.

Die Korrektur besteht nicht darin, wahllos mehr Backups anzuhäufen. Sie besteht darin, wiederherstellbare Zustände zu definieren, eine Wiederherstellung zu isolieren, Daten und Prozesse zu validieren, das Ergebnis zu messen und den Plan zu aktualisieren. So sind Backups nicht länger ein operatives Versprechen, sondern eine nachweisbare Fähigkeit zur Wiederherstellung des Dienstes.