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

​
Goal

Create and restore durable recovery points without confusing backup retention with short-lived transfer artifacts.

​
Prerequisites

  • A managed database
  • Database backup storage, encryption, and role-specific recovery credentials configured by the platform

​
Workflow

1
Open Backups and create or inspect a durable recovery point.
2
Confirm artifact completion, timestamps, checksum evidence, and restore-test status.
3
Restore only from a completed backup.
4
Verify connectivity and application behavior through the stable endpoint after restore.

​
Choose backup or Import / Export

Backups protect recovery and retention. Import / Export moves complete logical SQL between systems. They use different buckets, role credentials, database records, validation evidence, and expiry policies. Deleting a transfer cannot delete or weaken a backup, and a transfer export should not be treated as a recurring backup policy.
  • Use Backups to recover from data loss or a failed change and to maintain platform-controlled recovery points.
  • Use Import / Export to download portable SQL or load an external .sql or .sql.gz dump.
  • Use an import candidate when you need to inspect external data before explicitly replacing active contents.

​
Create and verify a backup

  • Wait for the durable capture operation and artifact verification to complete.
  • Review size, timestamp, checksum, encryption/retention state surfaced by the product, and restore-test evidence where available.
  • A completed capture proves an artifact was stored; a passed restore test is stronger recovery evidence but still does not prove application behavior.

​
Restore, then verify

Restore only from an eligible completed backup and confirm engine/version compatibility and the intended recovery timestamp. A finished platform operation is not the same as application-level correctness. Reconnect through the stable hostname, verify TLS and access policy, and smoke-test critical reads and writes.

​
Retention and deletion

Backup retention follows recovery policy and object-storage controls, not the transfer workflow’s 24-hour artifact lifecycle. Backup deletion cannot bypass a retention lock. Likewise, early transfer purge cannot shorten a retained generation’s rollback window.

​
Clone, restore, and import candidate

  • Clone creates a parallel copy for staging or testing where supported.
  • Backup restore recovers from a platform recovery artifact.
  • SQL import creates a hidden private candidate, validates it, and waits for explicit promotion.

​
Expected result

The database has a durable recovery point whose capture and restore evidence is understood independently from Import / Export.

​
Common failures

  • Backup restore is not configured because storage, encryption, or restore-reader configuration is incomplete.
  • Restoring from an incomplete or failed backup.
  • Assuming a completed capture has been restore-tested or application-tested.
  • Mixing the dedicated backup bucket or credentials with the independent database transfer bucket.
  • Using an older agent that does not implement the required backup/recovery endpoint.

Import and export a database

Move complete PostgreSQL or MySQL databases as portable SQL with resumable uploads, private candidates, structural validation, explicit promotion, and 24-hour rollback.

Database troubleshooting

Diagnose provisioning, stable connectivity, backup, upload, export, validation, promotion, download, rollback, and cleanup failures.

Create a database

Provision a managed database with the right engine, size, context, access, and hosted V2 expectations.

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.