Sauvegarde du répertoire d’état OpenClaw et passation de bail sur Mac cloud 2026 — protéger ~/.openclaw sans catastrophe de synchro

Les équipes qui font tourner la passerelle OpenClaw sur un Mac cloud Apple Silicon loué traitent le runtime comme du bétail jusqu’à ce que quelqu’un active Bureau et Documents iCloud et qu’une moitié de l’état de la passerelle se divise silencieusement entre portables. Conclusion de ce guide : gardez ~/.openclaw uniquement sur APFS local, créez des archives chiffrées avant tout changement de bail et répétez la restauration chaque trimestre avec un manifeste qui sépare secrets et configuration. Vous obtenez une matrice de sensibilité, dix points de contrôle de passation pour les rotations MacLogin à Hong Kong, au Japon, en Corée, à Singapour et aux États-Unis, et un exercice catastrophe en cinq étapes compatible avec une pause déjeuner.

Avant de modifier les chemins, lisez TCC et approbations d’exécution, comparez les surfaces d’installation dans install.sh contre npm global, et gardez l’aide MacLogin pour la connectivité. Pour dimensionner un hôte d’automatisation dédié, utilisez les tarifs afin de prévoir la RAM pour les modèles concurrents et la marge disque pour les instantanés d’état.

La gouvernance produit gagne à traiter le répertoire d’état comme une base de données opérationnelle : horaires de sauvegarde, propriétaire on-call, et critères d’acceptation pour toute PR qui touche aux chemins. Les incidents les plus coûteux ne viennent pas d’OpenClaw lui-même mais de la combinaison « home directory partagé + script launchd oublié + jeton Slack encore valide sur l’ancien hôte ».

Ce qui vit réellement sous ~/.openclaw sur un Mac passerelle

Considérez le répertoire comme trois couches : identité et liaisons de canaux (jetons, ID d’appareil), état d’orchestration (files d’attente, définitions cron, invites mises en cache) et brouillon éphémère (journaux, exports temporaires). Sauvegarder tout duplique bêtement les secrets dans des compartiments objet peu sûrs ; ne rien sauvegarder vous force à reconstruire les intégrations de mémoire pendant un incident.

• Fragments JSON / YAML de config qui décrivent le routage des modèles mais ne doivent pas embarquer de clés API dans Git.
• Références plist launchd qui doivent rester alignées sur le contexte utilisateur qui exécute la passerelle.
• Métadonnées d’espace de travail pointant vers des dépôts sur disque — ces chemins cassent lors d’un changement de région.

Ajoutez une quatrième couche implicite : versions de binaire et empreintes de build. Lors d’un litige « qui a déployé quoi », le manifeste doit inclure le semver du gateway et le hash du paquet, pas seulement les fichiers sous ~/.openclaw.

Pourquoi les dossiers de synchro cloud et les symlinks cassent l’état passerelle

En 2026, les recommandations communautaires répètent de ne pas placer l’état OpenClaw dans iCloud Drive, Dropbox ou la racine synchronisée de Google Drive. Les modes d’échec sont mécaniques : verrous de fichiers conflictuels pendant les rafales d’invites, téléversements partiels qui corrompent des magasins de type SQLite, partage accidentel d’un dossier contenant des identifiants longue durée.

1. Inventoriez les montages : exécutez df -h ~ et vérifiez que le home est en APFS local, pas un home réseau hérité d’Active Directory.
2. Vérifiez la redirection Bureau/Documents : les fonctions macOS qui reflètent ces dossiers vers iCloud déplacent silencieusement des chemins que vos scripts croyaient locaux.
3. Contrôlez l’inode : après migration, comparez les numéros d’inode entre hôte principal et secours — un décalage signifie qu’rsync a sauté un répertoire caché.
4. Documentez les exclusions : ajoutez des règles d’exclusion explicites pour **/tmp/** sous l’arbre d’état pour réduire les archives jusqu’à 40 %.
5. Faites tourner les clés après restauration : traitez tout fichier de jeton restauré comme potentiellement exposé ; prévoyez 15 minutes par fournisseur pour réémettre.

Les équipes conformité devraient exiger une preuve que le répertoire d’état n’est pas couvert par une politique de synchro MDM « Documents dans le cloud ». Une capture d’écran des réglages système plus la sortie de mount suffit souvent pour clore le point d’audit.

Matrice sensibilité et fréquence de sauvegarde

Sous-arbre	Sensibilité	Cadence	Notes
Modèles de config (expurgés)	Moyenne	Commit Git quotidien	Utilisez sops ou références vault plutôt que des littéraux
Secrets de canaux	Critique	Jamais en tarball clair	Dans KMS ; la passerelle tire au démarrage
Définitions cron / automatisation	Élevée	Instantané chiffré hebdomadaire	Corrélez avec planification launchd
Journaux scratch	Faible	Tampon 24 h optionnel	Utile au debug, risqué si riche en PII

Les équipes qui mesurent seulement la disponibilité oublient la reproductibilité : le même runbook doit fonctionner si l’ingénieur principal est en congé et si le nouvel hôte est dans une autre ville AWS-equivalente côté latence.

Dix points de contrôle quand le bail MacLogin tourne

#	Point	Critère de réussite
1	Arrêt propre de la passerelle	Aucun job actif dans le fichier de file
2	Export du bundle config expurgé	Checksum publié sur le ticket
3	Révocation des webhooks sortants	HTTP 401 sur ping test
4	Instantané plist + launchctl print	Sauvegardé à côté du bundle
5	Effacement local des secrets	Effacement sécurisé vérifié
6	Mise à jour DNS / extrémités tunnel	Propagation inférieure au TTL
7	Réinstallation passerelle sur le nouveau bail	Version conforme à la politique
8	Import de l’état non secret	Diff revue approuvée
9	Test fumée des canaux	3 messages synthétiques OK
10	Clôture fiche CMDB	Ancien actif marqué retiré

Numérotez ces étapes dans votre outil de ticketing ; les revues post-mortem montrent que les échecs viennent le plus souvent des étapes 3, 6 et 9 — webhooks fantômes, DNS à demi propagé, canaux « verts » qui n’ont testé qu’un seul sens de message.

Exercice de restauration en cinq étapes, rejouable chaque mois

1. Provisionnez un bail de staging dans la même région que la production (HK/JP/KR/SG/US) pour imiter la latence.
2. Appliquez le durcissement de base issu de vos runbooks sshd et passerelle avant de copier des données.
3. Restaurez uniquement le bundle expurgé, puis injectez les secrets via votre CLI vault — jamais de scp de fichiers .env bruts.
4. Lancez les health checks passerelle en miroir des sondes prod pendant 10 minutes.
5. Documentez le RTO réel par rapport à la cible ; en cas d’écart, ouvrez un ticket capacité avec les métriques CPU volées du Moniteur d’activité.

Alternez qui conduit l’exercice : un binôme différent chaque trimestre révèle les lacunes de documentation que l’auteur original ne voit plus.

FAQ

Devrions-nous utiliser Time Machine pour ~/.openclaw ? Acceptable si le disque de destination est chiffré et contrôlé en accès ; préférez des archives conscientes de l’application qui excluent les caches volatils.

Et les passerelles sous Docker ? Mappez explicitement les volumes vers des chemins hôtes hors dossiers synchronisés ; ne versionnez que le compose avec des espaces réservés de variables.

Faut-il un état séparé par environnement ? Oui — dev, stage et prod ne doivent pas partager un même arbre sur un Mac loué destiné à l’automatisation de production.

Pourquoi les baux Mac mini M4 aident à traiter l’état comme de l’infrastructure

La mémoire unifiée Apple Silicon stabilise les caches chauds des modèles pendant que les agents d’arrière-plan écrivent l’état sans tempêtes de pagination que les VM x86 montrent souvent sous charges IA mixtes. Les bares métal MacLogin donnent des performances disque prévisibles pour les instantanés chiffrés, et la présence multi-régions permet un standby chaud plus proche de la sortie Slack ou Teams. Louer signifie lancer un hôte jetable pour des exercices de restauration destructifs sans risquer le numéro de série prod lié aux profils MDM.

Si vous avez besoin d’un second nœud uniquement pour expérimenter l’état, clonez vos manifests sur du matériel issu des tarifs et épinglez la version passerelle au même semver que dans votre ticket.