Backups & Recovery

Sentinel runs as a container with persistent storage, so there are two ways to back it up.

Standard volume backup tools

Snapshot the entire persistent volume using whatever tooling your platform already provides (e.g. your cloud provider's disk/volume snapshots). On Azure App Services specifically, this means backing up the Azure Files share mounted at /data — see Install on Azure App Services.

This covers everything on the volume, including uploaded files.

Built-in database snapshots

Sentinel can also snapshot just its database(s) and upload them to remote storage on a schedule.

You can snapshot the main database (users, API keys, Security Groups, etc.) and/or Redis (short-lived data like rate-limiter state) independently.

Manual backups

In the admin app: Admin → Snapshots → Create Snapshot. Or via the API:

POST /v1/admin/snapshots/create

Automated snapshots

Set a cron schedule and destination:

Variable	Purpose
`SNAPSHOTS_MAIN_SCHEDULE`	Cron schedule for main-database snapshots (e.g. `0 2 * * *`). Disabled if unset.
`SNAPSHOTS_REDIS_SCHEDULE`	Cron schedule for Redis snapshots. Disabled if unset.
`SNAPSHOTS_STORAGE_PROVIDER`	`local`, `s3`, or `azure`.
`SNAPSHOTS_DB_PREFIX`	Path prefix for stored snapshots.
`SNAPSHOTS_ENCRYPTION_KEY`	Optional encryption key applied to snapshots.

Snapshot storage is configured independently from your file storage provider — you can send snapshots and uploads to different destinations. See the ENV Variables reference for the full list of SNAPSHOTS_STORAGE_* variables per provider.

Restoring a snapshot

In the admin app: Admin → Snapshots → Restore Snapshot, enter the remote snapshot's URI, and click Restore — the server reloads once the restore completes. Or via the API:

POST /v1/admin/snapshots/restore

Databases — engines also provide their own native backup/PITR tooling independent of Sentinel's built-in snapshots.
Storage Providers — configuring S3/Azure/local storage for uploads.
ENV Variables — full snapshot configuration reference.