---
title: Selbst gehostetes Claude Managed Agents aktualisieren
url: https://platform.claude.com/docs/de/managed-agents/self-hosted/upgrade
description: Aktualisiere eine selbst gehostete Claude-Managed-Agents-Bereitstellung auf Kubernetes oder Docker Compose und führe ein Rollback durch, wenn das neue Release nicht funktioniert.
---
Um Zugriff auf selbst gehostetes Claude Managed Agents anzufordern, kontaktiere dein Anthropic-Account-Team.
Diese Seite zeigt, wie du eine Bereitstellung auf Kubernetes oder Docker Compose aktualisierst und wie du ein Rollback durchführst. Auf Kubernetes hängt die Ausfallzeit davon ab, wie weit das Upgrade reicht:
| Upgrade | Zuerst die Datenbank sichern | Ausfallzeit auf Kubernetes |
| --------------------------------------------------------------------------------------- | ---------------------------------------- | -------------------------------------------------------------------------------------------------- |
| Patch: Nur die dritte Zahl ändert sich | Nein. Das Datenbankschema bleibt gleich. | Keine |
| Minor: Die zweite Zahl steigt um eins, etwa von `1.2.0` auf `1.3.0` | Ja. Das Schema ändert sich. | Keine, es sei denn, ein Abschnitt in `CHANGELOG.md` besagt, dass die Server gestoppt werden müssen |
| Überspringt ein Minor-Release, etwa von `1.1.0` auf `1.3.0`, oder ändert die erste Zahl | Ja. Das Schema ändert sich. | Ab dem Moment, in dem du die alten Server stoppst, bis die neuen bereit sind |
Ein Docker-Compose-Stack ist bei jeder Art von Upgrade während des Neustarts nicht verfügbar.
## Vor dem Upgrade
Lies den Abschnitt des neuen Releases in `CHANGELOG.md`, ganz oben im entpackten Archiv. Er beginnt mit den Upgrade-Schritten, die speziell für dieses Release gelten. Wenn du Releases überspringst, befolge jeden Abschnitt, der neuer als deine Version ist, beginnend mit dem ältesten.
Geh dann [Zu prüfende Einstellungen und Pfade](https://platform.claude.com/docs/de/managed-agents/self-hosted/upgrade#settings-and-paths-to-check) durch.
Ein Minor- oder Major-Upgrade beinhaltet ein Datenbank-Backup. Der Dump enthält jede Unterhaltung im Klartext, daher verschlüsseln die Befehle auf dieser Seite ihn mit dem [age-Verschlüsselungstool](https://age-encryption.org). Erstelle einmalig ein Schlüsselpaar und bewahre den privaten Schlüssel, `cma-backup.agekey`, getrennt von den Backups auf:
```bash
age-keygen -o cma-backup.agekey
age-keygen -y cma-backup.agekey > cma-backup.agepub
```
## Upgrade auf Kubernetes
Die `kubectl`-Befehle auf dieser Seite lesen den Namen des Deployments des Servers aus einer Shell-Variablen. Führe diese zwei Zeilen in jedem Terminal aus, in dem du die Befehle ausführst. Die erste Zeile ermittelt den Namen, und die zweite gibt ihn aus:
```bash
server=$(kubectl -n cma-server get deployment -l anthropic.com/role=server -o jsonpath='{.items[*].metadata.name}')
echo "$server"
```
Wenn die zweite Zeile `cma-server` ausgibt, fahre fort. Wenn ein anderer Name ausgegeben wird, lies vor dem Upgrade [die Namen deiner Objekte](https://platform.claude.com/docs/de/managed-agents/self-hosted/upgrade#object-names). Wenn nichts ausgegeben wird, prüfe, ob `kubectl` auf den richtigen Cluster zeigt, und führe die zwei Zeilen erneut aus.
Entpacke das neue Archiv. Baue und pushe seine drei Images unter der neuen Version, wie in [Die Images bauen und pushen](https://platform.claude.com/docs/de/managed-agents/self-hosted/kubernetes#build-and-push-the-images) beschrieben. Wenn du das [Egress-Gateway](https://platform.claude.com/docs/de/managed-agents/self-hosted/agent-identity#environment-variable-credentials) betreibst, baue und pushe auch dessen Image.
Wenn du ein eigenes Sandbox-Image baust, baue und pushe es ebenfalls neu, unter der neuen Version. Vergleiche sein Dockerfile mit `kubernetes/sandbox/Dockerfile` im neuen Archiv und lies nach, [was ein eigenes Image braucht](https://platform.claude.com/docs/de/managed-agents/self-hosted/call-the-api#what-an-image-of-your-own-needs).
Wenn eine Values-Datei `image.tag` setzt, ändere den Wert auf die neue Version.
Führe diesen Schritt nur in diesen Fällen aus:
* Ein Server, den du betreibst, liegt mehr als ein Minor-Release hinter dem neuen Release zurück.
* Die erste Zahl, die Major-Version, steigt.
* Ein Abschnitt in `CHANGELOG.md`, der neuer ist als das Release, das du betreibst, besagt, dass die Server gestoppt werden müssen.
Von diesem Schritt an, bis die neuen Server bereit sind, können Clients die Bereitstellung nicht erreichen. Plane daher ein Wartungsfenster ein.
```bash
kubectl -n cma-server scale deployment/$server --replicas=0
kubectl -n cma-server wait --for=delete pod -l anthropic.com/role=server --timeout=90s
```
Tu dies vor einem Minor- oder Major-Upgrade oder wenn du die Server gestoppt hast. Wenn das alte Release nicht mit dem geänderten Schema laufen kann, ist dieses Backup der einzige Weg zurück.
Verwende `pg_dump` aus derselben Hauptversion von PostgreSQL wie dein Datenbankserver. Verwende für `` und `` die Werte `user` und `dbname` aus `database.url` in `cma-server-values.yaml`. `pg_dump` fragt nach dem Passwort der Rolle.
```bash
set -o pipefail
PGSSLMODE=require pg_dump -h -U -d -Fc \
| age -r "$(cat cma-backup.agepub)" -o cma_server-.dump.age
```
Wenn einer der beiden Befehle einen Fehler ausgibt, ist die zurückgelassene Datei kein Backup. Behebe die Ursache und führe den Befehl erneut aus, bevor du fortfährst.
Wenn die Server laufen, enthält das Backup nur, was Clients vor Beginn des Dumps geschrieben haben.
Führe diese Befehle im obersten Verzeichnis des neuen Archivs aus und verwende dabei die Values-Dateien deiner Installation:
```bash
helm upgrade cma-server kubernetes/server/chart --namespace cma-server -f cma-server-values.yaml --wait
helm upgrade cma kubernetes/chart --namespace cma -f cma-values.yaml --wait
```
Wenn du mehr als eine Umgebung betreibst, führe den zweiten Befehl für jedes Sandbox-Release aus, mit dem Namen, dem Namespace und der Values-Datei des jeweiligen Releases.
Wenn du die Server gestoppt hast, migriert der erste Befehl das Schema, stellt die Serveranzahl wieder her und kehrt zurück, sobald die neuen Server bereit sind.
Bei laufenden Servern startet Helm jeden neuen Server, bevor es einen alten stoppt, sodass die Anzahl der bereiten Server nie sinkt. Bei einem Minor-Upgrade ändert der erste Befehl das Schema, während die alten Server weiterhin Anfragen bedienen, und ersetzt sie danach. Ein offener Event-Stream auf einem Server, der ersetzt wird, endet sauber, sodass ein Client, der einem Stream folgt, sich neu verbinden muss.
Wenn ein Befehl fehlschlägt, lies [Wenn das Upgrade fehlschlägt](https://platform.claude.com/docs/de/managed-agents/self-hosted/upgrade#if-the-upgrade-fails).
## Upgrade auf Docker Compose
Die Schritte sind für jede Art von Upgrade gleich. Führe jeden `docker compose`-Befehl im Compose-Verzeichnis eines Release aus, also in dem Verzeichnis, das `docker-compose.yml` enthält. Im entpackten Archiv ist das das Verzeichnis `compose`. Verwende ein Terminal, in dem `ANTHROPIC_BASE_URL`, `ANTHROPIC_API_KEY` und `ANTHROPIC_AUTH_TOKEN` nicht gesetzt sind, denn Compose übergibt die Werte dieser Variablen aus der Shell an den Server.
Tu dies vor einem Minor- oder Major-Upgrade im Compose-Verzeichnis des alten Release:
```bash
set -o pipefail
docker compose exec -T postgres sh -c 'pg_dump -U "$POSTGRES_USER" -d "$POSTGRES_DB" -Fc' \
| age -r "$(cat cma-backup.agepub)" -o cma_server-.dump.age
```
Lass `$POSTGRES_USER` und `$POSTGRES_DB` im Befehl unverändert. Der Text in einfachen Anführungszeichen läuft im Container `postgres`, der die Namen seiner Rolle und seiner Datenbank in diesen Variablen hält.
Der Stack bedient während des Backups weiterhin Anfragen, daher fehlt im Dump, was Clients nach Beginn des Dumps schreiben. Wenn einer der beiden Befehle einen Fehler ausgibt, ist die zurückgelassene Datei kein Backup. Behebe die Ursache und führe den Befehl erneut aus, bevor du fortfährst.
Lege das neue Archiv in ein Verzeichnis, in dem das neue Release bleiben kann, etwa das übergeordnete Verzeichnis des alten Release. Die Befehle entpacken das Archiv dort, und der neue Stack läuft aus den entpackten Dateien.
Wenn deine umask strenger als `022` ist, führe zuerst `umask 022` aus. Führe dann Folgendes im Compose-Verzeichnis des alten Release aus. Schreibe anstelle von `` den vollständigen Pfad des Verzeichnisses, das das neue Archiv enthält. Schreibe anstelle von `` den Namen des Archivs ohne `.tar.gz`.
```bash
releases=""
tar -xzf "$releases/.tar.gz" -C "$releases" && cp .env compose.config.yaml "$releases//compose/"
```
Die zweite Zeile kopiert außerdem deine `.env` und `compose.config.yaml` in das entpackte Verzeichnis `compose`. Der alte Stack läuft während beider Zeilen weiter. Wenn eine Zeile einen Fehler ausgibt, behebe die Ursache und führe beide Zeilen erneut aus.
Nur `.env` und `compose.config.yaml` werden übernommen. Nimm deine anderen Änderungen im Compose-Verzeichnis des neuen Release erneut vor:
* **Eine Datei, die du hinzugefügt hast:** Kopiere sie.
* **Eine mitgelieferte Datei, die du bearbeitet hast:** Nimm dieselbe Bearbeitung in der Kopie des neuen Release vor. Kopiere die alte Datei nicht darüber, denn damit machst du die Änderungen des Release an der Datei rückgängig.
* **Agent-Identität:** Kopiere das Verzeichnis `agent-identity` mit `cp -a`, mit `sudo`, wenn es root gehört, und bearbeite den Block `volumes:` von `docker-compose.yml` erneut.
* **Eine eigene Compose-Datei:** Kopiere sie und prüfe ihre relativen Pfade.
Nimm dann die Docker-Compose-Änderungen unter [Zu prüfende Einstellungen und Pfade](https://platform.claude.com/docs/de/managed-agents/self-hosted/upgrade#settings-and-paths-to-check) vor.
Führe diese Zeilen in dem Terminal aus, in dem du das Archiv entpackt hast, denn sie verwenden dessen Variable `$releases`. Bleib im Compose-Verzeichnis des alten Release und schreibe denselben Namen anstelle von ``. Wenn du `COMPOSE_FILE` für den alten Stack exportiert hast, exportiere zuerst denselben Wert.
```bash
ls "$releases//compose/.env" && docker compose down
cd "$releases//compose" && docker compose up --build -d
```
Die erste Zeile stoppt den alten Stack nur, wenn die `.env` des neuen Release vorhanden ist. `docker compose down` behält die Datenbank bei. Füge kein `-v` hinzu, denn das löscht sie. Der neue Stack übernimmt die Datenbank, und sein `migrate`-Container aktualisiert das Schema, bevor der Server startet.
Wenn ein Befehl fehlschlägt, lies [Wenn das Upgrade fehlschlägt](https://platform.claude.com/docs/de/managed-agents/self-hosted/upgrade#if-the-upgrade-fails).
## Wenn das Upgrade fehlschlägt
Finde vor einem Rollback die Ursache im Log:
* **Kubernetes:** Wenn der Migrations-Job fehlschlägt, wartet `helm upgrade` einige Minuten, während der Job es erneut versucht, und schlägt dann fehl. Führe während dieser Wartezeit in einem zweiten Terminal `kubectl -n cma-server logs job/$server-migrate` aus, mit `$server` gesetzt wie unter [Upgrade auf Kubernetes](https://platform.claude.com/docs/de/managed-agents/self-hosted/upgrade#upgrade-on-kubernetes). Kubernetes löscht das Log, wenn der Job keine weiteren Versuche mehr unternimmt. Wenn du es verpasst hast, führe `helm upgrade` erneut aus, wodurch der Job erneut startet.
* **Docker Compose:** Die Ausgabe von `docker compose up --build -d` zeigt möglicherweise nicht den Grund. Führe `docker compose logs` aus, um ihn zu finden.
| Was das Log zeigt | Was das bedeutet | Was zu tun ist |
| ----------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Eine Zeile, die `refusing to migrate: servers of another release are still running against this database` enthält | Manche Upgrades erfordern, dass zuerst alle Server gestoppt werden, und ein Server des alten Releases läuft noch. Die Migration hat nichts geändert. | Stoppe alle Server wie unter [Upgrade auf Kubernetes](https://platform.claude.com/docs/de/managed-agents/self-hosted/upgrade#upgrade-on-kubernetes) und führe `helm upgrade` erneut aus. Wenn ein Server nicht sauber heruntergefahren wurde, warte zuerst 20 Sekunden: Bis dahin zählt die Migration diesen Server noch als laufend. |
| Eine Zeile, die `cannot downgrade` enthält, wenn du das alte Release erneut bereitstellst | Das alte Release kann nicht mit dem geänderten Schema laufen. | Stelle das Backup wieder her, wie unter [Rollback](https://platform.claude.com/docs/de/managed-agents/self-hosted/upgrade#roll-back) beschrieben. |
| Ein anderer Fehler der Migration | Du musst kein Rollback durchführen. Auf Kubernetes bleiben die Server, wie sie waren, bis die Migration erfolgreich ist. | Behebe die Ursache und führe `helm upgrade` oder `docker compose up --build -d` erneut aus. |
Die Migration kann erfolgreich sein, während die neuen Server nicht bereit werden. Um die Ursache zu finden, lies das Log der Server:
* **Kubernetes:** `kubectl -n cma-server logs -l anthropic.com/role=server --prefix --tail=20`
* **Docker Compose:** `docker compose logs cma-server`
Auf Kubernetes nennt zum Beispiel eine Zeile, die `has invalid keys` enthält, eine Einstellung unter `server.config`, die das neue Release nicht akzeptiert. Behebe die Ursache und führe den Upgrade-Befehl erneut aus, bevor du eine Wiederherstellung in Betracht ziehst, denn bei einer Wiederherstellung gehen Daten verloren. Sobald sich auf Kubernetes das Schema geändert hat, bedient ein laufender Server des alten Releases weiterhin Anfragen, startet aber möglicherweise nicht erneut, wenn er stoppt.
## Rollback
Die `kubectl`-Befehle in diesem Abschnitt verwenden die Variable `$server` aus [Upgrade auf Kubernetes](https://platform.claude.com/docs/de/managed-agents/self-hosted/upgrade#upgrade-on-kubernetes). Prüfe vor einem Rollback [Wenn das Upgrade fehlschlägt](https://platform.claude.com/docs/de/managed-agents/self-hosted/upgrade#if-the-upgrade-fails). Führe das Rollback dann je nach Art des Upgrades durch:
* **Nach einem Patch-Upgrade:** [Das alte Release erneut bereitstellen](https://platform.claude.com/docs/de/managed-agents/self-hosted/upgrade#deploy-the-old-release-again). Beide Releases verwenden dasselbe Schema.
* **Nach einem Minor- oder Major-Upgrade:** Öffne `CHANGELOG.md` im neuen Archiv. Lies den Abschnitt jedes Release, das nach dem Release erschienen ist, zu dem du zurückkehrst.
* Wenn ein Abschnitt besagt, dass das alte Release nicht mit der migrierten Datenbank starten kann, stelle das Backup wieder her.
* Andernfalls stelle das alte Release erneut bereit. Wenn das mit `cannot downgrade` fehlschlägt, stelle das Backup wieder her.
Bei einer Wiederherstellung geht alles verloren, was Clients nach Beginn des Backups geschrieben haben.
### Das alte Release erneut bereitstellen
* **Kubernetes:** Wechsle in das oberste Verzeichnis des alten Archivs. Führe die zwei `helm upgrade`-Befehle aus [Upgrade auf Kubernetes](https://platform.claude.com/docs/de/managed-agents/self-hosted/upgrade#upgrade-on-kubernetes) aus, mit den Values-Dateien, wie sie für dieses Release waren. Wenn du zum Beispiel für das Upgrade `earlierNames` hinzugefügt hast, entferne es wieder. Führe den zweiten Befehl erst aus, wenn der erste erfolgreich ist.
* **Docker Compose:** Führe `docker compose down` im Compose-Verzeichnis des neuen Release aus und dann `docker compose up --build -d` im Compose-Verzeichnis des alten.
Wenn das alte Release nicht mit dem geänderten Schema laufen kann, zeigt das Log `cannot downgrade`:
* **Kubernetes:** Der Migrations-Job schlägt fehl, und die Server bleiben unverändert. [Wenn das Upgrade fehlschlägt](https://platform.claude.com/docs/de/managed-agents/self-hosted/upgrade#if-the-upgrade-fails) beschreibt, wie du das Log des Jobs liest.
* **Docker Compose:** Der Server startet nicht. Lies das Log mit `docker compose logs migrate`.
Auf Docker Compose zeigt die Ausgabe von `docker compose logs` stattdessen möglicherweise `stored value is encrypted but no encryption key is configured`. In diesem Fall hat die `.env` des alten Release keine Zeile `CMA_STORE__CREDENTIALS_ENCRYPTION_KEY`. Kopiere diese Zeile aus der `.env` des neuen Release und führe `docker compose up --build -d` erneut aus.
### Das Backup auf Kubernetes wiederherstellen
Dein Datenbankserver braucht Platz für eine zweite Kopie der Datenbank. Verwende für `` und `` die Werte `user` und `dbname` aus `database.url` in `cma-server-values.yaml`.
Verbinde dich als Administrator mit der Datenbank `postgres` auf deinem Datenbankserver und führe Folgendes aus:
```sql
CREATE DATABASE _restored OWNER ;
```
Führe dann auf dem Rechner, auf dem das Backup liegt, diesen Befehl mit den Pfaden zu deinem Schlüssel und deiner Backup-Datei aus. Verwende ein `pg_restore` derselben Hauptversion wie dein Datenbankserver. Es fragt nach dem Passwort der Rolle und gibt nichts aus, wenn es funktioniert.
```bash
age -d -i cma-backup.agekey cma_server-.dump.age \
| PGSSLMODE=require pg_restore -h -U -d _restored --no-owner --exit-on-error
```
Wenn dabei ein Fehler ausgegeben wird, brich ab. Deine Datenbank ist unverändert. Führe `DROP DATABASE _restored;` als Administrator aus und beginne diesen Schritt von vorn.
```bash
kubectl -n cma-server scale deployment/$server --replicas=0
kubectl -n cma-server wait --for=delete pod -l anthropic.com/role=server --timeout=90s
```
Verbinde dich als Administrator mit der Datenbank `postgres` und führe Folgendes aus:
```sql
ALTER DATABASE RENAME TO _upgraded;
ALTER DATABASE _restored RENAME TO ;
```
Wenn die erste Anweisung meldet, dass andere Sitzungen die Datenbank verwenden, schließe diese Sitzungen und führe beide Anweisungen erneut aus. Ein Connection-Pooler kann solche Sitzungen offen halten.
Befolge den Kubernetes-Punkt aus [Das alte Release erneut bereitstellen](https://platform.claude.com/docs/de/managed-agents/self-hosted/upgrade#deploy-the-old-release-again). Der erste Befehl stellt außerdem die Anzahl der Server wieder her. Wenn er fehlschlägt, `kubectl -n cma-server get pods` aber zeigt, dass die alten Server bereit sind, lies [Wenn die Schlüsselprüfung fehlschlägt](https://platform.claude.com/docs/de/managed-agents/self-hosted/upgrade#if-the-key-check-fails).
Diese Datenbank enthält noch, was Clients nach dem Backup geschrieben haben. Wenn das alte Release funktioniert, lösche sie mit `DROP DATABASE _upgraded;`.
#### Wenn die Schlüsselprüfung fehlschlägt
Im Schritt „Das alte Release bereitstellen“ wartet der erste `helm upgrade`-Befehl, bis die alten Server bereit sind. Dann prüft er den Schlüssel, mit dem sich die Sandboxes verbinden. Wenn der Befehl fehlschlägt, `kubectl -n cma-server get pods` aber zeigt, dass die alten Server bereit sind, ist diese Prüfung fehlgeschlagen.
Deine Daten sind wiederhergestellt und die Server funktionieren, aber die Sandboxes können sich noch nicht mit ihnen verbinden. Die Sandboxes verbinden sich mit einem Schlüssel aus dem Secret `cma-environment` in ihrem eigenen Namespace, `cma`. Dieser Schlüssel ist neuer als dein Backup, daher erkennt die wiederhergestellte Datenbank ihn nicht.
Um die Ursache zu bestätigen, führe den ersten Befehl erneut aus. Öffne, während er wartet, ein zweites Terminal und setze dort ebenfalls `$server`. Führe dann `kubectl -n cma-server logs job/$server-environment-default` aus und setze dabei den Namen deiner Umgebung anstelle von `default` ein. Suche nach einer Zeile, die `Secret cma/cma-environment records key` enthält. Wenn das Log einen anderen Fehler zeigt, behebe, was er nennt.
Wenn das Log diese Zeile zeigt, lösche das Secret mit `kubectl -n cma delete secret cma-environment` und führe den ersten Befehl erneut aus. Er erstellt das Secret erneut, mit einem neuen Schlüssel. Führe dann den zweiten Befehl aus.
### Das Backup auf Docker Compose wiederherstellen
Führe `docker compose down` im Compose-Verzeichnis des neuen Release aus. Führe dann `docker compose up -d --wait postgres` im Compose-Verzeichnis des alten Release aus. Bleib für die nächsten Schritte in diesem Verzeichnis.
Führe im Compose-Verzeichnis des alten Release Folgendes mit den Pfaden deines Schlüssels und deiner Backup-Datei aus:
```bash
docker compose exec -T postgres sh -c 'psql -U "$POSTGRES_USER" -d postgres \
-c "DROP DATABASE IF EXISTS ${POSTGRES_DB}_restored" -c "CREATE DATABASE ${POSTGRES_DB}_restored"' \
&& age -d -i cma-backup.agekey cma_server-.dump.age \
| docker compose exec -T postgres sh -c 'pg_restore -U "$POSTGRES_USER" -d "${POSTGRES_DB}_restored" --no-owner --exit-on-error'
```
Sie hat funktioniert, wenn `DROP DATABASE` und `CREATE DATABASE` ausgegeben werden und kein Fehler.
Lass `$POSTGRES_USER` und `$POSTGRES_DB` hier und in den nächsten Schritten unverändert. Der Text in einfachen Anführungszeichen läuft im Container `postgres`, der die Namen seiner Rolle und seiner Datenbank in diesen Variablen hält.
Wenn ein Fehler ausgegeben wird, ist deine Datenbank unverändert, sodass du den gesamten Befehl erneut ausführen kannst. Wenn das Backup nicht wiederhergestellt werden kann, führe `docker compose up --build -d` im Compose-Verzeichnis des neuen Release aus, um dieses Release wieder zu starten.
```bash
docker compose exec -T postgres sh -c 'psql -U "$POSTGRES_USER" -d postgres \
-c "ALTER DATABASE $POSTGRES_DB RENAME TO ${POSTGRES_DB}_upgraded" \
-c "ALTER DATABASE ${POSTGRES_DB}_restored RENAME TO $POSTGRES_DB"'
```
Führe `docker compose up --build -d` aus.
Diese Datenbank enthält noch, was Clients nach dem Backup geschrieben haben. Wenn das alte Release funktioniert, lösche sie:
```bash
docker compose exec -T postgres sh -c 'psql -U "$POSTGRES_USER" -d postgres -c "DROP DATABASE ${POSTGRES_DB}_upgraded"'
```
### Nach einer Wiederherstellung
Eine Wiederherstellung setzt Umgebungsschlüssel auf den Zeitpunkt des Backups zurück:
* **Ein Schlüssel, den du nach dem Backup widerrufen hast:** Er funktioniert wieder. Widerrufe ihn erneut.
* **Ein Schlüssel, den du nach dem Backup erstellt hast:** Er ist weg. Erstelle einen neuen Schlüssel für die Worker, die ihn verwendet haben.
[Einen Umgebungsschlüssel für deine eigenen Worker ersetzen](https://platform.claude.com/docs/de/managed-agents/self-hosted/kubernetes#replace-an-environment-key-for-your-own-workers) enthält die Befehle, die auch auf Docker Compose funktionieren. Die Sandboxes, die der Docker-Compose-Stack startet, erfordern keine Aktion, denn der Stack ersetzt ihren Schlüssel, wenn er startet.
Um die Schlüssel einer Umgebung aufzulisten, einschließlich widerrufener, führe `list-keys` wie folgt aus:
* Verwende das Terminal, das du in [Die API auf einem selbst gehosteten Server aufrufen](https://platform.claude.com/docs/de/managed-agents/self-hosted/call-the-api) eingerichtet hast. Verwende nicht das Terminal, in dem `docker compose` läuft.
* Führe auf Kubernetes zuerst `kubectl -n cma-server port-forward svc/$server 8400:8400` in einem anderen Terminal aus, in dem `$server` ebenfalls gesetzt ist.
* Führe den Befehl im obersten Verzeichnis des Archivs aus, einmal für jede Umgebung, mit der ID der jeweiligen Umgebung.
```bash
echo "$ANTHROPIC_API_KEY" | ./cma-server-admin list-keys \
-base-url http://127.0.0.1:8400 -env env_01595EKxaaTTGwwY3kyXdtbs \
-key-file - -all
```
### Ein Backup testen
Um zu beweisen, dass sich ein Dump wiederherstellen lässt, führe nur den Schritt „Das Backup in eine neue Datenbank wiederherstellen“ aus. Er steht unter [Das Backup auf Kubernetes wiederherstellen](https://platform.claude.com/docs/de/managed-agents/self-hosted/upgrade#restore-the-backup-on-kubernetes) und unter [Das Backup auf Docker Compose wiederherstellen](https://platform.claude.com/docs/de/managed-agents/self-hosted/upgrade#restore-the-backup-on-docker-compose). Dieser Schritt ändert die verwendete Datenbank nicht. Lösche danach die neue Datenbank. Auf Docker Compose ist ihr Name der Name deiner Datenbank mit `_restored` am Ende.
## Zu prüfende Einstellungen und Pfade
Lies diesen Abschnitt, bevor du einen Upgrade-Befehl ausführst.
Prüfe den Abschnitt `web_tools` deiner [Einstellungsdatei](https://platform.claude.com/docs/de/managed-agents/self-hosted/configuration-reference#where-settings-go). Wenn die Datei keinen solchen Abschnitt hat oder der Abschnitt keine Schlüssel setzt, sind die Tools `web_search` und `web_fetch` nach dem Upgrade ausgeschaltet. Ein Agent, der das Standard-Toolset verwendet, läuft dann ohne sie und ohne Fehler. Ein Agent, dessen Toolset eines der beiden Tools einschaltet, kann keine Sitzung starten. Wie du die Tools behältst, erfährst du unter [Web-Tools brauchen eine Server-Einstellung](https://platform.claude.com/docs/de/managed-agents/self-hosted/differences#web-tools-need-a-server-setting).
Prüfe auf Kubernetes, ob jede Sandbox-Values-Datei, etwa `cma-values.yaml`, `egress.mode` setzt. Damit deine Sandboxes ihren Zugriff auf das öffentliche Internet behalten, füge `mode: publicInternet` unter `egress` hinzu. Wenn eine Datei keinen Modus setzt, wendet das Chart seinen Standardmodus `closed` an. Der `helm upgrade`-Befehl des Sandbox-Charts bricht dann mit einem Fehler wie `egress.mode is closed and egress.closed.hosts is empty` ab und ändert nichts.
Prüfe `sandbox.idleTimeout` in denselben Dateien. Wenn eine Datei den Wert nicht setzt, verschwindet der Pod einer Sitzung etwa 5 Minuten nach dem Ende des Agent-Turns. Die Prozesse, die der Agent laufen gelassen hat, stoppen mit dem Pod. Standardmäßig bleiben die Dateien in `/workspace` erhalten. Um den Pod 30 Minuten lang zu behalten, füge `idleTimeout: 30m` unter `sandbox` hinzu.
Prüfe die Einstellungsdatei auf `inference.attribution` und die Umgebung des Servers auf `CMA_INFERENCE__ATTRIBUTION`. Lösche die Zeile, wenn du eine findest. Das Release, auf das du aktualisierst, hat diese Einstellung nicht, und sein Server startet nicht, wenn eines der beiden gesetzt ist.
Wenn die Claude API dein Inferenzanbieter ist, trägt nach dem Upgrade jeder Modellaufruf die IDs seiner Sitzung sowie des Agents und der Umgebung dieser Sitzung. Siehe [Was der Server an seinen Inferenzanbieter sendet](https://platform.claude.com/docs/de/managed-agents/self-hosted-data-and-access#what-the-server-sends-to-its-inference-provider).
### Kubernetes: die Namen deiner Objekte
`cma-server-values.yaml` muss in seiner Einstellung `earlierNames` angeben, welche Namen deine Installation hat. Um den Namen des Deployments des Servers zu finden, führe `kubectl -n cma-server get deployment -l anthropic.com/role=server` aus.
| Der Name des Deployments | Die Zeile in `cma-server-values.yaml` |
| ------------------------ | ------------------------------------- |
| `cma-onprem` | `earlierNames: true` |
| `cma-server` | `earlierNames: false` |
Wenn die Datei diese Zeile nicht hat, füge sie vor dem Upgrade hinzu und behalte sie für jedes spätere Upgrade bei. Ohne sie bricht der `helm upgrade`-Befehl des Server-Charts mit einem Fehler ab, der `earlierNames` nennt, und ändert nichts.
Mit `earlierNames: true` behalten die Objekte des Charts ihre `cma-onprem`-Namen, und die Server finden weiterhin die Secrets, die du unter diesen Namen erstellt hast. Diese Seiten verwenden die Namen in der mittleren Spalte. Verwende mit `earlierNames: true` stattdessen die Namen in der letzten Spalte:
| Objekt | Name auf diesen Seiten | Name mit `earlierNames: true` |
| ------------------------------------------------------------------- | ------------------------------- | ------------------------------- |
| Das Deployment und der Service des Servers | `cma-server` | `cma-onprem` |
| Der Migrations-Job | `cma-server-migrate` | `cma-onprem-migrate` |
| Der Job jeder Umgebung | `cma-server-environment-` | `cma-onprem-environment-` |
| Das Secret mit dem Datenbankpasswort | `cma-server-db` | `cma-onprem-db` |
| Das Secret mit den Anmeldedaten des Inferenzanbieters | `cma-server-upstream` | `cma-onprem-upstream` |
| Das Secret mit dem Server-API-Key und dem Verschlüsselungsschlüssel | `cma-server-keys` | `cma-onprem-server` |
Unabhängig davon, was `earlierNames` angibt, heißt der Namespace `cma-server` und das Image des Servers `cma-server-image`.
Jede Sandbox-Values-Datei, die `egress.mode: gateway` setzt, muss unter `egress.gateway` die zwei Services des Servers nennen. Wenn eine Datei das nicht tut, füge beide Zeilen hinzu. Dieses Beispiel enthält die Namen für eine Installation mit `earlierNames: true`:
```yaml
egress:
gateway:
serverService: cma-onprem
serverEgressService: cma-onprem-egress
```
### Docker Compose: das Layout und die Pfade des Archivs
Wenn das Release, von dem aus du aktualisierst, kein Verzeichnis `compose` hat, liegt seine `docker-compose.yml` ganz oben im Archiv, neben `bin`. Im neuen Archiv liegt diese Datei eine Ebene tiefer, in `compose`.
Nimm im Schritt „Deine anderen Änderungen wiederholen“ auch diese Änderungen vor:
* **Eine eigene Compose-Datei:** Wenn das alte Archiv kein Verzeichnis `compose` hatte, wandert auch deine Datei eine Ebene tiefer. Ein Pfad wie `./bin` darin wird zu `../bin`. Wenn die Datei den Dienst `cma-onprem` nennt, ändere diesen Namen in `cma-server`.
* **Pfade unter `/etc/cma-onprem/` oder `/run/cma-onprem/`:** Ändere jeden so, dass er mit `/etc/cma-server/` oder `/run/cma-server/` beginnt. Sieh in der `.env` und `compose.config.yaml` des neuen Release nach, in einer eigenen Compose-Datei und in jeder `volumes:`-Zeile, die du hinzugefügt hast. Ändere in einer `volumes:`-Zeile nur den Teil nach dem ersten Doppelpunkt, also den Pfad innerhalb des Containers.