Restoring a backup
Safe swap restore, full restore, and verification — step by step.
Restores run from a database's Backups view. Pick a completed backup and a strategy. Every strategy verifies the restored data against the backup's baseline before anything irreversible happens.
Swap restore (default, safest)
The Heroku-style restore:
- Download the backup from Backblaze B2 to the server.
- Restore it into a temporary database with
pg_restore. - Verify the restore (table count vs the backup's baseline) — this raises and aborts before touching the live database if anything's wrong.
- Atomically rename: live →
<name>_pre_rollback, restored → live. If anything fails mid-swap, LaunchPad renames the original back so you're never left without a live database.
Near-zero downtime, and a bad restore can't corrupt production.
Full restore
Drops and recreates the database directly from the backup. Faster, but causes downtime and has no swap safety net — use it when you accept the trade-off.
Restore drill
Restores into a temporary database, verifies it, and discards it. The live database is never changed. This is how LaunchPad proves your backups are restorable — run one any time you want confidence, and they run automatically on a schedule.
Recovering to a specific moment
To recover to a point between backups, see Point-in-time recovery.