PostgreSQL pg_dump und pg_restore: Anleitung für Backup und Migration per Kommandozeile

Mit pg_dump und pg_restore sichern und migrieren Sie PostgreSQL-Datenbanken per Kommandozeile. Die Anleitung zeigt die Unterschiede der Dump-Formate plain, custom, tar und directory, das Wiederherstellen kompletter Datenbanken und einzelner Tabellen, Parallel-Dump und Parallel-Restore sowie die Automatisierung. Sie richtet sich an Admins, Selfhoster und Entwickler, die PostgreSQL-Daten ohne grafische Tools sichern und auf einen anderen Server umziehen wollen.

Was sind pg_dump und pg_restore?

pg_dump exportiert eine einzelne Datenbank in einer Transaktion und damit auch bei laufendem Betrieb konsistent. pg_restore spielt Backups in den Formaten custom, tar und directory zurück; reine SQL-Dumps (plain) spielen Sie mit psql ein.

Einen ganzen Cluster mit allen Datenbanken, Rollen und Tablespaces sichert pg_dumpall, ausschließlich als plain SQL. Für Export und Umzug kombinieren Sie je nach Szenario diese drei Tools.

Warum nicht einfach das Datenverzeichnis kopieren?

Ein Kopieren des Datenverzeichnisses (physisches Backup) funktioniert nur bei gestopptem Server oder per Base-Backup und ist an Major-Version und Plattform gebunden. Logische Backups mit pg_dump sind versions- und plattformübergreifend, eignen sich für die PostgreSQL Datenmigration und lassen sich selektiv wiederherstellen.

Die drei Dump-Formate im Überblick

Das pg_dump Format bestimmt, wie flexibel der Restore ist:

Für die meisten Backups ist custom (-Fc) die beste Wahl: komprimiert, selektiv, parallel wiederherstellbar. Nur directory (-Fd) arbeitet auch beim Dump parallel. Parallel-Restore mit -j beherrschen nur custom und directory; tar-Backups laufen seriell.

Voraussetzungen

1. Ein laufender PostgreSQL-Server (eine noch unterstützte Version, aktuell 14 bis 18) als Quelle.
2. Die Client-Tools pg_dump, pg_restore, pg_dumpall und psql auf dem ausführenden System. Unter Debian/Ubuntu liefert sie das Paket postgresql-client.
3. Ein Datenbankbenutzer mit Leserechten auf alle zu sichernden Objekte (für vollständige Backups Superuser oder Eigentümer).
4. Freier Speicher für die Dump-Datei, als Faustwert etwa die Datenbankgröße (custom-Dumps sind meist deutlich kleiner). Parallel-Dump und -Restore profitieren von jedem CPU-Kern; für kleine Datenbanken reichen 2 Kerne und 4 GB RAM, x86 oder ARM.
5. Für die Migration: Zugriff auf den Zielserver und Rechte zum Anlegen einer Datenbank (CREATEDB).

Wichtig: pg_dump muss mindestens so neu sein wie der Quellserver; ältere Client-Tools verweigern den Dump. Sichern Sie bei Upgrades mit der neueren pg_dump-Version.

Schritt 1: Verbindung prüfen und Credentials setzen

Prüfen Sie vorab die Verbindung. Für einen schnellen Test genügt die Umgebungsvariable PGPASSWORD; im Dauerbetrieb rät die PostgreSQL-Doku davon ab, weil andere Benutzer auf manchen Systemen Umgebungsvariablen von Prozessen sehen. Für Skripte und Cronjobs ist eine .pgpass-Datei besser.

1. Testen Sie die Verbindung mit psql:

export PGHOST=localhost
export PGPORT=5432
export PGUSER=postgres
export PGPASSWORD='SicheresPasswort'

psql -d meineapp -c "SELECT version();"

Alternativ legen Sie eine ~/.pgpass an (Rechte unbedingt auf 600 setzen, sonst ignoriert PostgreSQL die Datei):

echo "localhost:5432:meineapp:postgres:SicheresPasswort" >> ~/.pgpass
chmod 600 ~/.pgpass

Verifizieren: psql -d meineapp -c "SELECT version();" gibt ohne Passwortabfrage die Server-Version aus, und pg_dump --version zeigt eine Hauptversion, die mindestens so hoch ist wie die des Servers.

Schritt 2: Ein Custom-Backup erstellen

Das Custom-Format ist der Standard für tägliche Backups: komprimiert, später selektiv und parallel wiederherstellbar.

1. Sichern Sie die Datenbank meineapp in eine Datei:

pg_dump -Fc -d meineapp -f meineapp_$(date +%F).dump

Große Datenbanken sichern Sie im directory-Format parallel. -j 4 startet vier Worker (nur mit -Fd):

pg_dump -Fd -j 4 -d meineapp -f meineapp_dir

--exclude-schema schließt ein Schema aus, etwa temporäre oder Audit-Daten. Große Objekte (BLOBs) sind standardmäßig enthalten und lassen sich per --no-large-objects ausschließen (bis PostgreSQL 15 --no-blobs, dort weiterhin gültig, ab 16 veraltet):

pg_dump -Fc -d meineapp --exclude-schema='temp_*' -f meineapp_ohne_temp.dump

Verifizieren: ls -lh meineapp_*.dump zeigt eine Datei mit plausibler Größe (nicht 0 Byte), und pg_dump hat ohne Fehlermeldung beendet (echo $? direkt danach liefert 0).

Schritt 3: Ein Plain-SQL-Backup erstellen

Das plain-Format ist menschenlesbar und per Texteditor anpassbar, aber nicht komprimiert und nicht selektiv.

1. Erzeugen Sie einen SQL-Dump und komprimieren Sie ihn gleich mit gzip:

pg_dump -Fp -d meineapp | gzip > meineapp_$(date +%F).sql.gz

Für ein komplettes Cluster-Backup inklusive aller Rollen und Berechtigungen verwenden Sie pg_dumpall:

pg_dumpall | gzip > cluster_$(date +%F).sql.gz

Nur die globalen Objekte (Rollen, Tablespaces) zusätzlich zu den Custom-Dumps sichert pg_dumpall --globals-only.

Verifizieren: gunzip -t meineapp_*.sql.gz meldet keinen Fehler, und zcat meineapp_*.sql.gz | head -20 zeigt den Kopf eines SQL-Dumps mit dem Kommentar „PostgreSQL database dump“.

Schritt 4: Eine Datenbank wiederherstellen

Das Vorgehen beim PostgreSQL Backup Restore hängt vom Format ab. Legen Sie zuerst die Ziel-Datenbank an, falls nötig.

1. Ziel-Datenbank erstellen:

createdb -O appuser meineapp_neu

1. Plain-SQL-Dump einspielen (mit psql, nicht mit pg_restore):

gunzip -c meineapp_2026-05-31.sql.gz | psql -d meineapp_neu

1. Custom- oder directory-Backup mit pg_restore einspielen, mit -j 4 parallel über vier Jobs (nur custom und directory; tar-Backups ohne -j seriell):

pg_restore -d meineapp_neu -j 4 meineapp_2026-05-31.dump

Mit -C (create) und -c (clean) samt Verbindung zur postgres-Datenbank legt pg_restore die Datenbank selbst an und löscht vorhandene Objekte vorher. Vorsicht: -c löscht die bestehende Datenbank gleichen Namens.

pg_restore -d postgres -C -c -j 4 meineapp_2026-05-31.dump

Verifizieren: psql -d meineapp_neu -c '\dt' listet die erwarteten Tabellen, und pg_restore bzw. psql haben keine Zeilen mit „ERROR“ ausgegeben.

Schritt 5: Selektiver Restore einzelner Tabellen

Aus custom-, tar- und directory-Backups spielen Sie gezielt einzelne Tabellen oder Schemata zurück, etwa wenn nur eine Tabelle versehentlich geleert wurde.

1. Inhaltsverzeichnis des Backups anzeigen:

pg_restore -l meineapp_2026-05-31.dump

1. Nur eine bestimmte Tabelle wiederherstellen:

pg_restore -d meineapp -t kunden meineapp_2026-05-31.dump

1. Nur die Datenbankstruktur ohne Daten (für eine leere Kopie):

pg_restore -d meineapp_leer --schema-only meineapp_2026-05-31.dump

Verifizieren: psql -d meineapp -c 'SELECT count(*) FROM kunden;' liefert wieder die erwartete Zeilenzahl, und in der leeren Kopie zeigt \dt alle Tabellen, aber count(*) ergibt 0.

Schritt 6: Verifikation und erster Test

Ein Backup zählt nur, wenn der Restore funktioniert. Prüfen Sie nach jeder Sicherung und Wiederherstellung stichprobenartig die Daten.

1. Tabellenanzahl und Zeilen vergleichen:

SELECT count(*) FROM kunden;
SELECT relname, n_live_tup
FROM pg_stat_user_tables
ORDER BY n_live_tup DESC
LIMIT 10;

1. Lesbarkeit des Custom-Dumps ohne echten Restore prüfen, indem Sie das Inhaltsverzeichnis auslesen und nach /dev/null verwerfen. Das erkennt beschädigte Dateiköpfe, ersetzt aber keinen Test-Restore:

pg_restore -l meineapp_2026-05-31.dump > /dev/null && echo "Dump lesbar"

Planen Sie regelmäßige Test-Restores auf einem separaten System ein.

Verifizieren: Die Zeilenzahlen aus pg_stat_user_tables stimmen zwischen Quelle und Test-Restore überein (bei frisch eingespielten Daten ggf. vorher ANALYZE; ausführen), und der Befehl oben gibt „Dump lesbar“ aus.

Updates, Wartung und Backup-Aufbewahrung

Halten Sie PostgreSQL aktuell; Sicherheitslücken betreffen auch Backup-Werkzeuge und Verbindungen. Beispiel: PostgreSQL 18.4 Sicherheitsupdate gegen CVE-2026-6473 und 6475.

Aufbewahrung und Rotation

Löschen Sie alte Backups nach festem Schema. Diese Rotation behält die letzten 14 Tage:

find /backup/postgres -name "*.dump" -mtime +14 -delete

Befolgen Sie die 3-2-1-Regel: drei Kopien, zwei Medien, eine außer Haus, etwa verschlüsselt in einem Cloud-Speicher.

Schritt 7: Backups per cron automatisieren

Mit einem Cron-Job läuft die Sicherung zuverlässig ohne Ihr Zutun. Legen Sie zunächst ein Backup-Skript an.

1. Skript /usr/local/bin/pg_backup.sh erstellen:

#!/usr/bin/env bash
set -euo pipefail

export PGHOST=localhost
export PGUSER=postgres
export PGPASSWORD='SicheresPasswort'

BACKUP_DIR=/backup/postgres
DB=meineapp
STAMP=$(date +%F_%H-%M)

mkdir -p "$BACKUP_DIR"
pg_dump -Fc -d "$DB" -f "$BACKUP_DIR/${DB}_${STAMP}.dump"

# Backups älter als 14 Tage entfernen
find "$BACKUP_DIR" -name "${DB}_*.dump" -mtime +14 -delete

Steht das Passwort im Skript, schützen Sie die Datei mit chmod 700 und chown root:root. Sauberer: die PGPASSWORD-Zeile entfernen und das Passwort in die ~/.pgpass des Cron-Benutzers legen.

1. Skript ausführbar machen und in die crontab eintragen (täglich um 2:30 Uhr). Die letzte Zeile gehört in den Editor, den crontab -e öffnet:

chmod +x /usr/local/bin/pg_backup.sh
crontab -e
30 2 * * * /usr/local/bin/pg_backup.sh >> /var/log/pg_backup.log 2>&1

Eine herstellerübergreifende Variante mit Cloud-Upload: MySQL- und PostgreSQL-Backups per cron und Cloud automatisieren.

Verifizieren: Ein manueller Aufruf von /usr/local/bin/pg_backup.sh legt eine neue Datei in /backup/postgres an, crontab -l zeigt den Eintrag, und nach dem ersten nächtlichen Lauf enthält /var/log/pg_backup.log keine Fehler.

Troubleshooting

1. „server version mismatch“: Ihre pg_dump-Version ist älter als der Server. Installieren Sie die passende oder eine neuere Client-Version aus dem PostgreSQL-Repository.
2. „permission denied for table“: Der Dump-Benutzer hat nicht auf alle Objekte Leserechte. Verwenden Sie einen Superuser oder vergeben Sie die nötigen GRANT SELECT-Rechte.
3. Restore bricht mit „role does not exist“ ab: Die im Dump referenzierten Rollen fehlen auf dem Zielserver. Spielen Sie zuerst pg_dumpall --globals-only ein oder nutzen Sie beim Restore --no-owner --no-privileges.
4. Parallel-Restore ignoriert -j: Bei plain-SQL- und tar-Dumps gibt es keinen Parallel-Restore. Nutzen Sie custom oder directory als Format.
5. .pgpass wird ignoriert: Ohne Rechte 600 ignoriert PostgreSQL die Datei.
6. Cron-Job läuft nicht: Cron kennt Ihre Shell-Variablen nicht. Pfade und Verbindungsdaten im Skript bzw. in der .pgpass setzen, Logfile prüfen.

Häufige Fragen

Was ist der Unterschied zwischen pg_dump und pg_dumpall?

pg_dump sichert eine Datenbank in allen Formaten. pg_dumpall sichert den ganzen Cluster samt Rollen und Tablespaces, nur als plain SQL. Üblich ist pg_dump -Fc je Datenbank plus pg_dumpall --globals-only.

Welches Format soll ich für Backups wählen?

Custom (-Fc) für reguläre Backups, directory (-Fd) für parallelen Dump, plain SQL (-Fp) für kleine Datenbanken oder zum Lesen und Bearbeiten.

Wie migriere ich eine Datenbank auf einen neuen Server?

Sichern Sie zuerst die Rollen mit pg_dumpall --globals-only und spielen Sie sie auf dem Ziel ein. Dann Custom-Backup mit pg_dump -Fc auf der Quelle, Datei kopieren und mit pg_restore -C -d postgres -j 4 einspielen.

Wie beschleunige ich Dump und Restore?

Dump mit pg_dump -Fd -j 4, Restore mit pg_restore -j 4 (nur custom und directory). Richten Sie die Zahl hinter -j nach CPU-Kernen und I/O-Leistung; der Gewinn ist bei vielen Tabellen und großen Datenmengen am größten.

Kann ich mit pg_dump zwischen PostgreSQL-Versionen migrieren?

Ja, das ist der größte Vorteil gegenüber physischen Backups. Verwenden Sie die pg_dump-Version der höheren beteiligten Server-Version.

Fazit

Für reguläre Sicherungen das Custom-Format, Parallel-Restore für große Datenmengen, selektive Restores für einzelne Tabellen und Automatisierung per cron. Testen Sie Ihre Restores regelmäßig; nur ein geprüftes Backup ist ein echtes Backup.

Weiterführende Anleitungen

Wenn Sie Ihre Sicherungsstrategie ausbauen wollen, zeigt Ihnen die Anleitung Datenbank-Backups mit cron und Cloud automatisieren den kompletten Workflow inklusive Off-Site-Speicher. Für die zeitgesteuerte Ausführung hilft die Anleitung Cron und crontab: Grundlagen unter Linux. Zur Sicherheit Ihrer Installation lohnt sich der Blick auf das PostgreSQL 18.4 Update. Weitere Beiträge finden Sie in der Kategorie Datenbanken.

Quellen

Offizielle Dokumentation: PostgreSQL pg_dump, PostgreSQL pg_restore, PostgreSQL pg_dumpall und Die Passwortdatei .pgpass.