Backups
This page explains what Bastide backs up from your database, how often and for how long depending on the tier, how a database is restored, and what does not exist yet. It separates the commitment of the price grid from what the code delivers today.
What is backed up, by tier
On the shared-cluster tiers, each database is backed up by a dump at every slot of its tier. Slots are aligned on UTC.
| Tier | Frequency | Retention | Status |
|---|---|---|---|
| Discovery | One dump a day, at midnight UTC | 7 days | Served |
| Standard | One dump an hour | Each dump for 48 hours, then the last of each day up to 30 days | Served |
| Pro | Continuous archiving, point-in-time recovery to the second (PITR) | 35 days | Not served yet |
| Sovereign | Continuous archiving and a synchronous replica | 90 days | Not served yet |
- A database unchanged since its last dump is not dumped again: the new slot points to the same dump. A dump is purged only when no retained slot points to it any more.
- Purging follows the schedule: a backup that has left its tier's schedule is removed, and no other.
- A Pro project lives on the shared cluster today, since no dedicated instance is served yet (see Database). Continuous archiving belongs to the dedicated instance, so a Pro project has no per-database dump: it is covered only by the cluster backup described below.
Beneath the dumps: the cluster backup
The whole cluster is copied as well: a full copy every week, a differential every day, and its write-ahead log. This layer keeps 30 days; the last full copy is never purged. It is used to rebuild a lost data node, not to return a single database to a chosen moment.
Off the machine
Every night, backups are copied off site, to another provider, encrypted before they leave: the key stays with the operator, never with the provider.
Restore drills
Every week, five databases are drawn at random, restored in an isolated environment, and checked against a logical checksum taken at dump time. A drill that does not report within 24 hours counts as a failure.
RPO and RTO
The price grid publishes a recovery point objective (RPO) and a recovery time objective (RTO) per tier:
| Tier | RPO | RTO |
|---|---|---|
| Discovery | 24 h | 4 h |
| Standard | 1 h | 2 h |
| Pro | 5 min | 30 min |
| Sovereign | 5 min | 30 min |
The RPO of Discovery and Standard follows from the dump frequency: at worst, you lose what was written since the last slot. The RPO of Pro and Sovereign assumes continuous archiving, which is not served yet. The RTO of a restored database is that of a restore carried out by the operator (below).
Restoring a database
There is no self-service restore: no screen and no tool lists a database's backup points or restores it. The deployment_restorable_list and deployment_rollback tools restore a release, not data (see Restore).
A database is restored by the platform operator, at your request, from one of its dumps. What the operation does:
- The dump is fetched and checked (size, fingerprint) before anything is written.
- The database is restored next to yours, under a temporary name your application cannot open, and checked against its dump's checksum.
- The switch closes the connections to your database, swaps the two names in one transaction, and your clients reconnect to the same name. Your database refuses connections for one or two seconds.
What the operation does not bring back:
- What you wrote after the dump. That is the loss your tier allows. The replaced database is kept aside for seven days: the operator can extract rows from it at your request.
- An arbitrary moment. Recovery to the second belongs to continuous archiving, not served yet.
- Storage objects. The files in your buckets are not restored with the database (see Storage).
Conseil. Before a risky operation, export what matters yourself: a read through
database_sql_reador the SQL editor, copied as CSV, or the exit archive described in Leave Bastide.
What does not exist yet
- Point-in-time recovery (PITR) and the synchronous replica of Pro and Sovereign.
- Self-service restore of a database, from the console or by an agent.
- A list of a database's backup points.
- The
database.backup.succeededanddatabase.backup.failedevents: they appear in the webhook catalogue but are not emitted yet. - Retention extended to 90 days as an option.
Common errors
- A migration destroyed data: ask the operator for a restore as soon as possible, giving the time of the migration. The longer you wait, the further the last earlier dump is from your last writes.
- You restored a release and your data did not change: that is expected,
deployment_rollbackdoes not touch the database.