5 Ways to Backup and Restore Postgres in 2026

There are many ways to back up Postgres. The right one depends on how much data you can afford to lose, how fast you need to restore, and who is responsible when something breaks.

For a tiny side project, pg_dump might be enough. For a production app, you probably want automated backups, point-in-time recovery, and regular restore tests.

Here are five ways to backup and restore Postgres in 2026.

Quick comparison

1. Managed backups and point-in-time recovery

The easiest backup strategy is to use a managed Postgres provider that includes automated backups and point-in-time recovery.

Sliplane Managed Postgres includes automated point-in-time backups, SSL by default, automatic security updates, built-in metrics and logs, free egress, API access, and the first 10 GB of storage.

This is the best option when you want to restore without building your own backup system. Instead of wiring cron, storage, monitoring, and retention yourself, you use the provider workflow.

Use managed backups if:

• the database is production-critical.
• you care about restoring to a recent point in time.
• nobody wants to maintain backup scripts.
• you want restore operations to be part of the product, not a weekend project.

Skip this if:

• you intentionally self-host everything.
• you need a custom backup pipeline.
• you want to keep all backup storage under your own infrastructure account.

2. Plain SQL backups with pg_dump

The simplest manual backup is a plain SQL dump:

PGPASSWORD='your-password' \
pg_dump \
  -h your-db-host \
  -p 5432 \
  -U your-user \
  -d your-database \
  -f backup-$(date +%F).sql

Restore it with psql:

PGPASSWORD='your-password' \
psql \
  -h your-db-host \
  -p 5432 \
  -U your-user \
  -d target-database \
  -f backup-2026-07-02.sql

Plain SQL backups are nice because you can read them, grep them, and understand what is inside. They are less nice when the database gets large, because restore times can become painful.

Use plain SQL if:

• the database is small.
• you want a readable dump.
• you are backing up a dev, staging, or low-risk database.

Skip it if:

• restores need to be fast.
• you need selective restores.
• you need point-in-time recovery.

3. Custom archive backups with pg_dump -Fc

For most manual Postgres backups, the custom archive format is better than plain SQL.

Create a compressed custom archive:

PGPASSWORD='your-password' \
pg_dump \
  -h your-db-host \
  -p 5432 \
  -U your-user \
  -d your-database \
  -Fc \
  -f backup-$(date +%F).dump

Restore it with pg_restore:

PGPASSWORD='your-password' \
pg_restore \
  -h your-db-host \
  -p 5432 \
  -U your-user \
  -d target-database \
  --clean \
  --if-exists \
  --no-owner \
  --no-privileges \
  backup-2026-07-02.dump

For larger restores, use parallel jobs:

PGPASSWORD='your-password' \
pg_restore \
  -j 4 \
  -h your-db-host \
  -p 5432 \
  -U your-user \
  -d target-database \
  backup-2026-07-02.dump

Custom archives are a good default for manual backups because they are compressed, flexible, and restore with pg_restore.

4. Backup and restore through an SSH tunnel

If your Postgres database is private and not exposed to the public internet, use an SSH tunnel. This is common for self-hosted databases and private Sliplane services.

First, create an SSH tunnel service. In Sliplane, add the SSH Tunnel preset and deploy it with:

• HOST=0.0.0.0
• PORT=2222
• ROOT_PASSWORD= set to a strong password

Then open a local tunnel:

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

Replace postgres-service-name.internal with the internal hostname of your Postgres service. Keep the terminal open while backing up or restoring.

Test the connection:

PGPASSWORD='your-password' \
psql \
  -h 127.0.0.1 \
  -p 5433 \
  -U your-user \
  -d your-database \
  -c 'SELECT version();'

Create a custom archive through the tunnel:

PGPASSWORD='your-password' \
pg_dump \
  -h 127.0.0.1 \
  -p 5433 \
  -U your-user \
  -d your-database \
  -Fc \
  -f backup-$(date +%F).dump

Restore through the same tunnel:

PGPASSWORD='your-password' \
pg_restore \
  -h 127.0.0.1 \
  -p 5433 \
  -U your-user \
  -d target-database \
  --clean \
  --if-exists \
  --no-owner \
  --no-privileges \
  backup-2026-07-02.dump

Use SSH tunnel backups if:

• the database is private.
• you do not want to expose Postgres publicly.
• you need manual pg_dump or pg_restore access from your machine.

Skip it if:

• the provider already gives you the restore you need.
• you need fully automated backups without keeping tunnels alive.
• network interruptions would make the process unreliable for very large dumps.

5. Volume or server snapshots

Snapshots can be useful for self-hosted Postgres, especially when you run everything on a VPS. But they are not automatically safe just because the provider calls them backups.

Postgres writes data continuously. If a snapshot is taken while writes are happening, you can end up with an inconsistent backup unless the snapshot system is coordinated with the database.

If you rely on snapshots:

• understand whether they are crash-consistent or application-consistent.
• prefer stopping writes or using database-aware tooling before snapshots.
• combine snapshots with logical backups.
• test restores onto a separate server.

Snapshots are good disaster-recovery material. They are not a replacement for Postgres-aware backups and restore testing.

Final recommendation

Use managed backups and point-in-time recovery for production apps. Use pg_dump -Fc for manual backups. Use SSH tunnels when the database is private. Use snapshots as an extra layer, not your only backup.

Most importantly: test restores. A backup strategy that has never restored a real database is just a theory with a timestamp.