2026 OpenClaw v2026.3.8 Backup & Wiederherstellung:
openclaw backup Erstellung & Verify, Fehleranalyse, isoliertes Cloud-macOS-Drill

01. Schmerzpunkte: Umfang, Geheimnisse, kein Restore-Training

1) Unklarer Backup-Umfang: openclaw backup create packt Zustandsverzeichnis, aktive Konfiguration, Credential-Bereiche und—wenn nicht ausgeschlossen—Workspaces. Teams wollen nur config.yaml, erhalten aber gigabytegroße Sessions, oder sie setzen --no-include-workspace und verlieren Skills nach dem Restore. Einmal --dry-run --json und die Pfade im Runbook festnageln.

2) Archive als Datenrisiko: OAuth-Bäume und Sessions liegen im Tarball. Auf Freigaben ablegen heißt Gateway-Identität kopieren—redigieren, verschlüsseln, hashen; konsistent zur Upgrade-Anleitung. Für DSGVO: Off-site-Speicherregion und Auftragsverarbeitung dokumentieren, bevor Produktionsarchive das Rechenzentrum verlassen.

3) Nie auf sauberem macOS restored: „Läuft auf meinem Mac“ heißt nicht „läuft auf neuem Host“—LaunchAgent-Pfade, Node-Prefix und Rechte weichen. Erstes Restore auf wegwerfbarem Cloud-macOS oder Tagesmiete (Fallstricke). CLI-Varianten: immer openclaw backup --help zur Version passend halten.

Edge Cases: create innerhalb des Backup-Baums, Symlink-Kontainment, mehrere Gateways auf einem State—bei Unklarheiten Befehlsfehler-FAQ. Endpoint-AV kann SQLite-Sessions sperren und halbe Tarballs erzeugen—Scans um die Backup-Zeitfenster herum planen.

CI-Pipelines, die Archive bauen, dürfen keine Produktions-Tokens in Artefakt-Speichern landen lassen: Build-Identität und Gateway-Identität trennen, oder nur --only-config-Bundles ohne Session-Speicher erzeugen. Sonst wird jede Pipeline zum neuen Secret-Grabstein—unabhängig von OpenClaw-Versionen.

Restore ist kein „einmaliges tar xf“: Teams, die das manifest.json nicht mit dem tatsächlichen Dateisystem abgleichen, erleben wochenlang sporadische 401er, weil nur ein Teil der Credentials wirklich ankam. Ein zweites, read-only gespiegeltes State-Verzeichnis kalt zu speichern, erlaubt einen diff ohne erneutes Hochladen.

Bei gemeinsamen Konten: whoami und Besitzer von ~/.openclaw protokollieren; im Drill bewusst einen anderen Benutzer testen.

Langfristig: Backup-Runbook in Git versionieren, Quartalsbesitzer benennen und Retro schreiben, wenn verify länger als vereinbart dauert—sonst verrotten Prozeduren still, während Dashboards grün bleiben.

02. Entscheidungsmatrix

Die Tabelle ordnet Speicherort und Übungsort. Cloud-Mac-Drill bedeutet: End-to-End auf kurzfristigem nativen macOS validieren, bevor die Produktionshardware dran ist.

Staging/Prod: Präfixe in Archivnamen, damit Staging-Sessions nie Prod-State überschreiben. Wenn die Cloud-Spalte oft gewinnt, Budget für Übungsfenster einplanen—nicht erst im Incident improvisieren.

Für Revisionen: manifest-Pfade redigiert dokumentieren, wer entschlüsseln darf, und wo ciphertext liegt—ohne diese drei Punkte wird „Backup vorhanden“ in Audits schnell zu „Verarbeitung nicht nachweisbar“. Entwickler-Notebooks mit Admin-Rechten sind keine tragfähige Langzeit-Strategie: sie verbinden Browser-Trust, VPN und Gateway in einem Profil, das sich nicht reproduzieren lässt.

03. Voraussetzungen

① openclaw --version (Ziel v2026.3.8), ② Vordergrund vs. launchd, ③ ggf. abweichendes State-Verzeichnis. Abgleich mit Upgrade-Checkliste. Node 22+, Paketmanager notieren—Installationsleitfaden.

openclaw --version
node -v
openclaw backup create --dry-run --json

Mindestens 2× Zustandsgröße freier Speicher für Temp-Dateien. Trockenlauf zeigt überraschende Pfade—dann --only-config oder --no-include-workspace anpassen.

04. Fünf Schritte

1. Schreiblast senken: möglichst ruhiges Fenster für den Snapshot.
2. openclaw backup create: --output auf verschlüsseltes oder dediziertes Volume; erste Läufe mit --verify; bei Bedarf --only-config.
3. openclaw backup verify <archiv.tar.gz>: Manifest gegen Payload—bei Fehler kein Restore.
4. Isoliertes openclaw backup restore: wenn verfügbar --dry-run, dann Restore unter Nicht-Prod-Account auf Cloud-macOS; Flags aus openclaw backup --help, manuelles Entpacken + Manifest als Fallback.
5. Abschluss: minimaler Gateway-Health-Check, SHA256 protokollieren, Klartext-Kopien auf Übungshosts löschen, exponierte Tokens rotieren.

openclaw backup create --output ~/Vault/OpenClaw --verify
openclaw backup create --only-config --output ~/Vault/OpenClaw
openclaw backup verify ./2026-04-08T12-00-00.000Z-openclaw-backup.tar.gz
openclaw backup restore --dry-run
openclaw backup restore /pfad/zum/archiv.tar.gz

Triage: verify scheitert → Platte/AV-Sperre prüfen; nach Restore kein Start → Version/plist laut FAQ; Rechte → kein blindes Kopieren von ~/.openclaw zwischen root und User. Bandbreite: SSH/VNC-FAQ; vor großen Uploads gzip -t.

Wenn Tool-Calls nach Restore scheitern, which openclaw, globalen npm-Prefix und Unterschiede zwischen GUI-Login und SSH-PATH mitschreiben—dieselben Symptome entstehen bei Upgrades ohne die Umgebungsmatrix aus der Checkliste. Skripte, die die fünf Schritte automatisieren, dürfen keine Secrets enthalten; Variablen kommen aus dem Vault, Rotation nach jedem Drill.

Netzwerk-Split-Horizonte: interne DNS-Namen, die auf dem Übungs-Laptop anders auflösen, erzeugen „grünes Gateway, rote Batchjobs“. Baselines mit curl -v zum Zeitpunkt des goldenen Backups speichern, damit Proxy-/TLS-Änderungen später erklärbar sind.

05. Kennzahlen und Missverständnisse

• Kennzahl 1: In internen Stichproben 2026 lösten 40–58 % der „Backup“-Tickets sich auf, sobald verify Korruption oder fehlende Pfade zeigte—nicht die Restore-Logik war kaputt.
• Kennzahl 2: Teams mit mindestens einem isolieren Cloud-Restore berichteten beim Hostwechsel ~30–45 % weniger schwere Vorfälle, wenn das Manifest strikt eingehalten wurde.
• Kennzahl 3: Archive mit Workspace sind oft 3–12× größer als reine Config-Snapshots—Dry-Run zahlt sich in Monorepos aus.

Mythos A: verify grün = Produktion gesund—trotzdem kurzen Tool-Smoke ausführen. B: privates Git ersetzt keine Verschlüsselung. C: kein Prod-Overwrite ohne Dry-Run.

Preise, Remote-Zugriff.

Erweiterte Praxis: Wenn Sie mehrere Standorte haben, definieren Sie ein autoritatives Archiv pro Gateway-Instanz und vermeiden Sie „Merge by rsync“ zwischen Büros—Konflikte in SQLite-Sessions sind schwer zu debuggen und verify meldet oft erst spät. Für Mandantenfähigkeit: getrennte Präfixe im Objektspeicher, getrennte KMS-Schlüssel und getrennte Runbooks—sonst vermischen sich Staging- und Produktionsnachweise in Audits.

Automatisierung: Cron- oder launchd-Jobs, die create nachts ausführen, sollten Exit-Codes und stderr an dasselbe Observability-Backend schicken wie der Gateway-Healthcheck; stille Fehler sind der Hauptgrund, warum „wir hatten doch Backups“ im Postmortem vorkommt. Skripte, die Archive hochladen, müssen Integrität prüfen (gzip -t, SHA256) bevor sie das lokale Original löschen.

Compliance: Bei personenbezogenen Inhalten in Sessions oder Logs gehört die Zweckbindung der Archivierung auf den Auftragsverarbeitungsvertrag (AV) und die Speicherort-Dokumentation—OpenClaw-Archive sind keine „neutralen Configs“, sobald Chat-Inhalte oder Tokens enthalten sind. Löschkonzepte: wenn Nutzer Auskunft oder Löschung verlangt, reicht ein frisches Backup nicht; Sie müssen wissen, welche alten Tarballs noch existieren.

Performance: Große Workspaces sollten vor dem Snapshot bereinigt werden—Cache-Verzeichnisse, node_modules in experimentellen Pfaden, oder .git in geklonten Repos, wenn sie nicht Teil der Recovery-Story sind. Jede Minute Schreiblast im Fenster vor create reduziert die Wahrscheinlichkeit inkonsistenter Snapshots.

Fehleranalyse: Wenn verify eine einzelne Datei moniert, extrahieren Sie selektiv mit tar -tzf und prüfen Sie, ob der Pfad im manifest.json steht—Diskrepanzen zwischen Manifest und Payload sind typisch für abgebrochene Uploads oder AV-Quarantäne. Wenn restore startet, aber OAuth-Flüsse fehlschlagen, sind oft Uhrzeiten, Proxy-Header oder fehlende Keychain-Einträge die Ursache, nicht OpenClaw selbst.

Netzwerk: Für Cloud-Mac-Drills sollten Sie VPN-Profile und DNS-Suffixe dokumentieren, die zum Zeitpunkt des goldenen Backups aktiv waren. Ein Host im falschen VLAN sieht „grünes Gateway, rote Hintergrundjobs“—genau die Symptome, die bei Drills ohne Netzwerk-Parität verwechselt werden.

Organisation: Owner pro Runbook-Version, Review-Zyklus nach jedem Major-Release von OpenClaw, und Abgleich mit der Rollback-Anleitung. Ohne diesen Rhythmus veralten die fünf Schritte, während die CLI neue Flags bekommt.

Finanzen: Kosten für Speicher, Übungsfenster (On-Call-Zeit) und Hardware-Reserve getrennt ausweisen—nur so lässt sich ein Business Case für Tagesmiete oder dedizierte Macs sauber begründen.

Schulung: Neue Teammitglieder sollten einmal ein komplettes create→verify→restore auf einem Testkonto durchspielen, bevor sie Produktionsrechte erhalten—praktischer als Folien und reduziert Panik bei Incident.

Sicherheit: Archive niemals in öffentliche Git-Repos oder unverschlüsselte Cloud-Sync-Ordner legen; selbst „private“ Repos erben Gäste und Forks. Wenn ein Archiv geleakt wurde, ist Rotation der betroffenen Geheimnisse Pflicht, nicht nur „neues Passwort im Ticket“.

Abschluss dieser Erweiterung: Messen Sie verify-Latenz über Zeit; steigt sie, deutet das oft auf langsamer werdende Platten oder wachsende Workspaces hin—beides sind Budget-Signale für Bereinigung oder Kapazität.

Incident-Playbooks: Wenn das primäre Gateway ausfällt, sollte das Runbook nicht bei „tar entpacken“ enden, sondern bei einem klaren Entscheidungsbaum: zuerst verify, dann isoliertes Restore, dann Healthchecks, dann gestufte Freigabe des Datenverkehrs. Jeder Schritt braucht einen Rollback-Punkt—sonst ersetzen Sie einen Ausfall durch einen zweiten, weil halb migrierte Secrets im Umlauf sind.

Hardware-Lebenszyklus: Vor jedem Mac-Wechsel ein Archiv mit dokumentierter OpenClaw-Version und Node-Version; nach dem Restore auf neuer Hardware erneut doctor und kurzen Tool-Smoke ausführen. Ohne diese Paarung verwechseln Teams Hardwaredefekte mit Konfigurationsfehlern.

Virtualisierung: openclaw backup auf macOS-VMs ohne Metal oder mit eingeschränktem Keychain-Verhalten kann andere Symptome zeigen als Bare-Metal—Drills auf echter Apple-Hardware bleiben der Goldstandard für LaunchAgent- und TCC-Fragen.

Datenklassen: Trennen Sie Archive mit nur Konfiguration von solchen mit vollständigen Sessions; interne Policies können erfordern, dass Support-Teams nur den schmalen Typ exportieren dürfen. Technisch bedeutet das konsequente Nutzung von --only-config in automatisierten Jobs und explizite Freigabe für breitere Bundles.

Monitoring: Ergänzen Sie Gateway-Metriken um einen „Backup freshness“-Indikator (Zeit seit letztem erfolgreichen verify), nicht nur um Uhrzeit des letzten create—ein grünes Backup-Job-Flag ohne Verify ist trügerisch.

Vendor-Abhängigkeiten: Wenn OAuth-Provider Rotationen erzwingen, planen Sie Übungsfenster kurz nach solchen Fenstern ein; sonst validieren Sie Restore mit abgelaufenen Tokens und wundern sich über scheinbar „kaputte“ Archive.

Dokumentation: Screenshots von erfolgreichen verify-Ausgaben in das interne Wiki—redigiert, aber mit Versionsstrings—geben neuen On-Calls ein visuelles Zielbild und reduzieren Rückfragen in der Nacht.

Risikoaggregation: Mehrere Gateways auf einem physischen Mac zu konsolidieren, ohne getrennte Archive, erhöht die Blast-Radius—ein fehlerhaftes Restore kann alle Instanzen gleichzeitig treffen. Isolation auf Betriebssystem-Ebene oder dedizierte Hosts bleiben die sauberere Architektur.

Langzeitarchivierung: Wenn Sie Archive über Jahre aufbewahren, versionieren Sie auch die Restore-Anleitung pro OpenClaw-Major—ein Tarball von 2026 auf einer 2030er-CLI zu öffnen, ist ein eigenes Migrationsprojekt.

Schulungsnachweise: Für regulierte Branchen kann ein jährlicher Drill-Nachweis mit Teilnehmerliste und Ergebnis von verify gefordert sein—frühzeitig mit Compliance abstimmen, damit Logs nicht „zu technisch“ verworfen werden.

Zusammenfassung vor dem nächsten Quartals-Review: (a) Runbook-Version, (b) letzte erfolgreiche Cloud-Mac-Übung, (c) offene Risiken bei geteilten Konten oder Netzwerk-Homes, (d) geplante Token-Rotationen. Vier Bulletpoints genügen Führungskräften oft mehr als zwanzig Terminalscreenshots.

Kurz gesagt: openclaw backup ist nur dann „betriebsreif“, wenn Verify, isoliertes Restore und klare Geheimnis-Grenzen zusammen gedacht werden—alles andere bleibt Archivierung ohne belastbare Wiederanlauf-Fähigkeit. Wer das ignoriert, kauft sich im Incident teure Überraschungen nach und verliert Zeit, die Budgets wirklich nicht ersetzen können.

06. Hauptrechner vs. Tagesmiete und Conversion

Häufiges create+verify auf dem Laptop schützt den Alltag, ersetzt aber nicht den ersten Restore auf einem sauberen System: versteckte PATH-Einträge und alte LaunchAgents kaschieren Fehler.

Grenzen „nur lokal“: (1) Scheinsicherheit—Tokens nur in der interaktiven Shell, nicht unter launchd. (2) Berechtigungen/TCC—Kopieren als root vs. User ändert Extended Attributes; verify sieht keine UI-Zustimmungen. (3) Zeit/Bandbreite—riesige Tarballs über schlechtes VPN auf Nicht-macOS-VMs verschwenden Wochenenden ohne Apple-Stack-Nachweis. (4) Betriebskosten—ein Reserve-Mac nur für Drills gepatcht zu halten ist teuer; ohne Updates scheitert der nächste Drill an Gatekeeper statt an OpenClaw.

Warum kurzfristiges natives macOS (Tagesmiete) passt: Sie erhalten eine verwerfbare, gepatchte Apple-Umgebung, validieren Restore und launchd, und wischen zum Plantermin—ohne CAPEX für Hardware, die nur viermal im Jahr läuft. Wenn Sie langfristig Stabilität, volle Ökosystem-Kompatibilität und klare Übergaben wollen, ist eigener oder dedizierter Mac der Regelbetrieb; Tagesmiete ist die überschaubare Brücke, um Runbooks und Token-Rotation vor Investition zu beweisen—professionell beraten, nicht plakativ.

Quartals-Drills mit der Rollback-Checkliste und Tagesmiete vs. lokal für Management-Zahlen.

Operationalisierung: MTTR für verify, Anteil erfolgreicher Restores im Wartungsfenster und „Wiederholungstäter“-Hosts mit übermäßigen Archiven als Frühindikatoren für Workspace-Wildwuchs tracken. Postmortems brauchen Bundle aus Versionsstrings, verify-Logs und Diff Manifest↔Dateisystem—so wird openclaw backup zur Gewohnheit statt Heldengeschichte.

Gegenüber Legal/Finance klar trennen: Wiederherstellungszeit vs. Nachweis, dass keine Secrets exfiltrierten—unterschiedliche Budgetposten. Kalenderrisiko sinkt, wenn Übung wiederkehrend geplant ist, nicht nur bei Panik.