Backup und PITR mit pgBackRest

Vollständige, differenzielle und inkrementelle Backups mit pgBackRest, kontinuierliche WAL-Archivierung und Point-in-Time-Recovery (PITR). Für einen Einzelserver, Streaming Replication (Primary + Standbys) oder einen Patroni-Cluster; das Repository kann auf demselben Server, auf einem separaten Backup-Server (SSH) oder in S3-kompatiblem Object Storage liegen. Verschlüsselung, Komprimierung, Aufbewahrungsrichtlinie, Zeitplanung per cron/systemd und ein Test-Restore in ein separates Verzeichnis sind enthalten; derselbe Guide erzeugt auch das Runbook für den In-Place-Restore im Katastrophenfall (einschließlich Neuaufbau eines Patroni-Clusters aus dem Backup). Abgrenzung: Dies ist das für die Produktion empfohlene physische Backup-Werkzeug; für physische Backups und PITR ohne zusätzliches Werkzeug dient der Guide pg_basebackup + WAL-Archivierung, für logische Backups (Dumps von Tabellen/Datenbanken, Migration zwischen Hauptversionen) der Guide pg_dump / pg_restore.

Topologie: 1 Server, Primary + Standbys oder ein Patroni-Cluster; optional ein Backup-Server

Szenarien

• pgBackRest-Installation + erstes Backup + Test-Restore — pgBackRest ist noch nicht eingerichtet: Software, Repository, WAL-Archivierung, erstes Backup, Zeitplanung und ein Test-Restore.
• Katastrophenfall: In-Place-Restore (auf den letzten Stand oder einen Zeitpunkt) — Setze die Datenbank an Ort und Stelle auf einen Zeitpunkt zurück, den Backup und Archiv abdecken: den letzten Stand, eine Uhrzeit, eine xid, eine LSN oder einen Restore Point. Der Cluster wird gestoppt; Änderungen nach dem Ziel gehen verloren.
• Beschädigte oder gelöschte Dateien im Datenverzeichnis (mit Delta-Restore reparieren) — Der Server ist intakt, aber einige Datendateien sind nicht lesbar oder wurden gelöscht: --delta schreibt nur die abweichenden Dateien aus dem Backup zurück und spielt bis zum Ende des Archivs ein. Der Cluster wird gestoppt.
• Nur eine einzelne Datenbank wiederherstellen (--db-include) — Der Cluster bleibt in Betrieb: Die einzelne Datenbank wird in eine temporäre Instanz (separates Verzeichnis und Port) wiederhergestellt, mit pg_dump exportiert und unter neuem Namen in den Live-Server geladen. Auch für eine einzelne gelöschte Tabelle gilt diese Karte (dort mit pg_dump -t).
• Backup auf einem anderen Server wiederherstellen (Klon / Test / Reporting) — Der Live-Server wird nicht angefasst. Das Backup wird auf einem neuen Server geöffnet; die WAL-Archivierung wird abgeschaltet, damit der Klon nicht in das Live-Repository schreibt. Bei einem verschlüsselten Repository wird der Schlüssel benötigt.
• Server komplett verloren: Backup auf einem neuen Server öffnen und ihn ersetzen — Platten- oder Serververlust: Der neue Server wird aus dem Backup geöffnet und wird neuer Primary; WAL-Archivierung und Backups laufen in derselben Stanza weiter. Der alte Server muss unbedingt ausgeschaltet bleiben.
• Neuen Standby aus dem Backup aufbauen (--type=standby) — Neuer Standby ohne Kopierlast auf dem Primary: Die Dateien kommen aus dem Backup, fehlendes WAL wird aus dem Archiv und per Streaming ergänzt. Der Primary bleibt in Betrieb.
• Sind die Backups wirklich intakt? (info / check / verify und Restore-Übung) — Rein lesende Prüfungen und eine Restore-Übung in ein separates Verzeichnis, die den Live-Server nicht berührt. Zusätzlich wird ein monatlicher Prüfjob (cron) eingerichtet.
• Aufbewahrungsdauer ändern und alte Backups bereinigen (expire) — Ändert die Einstellungen repo1-retention-full/diff, zeigt zuerst mit --dry-run, was gelöscht würde, und führt dann expire aus. Ein gelöschtes Backup lässt sich nicht zurückholen.

Vor dem Start

• PostgreSQL … ist installiert und läuft (Guide pg-install)…; dieser Server ist der Primary…. Datenverzeichnis ….
• Der Patroni-Cluster … läuft (Patroni-Installation): ein Leader, die übrigen sind Streaming-Replicas. Auf allen Nodes ist das Datenverzeichnis …, die Patroni-Konfiguration …, das REST-API-Passwort steht in /etc/patroni/patroni.env.
• Kein anderes Archivierungs-/Backup-Werkzeug (Barman, WAL-G, ein selbst geschriebenes archive_command) ist konfiguriert; falls doch, entferne es zuerst. Verschieben zwei Werkzeuge dasselbe WAL an verschiedene Orte, sind am Ende beide unvollständig.… Bei Patroni steht der aktuelle Wert in der Ausgabe von patronictl show-config.…
• Die Datenbankgröße ist bekannt. Das Repository braucht grob (Anzahl Fulls + 1) × komprimierte Größe + WAL-Archiv (mit zst schrumpfen die meisten Datenbanken auf 1/3–1/5).
• Das Repository-Verzeichnis … liegt auf einer von der Datenbank getrennten Platte/NFS-Freigabe und ist dauerhaft eingehängt (fstab).
• Auf dem Backup-Server ist eine separate Platte mit genügend Platz für … eingehängt. Der Backup-Server gehört zur selben Betriebssystemfamilie wie die Datenbank.
• Die Server lösen die Namen der jeweils anderen auf (…, …), und zwischen ihnen ist 22/tcp (SSH) offen.
• Die Standbys (………, ……) sind Streaming-Standbys, die WAL vom Primary empfangen, und nutzen denselben PGDATA-Pfad wie der Primary (…).
• Der Bucket … ist angelegt; ein Zugriffsschlüssel (Access Key + Secret Key) mit Lese-/Schreib-/Löschrechten nur auf diesen Bucket liegt bereit. Im Bucket gibt es keine Lifecycle-Regel, die Objekte löscht (die Aufbewahrung verwaltet pgBackRest). Der Server erreicht den Endpoint.
• Die Uhrzeit ist synchronisiert (NTP). Der PITR-Zielzeitpunkt und die S3-Signaturen hängen von der korrekten Uhrzeit ab.
• Die Server erreichen die PGDG- und EPEL-Repositorys (oder einen internen Mirror); die pgBackRest-Abhängigkeit libssh2 kommt aus EPEL.
• Ein Ort zur Aufbewahrung des Verschlüsselungsschlüssels (Passwort-Tresor / Vault) steht bereit. Wird der Schlüssel nicht außerhalb des Servers aufbewahrt, lassen sich die Backups nach einem Serververlust nicht öffnen.

Phasen der Anleitung

• pgBackRest-Software installieren — PGDG-Repository hinzufügen (Backup-Server) · PGDG-Repository hinzufügen (Backup-Server) · EPEL-Repository aktivieren · pgBackRest installieren · Benutzer pgbackrest anlegen · Alte Konfigurationsdatei entfernen
• Repository vorbereiten — Repository-Verzeichnis anlegen · Repository-Verzeichnis anlegen · SSH-Schlüssel erzeugen (Backup-Server) · SSH-Schlüssel erzeugen (Datenbankserver) · Schlüssel des Backup-Servers autorisieren · Schlüssel der Datenbankserver autorisieren …
• pgBackRest-Konfiguration — Konfigurationsdatei schreiben · Konfigurationsdatei schreiben (Backup-Server) · Konfigurationsdatei schreiben (Datenbankserver) · S3-Zugriffsschlüssel eingeben · Verschlüsselungsschlüssel erzeugen · Verschlüsselungsschlüssel auf Server … schreiben …
• Stanza und erstes Backup — Stanza anlegen · Stanza anlegen · Konfiguration prüfen (check) · Erstes Full-Backup erstellen · Erstes Full-Backup erstellen · Repository-Status anzeigen (info) …
• Backup-Zeitplanung — Pfad des Befehls pgbackrest prüfen · Backup-Skript schreiben · Eigentümer und Berechtigungen des Skripts setzen · systemd-Service und -Timer anlegen · Zeitplanung testen (manuell auslösen) · cron-Dienst vorbereiten …
• Prüfung und Recovery-Test — Prüfen, ob die WAL-Archivierung funktioniert · Testdaten schreiben und Zielzeitpunkt festhalten · Verzeichnis für den Test-Restore vorbereiten · In ein separates Verzeichnis bis zum Zielzeitpunkt wiederherstellen · Test-Cluster auf separatem Port starten · Wiederhergestellte Daten prüfen …
• Monitoring und Wartung — Integrität des Repositorys prüfen (verify) · Integrität des Repositorys prüfen (verify) · Alter des letzten Backups überwachen · Alter des letzten Backups überwachen · Zweite Kopie und Aufbewahrung der Schlüssel
• Diagnose: beschädigte oder fehlende Datei? — Fehler und betroffene Datei im Log finden · Beschädigtes Objekt ermitteln · Prüfen, ob ein intaktes Backup und Archiv vorhanden sind
• Prüfungen vor dem Restore — Backups auflisten · Anwendungsverbindungen prüfen · Standbys stoppen · PostgreSQL stoppen · Kopie des aktuellen Datenverzeichnisses erstellen (falls Platz vorhanden)
• In-Place-Restore — Wiederherstellen (--delta) · PostgreSQL starten und auf das Ende der Recovery warten · Daten am Ziel prüfen (pause) · Recovery beenden und promoten
• Prüfung — Restore-Einstellungen bereinigen · Zustand des Clusters prüfen · Anwendungsdaten prüfen · Prüfen, ob die Beschädigung behoben ist (amcheck) · Prüfen, ob die Archivierung weiterläuft · Neues Full-Backup erstellen …
• Vor dem Restore: Patroni-Cluster stoppen — Backups auflisten · Cluster-Zustand und dynamische Konfiguration sichern · Anwendungen stoppen · Patroni auf den Replicas stoppen · Patroni auf dem Leader stoppen · Kopie des aktuellen Datenverzeichnisses erstellen (falls Platz vorhanden)
• Prüfung und Aufräumen (Patroni) — Prüfen, ob die Archivierung weiterläuft · Neues Full-Backup erstellen · Cluster und Anwendungszugriff prüfen · Beiseitegelegte Datenverzeichnisse löschen
• Patroni: beschädigten Node neu aufbauen (reinit) — Ermitteln, auf welchem Node die Beschädigung liegt · Ist der beschädigte Node der Leader, Leader-Rolle abgeben · Beschädigtes Replica neu aufbauen (reinit)
• Backup-Prüfung und Restore-Übung — Zustand der Backups und Alter des letzten Backups (info) · Prüfen, ob die Archivierung gerade funktioniert (check) · Integrität des Repositorys prüfen (verify) · Verzeichnis für die Übung vorbereiten · Letztes Backup in das Übungsverzeichnis wiederherstellen · Übungsinstanz starten und auf die Recovery warten …
• Zeitplanung der monatlichen Prüfung — Skript für die monatliche Prüfung schreiben · Berechtigungen des Skripts setzen und mit cron-Umgebung testen · Monatlichen cron-Job schreiben · Berechtigungen der cron-Datei setzen
• Aufbewahrungsrichtlinie ändern — Aktuelle Aufbewahrungseinstellung und Backups · Aufbewahrungseinstellung ändern · Anzeigen, was gelöscht würde (dry-run) · Alte Backups löschen (expire) · Belegung des Repositorys und Zeitplanung prüfen