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 every volume. 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 one app back as it was last night, without touching the rest.
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. Turn on backups is the one-click version: daily, kept 30 days. The first recovery point appears at the next scheduled time, or immediately if you trigger one by hand.
Every volume in the project is included; there is nothing to opt into. klickops picks the method itself: a storage snapshot where the cluster supports it, a file copy otherwise. While backups are on, the project's volume storage is billed once more at the backup rate.
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.
A restore always puts the chosen items back in place: everything written to them since the recovery point is lost, and there is no undo. Take a fresh backup first if you might want today's data back, and narrow the restore to the app or volume you need so the rest keeps running. Databases are not part of it; they restore from their own page.
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 | 30 days | 7, 30, 90 or 365 days, before recovery points age out. |
| Method | automatic | A storage snapshot where the cluster supports it, a file copy of every volume otherwise. |
| Restore scope | whole project | Narrow to named apps or volumes. |
Limits and gotchas
- A recovery point that saved no disk data is flagged. The page warns about points that finished without copying any files and will not restore from them, since that would leave your volumes empty.
- Backups are only as good as the last restore you tried. Restore one unimportant app once, on purpose, before you need it for real.
- Every restore overwrites what is there. Items outside the scope keep running, but the ones you restore lose everything written since the recovery point.
- A volume newer than the recovery point is not in it. A whole-project restore leaves such a volume running, and restoring it on its own, or the app it belongs to, is refused rather than deleting it with nothing to put back.
- One restore at a time. While a restore runs, another one that touches the same app, the same volume or the whole project is refused until the first finishes or you abort 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.
- Backups run at most once an hour. Through the CLI or the API the cadence can also be a cron schedule, as long as it names a single minute. Retention tops out at 365 days.
Deleting a project deletes its backup schedule and recovery points with it. If you are cleaning up something that might matter later, restore what you need first, or export it.