LaunchPad

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 .enc artifact. 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.