OpenClaw-Backups: Archive, SQLite und Verifikation richtig nutzen

Der Ausfall kommt ungelegen, aber im Sicherungsordner liegt immerhin ein Archiv. Ob es sich öffnen, prüfen und tatsächlich zurückspielen lässt, hat allerdings nie jemand geklärt. Genau dann zeigt sich der Unterschied zwischen einer vorhandenen Datei und einem belastbaren Backup.

Bei OpenClaw entscheidet deshalb nicht allein das Erstellen des Archivs. Ebenso wichtig sind die Vorschau davor, die Verifikation danach und ein Restore in ein getrenntes Testverzeichnis.

Erst simulieren, dann das Ziel festlegen

openclaw backup create erstellt ein Archiv mit dem OpenClaw-State, der Konfiguration, den Auth-Profilen, den Zugangsdaten für Kanäle und Provider, den Sessions und optional den Workspaces. Ein Vollarchiv enthält damit einen großen Teil des laufenden Setups. Es gehört nicht in einen beliebigen Sync-Ordner, sondern an einen Speicherort mit passenden Zugriffsrechten und einer getrennten Aufbewahrungsstrategie.

Vor dem eigentlichen Lauf liefert openclaw backup create --dry-run --json eine Vorschau auf den geplanten Umfang. Dieser Schritt lohnt sich besonders nach Änderungen an Konfiguration oder Workspaces: Er zeigt vor dem Schreiben, was in die Sicherung einfließen soll. Dateiname und Größe verraten das später nicht zuverlässig.

Für das Ziel gelten Schutzregeln. OpenClaw überschreibt keine vorhandene Archivdatei. Ausgabepfade innerhalb der gesicherten State- oder Workspace-Verzeichnisse werden ebenfalls abgelehnt, damit sich das Archiv nicht selbst einschließt. Das verhindert zwei typische Fehlkonfigurationen, ersetzt aber nicht die Entscheidung für einen geeigneten Ablageort.

Auch bei Secrets lohnt ein genauer Blick. Vollarchive enthalten die aktive Konfiguration samt benötigten Include-Dateien; Text, Kommentare und Umgebungs-Platzhalter bleiben erhalten. Aufgelöste Secrets landen nicht in der Config-Kopie. Trotzdem können Zugangsdaten und Sessions Teil des Archivs sein. Das Paket bleibt sensible Betriebsinformation.

Die Prüfung gehört zum Backup

Mit openclaw backup create --verify wird das Archiv direkt nach dem Schreiben geprüft. Die Verifikation weist Traversal-Pfade und unsichere symbolische Links zurück, kontrolliert die im Manifest aufgeführten Inhalte und validiert die erfassten SQLite-Datenbanken. Dazu gehören der Root-Snapshot und die Agent-Snapshots.

Diese Prüfungen beantworten unterschiedliche Fragen: Lässt sich das Paket sicher verarbeiten? Sind die angekündigten Inhalte vorhanden? Sind die erfassten Datenbanken konsistent? Ein bloßer Größenvergleich beantwortet keine davon.

Trotzdem ist ein erfolgreiches --verify kein vollständiger Wiederherstellungstest. Andere Dateien, darunter Plugin-Snapshots, bleiben bei Verifikation und Restore inhaltlich undurchsichtig. Der nächste sinnvolle Schritt ist deshalb ein getrenntes Zielverzeichnis:

openclaw backup restore <archiv> --target ./restored-openclaw

Danach sollte das Betriebsteam Erwartung und Ergebnis vergleichen: Ist die vorgesehene Verzeichnisstruktur vorhanden? Sind Konfiguration und benötigte Datenbanken lesbar? Fehlen Bestandteile, die für den eigenen Betrieb relevant sind? Erst diese Kontrolle zeigt, ob das Archiv den konkreten Wiederanlauf abdeckt.

Ein brauchbarer Ablauf ist damit überschaubar: Nach größeren Änderungen zunächst den Dry-Run prüfen, anschließend ein Archiv mit --verify erstellen und in festen Abständen einen Restore in ein Testverzeichnis durchführen. Datum und Ergebnis gehören in das Betriebsprotokoll. Scheitert einer dieser Schritte, bleibt die vorherige Sicherung unangetastet, bis Ursache und neuer Lauf geklärt sind.

Vollarchiv, SQLite-Snapshot oder Git-Historie

Nicht jedes Sicherungsziel braucht ein Vollarchiv. OpenClaw bietet daneben zwei Wege, die sich auf Datenbanken konzentrieren.

Das Vollarchiv bündelt Konfiguration, Zugangsdaten, Sessions und auf Wunsch die Workspaces. Es passt, wenn ein großer Teil des Setups nach einem Ausfall wieder verfügbar sein muss, ist aber zugleich das sensibelste Artefakt.

Der SQLite-Snapshot über openclaw backup sqlite erzeugt eine portable Sicherung genau einer OpenClaw-eigenen Datenbank: entweder der globalen Datenbank oder der eines einzelnen Agenten. Das ist sinnvoll, wenn ein bestimmter Datenbestand separat gesichert oder untersucht werden soll.

Die Git-Historie über openclaw backup git legt Tabellen als deterministische JSONL-Dateien in einem eigenen Repository ab. Ein Repository kann die gemeinsame Datenbank und alle Agent-Datenbanken aufnehmen. Jeder Lauf erzeugt einen Commit; bei unverändertem Inhalt meldet der Befehl no changes und legt keinen neuen Commit an. Dieses Repository sollte ausschließlich für OpenClaw-Backups genutzt werden, dem aktuellen Nutzer gehören und weder für die Gruppe noch für andere beschreibbar sein.

Die Auswahl beginnt mit einer Betriebsfrage: Was muss nach einem Ausfall zurückkommen? Für das gesamte Setup liegt das Vollarchiv nahe. Für einzelne Datenbestände sind SQLite-Snapshot oder Git-Historie gezielter und leichter zu kontrollieren.

Fertig ist das Backup erst nach dem Test

Eine erzeugte Datei ist nur der Anfang. Belastbar wird die Sicherung, wenn die integrierte Prüfung bestanden ist und ein Restore im Testverzeichnis das erwartete Ergebnis liefert. Wer diesen Ablauf regelmäßig durchspielt, entdeckt Lücken im Normalbetrieb – nicht erst während des Ausfalls.