Sicherung und PITR mit pg_basebackup + WAL-Archiv (ohne pgBackRest)

Physische Sicherung mit den Bordmitteln von PostgreSQL, ohne Zusatzsoftware: kontinuierliche WAL-Archivierung mit archive_command, nächtliches Base Backup mit pg_basebackup, Aufbewahrung mit pg_archivecleanup. Wiederherstellung auf einen Zeitpunkt / eine Transaktion / einen Restore Point (recovery.signal, restore_command, recovery_target_*), Timelines und eine regelmäßige Restore-Übung; am Ende stehen ein archivierter WAL-Strom, eine nächtliche Sicherung und ein erprobter Weg zurück. Alternativen: Brauchst du inkrementelle/parallele/verschlüsselte Sicherungen, S3 und eine fertige Aufbewahrungsverwaltung, nimm den pgBackRest-Guide; um eine Tabelle/Datenbank umzuziehen oder eine einzelne Tabelle zurückzuholen, eine logische Sicherung (pg_dump, kein PITR).

Topologie: 1 Server; bei Streaming oder Patroni ist das Archivverzeichnis auf allen Nodes gemeinsam (NFS)

Szenarien

• WAL-Archivierung und nächtliches Base Backup einrichten — Ersteinrichtung: kontinuierliche WAL-Archivierung mit archive_command, ein pg_basebackup-Skript, Zeitplanung in /etc/cron.d, Aufbewahrung und WAL-Bereinigung. archive_mode erfordert einmalig einen kurzen Neustart.
• Auf einen bestimmten Punkt zurückgehen (PITR: Zeit, xid, LSN, Restore Point) — Daten wurden versehentlich gelöscht/geändert (DROP, DELETE, TRUNCATE) oder Server/Platte ist verloren: Das Base Backup wird zurückgespielt und das archivierte WAL bis zum Ziel angewendet. Der ganze Cluster wird gestoppt und kehrt zum Ziel zurück; alles nach dem Ziel geht verloren.
• Restore-Übung (in separatem Verzeichnis, ohne die Produktion anzufassen) — Um zu belegen, dass sich die Sicherung tatsächlich zurückspielen lässt (monatlich empfohlen): Das letzte Base Backup wird geprüft (pg_verifybackup), in ein separates Verzeichnis entpackt und mit dem Archiv an einem eigenen Port gestartet; die Dauer (RTO) wird gemessen. Die Produktion bleibt unberührt.
• Alte Base Backups und WAL-Archiv bereinigen — Die Archiv- oder Sicherungsplatte läuft voll, oder die Aufbewahrung hat sich geändert: Alte Base Backups werden gelöscht, pg_archivecleanup entfernt WAL, das älter als die älteste Sicherung ist (zuerst Dry Run). Die Datenbank bleibt geöffnet.

Vor dem Start

• PostgreSQL … ist installiert und läuft (pg-install); Datenverzeichnis ….
• … und … liegen auf einer von der Datenplatte getrennten Platte bzw. NFS-Freigabe, dauerhaft eingehängt (fstab)… und auf allen PostgreSQL-Servern unter demselben Pfad (nach einem Failover muss der neue Primary ins selbe Archiv schreiben)…. Platz: (Anzahl aufbewahrter Sicherungen + 1) × komprimierte Datenmenge + tägliches WAL-Volumen × Aufbewahrungstage.
• Kein anderes Archiv-/Sicherungswerkzeug (pgBackRest, Barman, WAL-G) ist eingerichtet; schicken zwei Werkzeuge dasselbe WAL an verschiedene Orte, bleiben beide unvollständig.
• Die Uhren sind per NTP synchronisiert (die PITR-Zielzeit wird anhand der Serveruhr interpretiert).
• Für die Änderung von archive_mode steht ein kurzes Neustartfenster zur Verfügung.
• Die Anwendungen sind gestoppt; es ist abgestimmt, dass alle Änderungen nach dem Ziel verloren gehen.… Standbys/Replicas werden nach der Wiederherstellung neu aufgebaut.…

Phasen der Anleitung

• Einrichtung von WAL-Archiv und Base Backup — Archiv- und Sicherungsverzeichnisse vorbereiten · WAL-Archivskript schreiben · Skript ausführbar machen und testen · Archiveinstellungen von PostgreSQL schreiben · PostgreSQL neu starten · Archiveinstellungen in Patroni schreiben (edit-config) …
• Restore-Übung — Übungsverzeichnis vorbereiten und letzte Sicherung auswählen · Sicherung entpacken und prüfen (pg_verifybackup) · Übungsinstanz mit dem Archiv starten · Daten prüfen · Übungsinstanz herunterfahren und aufräumen
• Aufbewahrung und WAL-Bereinigung — Sicherungen, Archivgröße und ältestes benötigtes WAL · Base Backups außerhalb der Aufbewahrung löschen · WAL-Bereinigung zuerst als Dry Run anzeigen · WAL-Archiv bereinigen · Prüfen, ob die Archivierung weiterhin funktioniert