J’ai perdu une semaine de configuration d’OpenClaw une fois. Pas à cause d’un piratage ou d’une panne matérielle. Parce que j’ai effectué une mise à jour système qui a corrompu ma carte SD. Tout — ma configuration, mes compétences personnalisées, mes fichiers de mémoire, mes définitions de tâches cron — disparu.
Reconstruire a pris tout un week-end. Et le pire, c’est que je savais que je devrais avoir des sauvegardes. Je repoussais juste parce que « je vais le mettre en place demain. »
Voici la stratégie de sauvegarde que j’utilise maintenant. Elle prend 20 minutes à configurer et fonctionne automatiquement. Pas d’excuses.
Ce qui a besoin d’être sauvegardé
Pas tout. OpenClaw lui-même peut être réinstallé. Le système d’exploitation peut être reflasqué. Ce qui ne peut pas être facilement recréé :
Fichiers de configuration. Votre configuration principale (YAML), clés API, paramètres de modèle, configurations d’intégration. C’est des heures de réglages minutieux que vous ne voudriez pas refaire.
Fichiers de mémoire et de travail. Mémoire à long terme, notes quotidiennes, documentation de projet, instructions personnalisées. C’est le savoir accumulé de votre agent.
Compétences personnalisées. Toutes les compétences que vous avez écrites ou modifiées. Les compétences communautaires peuvent être réinstallées, mais les vôtres n’existent que sur votre machine.
Historique de session. Facultatif — dépend de l’importance que vous accordez aux conversations passées. Je conserve 30 jours d’historique pour référence, mais je ne pleurerais pas si cela disparaissait.
Définitions de tâches cron. Vos tâches planifiées et leurs configurations. Recréer cela de mémoire est sujet aux erreurs.
La stratégie de sauvegarde
Trois couches, chacune ayant un but différent :
Couche 1 : Sauvegarde locale quotidienne. Une tâche cron qui s’exécute à 2 heures du matin, copie les répertoires critiques dans un dossier daté sur la même machine. Cela protège contre la suppression accidentelle et les erreurs de configuration. Si je fais une erreur dans un fichier de configuration à 15 heures, je peux restaurer la version d’hier en quelques secondes.
Conservation : 7 jours de sauvegardes quotidiennes. Les plus anciennes sont supprimées automatiquement.
Couche 2 : Sauvegarde distante quotidienne. Après que la sauvegarde locale soit terminée, rsync copie la sauvegarde sur une deuxième machine (j’utilise un NAS sur mon réseau domestique, mais un VPS pas cher fonctionne aussi). Cela protège contre les pannes matérielles. Si la carte SD du Pi meurt, la sauvegarde existe ailleurs.
La commande rsync est simple : rsync -az --delete /backup/openclaw/ nas:/backups/openclaw/. Le drapeau --delete maintient la copie distante synchronisée sans croître indéfiniment.
Couche 3 : Sauvegarde cloud hebdomadaire. Chaque dimanche, les fichiers de configuration critiques (juste les petites choses — config, compétences, fichiers de mémoire — environ 5 Mo au total) sont chiffrés et téléchargés sur un stockage cloud. C’est la couche de récupération après sinistre. Si ma maison brûle et emporte à la fois le Pi et le NAS, j’ai toujours mes configurations.
J’utilise rclone pour synchroniser vers Backblaze B2 (quelques centimes par mois pour cette quantité de données). Les fichiers sont chiffrés localement avant le téléchargement en utilisant GPG.
Le script de sauvegarde
La sauvegarde complète est un script bash, d’environ 30 lignes :
1. Définir les répertoires à sauvegarder (configuration, espace de travail, compétences, sessions)
2. Créer un tarball daté de ces répertoires
3. Conserver les 7 derniers tarballs locaux, supprimer les plus anciens
4. Rsync le dernier tarball vers le serveur distant
5. Le dimanche : chiffrer et télécharger vers le stockage cloud
6. Enregistrer le résultat (succès/échec, tailles, durée)
Le script s’exécute via cron à 2 heures du matin chaque jour. Temps d’exécution total : environ 30 secondes pour une installation typique.
Tester les restaurations
Une sauvegarde que vous n’avez jamais testée n’est pas une sauvegarde — c’est un espoir.
Chaque mois, je fais un test de restauration. Pas sur mon Pi de production — sur une carte SD de rechange. Flash un nouvel OS, installer OpenClaw, restaurer à partir de la sauvegarde, et vérifier que tout fonctionne. L’ensemble du test prend environ 30 minutes.
Des choses que j’ai découvertes lors des tests de restauration :
– Un chemin de sauvegarde qui a changé après une mise à jour d’OpenClaw (la structure des répertoires a changé)
– Une définition de tâche cron qui faisait référence à un chemin local non inclus dans la sauvegarde
– Une clé API qui était stockée dans une variable d’environnement au lieu du fichier de configuration (et donc n’a pas été sauvegardée)
Chacune de ces erreurs aurait été une mauvaise surprise lors d’une vraie récupération. Mieux vaut les découvrir lors d’un test calme un samedi que lors d’une urgence à 3 heures du matin.
La procédure de récupération
Quand les choses vont mal, vous voulez une liste de contrôle, pas un arbre de décision. Voici la mienne :
1. Flasher un nouvel OS sur une nouvelle carte SD / SSD
2. Installer Node.js et OpenClaw
3. Copier le tarball de sauvegarde sur le nouveau système
4. Extraire dans les répertoires corrects
5. Vérifier les clés API et les connexions
6. Démarrer OpenClaw et vérifier les fonctionnalités de base
7. Vérifier les tâches cron et les tâches planifiées
8. Vérifier que les fichiers de mémoire et de travail sont intacts
Temps total de récupération : environ 45 minutes d’une carte SD vierge à un système pleinement opérationnel. Comparez cela au week-end que j’ai passé à reconstruire sans sauvegardes.
Ce que la plupart des gens se trompent
Sauvegarder trop de choses. Vous n’avez pas besoin de sauvegarder l’ensemble du système. L’OS et OpenClaw lui-même peuvent être facilement réinstallés. Sauvegardez uniquement ce qui est unique à votre installation.
Ne pas sauvegarder les clés API. Si vos clés API sont dans des variables d’environnement au lieu de fichiers de configuration, elles ne seront pas dans votre sauvegarde. Déplacez-les vers le fichier de configuration ou maintenez un document sécurisé séparé avec toutes les clés.
Pas de copie distante. Une sauvegarde sur la même machine qui échoue n’est pas une sauvegarde du tout. Au minimum, copiez sur une deuxième machine. La version la plus simple : envoyez-vous par e-mail le fichier de configuration une fois par semaine.
Ne jamais tester les restaurations. Testez votre processus de restauration avant d’en avoir besoin. Le moment pour découvrir que votre sauvegarde est incomplète n’est pas lors d’une urgence.
🕒 Published: