Skip to content
Ophiolite docs

Recovery and moves

Backup

Section titled “Backup”
Terminal window
./ophiolite-ops backup nightly-2026-09-28
./ophiolite-ops copy-out nightly-2026-09-28.tar.gz     # to this directory, for your off-host copy

The server is stopped for the backup and started again afterwards. The archive holds the project database, the stored files and records of every exact version, the configuration and a manifest with a checksum for every file, the list of data sources and the records of the 2026.10.1 catalog move. Tokens, the sign-in document, connection targets and the connection key are not in it; the operator keeps them (./ophiolite-ops connection-key export connection.key, see Install).

Restore

Section titled “Restore”

Restore into an empty deployment: a new directory with its own compose.yaml, config.json and secrets (or the same directory after docker compose down -v).

Terminal window
docker compose up -d postgres
./ophiolite-ops copy-in nightly-2026-09-28.tar.gz
./ophiolite-ops restore nightly-2026-09-28

The archive is checked completely before anything is written. A restore into a deployment that already has data is refused. While a restore runs the deployment carries a marker; if the restore is interrupted the server will not start until you remove the deployment (docker compose down -v) and restore again. People sign in with the tokens they already have.

In a new directory, configure what the backup does not carry before people sign in through the identity provider or use stored connections:

Terminal window
./ophiolite-ops configure sign-in sign-in.json          # identity links are in the database already, for the same issuer
./ophiolite-ops connection-key import connection.key    # before configure connection-admin
./ophiolite-ops configure connection-admin targets.json

A restored deployment whose data holds stored database credentials starts without creating a key: Add a source shows that the connection key is missing and that no database is approved, and configure connection-admin refuses to make a new key that could not read those credentials. Import the key you exported from the original deployment first; then configure the targets and restart.

Identity links belong to one sign-in provider (its issuer). If the restored deployment signs in through a different provider — another issuer URL, for example a second evaluation provider on its own port — every provider sign-in is refused until you link each person again with ./ophiolite-ops link-identity USER SUBJECT using the subjects of the new provider.

Move a project to another deployment

Section titled “Move a project to another deployment”

A move transfers the project: afterwards the destination accepts changes and the origin keeps serving reads but refuses changes. People are mapped explicitly; the destination must already have every mapped person as a member.

Terminal window
# destination
./ophiolite-ops identity                                   # note the printed identity
# origin
./ophiolite-ops export-project --project geoscience --out move-1 --transfer \
    --target <destination identity> --target-project geoscience
./ophiolite-ops copy-out move-1
# destination: map.json is {"<origin person>": "<destination person>", ...}
./ophiolite-ops copy-in move-1 && ./ophiolite-ops copy-in map.json
./ophiolite-ops import-project --package move-1 --project geoscience \
    --identity-map /backups/map.json --authority transfer

An import whose map leaves out a person the project names is refused and changes nothing.