PostgreSQL-Backups, die man auch wirklich wiederherstellen kann: pgBackRest einrichten

Die meisten kleinen Postgres-Setups, die ich von Kunden übernehme, teilen exakt dieselbe Version einer Backup-Strategie. Meistens ist es ein Cron-Job, der jede Nacht pg_dump ausführt, den Output durch gzip jagt, die Datei in irgendeinen Ordner wirft und sie vielleicht noch mit rclone Off-Site synchronisiert.

Das sieht von außen exakt wie ein echtes Backup aus. Es läuft jede Nacht brav durch, ohne Fehler zu werfen. Das einzige Problem dabei ist: Niemand hat seit einer halben Ewigkeit mehr versucht, daraus auch nur irgendetwas wiederherzustellen.

Als absolutes Minimum ist pg_dump völlig in Ordnung. Aber in der Sekunde, in der eine Datenbank größer als ein paar Gigabyte wird, stößt es an sehr harte Grenzen. Der Dump dauert jeden Monat länger und länger. Er belastet den Server für die gesamte Dauer des Durchlaufs. Und was noch viel wichtiger ist: Eine einzelne Dump-Datei gibt einem exakt einen einzigen Recovery-Punkt pro Tag. Wenn nachmittags um 15:00 Uhr etwas katastrophal schiefgeht, rollt man auf den Stand von letzter Nacht zurück und verliert unwiderruflich alles, was dazwischen passiert ist. Es gibt keine Point-in-Time-Recovery, und Dump-basierte Backups skalieren schlichtweg nicht vernünftig, sobald man mit zig Gigabyte hantiert.

Der Wechsel zu pgBackRest

pgBackRest löst fast all diese Probleme, ohne viel zusätzliche Infrastruktur zu erfordern. Es bewältigt mühelos volle, differenzielle und inkrementelle Backups. Es archiviert WAL (Write-Ahead Logs) kontinuierlich, sodass man echte Point-in-Time-Recovery bekommt. Es unterstützt parallele Verarbeitung für dramatisch schnellere Backups auf Multi-Core-Maschinen, und es kann Archive direkt auf eine lokale Festplatte, in S3-kompatiblen Speicher oder auch gleichzeitig in beides pushen.

Für einen einzelnen, kleineren Server sieht mein Standard-Setup in etwa so aus:

# /etc/pgbackrest/pgbackrest.conf
[global]
repo1-path=/var/lib/pgbackrest
repo1-retention-full=2
repo1-retention-diff=4

[main]
pg1-path=/var/lib/postgresql/16/main
pg1-port=5432

Anschließend aktiviert man die WAL-Archivierung in der postgresql.conf:

archive_mode = on
archive_command = 'pgbackrest --stanza=main archive-push %p'

Erstellen Sie die Stanza und triggern Sie das allererste Full-Backup manuell:

sudo -u postgres pgbackrest --stanza=main stanza-create
sudo -u postgres pgbackrest --stanza=main --type=full backup

Nach diesem initialen Setup hält ein Zeitplan von einem Full-Backup pro Woche und Inkrementellen an den restlichen Tagen die Größe des Repositories extrem handlich. Er liefert dennoch einen soliden Wiederherstellungspunkt für jeden einzelnen Tag, plus die kontinuierliche WAL-Archivierung für alles, was feingranularer wiederhergestellt werden muss.

# Sonntag: Full-Backup
0 2 * * 0 postgres pgbackrest --stanza=main --type=full backup
# Mo-Sa: Inkrementell
0 2 * * 1-6 postgres pgbackrest --stanza=main --type=incr backup

Der Teil, den fast jeder überspringt

Die gesamte Konfiguration von oben ist völlig wertlos, wenn man nie daraus wiederhergestellt hat.

Ich halte speziell für diese eine Aufgabe einen kleinen sekundären VPS bereit. Einmal im Monat zieht er das allerneueste Backup, führt pgbackrest --stanza=main --delta restore aus und startet Postgres. Danach werfe ich ein paar einfache Sanity-Queries dagegen: Ich checke die Row-Counts der größten Tabellen und prüfe einen aktuellen updated_at-Timestamp. Das Ganze dauert von Anfang bis Ende vielleicht zwanzig Minuten, und ich notiere mir jedes Mal explizit, wie lange der eigentliche Restore-Prozess gedauert hat.

Diese eine spezifische Zahl – die echte Restore-Zeit unter realen Bedingungen – ist Ihre wahre Recovery Time Objective (RTO). Nicht irgendeine hypothetische Zahl, die in einem Runbook steht. Als ich diesen Drill zum allerersten Mal für einen Kunden durchführte, dauerte der Restore spürbar länger als ich angenommen hatte – einzig und allein wegen der physischen Durchsatzlimits der Festplatte im Ziel-VPS. Es ist unendlich viel besser, diese harte Realität an einem ruhigen Mittwochnachmittag herauszufinden als mitten in einem aktiven Incident.

Was bedeutet das für Off-Site-Kopien?

repo1 kann so konfiguriert werden, dass es direkt auf S3-kompatiblen Object-Storage zeigt. Backblaze B2 und Wasabi funktionieren beide außergewöhnlich gut und sind so günstig, dass Kosten niemals ein valider Grund sind, darauf zu verzichten.

Für jede Datenbank, bei der ich tatsächlich unruhig schlafen würde, konfiguriere ich eine zweite Repo-Definition, die exklusiv auf Off-Site-Speicher zeigt. Auf diese Weise zieht ein kompletter Host-Ausfall – und nicht nur ein verpfuschtes Deployment – nicht direkt die einzige Kopie der Backups mit ins Verderben.

Ein Backup, das man nie wiederhergestellt hat, ist nur eine bloße Hoffnung, kein Backup. pgBackRest bringt einen mit einer simplen Config-Datei und ein paar Cron-Einträgen sehr nah an den Zustand "tatsächlich wiederherstellbar" heran. Der monatliche Restore-Drill ist das, was diese Lücke endgültig schließt.