Skip to main content

​
How backups work

DBHost uses pg_dump piped through gzip to create compressed SQL backups. Backups run asynchronously. You can trigger them manually, and DBHost also runs a daily automated backup job at 02:00 UTC with 30-day retention in production. In production, durable backups are stored off-host in AWS S3 eu-north-1 and exposed in the dashboard as timestamped .sql.gz files.

​
Triggering a backup

  1. Go to your database detail page
  2. Click Export Data to start a new backup and jump to the backups page
  3. Or click Backups and use Trigger Backup from there
The backup is queued as an operation. The dashboard polls its status and updates the list without requiring a page refresh.

​
Viewing backup history

The backups page shows all available backups with:
  • Filename (timestamp-based: YYYYMMDD_HHMMSS.sql.gz)
  • Size (compressed)
  • Created at (UTC)
  • Actions — role-appropriate download, delete, and limited-rollout actions
Developers can view and download backups. Owners and admins can trigger and delete backups. Restore and import controls are hidden unless the exact database is enrolled in the limited rollout described below.

​
Restoring from a backup (limited rollout)

The staged restore design uses an isolated staging database, validates the artifact, creates and verifies a pre-restore backup, then performs a guarded swap during a maintenance window of at most five minutes. The previous database is retained in isolation for 24 hours for an operator-controlled rollback.
An enabled release flag is not target authorization. Restore remains available only when the database ID/name, managed-registry generation, operation ID and agent capability all match the approved rollout policy.

​
Importing a database dump (limited rollout)

The staged import flow accepts a pg_dump file from another host or platform. It is not a generally available customer migration path; the controls appear only for an exact enrolled database.
  1. Initialize an upload operation.
  2. Select a file (.sql, .sql.gz, .dump, or .backup - max 512 MB).
  3. Upload directly to the isolated S3 staging prefix with the short-lived presigned URL.
  4. Complete the upload so DBHost can validate size, checksum, format and schema inventory before a restore can proceed.
Restore staging has a 30-minute execution limit. Plain .sql and .sql.gz files must also remain within 512 MB after decompression, and each physical SQL line - including one COPY row - must be no larger than 16 MiB. Use a custom .dump or .backup file when a single value needs a larger line. The file does not travel through Vercel or Caddy. Upload completion does not by itself authorize a production restore. After a successful staged restore, DBHost verifies that restored objects belong to the limited tenant owner before the database can become active.

​
Retention

Backups are retained for 30 days in production. Automated cleanup runs as part of the scheduled backup job. A deletion backup is a separate lifecycle artifact. It is bound to the exact delete operation, remains downloadable only during that database’s seven-day recovery window, and is permanently removed together with the physical tombstone. It does not become an ordinary 30-day backup after deletion.

​
Downloading and deleting backups

  • Use Download to fetch the exact .sql.gz file for local storage or operator restore work. S3 returns the object through a 15-minute presigned URL when the direct-download capability is available; the backup body does not pass through Vercel. Local storage uses bounded streaming with an idle timeout.
  • Use Delete to remove a backup file permanently from backup storage.
Deleting a backup cannot be undone.