Ich habe einmal eine Woche mit der Konfiguration von OpenClaw verloren. Nicht wegen eines Hacks oder eines Hardwarefehlers. Weil ich ein Systemupdate durchgeführt habe, das meine SD-Karte beschädigt hat. Alles — meine Konfiguration, meine benutzerdefinierten Fähigkeiten, meine Speicherdateien, meine Cron-Job-Definitionen — weg.
Der Wiederaufbau dauerte ein ganzes Wochenende. Und das Schlimmste: Ich wusste, dass ich Backups hätte machen sollen. Ich habe es immer wieder aufgeschoben, weil ich dachte: “Ich richte es morgen ein.”
Hier ist die Backup-Strategie, die ich jetzt benutze. Sie braucht 20 Minuten zur Einrichtung und läuft automatisch. Keine Ausreden.
Was Sicherung braucht
Nicht alles. OpenClaw selbst kann neu installiert werden. Das Betriebssystem kann neu geflasht werden. Was nicht leicht reproduziert werden kann:
Konfigurationsdateien. Deine Hauptkonfiguration (YAML), API-Schlüssel, Modelleinstellungen, Integrationskonfigurationen. Das sind Stunden sorgfältiger Anpassungen, die du nicht neu machen möchtest.
Speicher- und Arbeitsbereichsdateien. Langzeitgedächtnis, tägliche Notizen, Projektdokumentation, benutzerdefinierte Anweisungen. Dies sind das angesammelte Wissen deines Agenten.
Benutzerdefinierte Fähigkeiten. Alle Fähigkeiten, die du geschrieben oder modifiziert hast. Gemeinschaftsfähigkeiten können neu installiert werden, deine benutzerdefinierten existieren jedoch nur auf deinem Rechner.
Sitzungshistorie. Optional — hängt davon ab, ob dir vergangene Gespräche wichtig sind. Ich behalte 30 Tage Historie als Referenz, aber ich würde nicht weinen, wenn sie verschwinden würde.
Cron-Job-Definitionen. Deine geplanten Aufgaben und deren Konfigurationen. Diese aus dem Gedächtnis neu zu erstellen, ist fehleranfällig.
Die Backup-Strategie
Drei Ebenen, jede mit einem anderen Zweck:
Ebene 1: Tägliches lokales Backup. Ein Cron-Job, der um 2 Uhr nachts läuft, kopiert die kritischen Verzeichnisse in einen datierten Ordner auf demselben Rechner. Dies schützt vor versehentlichem Löschen und Konfigurationsfehlern. Wenn ich um 15 Uhr eine Konfigurationsdatei vermassle, kann ich in Sekunden die Version von gestern Abend wiederherstellen.
Aufbewahrung: 7 Tage täglicher Backups. Ältere werden automatisch gelöscht.
Ebene 2: Tägliches Remote-Backup. Nachdem das lokale Backup abgeschlossen ist, kopiert rsync das Backup auf einen zweiten Rechner (ich benutze ein NAS in meinem Heimnetzwerk, aber ein günstiger VPS funktioniert auch). Dies schützt vor Hardwarefehlern. Wenn die SD-Karte des Pi ausfällt, existiert das Backup anderswo.
Der rsync-Befehl ist einfach: rsync -az --delete /backup/openclaw/ nas:/backups/openclaw/. Das --delete Flag hält die Ferne Kopie synchron, ohne unendlich zu wachsen.
Ebene 3: Wöchentliches Cloud-Backup. Jeden Sonntag werden die kritischen Konfigurationsdateien (nur die kleinen Sachen — Konfiguration, Fähigkeiten, Speicherdateien — insgesamt etwa 5MB) verschlüsselt und in die Cloud gespeichert. Dies ist die Schicht für die Katastrophenwiederherstellung. Wenn mein Haus abbrennt und sowohl den Pi als auch das NAS vernichtet, habe ich immer noch meine Konfigurationen.
Ich benutze rclone, um zu Backblaze B2 zu synchronisieren (Cents pro Monat für diese Datenmenge). Die Dateien werden lokal vor dem Hochladen mit GPG verschlüsselt.
Das Backup-Skript
Das gesamte Backup besteht aus einem Bash-Skript, etwa 30 Zeilen lang:
1. Definiere die Verzeichnisse, die gesichert werden sollen (Konfiguration, Arbeitsbereich, Fähigkeiten, Sitzungen)
2. Erstelle ein datiertes Tarball dieser Verzeichnisse
3. Behalte die letzten 7 lokalen Tarballs, lösche ältere
4. Rsync das neueste Tarball auf den Remote-Server
5. An Sonntagen: verschlüsseln und in die Cloud speichern
6. Protokolliere das Ergebnis (Erfolg/Misserfolg, Größen, Dauer)
Das Skript läuft täglich um 2 Uhr nachts über Cron. Gesamtdauer der Ausführung: etwa 30 Sekunden für eine typische Installation.
Wiederherstellungstests
Ein Backup, das du nie getestet hast, ist kein Backup — es ist eine Hoffnung.
Jeden Monat mache ich einen Wiederherstellungstest. Nicht auf meinem Produktions-Pi — auf einer Ersatz-SD-Karte. Frisches Betriebssystem flashen, OpenClaw installieren, aus dem Backup wiederherstellen und überprüfen, ob alles funktioniert. Der gesamte Test dauert etwa 30 Minuten.
Dinge, die ich in den Wiederherstellungstests entdeckt habe:
– Ein Backup-Pfad, der sich nach einem OpenClaw-Update geändert hat (die Verzeichnisstruktur hat sich verschoben)
– Eine Cron-Job-Definition, die auf einen lokalen Pfad verwies, der nicht im Backup enthalten war
– Ein API-Schlüssel, der in einer Umgebungsvariablen anstelle der Konfigurationsdatei gespeichert war (und daher nicht gesichert wurde)
Jedes dieser Probleme wäre während einer echten Wiederherstellung eine böse Überraschung gewesen. Es ist besser, sie während eines ruhigen Tests an einem Samstag zu entdecken, als während eines Notfalls um 3 Uhr morgens.
Das Wiederherstellungsverfahren
Wenn etwas schief geht, möchtest du eine Checkliste, kein Entscheidungsbaum. Hier ist meine:
1. Frisches Betriebssystem auf neuer SD-Karte / SSD flashen
2. Node.js und OpenClaw installieren
3. Backup-Tarball auf das neue System kopieren
4. In die richtigen Verzeichnisse extrahieren
5. API-Schlüssel und Verbindungen überprüfen
6. OpenClaw starten und grundlegende Funktionalität überprüfen
7. Cron-Jobs und geplante Aufgaben überprüfen
8. Überprüfen, ob Speicher- und Arbeitsbereichsdateien intakt sind
Gesamte Wiederherstellungszeit: etwa 45 Minuten von einer leeren SD-Karte zu einem voll funktionsfähigen System. Vergleiche das mit dem Wochenende, das ich ohne Backups mit dem Wiederaufbau verbracht habe.
Was die meisten Leute falsch machen
Zu viel sichern. Du musst nicht das gesamte System sichern. Das Betriebssystem und OpenClaw selbst können leicht neu installiert werden. Sichere nur das, was einzigartig für deine Installation ist.
API-Schlüssel nicht sichern. Wenn deine API-Schlüssel in Umgebungsvariablen statt in Konfigurationsdateien sind, sind sie nicht in deinem Backup enthalten. Bewege sie in die Konfigurationsdatei oder halte ein separates, sicheres Dokument mit allen Schlüsseln bereit.
Keine Remote-Kopie. Ein Backup auf demselben Rechner, der ausfällt, ist überhaupt kein Backup. Minimal solltest du auf einen zweiten Rechner kopieren. Die einfachste Version: Sende dir selbst einmal pro Woche die Konfigurationsdatei per E-Mail.
Nie Wiederherstellungen testen. Teste deinen Wiederherstellungsprozess, bevor du ihn benötigst. Der Zeitpunkt, um herauszufinden, dass dein Backup unvollständig ist, ist nicht während eines Notfalls.
🕒 Published: