Database Backups & Restore
TL;DR — Every managed cluster is backed up daily, automatically. Browse the backups on the Backups tab. Click Restore on any backup to open a pre-filled support ticket — our team performs the restore for you to guarantee data integrity.
How Backups Work
- Frequency: at least one automated full backup every 24 hours
- Retention: 7 days of daily backups (longer windows available — contact support)
- Coverage: full cluster snapshot — all logical databases, schemas, users, and configurations
- Storage: backups live in geographically separated object storage, isolated from the live cluster
- Encryption: backups are encrypted at rest with our keys
- Cost: included in your subscription — no extra charges
You don't have to do anything to enable backups. They start within hours of cluster provisioning.
View Available Backups
- Open your cluster
- Click the Backups tab
You'll see a table listing every backup with:
| Column | Description |
|---|---|
| Created At | When the backup completed (UTC) |
| Size | Backup size in GB (when reported by the engine) |
| Restore | Button to request a restore to this point |
The newest backup is at the top. Older backups roll out of the retention window automatically.
Request a Restore
Restores are performed by our engineering team. This is intentional — point-in-time restores are one-way operations, and our engineers verify destination capacity, lock the live cluster briefly, and confirm data integrity after the restore.
To request a restore:
- Find the backup you want to restore from
- Click Restore on that row
- A new support ticket is pre-filled with:
- Cluster name and ID
- Selected backup timestamp
- Default questions ("restore in place" vs "restore as a new cluster", any data you'd like preserved from the current state, downtime window)
- Add any extra context and submit
We'll typically respond within a few business hours and execute the restore in the agreed window.
Restore Modes
Tell us in the ticket which option you want:
- Restore in place — the live cluster is rolled back to the backup. Anything written after the backup is lost. Fastest, ideal when you know exactly what went wrong (e.g. accidental
DROP TABLE). - Restore as a new cluster — a brand-new cluster is provisioned from the backup. The live cluster is untouched. You can extract just the data you need, then point your app at the original cluster or the restored one. Requires an unused subscription plan.
Point-in-Time Recovery (PITR)
By default you can restore to any of the daily backup points. For tighter recovery objectives (e.g. "restore to 14:32 yesterday"), our enterprise tier supports continuous WAL archiving + arbitrary point-in-time recovery on PostgreSQL and MySQL. Contact support to enable.
Best Practices
- Don't rely on backups for non-destructive workflows. Use logical exports (
pg_dump,mysqldump) or read replicas for ad-hoc data extraction. - Test restores quarterly. Open a ticket for a "restore as a new cluster" once per quarter to verify your runbook.
- Snapshot before destructive deploys. Before a high-risk migration, request a manual backup (in a support ticket) and confirm it completed before running the deploy.
- Track your recovery point objective (RPO). With daily backups, your worst-case data loss is ≈ 24h. If you need < 1h RPO, enable PITR via support.
- Read replicas are not backups. Replicas replay the primary in near-real-time, including
DROP TABLE— they won't save you from accidental deletes.
Backups for Read Replicas
Read replicas are not backed up independently — they are continuous copies of the primary. Restoring the primary effectively restores the data shared with replicas (replicas will resync from the restored primary).
When Backups Are Unavailable
Backups appear in the list once at least one has completed. For new clusters, the first backup typically lands within 24 hours of provisioning. If the Backups tab is empty after that, contact support.
Troubleshooting
The backup I need rolled off the retention window
We may still have it in cold storage — open a support ticket with the date / time and we'll check.
The restore ticket was submitted hours ago and I haven't heard back
Check the ticket status in /cloudpanel/support. If it's outside business hours and not urgent, expect a response on the next business day. For critical production issues, mark the ticket as urgent.
Can I download a backup file?
Backups are stored in a proprietary format that requires our tooling to restore. We don't provide direct downloads, but we can restore into a new cluster from which you can take a logical dump (pg_dump, etc.) and download that.
Can I trigger a manual backup before a risky migration?
Yes — open a support ticket asking for an on-demand backup, and confirm it has completed before you deploy.