Akzeptablen Verlust und Ausfall definieren
Notieren Sie den spätesten akzeptablen Wiederherstellungspunkt und die Zielzeit für die Wiederherstellung eines nützlichen Dienstes. Dies sind Anwendungsziele, kein PrivacyNodes-SLA. Wenn der Verlust einer Stunde an Daten inakzeptabel ist, kann eine tägliche Kopie allein dieses Ziel nicht erfüllen. Wählen Sie eine Datenbank-Backup-Methode, die zu Ihrer Workload und Version passt.
Beschaffen Sie ein wegwerfbares Ziel, das Anwendungsartefakt und autorisierte Wiederherstellungs-Anmeldedaten über geschützten Speicher. Bestätigen Sie, wer die Wiederherstellung von Kundendaten genehmigt und wie die Testumgebung externen Verkehr verhindert. Stellen Sie nicht über die laufende Produktionsdatenbank oder ein vorhandenes Verzeichnis wieder her.
Den vollständigen Anwendungszustand erfassen
Listen Sie für die Reporting-API PostgreSQL, Uploads, Exporte, die nicht reproduziert werden können, Konfiguration, Verschlüsselungsschlüssel-Referenzen, DNS und externe Abhängigkeiten auf. Unterscheiden Sie einen wegwerfbaren Cache von einer Queue mit Kundenarbeit, die abgeglichen werden muss. Ein Container-Image beschreibt Software, nicht den gesamten persistenten Zustand.
| Eintrag | Ihr Wert |
|---|---|
| Artefakt- und Konfigurationsversion | Genaue Bezeichner |
| Datenbank-Backup und Wiederherstellungspunkt | Gewähltes Archiv und Zeitstempel |
| Upload-Snapshot und Konsistenzgrenze | Snapshot, Pfad und Abgleichsplan |
| Wegwerfbares Ziel | Verifizierte Umgebung und leeres Ziel |
| Anmeldedaten und Genehmiger | Nur geschützte Referenzen |
| Start, Abschluss, fehlende Schritte | Beobachtete Ergebnisse, keine Schätzungen |
Verstehen, was das Backup enthält
PostgreSQL dokumentiert logische Dumps, Dateisystem-Backups und kontinuierliche Archivierung als unterschiedliche Strategien. Ein pg_dump Archiv deckt eine Datenbank ab; clusterweite Rollen und Tablespaces erfordern eine separate Betrachtung. Sein Client kann keinen neueren Major-Version-Server dumpen. Bringen Sie Werkzeugversionen und Strategie mit dem Ziel in Einklang; das Kopieren eines Live-Datenverzeichnisses ist nicht automatisch konsistent.
Prüfen Sie ein Archiv vor der Wiederherstellung. Die Auswahl einer Tabelle mit pg_restore schließt nicht automatisch alle ihre Abhängigkeiten ein. Seine --clean Option löscht vorhandene Objekte; eine Wiederherstellung in einer einzigen Transaktion lässt sich nicht mit parallelen Jobs kombinieren. Prüfen Sie die Optionen für die speziell identifizierte leere Testdatenbank.
Technische Referenz: PostgreSQL-Backup und -Wiederherstellung · PostgreSQL pg_dump · PostgreSQL pg_restore.
Integrität prüfen und unabhängig wiederherstellen
Repository-Prüfungen und funktionale Wiederherstellungen beantworten unterschiedliche Fragen. Restics gewöhnliches check liest nicht jedes gespeicherte Datenpaket; check --read-data fügt diese Lesevorgänge hinzu und kann erhebliche Bandbreite verbrauchen. Keines von beiden beweist, dass der Snapshot alles enthält, was die API benötigt.
Wählen Sie einen bestimmten Snapshot und ein neues Zielverzeichnis. Ein unqualifiziertes latest in einem gemeinsam genutzten Repository kann eine andere Workload auswählen. Eine Wiederherstellung kann Dateien überschreiben und eine Unterbrechung kann Teilergebnisse hinterlassen. Überprüfen Sie zuerst das Ziel und lassen Sie Produktionsdateien und das ursprüngliche Repository unberührt.
Technische Referenz: restic-Repository-Prüfungen · restic-Wiederherstellungsziele.
Das wiederhergestellte Verhalten in Abhängigkeitsreihenfolge testen
Erstellen Sie die Umgebung neu, stellen Sie die Datenbank und passende Uploads wieder her und starten Sie dann die API mit Staging-Anmeldedaten. Halten Sie Worker pausiert, bis ihr Rückstand und ihre Seiteneffekte verstanden sind. Deaktivieren Sie Produktions-E-Mail, Zahlungsaufrufe und Webhooks; verwenden Sie ein Test-Exportziel und konsumieren Sie niemals die Produktions-Queue.
Verwenden Sie ein bekanntes Testkonto, um einen Datensatz zu lesen, dessen Upload zu öffnen, Zugriffsbeschränkungen zu prüfen und einen kleinen neuen Export auszuführen. Verifizieren Sie, dass ein anderes Testkonto seine Daten nicht lesen kann. Vergleichen Sie den gewählten Wiederherstellungspunkt mit dem spätesten erwarteten Datensatz. Zeichnen Sie die tatsächliche Wiederherstellungszeit nach der Übung auf; schreiben Sie nicht im Voraus ein erfundenes Erfolgsergebnis.
Schreibverantwortung vor einem echten Cutover klären
Entscheiden Sie während eines Vorfalls, welches System Schreibvorgänge annehmen darf und wie spätere Änderungen abgeglichen werden. Zwei beschreibbare Kopien können divergieren. Eine Übung dokumentiert diese Entscheidung, ohne echten Verkehr umzuschalten. Entfernen Sie wegwerfbare Daten gemäß Ihren Aufbewahrungsregeln, wenn die Übung endet.
Korrigieren Sie fehlende Anmeldedaten, Abhängigkeiten und Validierungsschritte nach jeder Übung. Bewahren Sie das Runbook außerhalb des ursprünglichen Hosts auf und stellen Sie sicher, dass ein anderer autorisierter Maintainer es finden kann. Die auswählbare Backup-Option ist von diesem Anwendungsprozess getrennt; bestätigen Sie Umfang und Wiederherstellungsverfahren in Service-Fakten. Verwenden Sie die Release-Eintrag für das folgende Deployment.
Offizielle Referenzen
Die Dokumentation wurde für diesen Artikel überprüft. Beispiele sind Planungsübungen, keine auf einem PrivacyNodes-Server getesteten Befehle. Prüfen Sie die Dokumentation für Ihre installierte Version.