5 Wege, Postgres in 2026 zu sichern und wiederherzustellen

Jonas Scholz

7 min

Es gibt viele Wege, Postgres zu sichern. Welcher davon passt, hängt davon ab, wie viel Datenverlust du akzeptieren kannst, wie schnell ein Restore laufen muss und wer verantwortlich ist, wenn etwas kaputtgeht.

Für ein kleines Side Project reicht vielleicht pg_dump. Für eine Production App willst du wahrscheinlich automatische Backups, Point-in-Time Recovery und regelmäßige Restore-Tests.

Hier sind fünf Wege, Postgres in 2026 zu sichern und wiederherzustellen.

Schneller Vergleich

Methode	Am besten für	Restore-Form	Worauf du achten musst
Managed Backups und PITR	Production Apps, die keine Daten verlieren sollen	Restore auf einen Zeitpunkt über Provider-Dashboard/API	Provider-spezifisches Retention Window
`pg_dump` Plain SQL	Kleine Datenbanken und lesbare Backups	`psql -f backup.sql`	Langsam bei größeren Datenbanken
`pg_dump -Fc` Custom Archive	Die meisten manuellen logischen Backups	`pg_restore`, selektiver Restore, paralleler Restore	Immer noch ein logisches Backup, kein PITR
SSH-Tunnel Backups	Private Datenbanken ohne public Exposure	`pg_dump`/`pg_restore` über lokalen Tunnel	Tunnel muss offen bleiben
Volume/Server-Snapshots	Disaster Recovery für selbst gehostete Setups	Volume- oder VM-Snapshot wiederherstellen	Kann inkonsistent sein, wenn Postgres gerade schreibt

1. Managed Backups und Point-in-Time Recovery

Die einfachste Backup-Strategie ist ein Managed Postgres Provider, der automatische Backups und Point-in-Time Recovery mitbringt.

Sliplane Managed Postgres enthält automatische Point-in-Time Backups, SSL by default, automatische Security Updates, eingebaute Metrics und Logs, kostenlosen Egress, API-Zugriff und die ersten 10 GB Storage.

Das ist die beste Option, wenn du Restores willst, ohne dein eigenes Backup-System zu bauen. Statt Cron, Storage, Monitoring und Retention selbst zu verkabeln, nutzt du den Workflow vom Provider.

Nutz Managed Backups, wenn:

die Datenbank production-critical ist.
du auf einen möglichst aktuellen Zeitpunkt zurückspringen willst.
niemand Backup-Scripts pflegen möchte.
Restore Operations Teil vom Produkt sein sollen, nicht ein Wochenendprojekt.

Überspring es, wenn:

du bewusst alles selbst hostest.
du eine eigene Backup-Pipeline brauchst.
du den kompletten Backup-Storage in deinem eigenen Infrastruktur-Account halten willst.

Einfachere Restores?

Managed Postgres auf Sliplane enthält automatische Point-in-Time Backups, SSL, Metrics, Logs, kostenlosen Egress und 10 GB inkludierten Storage.

2. Plain SQL Backups mit `pg_dump`

Das simpelste manuelle Backup ist ein Plain SQL Dump:

Terminal

PGPASSWORD='dein-passwort' \
pg_dump \
  -h dein-db-host \
  -p 5432 \
  -U dein-user \
  -d deine-datenbank \
  -f backup-$(date +%F).sql

Stell es mit psql wieder her:

Terminal

PGPASSWORD='dein-passwort' \
psql \
  -h dein-db-host \
  -p 5432 \
  -U dein-user \
  -d ziel-datenbank \
  -f backup-2026-07-02.sql

Plain SQL Backups sind angenehm, weil du sie lesen, mit grep durchsuchen und verstehen kannst, was drinsteht. Weniger angenehm werden sie, wenn die Datenbank größer wird, weil Restore-Zeiten dann schnell nerven.

Nutz Plain SQL, wenn:

die Datenbank klein ist.
du einen lesbaren Dump willst.
du eine Dev-, Staging- oder Low-Risk-Datenbank sicherst.

Überspring es, wenn:

Restores schnell sein müssen.
du selektive Restores brauchst.
du Point-in-Time Recovery brauchst.

3. Custom Archive Backups mit `pg_dump -Fc`

Für die meisten manuellen Postgres Backups ist das Custom Archive Format besser als Plain SQL.

Erstell ein komprimiertes Custom Archive:

Terminal

PGPASSWORD='dein-passwort' \
pg_dump \
  -h dein-db-host \
  -p 5432 \
  -U dein-user \
  -d deine-datenbank \
  -Fc \
  -f backup-$(date +%F).dump

Stell es mit pg_restore wieder her:

Terminal

PGPASSWORD='dein-passwort' \
pg_restore \
  -h dein-db-host \
  -p 5432 \
  -U dein-user \
  -d ziel-datenbank \
  --clean \
  --if-exists \
  --no-owner \
  --no-privileges \
  backup-2026-07-02.dump

Für größere Restores kannst du parallele Jobs nutzen:

Terminal

PGPASSWORD='dein-passwort' \
pg_restore \
  -j 4 \
  -h dein-db-host \
  -p 5432 \
  -U dein-user \
  -d ziel-datenbank \
  backup-2026-07-02.dump

Custom Archives sind ein guter Default für manuelle Backups, weil sie komprimiert und flexibel sind und mit pg_restore wiederhergestellt werden.

4. Backup und Restore über einen SSH-Tunnel

Wenn deine Postgres-Datenbank privat ist und nicht im public Internet hängt, nutz einen SSH-Tunnel. Das ist häufig bei selbst gehosteten Datenbanken und privaten Sliplane Services.

Erstell zuerst einen SSH-Tunnel-Service. In Sliplane fügst du das SSH Tunnel Preset hinzu und deployst es mit:

HOST=0.0.0.0
PORT=2222
ROOT_PASSWORD= mit einem starken Passwort

Öffne dann einen lokalen Tunnel:

Terminal

ssh -p 2222 \
  root@deine-tunnel-domain.sliplane.app \
  -L 5433:postgres-service-name.internal:5432 \
  -N

Ersetz postgres-service-name.internal durch den internen Hostname deines Postgres Service. Lass das Terminal offen, solange du Backup oder Restore ausführst.

Teste die Verbindung:

Terminal

PGPASSWORD='dein-passwort' \
psql \
  -h 127.0.0.1 \
  -p 5433 \
  -U dein-user \
  -d deine-datenbank \
  -c 'SELECT version();'

Erstell ein Custom Archive durch den Tunnel:

Terminal

PGPASSWORD='dein-passwort' \
pg_dump \
  -h 127.0.0.1 \
  -p 5433 \
  -U dein-user \
  -d deine-datenbank \
  -Fc \
  -f backup-$(date +%F).dump

Stell es durch denselben Tunnel wieder her:

Terminal

PGPASSWORD='dein-passwort' \
pg_restore \
  -h 127.0.0.1 \
  -p 5433 \
  -U dein-user \
  -d ziel-datenbank \
  --clean \
  --if-exists \
  --no-owner \
  --no-privileges \
  backup-2026-07-02.dump

Nutz SSH-Tunnel Backups, wenn:

die Datenbank privat ist.
du Postgres nicht public exposen willst.
du manuellen pg_dump- oder pg_restore-Zugriff von deiner Maschine brauchst.

Überspring es, wenn:

der Provider dir schon den Restore gibt, den du brauchst.
du vollautomatische Backups brauchst, ohne Tunnel offen zu halten.
Netzwerkunterbrechungen große Dumps unzuverlässig machen würden.

5. Volume- oder Server-Snapshots

Snapshots können für selbst gehostetes Postgres nützlich sein, besonders wenn alles auf einem VPS läuft. Aber sie sind nicht automatisch sicher, nur weil der Provider sie Backups nennt.

Postgres schreibt kontinuierlich Daten. Wenn ein Snapshot während aktiver Writes erstellt wird, kann das Backup inkonsistent sein, falls das Snapshot-System nicht mit der Datenbank koordiniert ist.

Wenn du dich auf Snapshots verlässt:

versteh, ob sie crash-consistent oder application-consistent sind.
stopp Writes lieber vorher oder nutz datenbankbewusste Tools vor dem Snapshot.
kombinier Snapshots mit logischen Backups.
teste Restores auf einem separaten Server.

Snapshots sind gutes Disaster-Recovery-Material, aber kein Ersatz für Postgres-aware Backups und Restore-Tests.

Finale Empfehlung

Nutz Managed Backups und Point-in-Time Recovery für Production Apps. Nutz pg_dump -Fc für manuelle Backups. Nutz SSH-Tunnel, wenn die Datenbank privat ist. Nutz Snapshots als zusätzliche Schicht, nicht als dein einziges Backup.

Am wichtigsten: teste Restores. Eine Backup-Strategie, die noch nie eine echte Datenbank wiederhergestellt hat, ist nur Theorie mit Timestamp.

5 Wege, Postgres in 2026 zu sichern und wiederherzustellen

Schneller Vergleich

1. Managed Backups und Point-in-Time Recovery

2. Plain SQL Backups mit pg_dump

3. Custom Archive Backups mit pg_dump -Fc

4. Backup und Restore über einen SSH-Tunnel

5. Volume- oder Server-Snapshots

Finale Empfehlung

Willkommen auf deiner Cloud-Plattform

2. Plain SQL Backups mit `pg_dump`

3. Custom Archive Backups mit `pg_dump -Fc`