Updates und Backups¶

Versionen¶

Die Container-Images liegen in der GitHub Container Registry. Ein einziges IMAGE_TAG in der .env gilt für alle drei:

Für den Betrieb empfehlen wir eine Release-Version, damit jedes Update eine bewusste Entscheidung ist. Versionierung, Release-Rhythmus und Supportzeiträume regelt die Release- und Support-Politik.

Aktualisieren mit update.sh¶

./update.sh                  # auf latest
./update.sh --tag v0.11.0    # auf eine bestimmte Version
./update.sh --tag dev        # Entwicklungsstand (instabil)
./update.sh --dry-run        # nur prüfen, nichts ändern
./update.sh --rollback       # zurück auf die Version vor dem letzten Update

So läuft ein Update:

1. Das Skript prüft, ob es das Ziel-Tag für alle drei Images gibt, und bricht sonst ab, bevor es etwas ändert.
2. Es bietet eine Sicherung mit ./backup.sh an und merkt sich die bisherige .env als .env.pre-update.
3. Liegt die Installation in einem Git-Repository, holt es den neuesten Stand des aktuellen Zweigs.
4. Es zieht die neuen Images; die laufenden Dienste arbeiten weiter.
5. Ingestor, Protokoll-Orchestrator und Worker halten während der Migrationen an. Die verträglichen Migrationen laufen vor dem Umschalten in einem eigenen Container (safemigrate), ebenso die der Website.
6. Die Worker starten mit dem neuen Image vor der Anwendung (Migration, dann Worker, dann Web). Danach tauscht das Skript die Container der Anwendung und der Website; Caddy hält Anfragen währenddessen kurz an.
7. Eine Anwendungsprüfung im Container ruft unter anderem Bereitschaft, Anmeldeseite, Bürgerportal und OParl-System ab. Scheitert sie, schaltet das Skript selbst auf das vorherige Image zurück.
8. Zum Schluss spielt es die übrigen Migrationen ein und startet Ingestor und Protokoll-Orchestrator mit dem neuen Image.

Welche Dienste während der Migrationen stehen, legt WORKER_SERVICES fest (Vorgabe: ingestor minutes-orchestrator worker worker-heavy worker-live). Wer einen weiteren Dienst in einer eigenen Compose-Datei betreibt, ergänzt ihn dort, zum Beispiel WORKER_SERVICES="ingestor minutes-orchestrator worker worker-heavy ocr-worker" in der .env.

Für nicht interaktive Updates (Betrieb, Automatisierung) gibt es deploy/scripts/deploy.sh mit derselben Prüfung und demselben Rückfall, Beschreibung in DEPLOYMENT.md im Repository.

Sicherung mit backup.sh¶

./backup.sh schreibt ein Archiv nach ./backups/; die letzten sieben bleiben liegen. Der Installer richtet dafür einen täglichen Lauf um 02:00 per Crontab ein (./backup.sh --quiet).

Ein unvollständiger Lauf (Uploads nicht lesbar, Passphrase-Datei fehlt) schreibt das Archiv trotzdem, endet aber mit Exit-Code 1 und räumt dann keine alten Archive auf.

Konfiguration nur verschlüsselt¶

Die .env enthält alle Schlüssel, darunter den ENCRYPTION_MASTER_KEY. backup.sh legt sie deshalb nur verschlüsselt ins Archiv (openssl enc -aes-256-cbc -pbkdf2 -iter 600000 -md sha256). Die Passphrase kommt aus BACKUP_PASSPHRASE (nur Umgebung) oder aus der ersten Zeile der Datei BACKUP_PASSPHRASE_FILE (Vorgabe ./.backup-passphrase). Ohne Passphrase fehlt die Konfiguration im Archiv, und jeder Lauf warnt.

(umask 077; openssl rand -base64 32 > .backup-passphrase)
./backup.sh --verify

Verwahren Sie die Passphrase zusätzlich außerhalb des Servers, etwa in einem Passwort-Manager. Für eine Wiederherstellung auf einem neuen Server wird sie gebraucht.

Wiederherstellen¶

./backup.sh --restore backups/mandari_backup_<zeit>.tar.gz

Das Skript liest zuerst das ganze Archiv und entschlüsselt die Konfiguration; scheitert eins davon, bricht es ab, ohne etwas zu verändern. Nach einer Rückfrage stoppt es die Dienste, setzt die Konfiguration ein, spielt jede Datenbank zuerst in eine Zwischen-Datenbank ein und tauscht sie erst danach aus. Vor dem Start des Workers hebt es die Folgenummer der Ereignistechnik an (events_after_restore --apply), spielt Uploads und Dokument-Cache zurück, startet alle Dienste, führt migrate aus und baut den Suchindex neu auf.

Auf einem neuen Server genügt: Docker installieren, Repository klonen, Archiv und Passphrase bereitstellen und direkt ./backup.sh --restore … aufrufen, ohne vorher install.sh auszuführen. Danach die tägliche Sicherung wieder eintragen:

0 2 * * * cd /opt/mandari && ./backup.sh --quiet >> /opt/mandari/logs/backup.log 2>&1

Spielen Sie eine Wiederherstellung regelmäßig in einer Testumgebung durch; erst sie zeigt, dass die Sicherung taugt.

Verschlüsselte Sicherung an zwei Standorten (restic)¶

Für den Produktivbetrieb liegt im Repository unter deploy/backup/ ein eigener Sicherungsdienst mit restic. Er läuft als Container neben der Installation und sichert täglich verschlüsselt in zwei Repositorys an getrennten Standorten, per SFTP (ein reiner SFTP-Speicher genügt).

restic verschlüsselt vor der Übertragung; das Zielsystem sieht nur verschlüsselte Blöcke. Das restic-Passwort ist der Schlüssel zu allen Sicherungen und gehört zusätzlich außerhalb des Servers verwahrt. Einrichtung, Bedienung und Wiederherstellung beschreibt docs/BACKUP.md im Repository.

Was in jede Sicherung gehört¶

Elasticsearch muss nicht gesichert werden, der Index lässt sich aus der Datenbank neu aufbauen.