Ho perso una settimana di configurazione di OpenClaw una volta. Non a causa di un hack o di un guasto hardware. Perché ho eseguito un aggiornamento del sistema che ha corrotto la mia scheda SD. Tutto — la mia configurazione, le mie competenze personalizzate, i miei file di memoria, le mie definizioni di cron — scomparso.
Ricostruire ha preso tutto un fine settimana. E la cosa peggiore è che sapevo che avrei dovuto fare dei backup. Continuavo a rimandare dicendo « lo farò domani. »
Ecco la strategia di backup che uso ora. Ci vogliono 20 minuti per impostarla e funziona automaticamente. Niente scuse.
Ciò che deve essere salvato
Non tutto. OpenClaw stesso può essere reinstallato. Il sistema operativo può essere reinstallato. Ciò che non può essere facilmente ricreato:
File di configurazione. La tua configurazione principale (YAML), chiavi API, impostazioni del modello, configurazioni di integrazione. Sono ore di regolazioni precise che non vuoi rifare.
File di memoria e di lavoro. Memoria a lungo termine, appunti quotidiani, documentazione di progetto, istruzioni personalizzate. È il sapere accumulato del tuo agente.
Competenze personalizzate. Tutte le competenze che hai scritto o modificato. Le competenze della comunità possono essere reinstallate, ma le tue esistono solo sulla tua macchina.
Storico delle sessioni. Facoltativo — dipende dall’importanza che dai alle conversazioni passate. Tengo 30 giorni di storico per riferimento, ma non piangerei se sparisse.
Definizioni delle cron. I tuoi compiti programmati e le loro configurazioni. Ricreare questo a memoria è soggetto a errori.
La strategia di backup
Tre livelli, ognuno con uno scopo diverso:
Livello 1: Backup locale quotidiano. Un job cron che si esegue alle 2 di mattina, copia le directory critiche in una cartella datata sulla stessa macchina. Questo protegge contro cancellazioni accidentali e errori di configurazione. Se commetto un errore in un file di configurazione alle 15, posso ripristinare la versione della notte precedente in pochi secondi.
Conservazione: 7 giorni di backup quotidiani. I più vecchi vengono automaticamente eliminati.
Livello 2: Backup remoto quotidiano. Dopo il backup locale, rsync copia il backup su una seconda macchina (uso un NAS nella mia rete domestica, ma un VPS economico va bene). Questo protegge contro guasti hardware. Se la scheda SD del Pi va in panne, il backup esiste altrove.
Il comando rsync è semplice: rsync -az --delete /backup/openclaw/ nas:/backups/openclaw/. L’opzione --delete mantiene la copia remota sincronizzata senza crescita indefinita.
Livello 3: Backup settimanale nel cloud. Ogni domenica, i file di configurazione critici (solo le piccole cose — configurazione, competenze, file di memoria — circa 5 Mo in totale) vengono crittografati e caricati nello storage cloud. Questo è il livello di recupero dopo sinistro. Se la mia casa brucia e porta via sia il Pi che il NAS, ho ancora le mie configurazioni.
Uso rclone per sincronizzare verso Backblaze B2 (qualche centesimo al mese per questa quantità di dati). I file sono crittografati localmente prima del caricamento utilizzando GPG.
Lo script di backup
Il backup completo è uno script bash di circa 30 righe:
1. Definire le directory da salvare (config, spazio di lavoro, competenze, sessioni)
2. Creare un archivio tar datato di queste directory
3. Conservarne gli ultimi 7 archivi tar locali, eliminare i più vecchi
4. Rsync dell’ultimo archivio tar verso il server remoto
5. La domenica: crittografare e caricare nello storage cloud
6. Registrare il risultato (successo/fallimento, dimensioni, durata)
Lo script si esegue tramite cron alle 2 di mattina ogni giorno. Tempo di esecuzione totale: circa 30 secondi per un’installazione tipica.
Test di ripristino
Un backup che non hai mai testato non è un backup — è solo una speranza.
Ogni mese, faccio un test di ripristino. Non sul mio Pi di produzione — su una scheda SD di scorta. Flashare un nuovo sistema operativo, installare OpenClaw, ripristinare dal backup e verificare che tutto funzioni. Il test richiede circa 30 minuti.
Cose che ho scoperto durante i test di ripristino:
– Un percorso di backup che è cambiato dopo un aggiornamento di OpenClaw (la struttura delle directory è cambiata)
– Una definizione di cron che si riferiva a un percorso locale non incluso nel backup
– Una chiave API che era memorizzata in una variabile d’ambiente invece che nel file di configurazione (e quindi non è stata salvata)
Ciascuno di questi errori avrebbe potuto essere una brutta sorpresa durante un vero ripristino. È meglio scoprirli durante un test tranquillo del sabato piuttosto che durante un’emergenza alle 3 di mattina.
La procedura di recupero
Quando le cose vanno male, vuoi una lista di controllo, non un albero decisionale. Ecco la mia:
1. Flashare un nuovo sistema operativo su una nuova scheda SD / SSD
2. Installare Node.js e OpenClaw
3. Copiare l’archivio tar di backup nel nuovo sistema
4. Estrarre nelle directory corrette
5. Controllare le chiavi API e le connessioni
6. Avviare OpenClaw e verificare che le funzionalità di base funzionino
7. Controllare le cron e quelle pianificate
8. Verificare che i file di memoria e di lavoro siano intatti
Tempo totale di recupero: circa 45 minuti da una scheda SD vuota a un sistema completamente operativo. Confronta questo con il fine settimana che ho passato a ricostruire senza backup.
Cosa sbagliano la maggior parte delle persone
Backup eccessivi. Non hai bisogno di salvare tutto il sistema. L’OS e OpenClaw stesso possono essere facilmente reinstallati. Salva solo ciò che è unico per la tua installazione.
Non salvare le chiavi API. Se le tue chiavi API sono in variabili d’ambiente invece che in file di configurazione, non saranno nel tuo backup. Spostale nel file di configurazione o mantieni un documento sicuro separato con tutte le chiavi.
Nessuna copia remota. Un backup sulla stessa macchina che fallisce non è affatto un backup. Al minimo, copia su una seconda macchina. La versione più semplice: inviati via email il file di configurazione una volta a settimana.
Mai testare i ripristini. Testa il tuo processo di ripristino prima di averne bisogno. Il momento migliore per scoprire che il tuo backup è incompleto non è durante un’emergenza.
🕒 Published: