Backups_
Scheduled backups, manual backups, restores, and point-in-time recovery for your MySQL database.
3 min read
Native databases are backed up automatically. Backups are stored off the database instance and restorable from the API. For finer recovery granularity than scheduled backups, enable point-in-time recovery.
Automatic backups
Every database gets a default backup policy when it is provisioned, so you have scheduled backups from day one. You can adjust the default policy, or add more policies with different schedules and retention windows.
Backup policies
A policy defines a schedule (cron expression) and a retention period in days. Create one with:
| Parameter | Value | Description |
|---|---|---|
policyId | custom ID or unique() | Policy identifier |
name | text | Display name |
schedule | cron expression | When backups run, for example 0 3 * * * |
retention | days | How long backups from this policy are kept; 7 on Pro |
List, update, and delete policies with listBackupPolicies, updateBackupPolicy, and deleteBackupPolicy. Plan limits apply: Pro allows one policy with a daily schedule and 7-day retention.
Manual backups
Take an on-demand backup before a risky change:
The backup runs asynchronously with status pending until it completes. List backups and check their status with listBackups, or fetch one with getBackup.
Restore from a backup
Restoring replaces the database's current data with the backup's contents. The database status moves to restoring and returns to ready when the restore completes. Connections are still accepted while the restore runs, but data is replaced when it completes.
Track progress with getRestoration or the database status.
Everything written after the backup was taken is lost when you restore it. If you need the current state too, take a manual backup first, or use a branch to inspect data without touching the live database.
Point-in-time recovery
Scheduled backups recover to fixed snapshots. Point-in-time recovery (PITR) continuously archives the binary log, so you can restore to any moment inside the retention window, for example the second before a bad migration ran.
PITR is enabled by default when you create a database through the API, with 7 days of retention. Change it when creating the database, or later through the API:
pitrRetentionDays accepts 1 to 35 days. PITR is billed as an add-on on top of your specification; see pricing.
Check the recovery window
You can retrieve the time ranges you can restore to. Right after enabling PITR, no recovery window is available yet; the window opens once continuous archiving has captured its first segment.
Restore to a point in time
Pass an ISO 8601 timestamp inside the recovery window:
Like a backup restore, a PITR restore is in-place: the database is unavailable while restoring and everything after the target time is discarded.
Limits
| Limit | Value |
|---|---|
| Backup retention | 1 - 365 days |
| PITR retention | 1 - 35 days |
| Backup policies | Plan-dependent |
Was this page helpful?
Share what worked or what we should fix. Once approved, our agents automatically apply suggested updates to the docs.