PocketBase keeps everything in a SQLite file, and its built-in backup takes a
snapshot of that file when you ask for one, or on a schedule. That's a good
backup. It's just not a good undo: when something goes wrong at 4:37 PM, the
snapshot you have is from whenever the last one ran.
Continuous Backup on PocketBase Cloud closes that gap. Every change to your
instance's database is copied off-site as it happens, and you can put the
database back to any moment in the last 7 days. This post covers how it works,
how to turn it on, what it covers, and what actually happens when you press
Restore. The 53-second version:
The gap a snapshot leaves
Data on a PocketBase app usually gets damaged in one of three ways: a
migration that does more than you meant, a hook with a bug that quietly writes
the wrong value on every update, or a person deleting the wrong thing in the
admin panel. None of these throw an error. You find out later.
With a nightly snapshot, "later" costs you twice. Restoring the 2 AM backup
brings the damaged data back, and throws away every signup, order and edit
written since 2 AM. So you either accept that loss or spend the afternoon
copying records across by hand.
What you actually want is the database as it was at 4:13 PM, the minute before
the mistake.
How it works
Continuous Backup is built on Litestream. SQLite
writes every change to a write-ahead log before it lands in the main database
file. Litestream reads that log and ships the changes to object storage on a
different machine from your instance, about once a minute. Snapshots are taken
periodically, and the changes in between are kept, so any moment in the
window can be rebuilt: the latest snapshot before that moment, plus every
change up to it.
Two consequences are worth knowing up front:
- Restore points follow your writes. A new point appears only when the database changes. If nobody has written to an instance since Tuesday, the newest point is from Tuesday, because Tuesday is the current state.
- It's close to live, not live. Changes leave the server about once a minute. When the data is wrong and the server is fine, which is the common case, that doesn't matter: you pick a moment before the mistake. If the server itself is lost, the last minute or so of writes may not have left it.
Turning it on
It's off by default and set per instance, so you choose which instances get
it.
In the portal: open the instance, click Backups in the sidebar, and
flip the switch on the Continuous Backup card. The badge changes from
Off to Replicating once changes are streaming off-site. If it ever says
Not replicating, the card offers Retry Replication.
From the terminal:
pbc pocketbase continuous-backup enable --name my-app Continuous backup enabled. And to check an instance:
pbc pocketbase continuous-backup status --name my-app Enabled: yes Running: yes Restorable: yes Running tells you changes are being copied right now. Restorable tells you
there are restore points to go back to. Leave out --name inside a folder
that's linked to an instance, and pbc uses that one.
What it covers
| Covered | Not covered |
|---|---|
| Records, collections and schemas | Uploaded files (images, documents, attachments) |
| Users, auth settings and API rules | Request logs and admin activity history |
| Instance settings and superuser accounts |
Uploaded files sit next to the database, not inside it, so a restore doesn't
roll them back. Keep taking the regular PocketBase backup for those (Settings
→ Backups in the PocketBase dashboard), or store files in an S3-compatible
bucket.
Restoring to a moment
Restore is in the portal only. On the same Continuous Backup card:
- Open Restore to a Point in Time.
- Pick a Day, then a Time from the restore points that exist.
- Click Restore Instance, and confirm in the dialog.
The dialog says exactly what's about to happen: the instance stops, its
database is replaced with the state from the moment you picked, and it starts
again. Records written after that moment are lost, uploaded files are not
rolled back, and it can't be undone.
There's no pbc command for this, on purpose. A restore throws away
everything after the moment you choose, so you should be looking at the
available restore points when you pick one, not typing a timestamp from
memory. The CLI's status command is enough to tell you whether there's
anything to restore.
When you confirm, the restore is careful about the one thing that matters,
which is never leaving the instance without a database:
- The current database is renamed aside first. It isn't deleted.
- The restore goes to the exact moment you picked. There's no "restore to latest", because mid-incident the latest point may already include the damage.
- The restored file is checked before the instance starts on it.
- If any step fails, the previous database is put back and the instance restarts as it was.
Good to know before you need it
- Turning it off deletes the restore points. Switching it off stops copying new changes and permanently deletes every restore point already stored. The portal asks you to confirm with Turn Off Backup first. Nothing is deleted from the running instance itself. If you might need the points, leave it on.
- Check the badge on the instances you care about. Because it's opt-in, an instance you never switched on has nothing to restore.
- It's for the database. Plan file backups separately, as above.
- Starter and Pro. Continuous Backup is included with both plans. If an instance moves off a paid plan, replication stops, but the restore points already copied stay restorable until they age out of the 7-day window. Upgrade again and it picks back up.
Try it
Pick the instance whose data would hurt the most to lose, turn Continuous
Backup on, and run pbc pocketbase continuous-backup status a minute later to
see it replicating. Step by step for the portal and the CLI:
Continuous Backup docs.
How do you handle this on your own PocketBase servers today: scheduled
snapshots, Litestream by hand, or something else? I'd like to hear what's
working for people.
