> ## Documentation Index
> Fetch the complete documentation index at: https://docs.dbhost.app/llms.txt
> Use this file to discover all available pages before exploring further.

# Backups

> Trigger and manage database backups.

## 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.

<Warning>
  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.
</Warning>

## 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.

<Warning>Deleting a backup cannot be undone.</Warning>