Skip to main content
Live. This area is documented as current, user-reliable behavior.

​
Goal

Restore a database confidently without assuming legacy AWS/EBS behavior.

​
Prerequisites

  • A managed database
  • S3 backup storage configured on the control plane

​
Workflow

1
Create or inspect completed backups from the database view.
2
Restore only from a completed backup.
3
Verify connectivity and application behavior after restore.

​
What backups cover

Database backups are S3-backed snapshots taken on the control plane — not the older AWS/EBS model some stale docs describe. Manual backups are a plan feature, and backup testing lets you validate a backup is restorable before you depend on it.

​
Restore, then verify

  • Only restore from a completed backup; the database moves through a restoring state during recovery.
  • After restore, verify connectivity with the current credentials and check application behavior.
  • A finished restore means the data is back — confirm the app actually works rather than trusting the status alone.

​
Clone vs restore

Restore recovers a database from one of its backups. Clone makes a separate copy of a database (a plan feature) — useful for spinning up a staging or test copy without touching the original. Reach for clone when you want a parallel copy, and restore when you need to recover.

​
Expected result

Database backup and recovery behavior is predictable and grounded in the current implementation.

​
Common failures

  • S3 backup storage is not configured on the control plane, so backups cannot be created.
  • Restoring from an incomplete or failed backup.
  • Manual backups or clone are unavailable on the current plan.

Database troubleshooting

Common issues around provisioning, connectivity, backup configuration, and restore progress.

Create a database

Provision a managed database and understand the minimum runtime and recovery expectations around it.

Recovery states, logs, and troubleshooting

Read the operation state on a resource — its status, current step, attempt count, retryable flag, and last error — together with logs, instead of treating a single “error” badge as the whole story.