Sécuriser ses Sauvegardes OpenClaw : Cas Réel DevOps

Bon dimanche ! ☕

Une sauvegarde n'est pas une stratégie de reprise tant qu'on ne sait pas la vérifier, la retrouver et la restaurer. Cette semaine, on examine un dépôt public qui traite OpenClaw comme un vrai service de production, avec version figée, archives chiffrées et contrôles après mise à jour.

🎯 Le Cas : Reprendre un Serveur OpenClaw Après Incident

Auteur : basi163
Contexte : l'auteur exploite une instance OpenClaw sous Linux, derrière un service systemd, et maintient depuis le 12 avril 2026 un dépôt d'infrastructure dédié à sa continuité.
Objectif : pouvoir reconstruire l'environnement sur un nouveau serveur, conserver une configuration assainie dans Git et restaurer une archive complète sans publier les secrets.

📖 L'Histoire

Le problème de départ est classique : une instance OpenClaw accumule bien plus qu'un paquet npm. Elle dépend d'une configuration, d'agents, d'un service gateway, de secrets et d'un état local. Copier ponctuellement un dossier ne répond pas aux vraies questions : la copie est-elle valide ? Où est-elle stockée si le serveur disparaît ? La version restaurée démarrera-t-elle encore ?

Le dépôt openclaw-infra transforme ces questions en procédures. Il exporte une vue expurgée de la configuration dans state-export/, versionne les scripts dans GitHub et produit séparément des archives complètes chiffrées. Ce découpage est sain : Git conserve ce qui peut être audité ; une GitHub Release privée ou correctement protégée reçoit l'artefact sensible chiffré.

L'auteur a aussi choisi une politique conservatrice de mise à jour. Le serveur documenté reste épinglé sur openclaw@2026.4.12, même si une version plus récente existe. Une nouvelle version passe d'abord par une sauvegarde, une installation candidate, un redémarrage, des diagnostics profonds et un test de santé. Elle ne devient la nouvelle référence qu'après validation dans cet environnement précis.

La solution finale n'est donc pas un agent spectaculaire. C'est mieux : une discipline d'exploitation codée. Un cron exporte l'état, un second produit une sauvegarde quotidienne, le gateway redémarre automatiquement, et une procédure de reprise télécharge, contrôle puis déchiffre l'archive. Le dépôt était encore mis à jour le 14 juin 2026, ce qui confirme qu'il s'agit d'un environnement vivant, pas d'une maquette abandonnée.

🔧 Le Setup Technique

Architecture Agent

Le dépôt ne publie ni SOUL.md ni prompt métier : son périmètre est l'infrastructure. L'architecture observable est la suivante :

Instance OpenClaw sur Linux
├── gateway systemd unique, lié à loopback
├── export assaini -> dépôt GitHub
├── archive complète -> chiffrement AES-256-CBC
├── GitHub Release -> archive .enc + somme SHA-256
└── cron
    ├── export/synchronisation au redémarrage et périodiquement
    └── sauvegarde chiffrée chaque jour à 03:35 UTC

Il n'y a pas de session agent isolée dans ce workflow : cron lance des scripts shell sur l'hôte. Les intégrations externes sont Git, GitHub CLI, OpenSSL, systemd et les commandes natives openclaw backup, doctor, status et health.

Fichiers Clés

Politique d'exploitation (équivalent du cadre SOUL.md)

- mises à jour manuelles sur le canal stable
- version de production explicitement épinglée
- un seul service openclaw-gateway.service
- gateway lié à loopback
- sauvegarde avant changement, puis doctor, restart, status et health

Configuration des sauvegardes

OPENCLAW_BACKUP_PASSPHRASE='une-phrase-longue-et-unique'
GITHUB_BACKUP_REPO='votre-compte/openclaw-infra'

Le script appelle openclaw backup create --verify, chiffre ensuite l'archive avec AES-256-CBC, PBKDF2, sel aléatoire et 200 000 itérations, calcule une somme SHA-256, crée une Release GitHub puis supprime l'archive locale en clair.

Étapes de Mise en Place

1. Cloner le dépôt et examiner chaque script avant exécution :

git clone https://github.com/basi163/openclaw-infra.git ~/openclaw-infra
cd ~/openclaw-infra

2. Adapter les chemins codés pour le compte openclaw, le binaire et le service systemd. Le dépôt cible /home/openclaw et /home/linuxbrew/.linuxbrew/bin/openclaw : ces valeurs ne sont pas universelles.

3. Créer ~/.openclaw/.backup-release.env, lui appliquer des permissions restrictives, puis authentifier gh sur le dépôt de sauvegarde :

chmod 600 ~/.openclaw/.backup-release.env
gh auth login
bash scripts/backup-release.sh

4. Installer les tâches planifiées après avoir vérifié leur fréquence réelle :

AUTO_SYNC_SCHEDULE='*/5 * * * *' \
BACKUP_RELEASE_SCHEDULE='35 3 * * *' \
bash scripts/install-autosync.sh

5. Tester une reprise sans attendre l'incident :

bash scripts/restore-from-release.sh backup-YYYYmmdd-HHMMSS
openclaw backup verify ~/openclaw-restore/openclaw-backup-*.tar.gz

Le script s'arrête volontairement avant l'écrasement du système. Il faut encore couper les services, déployer l'archive puis relancer le gateway selon la procédure OpenClaw adaptée à l'hôte.

📊 Les Résultats

Gains mesurés :

• 1 archive complète planifiée par jour, à 03:35 UTC par défaut ;
• jusqu'à 5 tentatives de santé espacées de 3 secondes après une mise à jour ;
• 2 contrôles d'intégrité avant reprise : SHA-256 sur l'artefact chiffré, puis openclaw backup verify après déchiffrement ;
• 1 seul service gateway et une temporisation de redémarrage de 5 secondes dans le profil documenté.

L'auteur ne chiffre ni temps économisé, ni durée de restauration, ni nombre de reprises réussies. Il serait trompeur d'en inventer. Le résultat vérifiable est l'automatisation et la présence d'artefacts contrôlés, pas un objectif de disponibilité démontré.

Limites rencontrées :

• la restauration n'est pas entièrement automatisée : le dernier déploiement reste manuel ;
• plusieurs chemins et identités sont propres au serveur de l'auteur ;
• le README indique une synchronisation toutes les cinq minutes, tandis que install-autosync.sh définit actuellement 0 * * * *, donc une fois par heure. Il faut passer explicitement AUTO_SYNC_SCHEDULE='*/5 * * * *' pour obtenir la fréquence annoncée.

🧐 Analyse Critique

✅ Ce qui est bien fait

• Séparation des données. La configuration lisible est expurgée avant Git ; l'état complet part dans une archive chiffrée. Cela limite le risque de publier accidentellement un token avec l'historique versionné.
• Vérification à plusieurs niveaux. La création utilise --verify, le transport est contrôlé par SHA-256 et l'archive déchiffrée est vérifiée à nouveau. Chaque contrôle couvre une panne différente.
• Mises à jour réversibles. Épingler une version connue, sauvegarder avant le changement et conserver une commande de retour réduit fortement le rayon d'impact d'une release défectueuse.

⚠️ Points d'attention

• GitHub n'est pas une seconde région par magie. Si le compte ou le dépôt est compromis en même temps que le serveur, la disponibilité de la sauvegarde peut disparaître. Le chiffrement protège la confidentialité, pas la suppression.
• Le secret est le point de reprise. Perdre la phrase de chiffrement rend toutes les archives inutilisables ; la stocker uniquement sur le serveur sauvegardé annule une partie du dispositif.
• Le test s'arrête trop tôt. Vérifier une archive ne prouve pas qu'une instance restaurée démarre, retrouve ses agents et répond sur ses canaux. Seul un exercice complet mesure réellement le RTO.

💡 Améliorations possibles

• Ajouter une copie immuable hors GitHub, par exemple un bucket S3 compatible avec Object Lock, et une rotation documentée des archives.
• Exécuter mensuellement une restauration dans une VM jetable, puis enregistrer durée, version, taille, contrôles réussis et test fonctionnel du gateway.
• Rendre les chemins configurables par variables d'environnement et ajouter ShellCheck ainsi qu'un test CI des scripts pour éviter les divergences entre documentation et comportement.

🎓 Ce qu'on en retient

Leçons clés :

1. Une configuration Git expurgée et une archive complète chiffrée répondent à deux besoins distincts ; il faut les deux.
2. Une sauvegarde n'est crédible qu'avec des contrôles d'intégrité et un exercice de restauration périodique.
3. En production, une version connue et testée vaut souvent mieux qu'une mise à jour automatique vers la dernière release.

Pour aller plus loin :

• Gérer son homelab avec OpenClaw
• Publier des comptes rendus avec OpenClaw
• Source originale : basi163/openclaw-infra
• Documentation OpenClaw sur les sauvegardes

À dimanche prochain pour un nouveau cas ! 🦞