OpenClaw sicher updaten: Backup, Verify und Recovery ohne Blindflug

Wer OpenClaw länger als ein Demo-Wochenende betreibt, braucht vor jedem Update drei Dinge: ein prüfbares Backup, einen klaren Blick auf den Zielkanal und einen Recovery-Pfad, der mehr ist als “Installer nochmal drüberlaufen lassen”. Genau daran scheitern viele Wartungsfenster. Das Update selbst läuft an, aber hinterher fehlen Workspaces, eine kaputte Konfig blockiert die Sicherung oder ein Plugin kommt formal zurück, startet praktisch aber unvollständig.

Die gute Nachricht: Die aktuelle OpenClaw-Doku trennt diese Ebenen sauber. openclaw update kümmert sich um den Versionswechsel. openclaw backup create sichert State, aktive Konfiguration, externe Credentials-Verzeichnisse und optional Workspaces. openclaw backup verify prüft danach, ob das Archiv strukturell konsistent ist.

Für produktive Setups 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
openclaw gateway status --deep --json

Damit prüfst du vor dem Eingriff, was wirklich im Backup landet, welcher Kanal aktiv ist und ob überhaupt ein Wechsel ansteht. Nach dem Update endet die Kontrolle nicht bei einem grünen Bauchgefühl, sondern bei konkreten Laufzeitsignalen.

Was du vor dem Update wirklich prüfen solltest

Bevor irgendein Paket wechselt, sollten vier Fragen beantwortet sein:

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

Gerade der letzte Punkt wird gern verdrängt. 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 bleiben nur zwei saubere Ausweichpfade:

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

--no-include-workspace hält State, Konfigurationsdatei und ein externes Credentials-Verzeichnis weiter im Scope. --only-config ist der Minimalpfad, wenn du wenigstens die aktive, eventuell kaputte Konfiguration separat wegsichern willst.

Welche Daten das Backup wirklich erfasst

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

• dem State-Verzeichnis, meist ~/.openclaw
• dem aktiven Konfigurationspfad
• einem externen credentials/-Verzeichnis, falls es außerhalb des State liegt
• Workspace-Verzeichnissen aus der aktiven Konfiguration, sofern du sie nicht mit --no-include-workspace ausschließt

Wichtig ist auch, was bewusst nicht eins zu eins als Live-Zustand konserviert wird. Die Doku nennt unter anderem aktive Session-Transkripte, Cron-Run-Logs, Rolling Logs, Delivery-Queues sowie Socket-, PID- und Temp-Dateien als volatile Daten ohne sinnvollen Restore-Wert. Ein erfolgreiches Backup ist deshalb kein Zeitmaschinen-Snapshot jeder letzten Laufzeitspur.

Auch Plugins haben eine klare Grenze: Unter extensions/ sichert OpenClaw Quell- und Manifestdateien mit, aber nicht die verschachtelten node_modules/-Bäume. Diese Dependencies gelten als wiederaufbaubare Installationsartefakte. Wenn ein Restore später ein Plugin mit fehlenden Abhängigkeiten zurückbringt, ist der richtige nächste Schritt also meist openclaw plugins update <id> oder eine Neuinstallation des Plugins, nicht ein zweites Restore.

Update-Kanal, Dry-Run und Erwartungsmanagement

Für den eigentlichen Wechsel empfiehlt die Dokumentation klar openclaw update. Der Befehl erkennt den Installationsmodus, holt die Zielversion, führt openclaw doctor aus und startet den Gateway neu.

Für normale Wartung reichen oft schon diese Pfade:

openclaw update --dry-run
openclaw update --channel beta
openclaw update --channel extended-stable
openclaw update --channel dev
openclaw update status --json

Dazu kommt ein Detail, das leicht falsch gelesen wird: --channel beta bevorzugt laut Doku zwar den Beta-Stand, fällt aber auf stable beziehungsweise latest zurück, wenn Beta fehlt oder älter ist. Wenn du genau einen Paketstand aus dem npm-Tag erzwingen willst, ist dafür --tag beta gedacht. Für dev ist auch ein einmaliger Paketwechsel auf den GitHub-main-Stand möglich:

openclaw update --tag main

Für Diagnosen gilt außerdem: openclaw update hat kein --verbose. Wenn du mehr sehen willst, sind --dry-run, --json und openclaw update status --json die vorgesehenen Prüfpfade.

Ein robuster Wartungsablauf für produktive Setups

Ein brauchbares Update-Fenster trennt Absicherung, Diagnose, Wechsel und Runtime-Check sauber:

# 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
openclaw gateway status --deep --json

Wenn du sehr große Workspaces hast, kann --no-include-workspace den Lauf spürbar verkürzen. Für reine Konfigurationsarbeiten reicht manchmal sogar ein bewusst kleiner Sicherungslauf:

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

Das ersetzt kein vollständiges Betriebsbackup, ist aber ein sauberer Schutz, bevor du an Config, Kanal oder Auth drehst.

Typische Failure-Modes nach dem Update

Viele Post-Update-Probleme sehen gleich 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 Minimalzustand und behebe erst danach die Konfigurationsfehler.

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

Ein erfolgreiches openclaw backup verify bedeutet: Manifest-Struktur, Archivpfade und referenzierte Payloads sind konsistent. Es bedeutet nicht, dass volatile Laufzeitdateien, Delivery-Queues oder Build-Artefakte hinterher in exakt demselben Zustand wieder auftauchen. Verify ist ein Integritätscheck für das Archiv, kein Volltest deiner späteren Runtime.

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

Wenn ein wiederhergestelltes Plugin über fehlende Dependencies stolpert, liegt das oft daran, dass node_modules/ absichtlich nicht im Archiv steckt. Dann hilft typischerweise openclaw plugins update <id> oder eine Neuinstallation des betroffenen Plugins.

4. Der Kanal liefert etwas anderes als erwartet

openclaw update --channel beta kann auf stable zurückfallen, wenn Beta fehlt oder älter ist. Dann ist nicht automatisch das Update kaputt, sondern oft nur die Erwartung an die Kanal-Semantik falsch.

Recovery, wenn der Wechsel schiefgeht

Wenn der Update-Lauf hängt oder das System hinterher inkonsistent wirkt, hilft zuerst eine nüchterne Diagnoseleiter:

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

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>

Danach solltest du nicht blind weitermachen, sondern den Zustand explizit prüfen:

openclaw --version
openclaw plugins list --json
openclaw gateway status --deep --json
openclaw doctor --lint --json

Der Punkt ist wichtig: Ein Installer-Recovery ist kein magischer “alles wieder gut”-Knopf. Er ist der richtige Pfad, wenn die Paketlage selbst beschädigt oder unvollständig ist. Für reine Runtime-, Auth- oder Channel-Probleme lenkt ein erneuter Installer-Lauf oft eher ab.

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 in einer VM, auf einem VPS oder in einem größeren Stack 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 Mehrnutzer-Hosts.

Der schnelle Soforttest bleibt:

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

OpenClaw prüft dabei unter anderem, ob genau ein Root-Manifest vorhanden ist, ob Traversal-Pfade im Archiv fehlen und ob alle im Manifest referenzierten 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 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 kurze How-tos vermuten lassen. Genau daraus entsteht ein brauchbarer Betriebsablauf: 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 die Reihenfolge. Ein gutes Wartungsfenster produziert keine heldenhafte Ad-hoc-Debug-Session, sondern wenige klare Signale: Was wird gesichert, was darf fehlen, welcher Kanal ist aktiv und ob das System nach dem Wechsel wirklich wieder sauber läuft.