Backup and restore

Two things matter

The database. All your content, users, settings and memories.

ENCRYPTION_KEY. Without it, the credentials in a restored database cannot be decrypted. The backup still restores — every connector just has to be re-authenticated by hand.

Store ENCRYPTION_KEY somewhere other than the machine it runs on. A backup you cannot decrypt is a list of things you will have to redo.

Backing up

docker compose exec -T postgres \
  pg_dump -U lenshub lenshub | gzip > lenshub-$(date +%F).sql.gz

Nightly is right for most instances. Keep them somewhere the LensHub host cannot reach, so a compromise does not take the backups with it.

Attachments

Files pulled in by connectors live in the attachments volume. Back it up if you rely on them:

docker run --rm -v lenshub_attachments:/data -v "$PWD":/out \
  alpine tar czf /out/attachments-$(date +%F).tar.gz -C /data .

Everything else — clones, model files — is rebuildable and not worth backing up.

Restoring

docker compose down
docker compose up -d postgres
gunzip -c lenshub-2026-01-01.sql.gz | \
  docker compose exec -T postgres psql -U lenshub -d lenshub
docker compose up -d

Use the same ENCRYPTION_KEY as the instance that produced the dump.

Test it

An untested backup is a hope. Restore into a throwaway instance occasionally and confirm you can sign in and search — that exercises the whole chain rather than just the file existing.

What you do not need to back up

Container images, cloned repositories, downloaded model files. All re-fetched automatically.