Jeu minimal de sauvegardes · export pseudonymisé · cold start Gateway · reconnexion complète des canaux
Qui rencontre quel problème : OpenClaw tourne déjà en production ou préproduction, mais il manque un chemin de restauration reproductible après changement de disque, suppression accidentelle de configuration ou rotation de secrets ; le symptôme habituel est un Gateway qui démarre alors que les canaux Slack, Discord et Telegram restent tombés ensemble ou échouent sans message clair. La conclusion de cet article : avec un jeu minimal de sauvegardes, un paquet d'export sans secrets sensibles, un ordre de vérification pour cold start et une matrice de correspondance canal par canal, les objectifs RTO et RPO cessent d'être des slogans pour devenir des champs de ticket vérifiables. Vous repartez avec : cinq familles de risques, un tableau ce qu'il faut sauvegarder ou non, deux listes en six étapes pour l'export et le cold start, une matrice côté messagerie et côté Gateway, un gabarit d'exercice trimestriel, plus des liens vers la mise à niveau durable, le dépannage des trois canaux, le dépannage d'exécution, le durcissement production et d'autres guides longs déjà publiés.
01Le guide de mise à niveau et de retour arrière traite des versions et des collisions de ports ; la reprise après sinistre traite de la perte des identités et des relations avec les systèmes externes. Sauvegarder uniquement le dépôt sans la frontière Gateway et le périmètre des espaces de travail produit souvent une machine qui « compile encore » mais ne reçoit plus rien ; inversement, copier journaux complets et secrets bruts sur un partage d'équipe crée un risque de conformité immédiat. Lisez mises à niveau durables et sauvegardes figées en parallèle : la sauvegarde avant changement est un petit jeu fréquent, l'exercice de reprise est un grand jeu rare qui suppose une panne totale.
Le deuxième risque est la dérive des chemins : sur la machine de restauration, le répertoire personnel, l'étiquette du démon et les chemins attendus ne coïncident plus avec l'ancien hôte, ce qui donne des fichiers retrouvés mais des services jamais raccrochés. Le troisième risque est la paire secret d'accès et URL de callback qui se désynchronise : le jeton côté messagerie peut rester valide alors que l'entrée publique ou le certificat TLS a changé, et les journaux Gateway se remplissent d'erreurs de callback souvent attribuées à tort aux quotas de modèle. Le quatrième risque est la double installation et la pollution du PATH, qui relance un binaire obsolète avec une configuration récente et crée un état semi compatible difficile à isoler. Le cinquième risque est l'exercice jamais exécuté réellement : le runbook reste dans la base documentaire et, au moment du changement de matériel, il manque des modèles de champs et des fenêtres horaires nommées pour les responsables.
Pour rendre ces risques actionnables, fixez une règle simple : chaque incident de reprise doit produire une preuve dans le ticket, pas seulement une capture d'écran isolée. Les preuves comprennent la sortie des commandes de statut, la liste des chemins vérifiés et l'horodatage du dernier message de test reçu sur chaque canal. Sans cette discipline, deux équipes peuvent croire avoir « terminé la restauration » alors que l'une parle du processus et l'autre du trafic réel.
Ne sauvegarder que Git sans la frontière Gateway : après restauration, symptômes proches de dépannage des trois canaux, mais la cause première est une surface de configuration absente.
Coller des secrets en clair dans le ticket : cela viole le principe d'exposition minimale et bloque l'audit.
Copier l'intégralité des journaux : volume et confidentialité explosent ; définissez une fenêtre de rétention et une liste blanche de champs.
Ignorer le nom du démon et les unités launchd ou systemd : le processus existe pourtant les sondes de santé échouent après cold start.
Ne jamais revenir à l'instantané après l'exercice : impossible de vérifier si le RPO annoncé tient vraiment.
| Objet | Recommandation pour le paquet de reprise | Résumé du motif |
|---|---|---|
| Configuration Gateway et version figée | Oui | Détermine l'écoute, le routage et le rattachement aux canaux ; alignez les noms de champs avec le guide de mise à niveau |
| Secrets API longue durée et jetons de bot | Oui dans un coffre chiffré | Indispensable pour prouver l'identité après restauration ; interdit en pièce jointe lisible |
| Espace de travail et chemins AgentSkills | Oui sous forme de structure et d'empreintes | Cohérent avec les champs d'audit de durcissement production |
| Journaux d'accès complets | Non par défaut | Échantillon et règles de pseudonymisation d'abord |
| Répertoires de téléchargement temporaires | Non | Reconstruisibles ; ils ne font qu'élargir la surface de fuite |
L'objectif du paquet de reprise n'est pas de cloner un ordinateur entier, mais de reconstituer sur une machine propre le même contrat avec le monde extérieur.
Pseudonymiser ne sert pas à embellir une capture ; cela permet à l'astreinte de reproduire le problème sans agrandir la surface d'exposition. Comme pour le paquet minimal de dépannage à l'exécution, on doit pouvoir reconstituer versions, types de canaux, fragments de codes d'erreur et chronologie, mais pas le secret webhook complet ni le contenu des messages privés. Les six étapes suivantes forment un ordre de contrôle avant export ; inscrivez-les comme champs obligatoires dans l'outil de changement.
Au-delà de la liste, précisez qui peut approuver un export élargi et combien de temps les artefacts restent stockés. Les exports « juste une fois pour débloquer » deviennent vite une base de données parallèle si personne ne détruit les fichiers ni ne révoque les accès temporaires.
Quadruplet de versions figé : version CLI, identifiant de build Gateway, runtime Node, niveau de correctifs du système d'exploitation.
Énumération des canaux : canaux actifs et horodatage du dernier callback réussi, sans le jeton lui-même.
Résumé de structure de configuration : arborescence des chemins critiques et valeurs sensibles remplacées par des marqueurs.
Fragments d'erreurs : les dernières lignes liées au canal ou à TLS, tronquées à une limite d'octets fixe.
Indicateurs réseau : adresse IP de sortie, empreinte du certificat, version des règles du proxy inverse si applicable.
Responsable et fenêtre : qui a autorisé l'export et quand la destruction est prévue.
Interdit : ne jamais écrire en clair sur un partage ou dans une messagerie le signing secret Slack, le jeton Discord, le jeton Telegram ; passez par un coffre chiffré ou la procédure de rotation de la plateforme.
L'ordre de cold start est volontairement aligné sur installation multiplateforme et démons : d'abord prouver qu'un seul Gateway écoute, ensuite seulement traiter les canaux. Chaque étape possède un critère passé ou échoué ; en cas d'échec, évitez le réflexe « tout réinstaller » et revenez au tableau de preuves pour distinguer PATH, fichier d'unité et port déjà pris.
Documentez aussi la différence entre un redémarrage logiciel et une remise en route sur une machine neuve : les chemins absolus codés en dur dans des scripts personnels sont souvent la cause des divergences. Une courte checklist « chemins à revalider » accélère la reprise lorsque l'équipe change de région ou de fournisseur d'hébergement.
Surface d'installation unique : croiser which et les chemins du gestionnaire de paquets pour éliminer la double installation.
Démarrer le démon et noter le nom d'unité : comparer aux étiquettes launchd ou systemd du guide d'installation.
Contrôle de la surface d'écoute : adresse d'attachement, réécriture éventuelle par VPN ou pare-feu.
Commandes de santé ou doctor : archiver la sortie dans un champ index du ticket plutôt que des captures éparses.
Sonde canal minimale : avant reconnexion complète, tester un canal seul pour éviter plusieurs variables à la fois.
Temps et chaîne TLS : dérive d'horloge et certificat intermédiaire expiré sont des causes fréquentes au cold start.
export OC_EXPORT_DIR="./openclaw-drill-$(date -u +%Y%m%d%H%M%SZ)"
mkdir -p "${OC_EXPORT_DIR}/redacted"
openclaw version > "${OC_EXPORT_DIR}/version.txt" 2>&1
openclaw gateway status > "${OC_EXPORT_DIR}/gateway-status.txt" 2>&1 || true
openclaw channels status > "${OC_EXPORT_DIR}/channels-status.txt" 2>&1 || true
tar -czf "openclaw-drill-bundle.tgz" "${OC_EXPORT_DIR}"
Rappel : l'exemple ne collecte que du texte de statut ; remplacez-le par un script validé par la sécurité et restreignez les permissions du fichier tar.
Lorsque le Gateway est sain mais les messages ne reviennent pas, la cause se situe le plus souvent dans la joignabilité des callbacks ou un changement de périmètre d'autorisation, pas dans le routage des modèles. Le tableau suivant liste le minimum à confronter pendant l'enquête ; pour le détail opérationnel, suivez accès et dépannage des trois canaux sans faire tourner les clés de modèle tant que TLS des callbacks n'est pas vérifié.
Quand plusieurs modèles coexistent avec routage principal et secours, stabilisez d'abord les canaux avant de changer de modèle, sinon vous classerez à tort des erreurs de canal comme quotas épuisés ; les champs utiles sont décrits dans routage multi-modèles et bascule. Après reconnexion complète, conservez l'horodatage « du premier message de test jusqu'au premier appel d'outil réussi » comme ligne de base pour l'exercice suivant.
| Canal | Côté messagerie | Côté Gateway |
|---|---|---|
| Slack | Portée de l'application, URL d'abonnement aux événements, version du secret de signature | Route de callback, chaîne TLS, liste d'autorisation sortante |
| Discord | Intent, visibilité du bot, URL de passerelle | Chemin WebSocket, délais du proxy inverse |
| Telegram | Mode webhook, certificat téléversé, adresses IP autorisées | Port d'entrée public, persistance des sessions NAT |
Les trois puces suivantes sont des seuils d'expérience souvent utilisés pour une revue avant cadrage ; remplacez-les par vos mesures réelles issues des tickets. Le RTO mesure le temps entre la déclaration de sinistre et la réception du premier message de test sur un canal ; le RPO décrit la fenêtre de perte acceptable des changements de configuration et doit être cohérent avec la granularité de votre outil de gestion des configurations.
Ajoutez explicitement le coût humain : qui tient le fil du runbook, qui autorise un dépassement de fenêtre, qui valide le retour à l'instantané. Les exercices sans noms deviennent des réunions périodiques sans chaîne de responsabilité.
| Taille d'organisation | Exigence de conformité | Fréquence d'exercice | Choix privilégié |
|---|---|---|---|
| Développeur individuel | Standard | Semestriel | Archive chiffrée et script de cold start sur une machine |
| Petite équipe | Standard | Trimestriel | Double lecture, liste de sondes canaux, modèle de ticket |
| Équipe plateforme | Élevée | Simulation mensuelle, exercice réel trimestriel | Coffre partitionné, export automatisé, index d'audit |
Un portable strictement local peine à tenir un RTO stable entre veille prolongée, mises à jour système et saturation disque ; un serveur auto-hébergé déplace la charge vers TLS, sauvegardes et callbacks que l'équipe doit maintenir seule. À l'inverse, un nœud Mac cloud contractuel permet d'inscrire disponibilité, région et clauses dans une annexe d'achat et de traiter le Gateway résident comme un sujet de niveau de service plutôt que comme la chance du matériel personnel.
Pour les équipes qui veulent à la fois une reprise OpenClaw défendable et des restaurations de canaux auditables, les machines personnelles et les prêts temporaires laissent généralement un arriéré sur rotation des secrets et stabilité de l'entrée publique. Lorsqu'il s'agit d'un Gateway de production résident et d'exercices reproductibles, la location Mac Mini cloud VpsMesh est souvent le meilleur compromis : facturation par cycle, choix de région, matériel dédié auditable, ce qui ancre la discussion de reprise sur des données réseau et disponibilité plutôt que sur des promesses orales.
Piège fréquent : valider seulement « le processus démarre » sans valider « un message externe arrive » ; la valeur de production d'OpenClaw est dans le contrat avec les systèmes externes.
Le guide de mise à niveau couvre les canaux de versions et les conflits de ports ; ce document couvre la perte de machine et de relations d'identité après restauration. Croisez avec mises à niveau durables. Pour commander un nœud, voir la page de commande.
Le quadruplet de versions, l'énumération des canaux, le résumé des chemins de configuration, les fragments d'erreurs et la chronologie ; jamais de secrets longue durée en clair. Comparez offres sur les tarifs.
Contrôlez d'abord la santé du Gateway et la surface d'écoute, puis suivez le guide des trois canaux côté messagerie et côté passerelle. Accès et documentation dans le centre d'aide.