Backup and restore
Everything Sentinel needs is in its PostgreSQL database: events, decisions, alerts, cases, rules, people, API key hashes, filings, attachments and the audit log. Redis holds only counters that are rebuilt from the database, and the configuration lives in your environment variables. Back up the database and you can rebuild the rest.
Take a backup
sentinel-admin db backup runs pg_dump against SENTINEL_DATABASE_URL and writes one compressed file.
docker exec sentinel /app/sentinel-admin db backup -out /backups/sentinel-2026-10-22.dump
The folder has to exist inside the container and be writable by it, so mount one with -v /backups:/backups when you start the container. Without -out it writes sentinel-<time>.dump to the current directory. The file is readable only by its owner. A failed dump leaves no file behind, so a half-written backup is never mistaken for a good one.
The container image carries the PostgreSQL 17 client tools. If your server is a newer major version, run the command on a host that has matching tools, since pg_dump refuses a server newer than itself.
You can also use your own database backups, such as a managed service's snapshots or continuous archiving. Those suit a tight recovery point. sentinel-admin db backup suits a scheduled dump, a copy before an upgrade, and moving an install.
Restore
Restore into an empty database, then start Sentinel against it.
docker exec sentinel /app/sentinel-admin db restore -in /backups/sentinel-2026-10-22.dump
It refuses a database that already has people or events, so a mistyped URL can't overwrite a live install. To replace one on purpose, add -replace. That drops and recreates every table in the dump, in a single transaction: if anything fails, the database is left as it was.
When the load finishes, the command walks every organisation's audit chain and prints the result:
restored /backups/sentinel-2026-10-22.dump
ok: 44 audit entries verified for default
ok: 3 audit entries verified for acme
If any chain doesn't match, it prints BROKEN, names the organisation and exits with an error. Don't put that database into service until you know why. See the audit log.
A dump from an older version restores fine. Start the newer version afterwards and it applies the migrations it is missing.
A schedule that works
| What | How often | Notes |
|---|---|---|
sentinel-admin db backup | At least daily | Copy the file off the machine that took it |
| A copy before every upgrade | Each time | See Upgrade and roll back |
| A restore test | Every quarter, and after changing the setup | Restore into a scratch database and check the audit result |
Disaster recovery
Decide two numbers with your compliance lead, and write them down:
- How much data you can lose (recovery point). A daily dump means up to a day. Continuous archiving of PostgreSQL brings it down to minutes.
- How long you can be down (recovery time). Time a restore of a recent backup on the hardware you would really use. That is your number, not an estimate.
To recover on new hardware:
Prepare
Install the same Sentinel version, or newer, with the same environment variables, and an empty database.
Restore
Run sentinel-admin db restore with the most recent good backup.
Check
Confirm the audit result, start Sentinel, sign in, and open a recent alert and a recent filing.
Replay
Events sent after the backup are not in it. Your services can resend them: an event with an idempotency_key Sentinel already has is returned as it was, and a new one is scored. See Idempotency.
Test this before you need it. A backup nobody has restored is a guess.