Restore points and checkpoints
What each restore point covers — server, application, and service — and exactly which files a server checkpoint includes.
Restore points and checkpoints
A restore point is a moment you can go back to. strackt keeps them automatically and lets you save your own before a risky change. The Protection page for a server, application, or service lists every restore point for that one thing, newest first.
The most common restore point is a checkpoint — a point-in-time snapshot of the data. You'll see two kinds:
- Automatic checkpoints — taken on a schedule (hourly, daily, monthly). strackt manages these; older ones are tidied up over time.
- Saved checkpoints — ones you create yourself, with a label, before doing something you might want to undo.
Each page covers one thing
This is the part that's easy to miss: a restore point only covers the thing whose page you're on. Checkpoints don't overlap, so each kind of data is protected on its own page.
| Where you are | What its checkpoints cover |
|---|---|
| A server's Protection page | The server's shared files and settings |
| An application's Protection page | That app's deployed code and its files |
| A service's Protection page (database, cache) | The data stored inside that service |
So an "Automatic · Hourly checkpoint" on a server page is an hourly checkpoint of that server's shared data — not of your apps or databases. Those have their own hourly checkpoints on their own pages.
The "Protected" summary at the top of each page names what's covered and roughly how much data a restore point holds, e.g. Server data and settings — about 876 MB.
What a server checkpoint includes
A server checkpoint captures the folders that hold the server's shared state — the things that aren't tied to a single application:
- Home folders (
/home) — files belonging to the accounts on the server. - Served files (
/srv) — content the server serves that isn't part of a managed application. - System and service state (
/var) — server-level data and logs, including data for services that store their files here.
A server checkpoint does not include:
- Your applications' code and files — each application has its own restore points on its Protection page.
- Your databases and other services — each service has its own restore points on its Protection page.
This split is deliberate: it keeps each app and each database independently restorable, so rolling back one never disturbs the others.
What an application checkpoint includes
An application checkpoint covers that one environment's deployed code and the files it has written — uploads, generated assets, and anything stored on disk for that app. Production, staging, and preview are checkpointed independently, so restoring staging never touches production.
What a service checkpoint includes
A service checkpoint covers the data held by that service — for a database, every table and row it stores; for a cache, its stored contents.
Restoring to a point
Pick a restore point and choose Restore. Restoring data overwrites the current data in place, so strackt pauses new deploys until you confirm you're happy and Resume. Settings and release rollbacks are reversible and don't lose data.
If a restore doesn't complete
Now and then a restore can't finish. When that happens, the data on the server is left as it was — a restore that stops part-way doesn't leave you with a half-restored mix. What it means is simply that you're still on the current data, not the restore point you picked.
What to do:
- Check the server is online and healthy. A restore needs the server it runs on to be reachable and not in the middle of another operation. If the server's page shows it offline or busy, sort that out first.
- Try the restore again. Most restore hiccups are transient — a brief blip while the data is put back — and a second attempt from a clean state usually goes through.
- Pick a nearby restore point if one won't take. Restore points sit close together in time, so an adjacent one gets you to almost the same place if a particular one keeps failing.
If a restore keeps failing on a healthy server, reach out — this is one we'd rather work through with you than have you keep retrying. For a copy that survives losing the server entirely, set up an off-server backup (below).
Going further back: off-server backups
Checkpoints live on the server itself, so they're fast but tied to that machine. For copies that survive losing the server, set up an off-server backup — see Backups. When one is configured, the Protection page shows an Off-server backups section you can restore from.
Was this helpful?