Backup & Restore
What to back up in a self-hosted Rivet cluster, and how to restore it into a new cluster.
Backups protect against bucket loss or accidental deletion. Replication across control plane instances protects recent writes against a limited number of disk failures; it does not replace a backup.
What to back up
| What | Where | How |
|---|---|---|
| Tiered Rivet Actor data | The bucket | Turn on bucket versioning, and object lock or replication to a second bucket where your provider has it |
| Configuration | Your config files or manifests | Keep them in version control |
| Rivet token and bucket credentials | Your secret store | Back up the secret store |
Each instance’s log disk holds its identity and recent writes, including acknowledged writes that have not reached the bucket. Preserve these disks during maintenance. The separate read cache is disposable. Bucket protection alone does not back up recent log data.
What a backup does not cover
A bucket backup holds what had reached the bucket when it was taken. Writes that were only on the instances’ disks are not in it. If every instance and its disk is lost at once, the most recent writes are lost with them.
Restore
Restoring a bucket into a fresh cluster has not yet been validated for this release. Do not treat a successful /health response as proof that Actor data was restored. Keep the original bucket and log disks available until recovery has been verified.
Before relying on a backup, test recovery in an isolated cluster with a separate bucket or prefix. Verify namespace and pool configuration, Actor state, SQLite rows, and key-value data against known records, including the most recent acknowledged writes. A procedure must account for data still on log disks and for a consistent point in the bucket’s history.
Never start a second cluster against a bucket that the original cluster is still using. Bucket versioning preserves individual objects; it does not by itself guarantee a consistent cluster snapshot.