Ein Datenbankreplikat ersetzt kein Backup. Wie stellen Sie den Zustand vor einer Fehländerung wieder her?

Das Replikat übernimmt auch die unerwünschte Änderung

Ein physischer Standby spielt fortlaufend WAL ein, also die vom Primärserver empfangenen Änderungsaufzeichnungen. Enthalten diese eine bestätigte Löschung, übernimmt das Replikat beim Einspielen der entsprechenden Aufzeichnungen auch deren Ergebnis. Eine geringe Verzögerung beweist deshalb keinen Schutz vor diesem Fehler. Sie bedeutet einen kleinen Abstand zu einem Zustand, der bereits unerwünscht sein kann.

Klären Sie bei einem Vorfall zuerst, ob ein Rechner ausgefallen ist oder die Daten falsch sind. Hat das Replikat die Änderung bereits übernommen, bringt das bloße Umschalten der Clients keine alten Datensätze zurück. Sichern Sie Zeitleiste, Identifikation des Vorgangs und verfügbare Belege. Entscheiden Sie über weitere Schreibvorgänge nach den Auswirkungen auf den Dienst; ein automatischer Serverwechsel ersetzt diese Bewertung nicht.

Die Rückkehr in die Vergangenheit braucht vorbereitete Historie

Point-in-Time Recovery, kurz PITR, benötigt eine geeignete physische Basissicherung und eine lückenlose WAL-Folge von deren Beginn bis zum Ziel. Die Sicherung muss am gewählten Zeitpunkt bereits abgeschlossen sein. pg_basebackup kann eine Basissicherung eines laufenden Clusters erstellen. Unterscheiden Sie sie von pg_dump, einem logischen Datenbankschnappschuss. Prüfen Sie Sicherungsformat und Wiederherstellungsverfahren im Voraus.

Beobachten Sie in pg_stat_archiver failed_count und last_archived_time. Die letzte erfolgreiche Archivierung allein bestätigt nicht die Vollständigkeit aller älteren Segmente. Die Archivierung arbeitet mit abgeschlossenen WAL-Segmenten; berücksichtigen Sie daher bei wenigen Schreibvorgängen die Verzögerung bis zur Übertragung. Bewerten Sie die Aufbewahrung von Sicherungen und WAL gemeinsam. Prüfen Sie, ob benötigte Dateien und Zugänge während des gesamten vereinbarten Wiederherstellungszeitraums verfügbar bleiben.

Prüfen Sie das Wiederherstellungsziel zuerst außerhalb der Produktion

Wählen Sie einen Punkt vor der unerwünschten bestätigten Transaktion. Geben Sie für recovery_target_time eine eindeutige Zeitzone an, etwa einen numerischen UTC-Versatz. recovery_target_inclusive bestimmt auch, ob Transaktionen mit exakt der Ziel-Commitzeit einbezogen werden. Übernehmen Sie deshalb die angezeigte letzte Änderungszeit der Anwendung nicht automatisch als verifiziertes Ziel. Bestätigen Sie die Auswahl durch eine Testwiederherstellung und Prüfung der betroffenen Datensätze.

Dieses PITR-Verfahren stellt den gesamten Datenbankcluster wieder her, keine einzelne Tabelle. Starten Sie die wiederhergestellte Kopie in einer getrennten Umgebung mit kontrolliertem Zugriff und deaktivierten ausgehenden Integrationen. Vergleichen Sie den Zustand vor der Fehländerung mit den späteren berechtigten Vorgängen. Ein vollständiger Rücksprung der Produktion würde auch diese späteren Änderungen verwerfen. Der Wiederherstellungsplan muss deren Bedeutung und Beziehungen berücksichtigen.

Messen Sie Erfolg an richtigen Daten und der Dienstfunktion

pg_verifybackup prüft die Integrität einer unterstützten physischen Sicherung anhand von backup_manifest. Die Dokumentation betont, dass dies Testwiederherstellungen und Datenprüfungen nicht ersetzt. Erfassen Sie die verwendete Sicherung, den erreichten Punkt und das Prüfergebnis. Ein erfolgreicher Datenbankstart oder ein gesunder Replikationsstatus allein bestätigt nicht, dass Sie die benötigte Version der Datensätze wiederhergestellt haben.

Bereiten Sie in einer sicheren Übung einen bekannten Zustand vor, führen Sie eine kontrollierte Teständerung durch und stellen Sie eine Kopie vor dieser Änderung wieder her. Prüfen Sie konkrete Datensätze, Beziehungen und die betreffende Anwendungsfunktion. Messen Sie das gesamte Verfahren einschließlich der Beschaffung von Dateien und Zugängen. Wiederholen Sie die Übung nach Änderungen an Sicherungswerkzeugen oder Aufbewahrung. Replikat und Sicherung haben dann überprüfte Rollen für zwei unterschiedliche Szenarien.

• Unterscheiden Sie Serverausfall und unerwünschte Datenänderung.
• Prüfen Sie eine geeignete Basissicherung und lückenlose WAL-Historie.
• Bestätigen Sie Wiederherstellungspunkt und Inhalt in einer getrennten Kopie.
• Planen Sie die Datenrückführung unter Erhalt berechtigter späterer Änderungen.