Backups and recovery
Scheduled recovery points for a project, and how to get one piece back without disturbing the rest.
On this page
What it is
A recovery point is a copy of a project taken at a moment in time: the workloads, their configuration, and the contents of the volumes that opted in. klickops takes them on a schedule you set and keeps them for as long as you say.
Backups are configured per project rather than per workload, because a restore that brings back an app without the volume it writes to is not a restore.
When you'd use it
- Somebody deleted the wrong thing.
- A deploy corrupted data and you need yesterday.
- You want a copy of production to poke at, without touching production.
A backup is not a database backup. PostgreSQL keeps its own write-ahead logs and restores to the second, which is finer than anything here. See Databases. This page covers everything around it.
Turn it on
- Open the project and go to Backups.
- Pick a cadence: hourly, every six hours, daily, or weekly. Daily runs at 02:00.
- Set how long to keep them.
- Save. The first recovery point appears at the next scheduled time, or immediately if you trigger one by hand.
Volumes are not included until you say so. Each volume has its own backup setting, so a cache volume costs nothing while the uploads volume is protected. That is deliberate: protected storage is billed, and most projects have volumes worth nothing.
Restoring
A restore is scoped. You choose what comes back:
- The whole project. Everything in the recovery point.
- One app. Its resources and the volumes it mounts.
- One volume. Just that disk, by name.
You also choose what happens to what is there now. A restore can come back under a new name, so the original keeps running and you compare the two. That is almost always the right first move when you are unsure, and it is the difference between recovering and gambling.
Progress runs live on the page, step by step, and a restore can be aborted while it works.
Settings reference
| Setting | Default | What it does |
|---|---|---|
| Cadence | off | hourly, 6h, daily (02:00), or weekly. |
| Retention | none | How long recovery points are kept before they age out. |
| Volume backup | off, per volume | fs copies the files, snapshot uses the storage layer where the cluster supports it. |
| Restore scope | whole project | Narrow to named apps or volumes. |
| Restore as new name | off | Brings the copy back beside the original instead of over it. |
Limits and gotchas
- A volume without backup is not in the recovery point. The project schedule does not silently cover it. Check each volume that holds something you would miss.
- Backups are only as good as the last restore you tried. Do a restore-as-new-name once, on purpose, before you need one for real.
- Restoring over the original is destructive. That is what the option means, and there is no second undo behind it.
- Retention deletes. A recovery point past its retention is gone, so retention is a decision about worst-case data loss and not a tidiness setting.
Deleting a project deletes its recovery points with it. If you are cleaning up something that might matter later, restore what you need first, or export it.