OpenClaw sicher updaten: Backup, Verify und Recovery ohne Blindflug

Wer OpenClaw länger als ein Demo-Wochenende betreibt, braucht vor jedem Update drei Dinge: einen prüfbaren Backup-Plan, einen klaren Blick auf den Update-Kanal und eine nüchterne Vorstellung davon, was ein Archiv später wirklich retten kann. Genau daran scheitern viele Wartungsfenster. Das Update selbst läuft an, aber hinterher fehlen Workspaces, eine kaputte Konfig blockiert die Sicherung oder ein Plugin startet nicht sauber, obwohl das Backup formal gültig ist.

Die gute Nachricht: Die offizielle OpenClaw-Doku trennt Update, Backup und Verifikation inzwischen sauber. openclaw update kümmert sich um CLI und Gateway. openclaw backup create sichert State, Konfigurationspfad, externe Credentials-Verzeichnisse und auf Wunsch Workspaces. openclaw backup verify prüft danach, ob das Archiv strukturell konsistent ist.

Für produktive Systeme lohnt sich deshalb kein Improvisieren, sondern eine feste Kommandoleiter:

mkdir -p ~/Backups/openclaw
chmod 700 ~/Backups/openclaw

openclaw backup create --output ~/Backups/openclaw --dry-run --json
openclaw backup create --output ~/Backups/openclaw --verify
openclaw update status --json
openclaw update --dry-run
openclaw update
openclaw doctor
openclaw health

Damit siehst du vor dem Eingriff, was tatsächlich gesichert wird, welcher Kanal gerade aktiv ist und ob das Update überhaupt ansteht. Für angrenzende Failure-Modes sind auch unser Guide zu OpenClaw-Updates auf Linux-VPS, die Analyse zur stillen Config-Rücksetzung nach bestimmten Releases und der Sicherheitsleitfaden zu Secrets statt Klartext-Konfig relevant.

Was du vor dem Update wirklich prüfen solltest

Bevor irgendein Paket wechselt, müssen vier Fragen beantwortet sein:

• Läuft die OpenClaw-CLI auf dem Host, den du wirklich aktualisieren willst?
• Gibt es freien Platz für Archiv plus Verifikation?
• Ist klar, ob du auf stable bleiben oder gezielt beta, dev oder einen bestimmten Tag ansteuern willst?
• Ist deine aktive Konfigurationsdatei gültig genug, damit Workspace-Discovery überhaupt funktioniert?

Gerade der letzte Punkt wird leicht übersehen. Laut Backup-Doku umgeht openclaw backup zwar die normale Config-Preflight-Prüfung, aber openclaw backup create bricht trotzdem ab, wenn die Konfigurationsdatei existiert, ungültig ist und du weiterhin Workspaces mitsichern willst. In so einem Fall helfen nur zwei ehrliche Ausweichpfade:

openclaw backup create --no-include-workspace
openclaw backup create --only-config

--no-include-workspace rettet weiter State, aktive Konfiguration und ein externes Credentials-Verzeichnis. --only-config ist der Minimalpfad, wenn du wenigstens die kaputte Konfig selbst separat sichern willst.

Welche Daten das Backup wirklich erfasst

openclaw backup create sichert nicht einfach “irgendwie alles”, sondern baut sein Archiv aus klar aufgelösten Quellen:

• den lokalen State-Pfad, typischerweise ~/.openclaw
• den aktiven Konfigurationspfad
• ein aufgelöstes externes credentials/-Verzeichnis, falls es außerhalb des State liegt
• Workspace-Verzeichnisse aus der aktiven Konfiguration, sofern du sie nicht mit --no-include-workspace ausschließt

Das ist wichtig, weil viele Betreiber von einem Vollabbild ausgehen. Tatsächlich lässt OpenClaw bewusst volatile Dateien aus, die für eine Wiederherstellung kaum Wert haben. Dazu gehören laut Doku laufende Session-Transkripte, Cron-Run-Logs, Roll-Logs, Delivery-Queues, Socket-, PID- und Temp-Dateien. Genau deshalb ist ein erfolgreiches Backup nicht dasselbe wie ein Zeitmaschinen-Snapshot jedes zuletzt laufenden Zustands.

Auch Plugins haben eine wichtige Grenze: Installierte Plugin-Quellen und Manifestdateien unter extensions/ landen im Archiv, die verschachtelten node_modules/-Bäume aber nicht. Diese Dependencies gelten als wiederaufbaubare Installationsartefakte. Wenn ein Restore später ein Plugin mit fehlenden Abhängigkeiten zurückbringt, musst du dessen Abhängigkeiten nachziehen, statt dem Backup einen Fehler zu unterstellen.

Update-Kanal, Dry-Run und Erwartungsmanagement

Für den eigentlichen Versionswechsel empfiehlt die Dokumentation klar openclaw update. Der Befehl erkennt den Installationspfad, holt die Zielversion, führt openclaw doctor aus und startet den Gateway neu. Für normale Wartung reicht das oft. Für echte AgentOps nicht.

Relevant wird das vor allem dann, wenn du bewusst Kanäle wechselst oder eine bestimmte Zielversion im Blick hast:

openclaw update --dry-run
openclaw update --channel beta
openclaw update --channel dev
openclaw update --tag main
openclaw update status --json

Dabei steckt die wichtigste Stolperfalle im Unterschied zwischen Kanal und Tag. --channel beta bevorzugt laut Doku zwar Beta, fällt aber auf stable beziehungsweise latest zurück, wenn der Beta-Stand fehlt oder älter ist. Wer wirklich einen einmaligen Beta-Paketstand erzwingen will, sollte dieses Fallback im Hinterkopf behalten und nicht aus dem Kanalnamen mehr Verbindlichkeit herauslesen, als tatsächlich garantiert ist.

Für Diagnosen gilt außerdem: openclaw update hat kein --verbose. Wenn du genauer sehen willst, was passieren soll, sind --dry-run, --json und openclaw update status --json die vorgesehenen Prüfpfade. Ein hektischer zweiter update-Lauf liefert dir normalerweise weniger Erkenntnis als ein sauber gelesener Dry-Run.

Ein robuster Wartungsablauf für produktive Setups

Ein brauchbares Update-Fenster trennt Absicherung, Diagnose und Wechsel strikt:

# 1. Ausgabeziel vorbereiten
mkdir -p ~/Backups/openclaw
chmod 700 ~/Backups/openclaw

# 2. Backup-Plan lesen
openclaw backup create --output ~/Backups/openclaw --dry-run --json

# 3. Backup schreiben und direkt prüfen
openclaw backup create --output ~/Backups/openclaw --verify

# 4. Kanal und Update-Plan prüfen
openclaw update status --json
openclaw update --dry-run

# 5. Wechsel ausführen
openclaw update

# 6. Runtime danach prüfen
openclaw doctor
openclaw health

Wenn du sehr große Workspaces hast, kann --no-include-workspace den Lauf massiv beschleunigen. Das ist sinnvoll, wenn der eigentliche Risikobereich eher im Gateway, in der Konfiguration oder im Auth-State liegt und du Workspace-Daten anderweitig versionierst. Für punktuelle Konfigurationsänderungen reicht manchmal sogar ein bewusst kleiner Sicherungslauf:

openclaw backup create --output ~/Backups/openclaw --only-config --verify

Das ist kein Ersatz für ein vollständiges Betriebsbackup, aber ein sauberer Vorhang, bevor du an Config, Kanal oder Provider-Zugang arbeitest.

Typische Failure-Modes nach dem Update

Die meisten Probleme nach Updates sehen auf den ersten Blick ähnlich aus, haben aber unterschiedliche Ursachen:

1. Backup bricht vor dem Schreiben ab

Wenn die Konfiguration ungültig ist und Workspace-Discovery aktiv bleibt, scheitert openclaw backup create bewusst früh. Dann ist nicht das Backup-System kaputt, sondern deine Konfigurationslage ungeklärt. Nutze --no-include-workspace oder --only-config, sichere den minimal nötigen Zustand und behebe erst danach die Konfigurationsfehler.

2. Das Archiv ist gültig, aber nach Restore fehlt trotzdem etwas

Ein erfolgreiches openclaw backup verify bedeutet laut Doku: Manifest-Struktur, Archivpfade und referenzierte Payloads sind konsistent. Es bedeutet nicht, dass volatile Laufzeitdateien, Delivery-Queues oder alle Build-Artefakte später in exakt demselben Zustand wieder auftauchen. Genau deshalb ist Verify kein Volltest für Messenger-Zustellung, Cron-Rückstände oder zuletzt laufende Sessions.

3. Plugins kommen zurück, starten aber unvollständig

Wenn ein wiederhergestelltes Plugin über fehlende Dependencies stolpert, liegt das meist daran, dass node_modules/ absichtlich nicht mitgesichert wird. Der Recovery-Schritt ist dann kein zweites Restore, sondern ein Plugin-Update oder eine Neuinstallation des betroffenen Plugins.

4. Der Kanalwechsel liefert etwas anderes als erwartet

openclaw update --channel beta kann auf stable zurückfallen, wenn Beta nicht verfügbar oder älter ist. Wer danach irritiert auf die Versionsnummer schaut, hat nicht zwingend ein kaputtes Update, sondern möglicherweise nur die falsche Erwartung an die Kanal-Semantik.

Recovery, wenn der Wechsel schiefgeht

Wenn der Update-Lauf hängt oder du hinterher ein inkonsistentes System vermutest, hilft zuerst die nüchterne Diagnoseleiter:

openclaw update status --json
openclaw update --dry-run
openclaw doctor
openclaw health

Bleibt die Paketinstallation selbst der Verdächtige, nennt die Update-Dokumentation den Installer als sauberen Recovery-Pfad. Für npm-basierte Setups sieht das so aus:

curl -fsSL https://openclaw.ai/install.sh | bash -s -- --install-method npm

Wenn du gezielt auf einen bestimmten Paketstand zurück oder nach vorn musst:

curl -fsSL https://openclaw.ai/install.sh | bash -s -- --install-method npm --version <version-or-dist-tag>

Das ist kein Freifahrtschein für blindes Neuinstallieren. Erst wenn Dry-Run, Status und Health-Checks sauber eingegrenzt haben, dass die Paketlage selbst das Problem ist, wird dieser Pfad sinnvoll. Für reine Runtime-Störungen ohne Paketdefekt ist ein erneuter Installer-Lauf eher Ablenkung als Hilfe.

Reality Check: Dieses Backup- und Update-Modell schützt dich vor stillen Konfigurationsverlusten, falschen Kanalwechseln und unprüfbaren Schnellschüssen. Es ersetzt aber weder ein getestetes Restore-Fenster noch hostseitige Snapshots, wenn dein OpenClaw auf einer VM, einem VPS oder einem Cluster mit weiteren Abhängigkeiten läuft.

Backup-Sicherheit und was Verify nicht leisten kann

Backups können State, Auth-Profile, Sessions, Credentials und Workspace-Inhalte enthalten. Praktisch heißt das: Archive gehören nicht ins Git-Repository, nicht unverschlüsselt in Sync-Ordner und nicht mit laxen Dateirechten auf Hosts, die mehrere Nutzer teilen.

Der schnelle Soforttest bleibt:

openclaw backup verify ~/Backups/openclaw/<dein-archiv>.tar.gz

Dabei prüft OpenClaw unter anderem, ob genau ein Root-Manifest vorhanden ist, ob Traversal-Pfade im Archiv fehlen und ob alle im Manifest genannten Payloads im Tarball existieren. Das ist stark für Struktur und Integrität. Es ist kein Beweis dafür, dass nach einem Restore sofort jeder angebundene Messenger, jedes Plugin und jede externe Laufzeit wieder genauso reagiert wie vor dem Update.

Fazit

OpenClaw trennt Update, Backup und Verifikation inzwischen deutlich sauberer, als viele Kurz-Tutorials vermuten lassen. Genau daraus entsteht ein brauchbarer AgentOps-Ablauf: erst den Backup-Plan lesen, dann das Archiv prüfen, danach den Update-Kanal trocken testen und erst zuletzt die Runtime umstellen.

Wenn du OpenClaw ernsthaft betreibst, ist die eigentliche Absicherung nicht der einzelne Befehl, sondern deine Reihenfolge. Ein gutes Wartungsfenster produziert kein heldenhaftes Ad-hoc-Debugging, sondern wenige klare Signale: Was wird gesichert, was darf fehlen, welcher Kanal ist aktiv und welcher Recovery-Pfad ist wirklich gerechtfertigt.