Database Backups
The platform backs up PostgreSQL and MariaDB databases automatically. There is nothing to enable or configure — backups are set up automatically as soon as the database is created.
What is backed up
- PostgreSQL — a full backup is taken as soon as the database is created, then every night, and every change in between is archived continuously.
- MariaDB — a full backup every night.
Backups are kept for 14 days. They are stored on the platform’s own storage, separate from the database itself, so they survive problems with the database’s instances.
Deleting a database deletes its backups too, usually within an hour — there is nothing to restore afterwards.
You don’t manage backups yourself: there is no backup command in the CLI and no backup panel in the dashboard. If you want to confirm which databases you have and which engine each one runs, list them:
paas dbs list -o acme -p shop -e production
What is not backed up
Redis and MongoDB databases are not backed up today.
- Treat Redis as disposable — a cache or queue whose contents you can afford to lose.
- For MongoDB, don’t keep data you can’t recreate without making your own copies. If you need an export, take one yourself from your application (for example with a one-off command — see Console & One-off Commands).
Durability and recovery
| Storage | Survives app replacement? | Platform recovery protection |
|---|---|---|
| App filesystem or process memory | No guarantee; not shared across replicas | No backup; use only for temporary or rebuildable data. |
| PostgreSQL | Yes | Continuous change archiving and nightly backups, retained 14 days; optional HA protects against instance/server failure. |
| MariaDB | Yes | Nightly backups, retained 14 days; single instance. |
| MongoDB | Yes | Single instance; no platform backups. Arrange your own copies for data you cannot recreate. |
| Redis | Yes, while Redis remains available | Single instance; no platform backups. Cache and queue contents can be lost with Redis. |
| Capacity bucket | Yes | Single-node storage; protects against disk failure, not whole-node loss. No platform backups. |
| High-availability bucket | Yes | Replication protects against node loss; it is not a recovery mechanism for accidental deletion or overwriting. |
High availability and backups solve different problems. Replication can replicate an accidental deletion too. Keep independent copies of irreplaceable objects; the platform does not offer an object-restore workflow. See bucket tiers.
Before deleting a database or Environment, export anything you need and verify the copy. Database deletion also deletes its platform backups; Environment deletion removes all its resources. A code rollback never restores database contents.
Restoring from a backup
Restores are not self-serve. To restore a database, contact your platform’s support. There is no restore button in the dashboard and no restore command in the CLI.
When you get in touch, include:
- the Organization, Project, and Environment (for example
acme/shop/production), - the database’s name (for example
shop-db), - the point in time you want to get back to — PostgreSQL can be restored to a point in time within the last 14 days; MariaDB is restored from the nearest nightly backup.
Next steps
- Databases — creating and managing database Resources
- Attaching a Database — wiring a database to an app
- Object Storage Buckets — durable file storage
- Troubleshooting & FAQ