2026 OpenClaw Linux-VPS-Upgrade & Kanal-Wartung: openclaw update vs. Neuinstallation, Stable/Beta-Wechsel und schichtweises Rollback-Troubleshooting (FAQ)

Ein OpenClaw-Gateway auf einem Linux-Cloud-VPS lebt nicht von einer einzigen Installation, sondern von regelmäßigen Upgrades: neue Plugins, gefixte Webhook-Pfade, getunte Limits. 2026 stehen dafür meist zwei Wege nebeneinander — der bequeme Weg über openclaw update und der harte Weg über eine saubere Neuinstallation. Dazu kommen Kanäle (stable vs. beta) und gelegentlich eine angepinnte Version. Wer das nicht trennt, fällt früher oder später in den Klassiker: „nach dem Update hängt das Gateway, der Bot antwortet, aber Tool-Calls timeouten". Dieser Artikel ordnet die Wege, schlägt eine schichtweise Rollback-Strategie (Service → Config → State → Daten) vor und liefert eine kompakte Troubleshooting-FAQ für den Notfall um Mitternacht.

openclaw update vs. saubere Neuinstallation

Der Befehl openclaw update ist auf Idempotenz ausgelegt: er holt das aktuelle Release-Manifest des konfigurierten Kanals, vergleicht Hashes und tauscht nur die geänderten Dateien aus — Konfiguration, State und Datenverzeichnis bleiben unangetastet. Das ist der richtige Weg, solange das System konsistent ist: keine manuell editierten Binärdateien, kein halb gemounteter Container, keine vorzeitig getöteten Prozesse. Eine Neuinstallation dagegen ist sinnvoll, wenn das Layout zerschossen ist oder ein Major-Wechsel ansteht: Sie räumen das Programmverzeichnis komplett, behalten aber explizit gesicherte Konfigurations- und State-Pfade bei. Beide Wege müssen mit demselben Pre-Flight-Check beginnen — sonst überträgt sich ein bestehender Schaden in die neue Version.

Pre-Flight-Check, der nichts kostet

Vor jedem Upgrade läuft eine kleine Checkliste: aktuelle Version notieren (openclaw --version), Service-Status auf active (running) prüfen, Disk-Free über 20 % halten, ein lesbares Backup von ~/.openclaw/ oder /var/lib/openclaw/ ablegen und die letzten 200 Zeilen des Journals abrufen. Erst wenn das System vor dem Update grün ist, ist der Vergleich „vorher/nachher" überhaupt aussagekräftig.

Stable, Beta und Pin: drei Geschwindigkeiten

OpenClaw kennt 2026 typischerweise zwei Kanäle. Stable bekommt geprüfte Releases mit Backports; hier laufen Produktions-Gateways. Beta erhält Features früher, gelegentlich auch Schema-Änderungen — ideal für einen separaten Test-Host. Eine angepinnte Version (--version oder OPENCLAW_VERSION=…) ist die dritte Geschwindigkeit: friert die laufende Installation ein, bis Sie aktiv freigeben. In der Praxis lohnt es sich, Produktions-Profil und Beta-Profil physisch getrennt zu fahren (separate User, separate OPENCLAW_DIR, separate systemd-Unit), damit ein Beta-Bug nie versehentlich produktive Webhooks vergiftet. Der Wechsel selbst ist schmal: Kanal in der Konfiguration setzen, dann openclaw update ausführen — der Manifestwechsel bringt automatisch das passende Release.

# Aktuellen Zustand notieren
openclaw --version
openclaw config get channel

# Kanal wechseln (Beispiel: stable -> beta auf einem Test-Host)
openclaw config set channel beta
openclaw update

# Eine bestimmte Version pinnen (Rollback / Reproduzierbarkeit)
openclaw update --version 2026.04.2
openclaw config set pin 2026.04.2

# Pin wieder lösen, sobald die Untersuchung abgeschlossen ist
openclaw config unset pin

Wenn Sie mehrere Profile auf demselben Host benötigen (etwa Slack-Bot getrennt von Telegram-Bot), trennen Sie diese sauber per User und OPENCLAW_DIR — Details dazu in OpenClaw 2026 Linux-VPS Multi-Profil & parallele Gateways: systemd-User, OPENCLAW_DIR und FAQ. So bleibt ein Beta-Update strikt auf das Beta-Profil beschränkt.

Schichtweises Rollback: Service · Config · State · Daten

Ein gutes Rollback ist nicht ein einzelner Befehl, sondern eine Hierarchie. Sie steigen nur so tief, wie nötig — und stoppen, sobald das Problem verschwindet. Genau diese Disziplin verhindert, dass eine harmlose Konfigurationsänderung in eine vollständige Wiederherstellung eskaliert.

• Schicht 1 — Service: systemctl restart openclaw, transiente Worker-Probleme verschwinden meist hier.
• Schicht 2 — Konfiguration: letzte config.toml/config.yaml-Diff zurückrollen, gezielte Plugin-Toggles deaktivieren.
• Schicht 3 — State: Programmverzeichnis auf vorherige Version pinnen (openclaw update --version), Cache leeren, neu starten.
• Schicht 4 — Daten: aus Backup von ~/.openclaw/ oder /var/lib/openclaw/ wiederherstellen — letzte Wahl, dauert am längsten.

FAQ: typische Notfälle nach dem Upgrade

Webhook 200 OK, aber Tool-Calls timeouten? Häufig lebt eine alte NO_PROXY-Liste in der systemd-Unit-Umgebung weiter, während das neue Release einen anderen Upstream-Pfad nimmt. Prüfen Sie systemctl show openclaw --property=Environment, vergleichen Sie mit Ihrer Konfiguration und starten Sie nach einem daemon-reload neu.

Beta-Update bringt Schema-Änderung mit? Beta darf das. Pinnen Sie für Produktion auf den letzten Stable-Tag und testen Sie das Beta-Profil getrennt. Erst wenn Stable nachzieht, fließen die Änderungen produktiv.

Nach Neuinstallation fehlen Sessions? Sie haben das Datenverzeichnis (~/.openclaw/) nicht in den Backup-Pfad aufgenommen. Restore aus dem Pre-Flight-Backup, dann erneut starten.

Logs schweigen? Ein häufiger Grund ist eine geänderte Logfile-Rotation nach dem Update. Konsultieren Sie zuerst journalctl -u openclaw -n 200 — systemd hält die Wahrheit, auch wenn die alte Logdatei verschwunden ist. Tieferes Vorgehen beschreibt OpenClaw Linux Production-Troubleshooting: systemd-Logs, Gateway-Port und FAQ.