Backups

Skycloak backs up your cluster’s database every day, keeps each backup for your plan’s retention, and lets you take an extra backup whenever you need one, for example before a risky configuration change. Backups stay in the same region as your cluster.

Open a cluster and choose Backups in the sidebar.

What you see

• Storage used: the total size of this cluster’s stored backups.
• Next automatic backup: when the next daily backup starts.
• Automatic retention: how long daily backups are kept.
• The backup list, newest first, with for each backup:

Retention

A backup is deleted automatically when it expires. Deleting a cluster deletes all of its backups straight away, with no grace period, so download anything you want to keep first.

Daily backup time

By default the daily backup starts at the beginning of your cluster’s maintenance window. To pick your own time, set Daily backup time (UTC) and click Save time. The page also shows the time in your own time zone. Use maintenance window switches back to the default.

Backups run while your cluster keeps serving sign-ins; your users are not affected.

Backup now

Click Backup now, choose how long to keep the backup, and click Start backup. It appears in the list as Manual. Only one backup of a cluster runs at a time, so Backup now is unavailable while another backup is queued or running.

Downloading a backup

Click Download next to a completed backup. A backup is a complete copy of the cluster’s database, including every user and their credentials (password hashes, OTP secrets, client secrets), so you have to tick Include credentials to confirm before the download starts.

• The download link works once and expires after 15 minutes. Ask for a new one if you need it again.
• The file is a PostgreSQL custom-format archive (.dump). Restore it with pg_restore:

pg_restore --no-owner --dbname "$DATABASE_URL" my-cluster-auto-202609230300.dump

• Every download is recorded in your audit log as Backup Downloaded.

Store downloaded backups as securely as the cluster itself.

When a backup fails

A backup that still fails after several automatic retries is marked Failed, including a daily backup that could not start in its time slot. When that happens:

• every member of the workspace gets an email (members can turn these off under Cluster changes in their notification settings);
• the cluster page shows a Backup failed badge next to the cluster status, linking to the Backups page;
• a backup.failed webhook is sent, if you subscribe to it.

Your earlier backups stay available until they expire, and the next daily backup runs as planned. You can also start one right away with Backup now.

Webhooks

Subscribe a webhook with the Platform source to the Backup events:

The event’s data object:

{
  "backup_id": "auto-202609230300",
  "type": "automatic",
  "status": "completed",
  "retention_days": 14,
  "requested_at": "2026-09-23T03:00:00Z",
  "completed_at": "2026-09-23T03:04:12Z",
  "size_bytes": 52428800,
  "sha256": "9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08",
  "expires_at": "2026-10-07T03:04:12Z"
}

backup.failed carries failure_reason and attempts instead of size_bytes, sha256 and expires_at:

Automating backups

Everything on the Backups page is also available through the public API.

Backups and Database Export

Database Export is a separate, manual flow and works exactly as before. Exports never appear in the Backups list, and backups do not count against exports.