Una volta ho perso una settimana di configurazione di OpenClaw. Non a causa di un attacco o di un guasto hardware, ma perché ho eseguito un aggiornamento di sistema che ha corrotto la mia scheda SD. Tutto — la mia configurazione, le mie abilità personalizzate, i miei file di memoria, le definizioni dei miei cron job — andato.
Ricostruire tutto ha richiesto un intero weekend. E la parte peggiore: sapevo di dover avere dei backup. Continuavo a rimandare perché “lo configurerò domani.”
Ecco la strategia di backup che uso ora. Ci vogliono 20 minuti per impostarla e funziona automaticamente. Niente scuse.
Cosa Deve Essere Salvato
Non tutto. OpenClaw stesso può essere reinstallato. Il sistema operativo può essere ripristinato. Ciò che non può essere facilmente ricreato:
File di configurazione. La tua configurazione principale (YAML), chiavi API, impostazioni del modello, configurazioni di integrazione. Questo è ore di messa a punto che non vuoi rifare.
File di memoria e di lavoro. Memoria a lungo termine, note quotidiane, documentazione di progetto, istruzioni personalizzate. Questa è la conoscenza accumulata del tuo agente.
Abilità personalizzate. Qualsiasi abilità che hai scritto o modificato. Le abilità della comunità possono essere reinstallate, ma le tue personalizzate esistono solo sulla tua macchina.
Storia delle sessioni. Facoltativo — dipende se ti interessa delle conversazioni passate. Teniamo 30 giorni di storia per riferimento, ma non piangerei se dovesse scomparire.
Definizioni dei cron job. I tuoi compiti programmati e le loro configurazioni. Ricreare questi dalla memoria è suscettibile a errori.
La Strategia di Backup
Tre livelli, ognuno con uno scopo diverso:
Livello 1: Backup locale giornaliero. Un cron job che viene eseguito alle 2 AM, copia le directory critiche in una cartella datata sulla stessa macchina. Questo protegge da eliminazioni accidentali e errori di configurazione. Se sbaglio un file di configurazione alle 15, posso ripristinare la versione di ieri sera in pochi secondi.
Conservazione: 7 giorni di backup giornalieri. Quelli più vecchi vengono eliminati automaticamente.
Livello 2: Backup remoto giornaliero. Dopo il completamento del backup locale, rsync copia il backup su una seconda macchina (io uso un NAS sulla mia rete domestica, ma anche un VPS economico va bene). Questo protegge da guasti hardware. Se la scheda SD del Pi muore, 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 crescere indefinitamente.
Livello 3: Backup settimanale su cloud. Ogni domenica, i file di configurazione critici (solo le cose essenziali — configurazione, abilità, file di memoria — circa 5MB in totale) vengono crittografati e caricati su un servizio di cloud storage. Questo è il livello di ripristino in caso di disastro. Se la mia casa brucia e porta via sia il Pi che il NAS, ho ancora le mie configurazioni.
Uso rclone per sincronizzare con Backblaze B2 (poche centinaia di euro al mese per questa quantità di dati). I file vengono crittografati localmente prima del caricamento usando GPG.
Lo Script di Backup
Il backup completo è uno script bash di circa 30 righe:
1. Definisci le directory da salvare (configurazione, spazio di lavoro, abilità, sessioni)
2. Crea un tarball datato di quelle directory
3. Tieni gli ultimi 7 tarball locali, elimina quelli più vecchi
4. Rsync l’ultimo tarball sul server remoto
5. La domenica: crittografa e carica su cloud storage
6. Registra il risultato (successo/fallimento, dimensioni, durata)
Lo script viene eseguito tramite cron alle 2 AM ogni giorno. Tempo totale di esecuzione: circa 30 secondi per una normale installazione.
Test di Ripristino
Un backup che non hai mai testato non è un backup — è una speranza.
Ogni mese, faccio un test di ripristino. Non sul mio Pi in produzione — su una scheda SD di riserva. Flasho un OS fresco, installo OpenClaw, ripristino dal backup e verifico che tutto funzioni. L’intero test richiede circa 30 minuti.
Le cose che ho scoperto nei test di ripristino:
– Un percorso di backup che è cambiato dopo un aggiornamento di OpenClaw (la struttura delle directory è cambiata)
– Una definizione di cron job che faceva riferimento a un percorso locale non incluso nel backup
– Una chiave API che era memorizzata in una variabile d’ambiente anziché nel file di configurazione (e quindi non era stata salvata)
Ciascuna di queste sarebbe stata una brutta sorpresa durante un vero recupero. Meglio scoprirle durante un test tranquillo di sabato piuttosto che durante un’emergenza alle 3 di notte.
La Procedura di Recupero
Quando le cose vanno male, vuoi una lista di controllo, non un albero decisionale. Ecco la mia:
1. Flashare un OS fresco su una nuova scheda SD / SSD
2. Installare Node.js e OpenClaw
3. Copiare il tarball di backup sul nuovo sistema
4. Estrarre nelle directory corrette
5. Verificare chiavi API e connessioni
6. Avviare OpenClaw e verificare la funzionalità di base
7. Controllare i cron job e i compiti programmati
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 weekend che ho passato a ricostruire senza backup.
Cosa Molte Persone Sbagliano
Salvare troppa roba. Non è necessario eseguire il backup dell’intero sistema. L’OS e OpenClaw stesso possono essere reinstallati facilmente. Fai il backup solo di ciò che è unico per la tua installazione.
Non eseguire il backup delle chiavi API. Se le tue chiavi API sono in variabili d’ambiente anziché 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 un’email con il file di configurazione una volta a settimana.
Non testare mai i ripristini. Testa il tuo processo di ripristino prima di averne bisogno. Il momento per scoprire che il tuo backup è incompleto non è durante un’emergenza.
🕒 Published: