Backups
What is stored where, what the snapshot screen actually covers, and what to do on a schedule.
Backups are the part of an installation that is only judged once, and always at the worst possible moment. The short version: your data lives on the deployment, your settings live in the deployment too, and the panel can export both.
What is where
| Thing | Where it lives | How it is copied out |
|---|---|---|
| Accounts, projects, files, settings | The Convex deployment | The provider's own backup, and exports from the panel |
| Sealed tokens and keys | The deployment, encrypted | Exported as ciphertext, which needs the same SETTINGS_SECRET to read |
| Uploaded files | The deployment's file storage | Exports reference them; copy the storage as the provider describes |
| The code | This folder | Wherever you keep it. It is a folder, not a database |
Two of those are worth repeating: a snapshot without SETTINGS_SECRET restores an installation that cannot read
its own sealed tokens, and the code in this folder is the only piece you can lose without losing data.
The snapshot screen
System → Backups & exports does two different jobs, and mixing them up is how people end up with the wrong
kind of copy.
On a schedule
Before every update: a named snapshot, downloaded. Two minutes.
Weekly: a snapshot, downloaded to somewhere that is not this machine, and one export of the accounts list.
Monthly: confirm the provider's own backup of the deployment is enabled, and read the retention window on this screen.
Once: restore a snapshot into a throwaway installation and see it work. A backup nobody has restored is a hope.
Two actions on this screen lose something
Restore replaces what you have now, so anything changed since the snapshot is gone. Removing a snapshot deletes the only copy unless you downloaded it. Both ask for a typed confirmation, and neither can be undone from the panel.
What a snapshot is not
- It is not a copy of your users' uploaded files. Those are held in the deployment's file storage.
- It is not a copy of the code.
- It is not readable without the same
SETTINGS_SECRETas the installation it came from. - It is not a substitute for the provider's own backup of the deployment, which is the layer underneath all of this.
Recovering, in order of severity
| What happened | What to do |
|---|---|
| A setting was changed by mistake | Restore the most recent snapshot, then re-apply anything you meant to keep |
| A screen looks empty | Check System → Status & health first. Empty is usually unreachable, not lost |
| A table was cleared | Restore the snapshot, and read System → Audit log to see what else moved |
| Somebody deleted their account | Nothing restores that account alone. A full restore is all or nothing |
| The deployment is gone | Rebuild from the provider's own backup, then from the newest snapshot |
The list of what cannot be undone is short, and it is worth knowing
Deleting a person, clearing rows, restoring over something newer, and removing a snapshot. Everything else in the panel is reversible by changing it back, which is exactly why the audit log exists.