Updates und Sicherung
Updates
Ein Update ist ein neues Image von Nova. Beim Start bringt Nova das Datenbankschema selbst auf den neuen Stand: Es legt neue Tabellen und Spalten an und führt Datenmigrationen aus. Einen eigenen Migrationsschritt gibt es nicht. Die Migrationen laufen nur vorwärts – für den Weg zurück dient die Sicherung von vor dem Update.
Docker Compose: den neuen Programmstand einspielen, dann
docker compose -f deploy/docker-compose.yml --env-file deploy/.env up -d --build appCompose baut das Image neu und ersetzt den Container von Nova; die Datenbank läuft weiter. Optional übernimmt ein systemd-Timer das Update: deploy/autodeploy.sh prüft alle fünf Minuten einen Git-Zweig und baut bei Änderungen neu. Das Verzeichnis dient dann nur dem Betrieb; lokale Änderungen darin setzt das Skript zurück.
Kyma: das neue Image mit neuem Tag bauen und in die Registry laden, das Tag in deployment.yaml eintragen, die Datei anwenden und kubectl rollout status abwarten. Die Strategie Recreate beendet die alte Instanz, bevor die neue startet; Nova ist währenddessen kurz nicht erreichbar.
Laufende Arbeit bei einem Neustart
- Jobs, die während des Neustarts liefen, markiert Nova beim nächsten Start als fehlgeschlagen.
- Provisionierungsläufe, die der Neustart unterbrochen hat, nimmt Nova beim nächsten Start wieder auf, sofern ihr Ausführungsplan gespeichert ist.
- Termine geplanter Jobs, die in die Ausfallzeit fallen, holt Nova nicht nach; der Job läuft zum nächsten regulären Termin.
Datenbank sichern
Nova speichert seine Daten in der PostgreSQL-Datenbank – Identitäten, Zuweisungen, Konfiguration, Protokolle und Jobläufe. Im Container selbst legt Nova keine Daten ab. Eine Sicherung ist deshalb eine gewöhnliche PostgreSQL-Sicherung der Nova-Datenbank. Beispiel für Docker Compose; Benutzer und Datenbankname liest der Befehl aus der Umgebung des Datenbank-Containers:
DC="docker compose -f deploy/docker-compose.yml --env-file deploy/.env"
# sichern
$DC exec -T db sh -c 'pg_dump -U "$POSTGRES_USER" -Fc "$POSTGRES_DB"' > nova-$(date +%F).dump
# wiederherstellen: Nova anhalten, Sicherung einspielen, Nova starten
$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 appIn Kyma laufen dieselben Befehle im PostgreSQL-Pod, etwa kubectl -n nova-iam exec postgres-0 -- sh -c 'pg_dump -U "$POSTGRES_USER" -Fc "$POSTGRES_DB"' > nova.dump. Vor jedem Update ist eine frische Sicherung sinnvoll.
Konfigurationsexport
Zusätzlich bietet Nova Administratoren über die Schnittstelle GET /api/config/export einen Konfigurationsexport als JSON-Datei. Er enthält Zielsysteme mit geschwärzten Geheimnissen, Rollen, Business-Rollen samt Mitgliedern, SoD-Regeln, Genehmigungsabläufe und Einstellungen. Identitäten, Zuweisungen und Protokolle enthält er nicht; die Datenbanksicherung ersetzt er also nicht. Der Import über POST /api/config/import – mit ?dry_run=1 als Probelauf – übernimmt derzeit nur die SoD-Regeln.
Den Schlüssel sicher aufbewahren
NOVA_ENCRYPTION_KEY liegt nicht in der Datenbank, sondern in deploy/.env bzw. im Kubernetes-Secret. Mit diesem Schlüssel verschlüsselt Nova gespeicherte Geheimnisse, etwa Kennwörter und Client-Secrets der Ziel- und Quellsysteme oder das SMTP-Kennwort. Die Datenbanksicherung enthält diese Werte nur verschlüsselt.
- Ohne den Schlüssel – oder mit einem anderen – lassen sich die gespeicherten Geheimnisse nicht entschlüsseln; sie müssen dann neu eingegeben werden.
- Einen Schlüsselwechsel für bestehende Daten bietet Nova nicht. Den Schlüssel einer bestehenden Installation daher nicht austauschen.
- Fehlt die Variable, weicht Nova nicht auf einen temporären Schlüssel aus: Vorgänge, die ein gespeichertes Geheimnis ver- oder entschlüsseln, brechen mit einer Fehlermeldung ab.
Getrennt aufbewahren
Den Schlüssel zusammen mit SECRET_KEY und dem Datenbankkennwort getrennt von den Datenbanksicherungen aufbewahren, etwa in einem Passwort-Tresor. Eine Sicherung ist nur mit dem passenden Schlüssel vollständig wiederherstellbar.