Handbook

English

Deutsch

English

Deutsch

Appearance

Updates and backup ​

Updates ​

An update is a new Nova image. On start, Nova brings the database schema up to date itself: it creates new tables and columns and runs data migrations. There is no separate migration step. Migrations only run forwards – the way back is the backup taken before the update.

Docker Compose: install the new release files, then run

bash
docker compose -f deploy/docker-compose.yml --env-file deploy/.env up -d --build app

Compose rebuilds the image and replaces the Nova container; the database keeps running. Optionally, a systemd timer takes care of updates: deploy/autodeploy.sh checks a Git branch every five minutes and rebuilds when it changes. The directory is then used for operation only; the script resets any local changes in it.

Kyma: build the new image with a new tag and push it to the registry, enter the tag in deployment.yaml, apply the file and wait for kubectl rollout status. The Recreate strategy stops the old instance before the new one starts; Nova is briefly unavailable in the meantime.

Work in progress during a restart ​

  • Jobs that were running during the restart are marked as failed by Nova on the next start.
  • Provisioning runs interrupted by the restart are resumed by Nova on the next start, provided their execution plan was stored.
  • Scheduled job times that fall into the downtime are not caught up; the job runs at its next regular time.

Backing up the database ​

Nova stores its data in the PostgreSQL database – identities, assignments, configuration, logs and job runs. Nova does not keep any data in the container itself. A backup is therefore an ordinary PostgreSQL backup of the Nova database. Example for Docker Compose; the command reads the user and database name from the database container's environment:

bash
DC="docker compose -f deploy/docker-compose.yml --env-file deploy/.env"

# back up
$DC exec -T db sh -c 'pg_dump -U "$POSTGRES_USER" -Fc "$POSTGRES_DB"' > nova-$(date +%F).dump

# restore: stop Nova, load the backup, start Nova
$DC stop app
$DC exec -T db sh -c 'pg_restore -U "$POSTGRES_USER" -d "$POSTGRES_DB" --clean --if-exists' < nova-2026-09-27.dump
$DC start app

In Kyma, the same commands run in the PostgreSQL pod, for example kubectl -n nova-iam exec postgres-0 -- sh -c 'pg_dump -U "$POSTGRES_USER" -Fc "$POSTGRES_DB"' > nova.dump. A fresh backup before every update is advisable.

Configuration export ​

In addition, Nova offers administrators a configuration export as a JSON file through the interface GET /api/config/export. It contains target systems with redacted secrets, roles, business roles with their members, SoD rules, approval workflows and settings. It does not contain identities, assignments or logs, so it does not replace the database backup. The import through POST /api/config/import – with ?dry_run=1 as a trial run – currently applies only the SoD rules.

Keeping the key safe ​

NOVA_ENCRYPTION_KEY is not stored in the database but in deploy/.env or in the Kubernetes secret. Nova uses this key to encrypt stored secrets, such as passwords and client secrets of target and source systems or the SMTP password. The database backup contains these values in encrypted form only.

  • Without the key – or with a different one – the stored secrets cannot be decrypted; they then have to be entered again.
  • Nova offers no key rotation for existing data. Do not replace the key of an existing installation.
  • If the variable is missing, Nova does not fall back to a temporary key: operations that encrypt or decrypt a stored secret stop with an error message.

Keep it separate

Keep the key, together with SECRET_KEY and the database password, separate from the database backups, for example in a password vault. A backup can only be fully restored with the matching key.

Nova IAM