Backups & retention
Automated pg_dump backups, client-side AES-256-GCM encryption, Backblaze B2 storage, schedules, retention, and restore drills.
LaunchPad backs up managed PostgreSQL databases with pg_dump (custom format) over SSH, compresses them, encrypts them client-side, and uploads to Backblaze B2. Each backup also records a verification baseline (table count) so a restore can be proven.
When backups run
- Scheduled — an hourly job backs up any database past its backup frequency (default every 24 hours, configurable per database).
- Pre-deploy — before each deploy, when enabled, to power one-click rollback.
- Manual — on demand from the database's Backups view.
Encryption
Every new backup is encrypted with AES-256-GCM before it leaves your server, using a per-database key — Backblaze only ever stores ciphertext (plus provider-side encryption at rest). Restores through LaunchPad decrypt and authenticate automatically; a tampered or wrong-key artifact fails closed before it ever reaches pg_restore.
- Downloading a backup: the file you download is the encrypted
.encartifact. To use it outside LaunchPad, fetch the backup encryption key via Reveal credentials on the database page (step-up verified and audit-logged). - Key custody: the key lives encrypted in LaunchPad's control database. If the control database is lost, restore access to encrypted backups is lost with it — keep LaunchPad's own recovery story healthy.
- Older backups taken before encryption shipped remain restorable and are labeled as unencrypted; they age out with normal retention.
Retention
Backups expire after the database's retention window (default 30 days); a retention job deletes the expired B2 objects but always keeps the latest restorable backup, so a database is never left with no recovery point. A reaper marks any backup stuck mid-run as failed so a stalled backup can't silently age out your recovery point.
Backups are proven, not assumed
A backup only counts as "protected" if it has a storage object and a verification baseline. Restore drills run on a schedule: they restore a backup into a throwaway database, verify it, and discard it — proving the backup actually restores without touching production.
Continuous archiving (PITR)
For restore-to-any-second instead of snapshot intervals, enable WAL archiving. See Point-in-time recovery.