Backup and recovery
What BlixtFS stores, what needs backing up, and how to recover from the loss of a server or its database.
What lives where
| Data | Where | Back up? |
|---|---|---|
| File contents | Your bucket | Use your provider’s tools: versioning, replication, retention policies |
| Metadata index | PostgreSQL (in /data/postgresql for single node) |
Yes |
| Written data not yet uploaded | Write log in /data (single node) or the write tier (scale-out) |
Protected by replication in scale-out; drained by a clean shutdown |
| Chunk cache | /data/cache |
No: rebuilt from the bucket |
| Configuration | Your config file, values file, or environment | Keep it in version control, without secrets |
Backing up the database
For an external PostgreSQL, use its normal backup method: managed-service
snapshots, pg_dump, or continuous archiving.
For the embedded database in the single-node image, back up /data while
BlixtFS is stopped, or use pg_dump inside the running container. The
embedded database listens on port 4710:
docker exec -e PGPASSWORD=bfs blixt \
pg_dump -h localhost -p 4710 -U bfs bfs > blixt-$(date +%F).sql
Recovering
A server is lost, its data directory survives
Start a new container with the same data directory and configuration. BlixtFS resumes where it left off, including pending uploads.
The data directory is lost
Start BlixtFS with an empty data directory, and restore the database backup if you have one. Without a backup, BlixtFS indexes the buckets again from scratch:
- Every file and directory in the bucket comes back, with its contents.
- Metadata that only the index holds is lost: ownership, permissions and timestamps changed through BlixtFS, and files written but not yet uploaded when the disk was lost.
A file was deleted or overwritten by mistake
BlixtFS writes directly to your bucket, so recover the object with your provider’s own features, such as S3 or GCS object versioning or soft delete. Once the object is restored in the bucket, BlixtFS picks it up through change notifications or the next consistency check.
Turn on object versioning (or your provider’s soft-delete feature) for buckets that people edit through BlixtFS. It is the simplest protection against accidental deletes and overwrites.