Upgrade und Rollback

Ein Upgrade ersetzt das Binary; es migriert Sie nicht auf ein anderes Produkt. Das Data-Directory, der Audit-Signierschlüssel und das TLS-Material bleiben an ihrem Platz, und die Engine wendet neue Schema-Migrationen beim Boot selbst an. Diese Seite führt Betreiber vom „Soll ich dieses Release einspielen?“ bis zum „Ich brauche die vorige Version zurück“.

Zuerst sichern

Erstellen Sie vor jedem Upgrade mit dr backup des installierten Releases ein DR-Backup. Die Konsole unter Backups (/backups) und Sichern und wiederherstellen beschreiben das Verfahren. Nach einer Schemaerhöhung sind das Backup von vor dem Upgrade und seine private Passphrase oder sein KEK für die Rückkehr zum vorigen Release erforderlich. olivares upgrade sichert die ausführbare Datei, nicht die Datenbank.

Welcher Upgrade-Pfad ist Ihrer?

Es gibt vier Wege, das Binary vorwärtszubringen; alle führen zum selben Ziel.

Ihre Installation	Pfad
Ein deb-, rpm-, apk- oder AUR-Paket	Der Paketmanager. Aus einem Paket installieren
Binary auf einem Host, systemd (nicht aus einem Paket)	olivares upgrade — diese Seite
Ein Docker- oder Podman-Container	docker compose exec olivares olivares upgrade, danach den Container neu erstellen. Das Image kann sich nicht ändern; daher wird das Release im Datenvolume abgelegt (ota/ im Datenverzeichnis), und jeder Start des Image-Binary startet es, solange es neuer ist als das Image oder dieselbe Version anders gebaut ist. Wenn Sie ota/ entfernen, kehrt der Container zum Binary seines Images zurück. Docker und Compose enthält die Befehle.
Kubernetes / Helm	Setzen Sie das Image und lassen Sie den Operator den Rollout durchführen. Führen Sie olivares upgrade nicht in einem Pod aus: Die Bereitstellung ist deklarativ, und der nächste Reconcile würde die Änderung rückgängig machen.

Vor allem anderen: den Plan lesen

--check lädt das Channel-Manifest herunter, verifiziert es, vergleicht es mit der installierten Version und gibt aus, was geschehen würde. Es wird nichts ausgetauscht.

olivares upgrade --check

Die Ausgabe nennt die installierte und die verfügbare Version sowie eine Statuszeile: up to date, upgrade available, DOWNGRADE (blocked unless --force-rollback) oder UNKNOWN. Lesen Sie die Statuszeile, statt die beiden Versionsnummern selbst zu vergleichen.

UNKNOWN bedeutet nicht „wahrscheinlich in Ordnung“. Die installierte Version konnte nicht ermittelt werden — etwa bei einem Staging-Verzeichnis für eine andere Architektur, einem noexec-Mount oder einem Build aus dem Quellcode. Sowohl der Anti-Rollback-Schutz als auch das Mindestversions-Gate treffen Aussagen über die installierte Version und können daher nicht ausgewertet werden. Der Befehl verweigert den Vorgang, statt zu raten. Geben Sie die bekannte Version an; dann bleiben die Schutzmechanismen aktiv:

olivares upgrade --check --current-version 0.4

Release-Channels

olivares upgrade folgt einem Release-Channel. Es gibt 3; sie sind in core/release/manifest.go nach steigender Stabilität deklariert:

Wert für --channel	Deklariert als
stable	release.ChannelStable
security	release.ChannelSecurity
lts	release.ChannelLTS

Ein Wert außerhalb dieser Tabelle wird abgelehnt, bevor etwas heruntergeladen wird (release.ValidChannel).

stable ist die allgemein verfügbare Linie und der Standard. security enthält ausschließlich außerplanmäßige Sicherheitskorrekturen. Eine Bereitstellung auf diesem Channel erhält daher Sicherheits-, aber keine Feature-Releases.

lts wird validiert, aber nicht veröffentlicht

Die Tabelle oben wird aus den im Code deklarierten Channel-Konstanten erzeugt und listet daher jeden von --channel akzeptierten Wert — einschließlich lts. Es wird kein lts-Manifest erzeugt oder veröffentlicht. Eine Bereitstellung auf diesem Channel fragt den Update-Host daher nach einem nicht vorhandenen Objekt. Security-Support gilt nur für die Vertragslaufzeit und umfasst keine allgemeinen Backports; es gibt keine eingefrorene Linie. Ansprüche gelten für die bezahlte Laufzeit, ohne erworbenen Fallback und ohne unbefristetes Recht. Wählen Sie stable oder security.

Wählen Sie den Channel, der zu Ihrem Betrieb passt, und bleiben Sie dabei:

olivares upgrade --channel security

Ein Security-Release ist im Manifest entsprechend markiert, und --check gibt die behobenen Advisories aus. Auf dem Security-Channel erhalten Sie diese außerhalb der GA-Linie.

Upgrade durchführen

olivares upgrade

Auf einer Paketinstallation (deb, rpm, apk, AUR) wird das mit Exit-Code 2 abgelehnt, bevor etwas heruntergeladen wird: Nutzen Sie den Paketmanager, wie die Tabelle oben zeigt. --check zeigt weiterhin den Plan.

Der Befehl führt der Reihe nach folgende Schritte aus:

1. Er lädt das Channel-Manifest herunter und verifiziert dessen Signatur offline gegen den im Build eingebetteten Ed25519-Release-Schlüssel. Der Trust Anchor ist die Signatur, nicht der Transport. Bei einem Build ohne eingebetteten Schlüssel müssen Sie mit --pubkey einen bereitstellen; es gibt keinen unverifizierten Pfad.
2. Er verweigert den Rückwärtsgang. Eine ältere als die laufende Version wird nur mit --force-rollback installiert; der Override erzeugt einen Audit-Eintrag.
3. Er bindet das Artefakt an den signierten SHA-256 des Manifests, bevor die Bytes ausgeführt werden.
4. Er prüft den Kandidaten und tauscht ihn anschließend atomar aus. Dabei bleibt ein mit Zeitstempel versehenes Backup des ersetzten Binary erhalten. Läuft das neu installierte Binary nicht, stellt der Befehl dieses Backup selbst wieder her.
5. Er lässt den laufenden Prozess unangetastet. Der Austausch ändert die Datei auf der Platte. Der neue Code übernimmt nach dem Neustart des Dienstes.

Fügen Sie --yes hinzu, wenn ein Skript den Vorgang steuert und niemand die Bestätigungsfrage beantworten kann.

Der automatische Rollback in Schritt 4 prüft version, nicht den Dienststart oder die Datenbankkompatibilität. Er stellt keinen beim nächsten Neustart migrierten Store wieder her.

Kein Hot-Patching

Ein Go-Binary wird nicht im laufenden Prozess gepatcht. „Zero Downtime“ bedeutet hier Graceful Drain und Übergabe oder einen Rolling Restart — niemals einen In-Process-Patch. Ohne Neustart werden hingegen Daten und Konfiguration live wirksam: Sources, Connectors, Secrets, Policy und Lizenz.

Air-Gap-Installationen

Eine Air-Gap-Bereitstellung erreicht niemals einen Update-Host. Übertragen Sie das Bundle mit einem bereits vertrauenswürdigen Verfahren und installieren Sie es aus der lokalen Datei. Die Verifikation ist identisch, denn dem Netzwerk wurde nie vertraut.

Offline-Installation erfordert Enterprise. Community prüft ein Bundle mit --bundle --check, ohne eine Lizenz zu lesen oder es zu installieren.

olivares upgrade --bundle ./olivares-release.tar.gz --check

Gestaffelter Rollout und unbeaufsichtigte Prüfungen

Ein Manifest kann eine Kohorte für den gestaffelten Rollout benennen, sodass ein Release zunächst nur einen Teil der Estate erreicht. Mit --if-eligible handelt ein Node nur dann, wenn er dieser Kohorte angehört; andernfalls geschieht nichts:

olivares upgrade --if-eligible --yes

In dieser Form läuft der eingebaute Timer. Um einen systemd-Timer samt Dienst auszugeben, der den Befehl innerhalb eines Wartungsfensters aufruft:

olivares upgrade --install-timer --timer-schedule 'Sun *-*-* 03:00:00'

Standardmäßig gibt der Befehl die Units aus; --timer-dir schreibt sie in das von Ihnen angegebene Verzeichnis. Das ist opt-in — nichts plant sich selbst ein.

Bei einer Paketinstallation verweigert der Befehl das: /usr/bin/olivares gehört dem Paketmanager, daher endet er mit dem Exit-Code 2, schreibt keine Unit und nennt den Weg: den Paketmanager des Hosts, auf der Olivares-Appliance systemctl start olivares-appliance-update.service. Mit --enterprise --connect nennt er zusätzlich olivares license connect refresh. Die Prüfung erfolgt über den Pfad; eine Binärdatei, die install.sh --bindir /usr/bin dort abgelegt hat, wird also ebenfalls verweigert.

Die Konsole bietet die schreibgeschützte Hälfte derselben Information: Settings → update status ruft POST /v1/console/update-check auf und führt bei Bedarf eine Prüfung gegen den konfigurierten Channel aus. Eine Air-Gap-Bereitstellung oder eine ohne konfigurierten Channel antwortet mit 501 und nennt den Grund, statt zu melden, es gebe kein Update.

Upgrade verifizieren

olivares version
olivares upgrade --check

--check sollte jetzt up to date melden. Prüfen Sie anschließend den Dienst selbst: in der Konsole unter Health (/health) oder über den Readiness-Endpunkt der Engine aus Mit Prometheus überwachen.

Rollback

Die vorige ausführbare Datei bleibt neben ihrem Ersatz erhalten; der Befehl gibt ihren Pfad aus. Diese Kopie ist kein Wiederherstellungspunkt für Ihre Daten.

Ein älteres Binary verweigert eine Core-Schemaversion, die neuer ist als die von ihm unterstützte, auch nach additiven Migrationen. Das alte Binary oder Image zurückzuspielen macht die Schemaerhöhung nicht rückgängig. Ändern Sie weder die Migrationshistorie noch den Schutz.

1. Stoppen Sie alle Engines am Store. Bewahren Sie die aktualisierten Daten, Dienstkonfiguration, das TLS-Material und externe Sealer-Schlüssel auf.
2. Stellen Sie mit dem Binary des vorigen Releases das DR-Bundle von vor dem Upgrade wieder her: Sichern und wiederherstellen. SQLite: frisches Datenverzeichnis oder dr restore --in-place mit --operator und --reason; bewahren Sie die automatisch gesicherten Dateien bis zur bestätigten Wiederherstellung auf. PostgreSQL: leeres Ziel mit olivares db init, dessen --dsn, --owner-dsn und --admin-dsn sowie ein frisches Verzeichnis für den wiederhergestellten Signierschlüssel verwenden.
3. Ledger und Audit-Schlüssel müssen erfolgreich verifiziert sein. Richten Sie Datenverzeichnis, Volumes und PostgreSQL-DSNs des Dienstes auf den wiederhergestellten Store und die passenden Signierschlüssel aus, bevor Sie das vorige Release starten.
4. Melden Sie sich an und prüfen Sie die wiederhergestellten Daten und den Dienstzustand.

Die Wiederherstellung kehrt zum gesicherten Zeitpunkt zurück. Spätere Schreibvorgänge fehlen; bewahren Sie den aktualisierten Store zum Abgleich auf. Ohne das Bundle und seine Passphrase oder seinen KEK ersetzt die ausführbare Datei keine Wiederherstellung.

--force-rollback erlaubt die Installation eines älteren Binary und protokolliert den Override im Audit-Log. Es umgeht weder die Core-Schemaprüfung noch das Mindestversions-Gate und stellt keine Daten wieder her. Unterhalb der Mindestversion ist ein Zwischenrelease erforderlich.

Wiederherstellung vor dem Produktionsupgrade testen

Starten Sie das verifizierte vorige Release mit einem temporären SQLite-Datenverzeichnis, führen Sie Setup und Anmeldung durch, stoppen Sie es und erstellen und verifizieren Sie mit seinem dr backup und dr verify ein Bundle. Starten Sie den Kandidaten auf demselben Store, melden Sie sich an und stoppen Sie ihn. Nach einer Schemaerhöhung über die unterstützte Version muss das vorige Release mit core schema version newer than this binary supports fehlschlagen. Stellen Sie das Bundle mit dem vorigen dr restore in ein frisches Verzeichnis wieder her. Verlangen Sie Exit null und erfolgreiche Ledger-Verifikation; starten Sie dort das vorige Release und prüfen Sie Anmeldung, ursprünglichen Audit-Public-Key und gesicherte Daten. Ein fehlgeschlagener Restore oder eine fehlgeschlagene Anmeldung bedeutet einen fehlgeschlagenen Test.

Gemessene SQLite-Wiederherstellung (2026-10-08): Das offizielle Release 26.10.1 erstellte Core-Schema 18, ein neuerer Kandidat erhöhte es auf 27. Das alte Binary verweigerte den Store mit Exit 1 (database=27 binary=18). Seine dr backup, dr verify und dr restore beendeten sich mit Code 0. Nach Wiederherstellung des Bundles von vor dem Upgrade in ein frisches Verzeichnis funktionierten die ursprüngliche Anmeldung und der ursprüngliche Audit-Public-Key.

Wenn etwas schiefgeht

Symptom	Bedeutung	Maßnahme
--check gibt UNKNOWN aus	Die installierte Version konnte nicht ermittelt werden, daher ist keine Aussage über die Reihenfolge möglich	Übergeben Sie mit --current-version die bekanntermaßen installierte Version
min_ver meldet eine zu alte Version	Das Release verweigert die direkte Installation über Ihrer Version	Aktualisieren Sie zuerst auf das genannte Zwischenrelease
Die installierte Datei besteht die version-Prüfung nach dem Austausch nicht	Die Prüfung der ausführbaren Datei ist fehlgeschlagen	Der Befehl stellt die gesicherte Datei wieder her; prüfen Sie die Logs
Dienststart nach dem Neustart fehlgeschlagen oder Core-Schema zu neu für das alte Binary	Das liegt außerhalb der Prüfung der ausführbaren Datei	Dienst stoppen und gemäß Rollback das DR-Bundle von vor dem Upgrade wiederherstellen
--install-timer löst aus, aber nichts geschieht	Der Node gehört nicht zur Kohorte des gestaffelten Rollouts	Mit --if-eligible ist das erwartet; die Kohorte wird im Verlauf des Rollouts erweitert
“another olivares upgrade is already installing”, exit 5	Je Binary kann nur ein Upgrade laufen. Die Sperre gilt für die gesamte Download-und-Austausch-Sequenz	Warten Sie auf den laufenden Vorgang und starten Sie erneut. Läuft nichts mehr, hat der Kernel die Sperre bereits freigegeben; starten Sie jetzt erneut
“it CHANGED while this upgrade was downloading”	Nach der Planung hat etwas anderes das Binary ersetzt — Paketmanager, Image-Rollout oder Konfigurationsverwaltung	Starten Sie erneut: Die Schutzmechanismen werden gegen die tatsächlich installierte Datei neu ausgewertet. Wiederholt sich das, verwalten zwei Systeme dasselbe Binary

Ein Upgrade-Agent pro Binary. olivares upgrade hält während der gesamten Prepare-Download-Swap-Sequenz eine exklusive Sperre auf dem Ziel. Ein zweiter Lauf beendet sich daher mit 5, statt zu installieren. Installieren Sie einen Timer und ändern Sie darin --channel, statt je Channel einen Timer zu betreiben: Zwei Installationen, die in derselben Sekunde endeten, konnten früher das Rollback-Backup der jeweils anderen überschreiben; der automatische Rollback des Verlierers stellte dann das andere Binary wieder her und meldete Erfolg. Unmittelbar vor dem Austausch liest der Befehl außerdem die Bytes des Ziels erneut und verweigert den Vorgang, wenn sie nicht der eingeplanten Datei entsprechen. Anti-Rollback- und Mindestversionsurteile beziehen sich auf eine konkrete installierte Datei.

Für alles Weitere ist Fehlerbehebung der allgemeine Einstieg; die Konsole zeigt unter Logs (/logs) den eigenen Log-Stream der Engine.