Database backups & restore

PandaStack databases support automated backups with a retention count and in-place restore from a completed backup. Backups and restore are read and executed live through worker-v3, which has Kubernetes access to the KubeBlocks cluster (the API layer does not).

Enabling backups

Backups are controlled by the backup field (enabled | disabled), set at create time and reflected on the database detail:

Field	Type	Notes
backup	string	enabled or disabled
backupsToKeep	number	How many backups to retain (retention count)

When enabled, backups run on a schedule and older backups beyond backupsToKeep are pruned.

Backup retention by plan

The maximum backup retention window scales with your plan:

Plan	DB backup retention (days)
Free	7
Pro	15
Premium	30
Enterprise	30

Listing backups

GET /v1/databases/:id/backups

Backups are read live by proxying to worker-v3. The response (DatabaseBackups) includes the backup schedule config and the list of backups:

{
  "success": true,
  "data": {
    "config": {
      "enabled": true,
      "method": "volume-snapshot",
      "cronExpression": "0 2 * * *",
      "retentionPeriod": "7d"
    },
    "items": [
      {
        "name": "app-db-backup-20260714",
        "status": "Completed",
        "method": "volume-snapshot",
        "totalSize": "512Mi",
        "startedAt": "2026-07-14T02:00:00.000Z",
        "completedAt": "2026-07-14T02:03:11.000Z",
        "expiresAt": "2026-07-21T02:00:00.000Z"
      }
    ]
  }
}

Backup config fields (DatabaseBackupConfig):

Field	Type	Notes
enabled	boolean	Whether scheduled backups are on
method	string (nullable)	Backup method reported by KubeBlocks
cronExpression	string (nullable)	The backup schedule
retentionPeriod	string (nullable)	Retention window

Per-backup fields (DatabaseBackup): name, status, method, totalSize, startedAt, completedAt, expiresAt — all nullable except name, so the UI shows - where no source reported a value.

Fail-safe reads

If worker-v3 is unreachable, the backups endpoint returns an explicit unavailable shape rather than fabricating data.

Restore from backup

POST /v1/databases/:id/restore

Restore is in-place from a completed backup. It overwrites the current data while keeping the database name, connection string, and any project links. It is:

• Destructive — the current data is replaced by the backup’s data.
• Paid only — RestoreDatabaseInput is gated to paid plans.
• Guarded by explicit confirmation — you must pass confirm: true.
• Blocked while another change is in flight — only one change at a time per database.

Request body (RestoreDatabaseInput):

Field	Type	Required	Notes
backupName	string	Yes	The name of a completed backup to restore from.
confirm	boolean	No (default false)	Must be true to proceed — this is destructive.

curl -X POST https://api.pandastack.io/v1/databases/903/restore \
  -H "Authorization: Bearer $PANDASTACK_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{ "backupName": "app-db-backup-20260714", "confirm": true }'

In the dashboard, restore requires a type-to-confirm step before it runs, matching the destructive nature of the operation.

Related

• Databases overview
• Create a database — enable backups at create time.
• Metrics — also read live via worker-v3.
• Plans & limits — backup retention by plan.