Mit dieser PostgreSQL pg_dump pg_restore Anleitung sicherst und migrierst du deine Datenbanken zuverlässig per Kommandozeile. Du lernst, wie sich die drei Dump-Formate plain, custom und tar unterscheiden, wie du komplette oder einzelne Tabellen wiederherstellst, wie du mit Parallel-Dump und Parallel-Restore Zeit sparst und wie du deine Sicherungen automatisierst. Die Anleitung richtet sich an Admins, Selfhoster und Entwickler, die ihre PostgreSQL-Daten ohne grafische Tools zuverlässig sichern und auf einen anderen Server umziehen wollen.

Kurzfassung: pg_dump -Fc erzeugt ein komprimiertes Custom-Backup, das du mit pg_restore -j 4 parallel und selektiv zurückspielst. Für reines SQL nutzt du pg_dump -Fp und psql < backup.sql. Cluster-weit sicherst du mit pg_dumpall. Automatisiert wird das Ganze per cron mit gesetzter PGPASSWORD.

Was sind pg_dump und pg_restore?

pg_dump ist das offizielle Werkzeug von PostgreSQL, um eine einzelne Datenbank konsistent zu exportieren. Es liest die Datenbank in einer Transaktion aus, sodass dein Backup auch bei laufendem Betrieb einen konsistenten Stand abbildet. Das Gegenstück pg_restore spielt Backups in den Formaten custom, tar und directory zurück. Reine SQL-Dumps (Format plain) werden dagegen direkt mit psql eingespielt.

Für das Sichern eines ganzen Clusters inklusive aller Datenbanken, Rollen und Tablespaces gibt es zusätzlich pg_dumpall. Dieses Werkzeug schreibt ausschließlich plain SQL. Wer also PostgreSQL Daten exportieren und auf einen neuen Server bringen möchte, kombiniert je nach Szenario diese drei Tools.

Warum nicht einfach das Datenverzeichnis kopieren?

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

Die drei Dump-Formate im Überblick

Das richtige pg_dump Format entscheidet darüber, wie flexibel dein Restore später ist. Diese Tabelle fasst die wichtigsten Eigenschaften zusammen:

FlagFormatRestore mitKomprimiertSelektiv / parallel

-Fp

plain (SQL)

psql

nein

-Fc

custom

pg_restore

ja (selektiv, Restore parallel)

-Ft

tar

pg_restore

nein

selektiv, kein Parallel-Dump/-Restore

-Fd

Voraussetzungen

Ein laufender PostgreSQL-Server (Version 13 oder neuer empfohlen) als Quelle.
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.
Ein Datenbankbenutzer mit Leserechten auf alle zu sichernden Objekte (für vollständige Backups idealerweise ein Superuser oder der Eigentümer).
Genügend freier Speicherplatz für die Dump-Datei.
Für die Migration: Zugriff auf den Zielserver und Rechte zum Anlegen einer Datenbank (CREATEDB).

Wichtig: Die Version der Client-Tools sollte gleich oder neuer als die des Zielservers sein. Sichere bei Upgrades immer mit der neueren pg_dump-Version, damit beim Restore auf die neue Major-Version keine Inkompatibilitäten auftreten.

Schritt 1: Verbindung prüfen und Credentials setzen

Bevor du sicherst, prüfe die Verbindung zur Datenbank. Damit du nicht bei jedem Aufruf das Passwort eintippen musst, setzt du die Umgebungsvariable PGPASSWORD. Für Skripte ist das praktisch, für interaktive Nutzung ist eine .pgpass-Datei sicherer.

Teste die Verbindung mit psql:

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

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

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

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

Schritt 2: Ein Custom-Backup erstellen

Das Custom-Format ist der Standard für tägliche Backups. Es ist komprimiert und erlaubt später einen selektiven sowie parallelen Restore.

Sichere die Datenbank meineapp in eine Datei:

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

Bei großen Datenbanken nutzt du das directory-Format mit Parallel-Dump. Der Parameter -j 4 startet vier parallele Worker und beschleunigt den Export deutlich (nur mit -Fd möglich):

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

Möchtest du ein bestimmtes Schema ausschließen, etwa temporäre oder Audit-Daten, hilft --exclude-schema. Große Objekte (BLOBs) sind standardmäßig enthalten, lassen sich aber per --no-blobs ausschließen:

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

Schritt 3: Ein Plain-SQL-Backup erstellen

Wenn du den Inhalt menschenlesbar prüfen oder per Texteditor anpassen willst, eignet sich das plain-Format. Es ist nicht komprimiert und nicht selektiv, dafür universell einsetzbar.

Erzeuge einen SQL-Dump und komprimiere 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 verwendest du pg_dumpall:

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

Reicht dir nur die Sicherung der globalen Objekte (Rollen, Tablespaces) zusätzlich zu den Custom-Dumps, nutze pg_dumpall --globals-only.

Schritt 4: Eine Datenbank wiederherstellen

Beim PostgreSQL Backup Restore hängt das Vorgehen vom Format ab. Lege zunächst die Ziel-Datenbank an, falls sie noch nicht existiert.

Ziel-Datenbank erstellen:

createdb -O appuser meineapp_neu

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

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

Custom- oder directory-Backup mit pg_restore einspielen. Mit -j 4 läuft der Restore parallel über vier Jobs (Parallel-Restore funktioniert nur mit custom und directory; tar-Backups spielst du ohne -j seriell ein):

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

Soll pg_restore die Datenbank selbst anlegen und vorhandene Objekte vorher löschen, nutzt du -C (create) und -c (clean) zusammen mit der Verbindung zur postgres-Datenbank:

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

Schritt 5: Selektiver Restore einzelner Tabellen

Ein großer Vorteil der Formate custom, tar und directory: Du kannst gezielt einzelne Tabellen oder Schemata zurückspielen, ohne das gesamte Backup einzulesen. Das ist Gold wert, wenn nur eine Tabelle versehentlich geleert wurde.

Inhaltsverzeichnis des Backups anzeigen:

pg_restore -l meineapp_2026-05-31.dump

Nur eine bestimmte Tabelle wiederherstellen:

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

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

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

Schritt 6: Verifikation und erster Test

Ein Backup ist nur dann etwas wert, wenn der Restore funktioniert. Prüfe nach jeder Sicherung und nach jeder Wiederherstellung stichprobenartig die Daten.

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;

Integrität des Custom-Dumps ohne echten Restore prüfen, indem du das Inhaltsverzeichnis ausliest und nach /dev/null verwirfst:

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

Plane regelmäßige Test-Restores auf einem separaten System ein. Nur so weißt du sicher, dass dein Notfallplan im Ernstfall trägt.

Updates, Wartung und Backup-Aufbewahrung

Halte deine PostgreSQL-Installation aktuell, denn Sicherheitslücken betreffen auch Backup-Werkzeuge und Verbindungen. Lies dazu unseren Beitrag zum PostgreSQL 18.4 Sicherheitsupdate gegen CVE-2026-6473 und 6475, der zeigt, warum zeitnahe Patches wichtig sind.

Aufbewahrung und Rotation

Lösche alte Backups nach einem festen Schema, damit dein Speicher nicht überläuft. Eine einfache Rotation behält die Sicherungen der letzten 14 Tage:

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

Befolge die 3-2-1-Regel: drei Kopien, zwei verschiedene Medien, eine Kopie außer Haus. Lade deine Dumps also zusätzlich verschlüsselt in einen Cloud-Speicher.

Schritt 7: Backups per cron automatisieren

Manuelle Backups werden vergessen. Mit einem Cron-Job läuft die Sicherung zuverlässig und ohne dein Zutun. Lege zunächst ein Backup-Skript an.

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

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

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

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 aelter als 14 Tage entfernen
find "$BACKUP_DIR" -name "${DB}_*.dump" -mtime +14 -delete

Skript ausführbar machen und in die crontab eintragen (täglich um 2:30 Uhr):

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 ausführliche, herstellerübergreifende Variante mit Cloud-Upload findest du in unserer Anleitung MySQL- und PostgreSQL-Backups per cron und Cloud automatisieren.

Troubleshooting

"server version mismatch": Deine pg_dump-Version ist älter als der Server. Installiere die passende oder eine neuere Client-Version aus dem PostgreSQL-Repository.
"permission denied for table": Der Dump-Benutzer hat nicht auf alle Objekte Leserechte. Verwende einen Superuser oder vergib die nötigen GRANT SELECT-Rechte.
Restore bricht mit "role does not exist" ab: Die im Dump referenzierten Rollen fehlen auf dem Zielserver. Spiele zuerst pg_dumpall --globals-only ein oder nutze beim Restore --no-owner --no-privileges.
Parallel-Restore ignoriert -j: Bei plain-SQL- und tar-Dumps gibt es keinen Parallel-Restore. Nutze custom oder directory als Format.
.pgpass wird ignoriert: Die Datei muss die Rechte 600 haben, sonst verweigert PostgreSQL aus Sicherheitsgründen den Zugriff.
Cron-Job läuft nicht: Cron kennt deine Shell-Variablen nicht. Setze PGPASSWORD und Pfade direkt im Skript und prüfe das Logfile.

Häufige Fragen

Was ist der Unterschied zwischen pg_dump und pg_dumpall?

pg_dump sichert genau eine Datenbank und beherrscht alle Formate inklusive komprimiertem Custom-Format. pg_dumpall sichert das gesamte Cluster inklusive Rollen und Tablespaces, schreibt aber nur plain SQL. Für die meisten Setups kombiniert man pg_dump -Fc pro Datenbank mit pg_dumpall --globals-only für die globalen Objekte.

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

Für reguläre Backups ist das Custom-Format (-Fc) die beste Wahl, weil es komprimiert ist und einen selektiven sowie parallelen Restore erlaubt. Das directory-Format (-Fd) ist sinnvoll, wenn auch der Dump selbst parallel laufen soll. Plain SQL (-Fp) eignet sich für kleine Datenbanken oder wenn du den Inhalt lesen und bearbeiten willst.

Wie migriere ich eine Datenbank auf einen neuen Server?

Erstelle auf dem Quellserver ein Custom-Backup mit pg_dump -Fc, kopiere die Datei auf den Zielserver und spiele sie dort mit pg_restore -C -j 4 ein. Sichere vorher die globalen Rollen mit pg_dumpall --globals-only und spiele sie zuerst ein, damit die Eigentümer korrekt zugeordnet werden.

Wie beschleunige ich Dump und Restore?

Nutze für den Dump das directory-Format mit pg_dump -Fd -j 4 und für den Restore pg_restore -j 4. Parallel-Restore mit -j funktioniert nur bei custom- und directory-Backups. Die Zahl hinter -j sollte sich an der Anzahl der CPU-Kerne und der I/O-Leistung orientieren. Parallelisierung bringt vor allem bei vielen Tabellen und großen Datenmengen Geschwindigkeit.

Kann ich mit pg_dump zwischen PostgreSQL-Versionen migrieren?

Ja. Logische Dumps sind versionsübergreifend einsetzbar, das ist ihr größter Vorteil gegenüber physischen Backups. Verwende immer die pg_dump-Version, die zur höheren der beiden beteiligten Server-Versionen passt, also beim Upgrade die neuere.

Fazit

Mit pg_dump und pg_restore hast du ein robustes, versionsunabhängiges Werkzeugpaar für Backup und PostgreSQL Datenmigration an der Hand. Setze für reguläre Sicherungen auf das Custom-Format, nutze Parallel-Restore für große Datenmengen, halte mit selektiven Restores einzelne Tabellen jederzeit wiederherstellbar und automatisiere den ganzen Prozess per cron. Wichtig bleibt: Teste deine Restores regelmäßig, denn nur ein geprüftes Backup ist ein echtes Backup.

Weiterführende Anleitungen

Wenn du deine Sicherungsstrategie ausbauen willst, zeigt dir die Anleitung Datenbank-Backups mit cron und Cloud automatisieren den kompletten Workflow inklusive Off-Site-Speicher. Zur Sicherheit deiner Installation lohnt sich der Blick auf das PostgreSQL 18.4 Update. Weitere Beiträge findest du in der Kategorie Datenbanken.

Quellen

Offizielle Dokumentation: PostgreSQL pg_dump, PostgreSQL pg_restore und PostgreSQL pg_dumpall.