Ich habe einmal eine Woche mit der Konfiguration von OpenClaw verloren. Nicht wegen eines Hacks oder eines Hardwarefehlers. Sondern, weil ich ein Systemupdate ausgefü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 hat ein ganzes Wochenende gedauert. Und das Schlimmste ist, dass ich wusste, dass ich Backups hätte machen müssen. Ich habe es ständig aufgeschoben, weil ich dachte: „Ich mache es morgen.“
Hier ist die Backup-Strategie, die ich jetzt verwende. Sie dauert 20 Minuten, um sie einzurichten, und funktioniert automatisch. Keine Ausreden.
Was gesichert werden muss
Nicht alles. OpenClaw selbst kann neu installiert werden. Das Betriebssystem kann neu installiert werden. Was nicht leicht neu erstellt werden kann:
Konfigurationsdateien. Ihre Hauptkonfiguration (YAML), API-Schlüssel, Modellparameter, Integrationskonfigurationen. Das sind Stunden minutösen Feintunings, die Sie nicht wiederholen möchten.
Speicher- und Arbeitsdateien. Langzeitgedächtnis, tägliche Notizen, Projektdokumentation, benutzerdefinierte Anweisungen. Das ist das angesammelte Wissen Ihres Agenten.
Benutzerdefinierte Fähigkeiten. Alle Fähigkeiten, die Sie geschrieben oder geändert haben. Die Community-Fähigkeiten können neu installiert werden, aber Ihre existieren nur auf Ihrer Maschine.
Sitzungshistorie. Optional – das hängt davon ab, wie wichtig Ihnen vergangene Gespräche sind. Ich behalte 30 Tage Historie zur Referenz, aber ich würde nicht weinen, wenn sie verschwinden würde.
Cron-Job-Definitionen. Ihre geplanten Aufgaben und deren Konfigurationen. Das 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 morgens ausgeführt wird und kritische Verzeichnisse in einen datierten Ordner auf derselben Maschine kopiert. Das schützt vor versehentlichem Löschen und Konfigurationsfehlern. Wenn ich um 15 Uhr einen Fehler in einer Konfigurationsdatei mache, kann ich die Version von der Nacht zuvor in wenigen Sekunden wiederherstellen.
Aufbewahrung: 7 Tage tägliche Backups. Die ältesten werden automatisch gelöscht.
Ebene 2: Tägliches Remote-Backup. Nach dem lokalen Backup kopiert rsync das Backup auf eine zweite Maschine (ich verwende ein NAS in meinem Heimnetzwerk, aber ein kostengünstiger VPS funktioniert auch). Das schützt vor Hardwareausfällen. Wenn die SD-Karte des Pi ausfällt, existiert das Backup woanders.
Der rsync-Befehl ist einfach: rsync -az --delete /backup/openclaw/ nas:/backups/openclaw/. Die Option --delete hält die Remote-Kopie synchronisiert, ohne dass sie unbegrenzt wächst.
Ebene 3: Wöchentliches Cloud-Backup. Jeden Sonntag werden die kritischen Konfigurationsdateien (nur die kleinen Dinge – Konfiguration, Fähigkeiten, Speicherdateien – insgesamt etwa 5 MB) verschlüsselt und in den Cloud-Speicher hochgeladen. Das ist die Stufe der Wiederherstellung nach Katastrophen. Wenn mein Haus brennt und sowohl der Pi als auch das NAS verloren gehen, habe ich immer noch meine Konfigurationen.
Ich benutze rclone, um mit Backblaze B2 zu synchronisieren (ein paar Cent pro Monat für diese Datenmenge). Die Dateien werden lokal verschlüsselt, bevor sie hochgeladen werden, mit GPG.
Das Backup-Skript
Das gesamte Backup ist ein Bash-Skript von etwa 30 Zeilen:
1. Verzeichnisse festlegen, die gesichert werden sollen (Konfiguration, Arbeitsbereich, Fähigkeiten, Sitzungen)
2. Ein datiertes tar-Archiv dieser Verzeichnisse erstellen
3. Die letzten 7 lokalen tar-Archive aufbewahren, die ältesten löschen
4. Rsync des letzten tar-Archivs auf den Remote-Server
5. Am Sonntag: verschlüsseln und in den Cloud-Speicher hochladen
6. Ergebnis protokollieren (Erfolg/Misserfolg, Größen, Dauer)
Das Skript wird über Cron jeden Tag um 2 Uhr morgens ausgeführt. Gesamte Ausführungszeit: etwa 30 Sekunden für eine typische Installation.
Wiederherstellungstests
Ein Backup, das Sie nie getestet haben, ist kein Backup – es ist nur eine Hoffnung.
Jeden Monat mache ich einen Wiederherstellungstest. Nicht auf meinem Produktions-Pi – auf einer Ersatz-SD-Karte. Ein neues Betriebssystem flashen, OpenClaw installieren, aus dem Backup wiederherstellen und überprüfen, dass alles funktioniert. Der Test dauert etwa 30 Minuten.
Dinge, die ich bei den Wiederherstellungstests herausgefunden habe:
– Ein Backup-Pfad, der sich nach einem Update von OpenClaw geändert hat (die Verzeichnisstruktur hat sich verschoben)
– Eine Cron-Job-Definition, die auf einen lokalen Pfad verweist, der nicht im Backup enthalten ist
– Ein API-Schlüssel, der in einer Umgebungsvariable gespeichert war, anstatt in der Konfigurationsdatei (und deshalb nicht gesichert wurde)
Jeder dieser Fehler hätte bei einer echten Wiederherstellung eine unangenehme Überraschung sein können. Besser, sie bei einem ruhigen Test am Samstag zu finden, als während eines Notfalls um 3 Uhr morgens.
Die Wiederherstellungsverfahren
Wenn die Dinge schiefgehen, möchten Sie eine Checkliste, kein Entscheidungsbaum. Hier ist meine:
1. Flashen Sie ein neues Betriebssystem auf eine neue SD-Karte / SSD
2. Installieren Sie Node.js und OpenClaw
3. Kopieren Sie das Backup-tar-Archiv in das neue System
4. Entpacken in die richtigen Verzeichnisse
5. Überprüfen Sie die API-Schlüssel und Verbindungen
6. Starten Sie OpenClaw und überprüfen Sie, ob die grundlegenden Funktionen funktionieren
7. Überprüfen Sie die Cron- und geplanten Aufgaben
8. Überprüfen Sie, ob die Speicher- und Arbeitsdateien intakt sind
Gesamte Wiederherstellungszeit: etwa 45 Minuten von einer leeren SD-Karte zu einem vollständig funktionsfähigen System. Vergleichen Sie das mit dem Wochenende, das ich damit verbracht habe, ohne Backups neu zu konstruieren.
Was die meisten Leute falsch machen
Zu viel sichern. Sie müssen nicht das gesamte System sichern. Das OS und OpenClaw selbst können leicht neu installiert werden. Sichern Sie nur, was einzigartig für Ihre Installation ist.
API-Schlüssel nicht sichern. Wenn Ihre API-Schlüssel in Umgebungsvariablen anstelle von Konfigurationsdateien sind, werden sie nicht in Ihrem Backup sein. Verschieben Sie sie in die Konfigurationsdatei oder führen Sie ein separates gesichertes Dokument mit allen Schlüsseln.
Keine Remote-Kopie. Ein Backup auf derselben Maschine, die ausfällt, ist überhaupt kein Backup. Mindestens sollten Sie auf eine zweite Maschine kopieren. Die einfachste Version: Senden Sie sich die Konfigurationsdatei einmal pro Woche per E-Mail.
Nie Wiederherstellungen testen. Testen Sie Ihren Wiederherstellungsprozess, bevor Sie ihn benötigen. Der Zeitpunkt, an dem Sie herausfinden, dass Ihr Backup unvollständig ist, sollte nicht während eines Notfalls sein.
🕒 Published: