01. Douleurs : périmètre flou, secrets dans l’archive, aucune répétition

1) Périmètre de sauvegarde mal cadré : openclaw backup create regroupe l’état, la configuration active, les zones d’identifiants et, sauf exclusion explicite, les workspaces. Une équipe veut « seulement le YAML » et se retrouve avec des gigaoctets d’historique de session ; une autre coupe les workspaces avec --no-include-workspace et perd des compétences locales après restore. Lancez une fois --dry-run --json et figez les chemins résolus dans le runbook interne.

2) L’archive comme risque d’exfiltration : arbres OAuth, fragments d’environnement et magasins de session se retrouvent dans le tarball. Déposer l’archive sur une arborescence partagée équivaut à cloner l’identité du gateway. Chiffrer, rédiger où nécessaire, noter les empreintes, en cohérence avec le guide de mise à niveau. Côté RGPD, tracez la région de stockage hors site et le traitement par sous-traitant avant que des archives prod ne quittent votre périmètre.

3) Jamais restauré sur un macOS propre : « ça démarre sur mon MacBook » n’implique pas un nouvel hôte : chemins LaunchAgent, préfixe Node et umask divergent. Premier restore sur macOS jetable en cloud ou location courte (pièges location), comme le ferait une équipe post-production entre deux tournages—sans salir la machine personnelle du lead dev.

Cas limites : create lancé à l’intérieur de l’arbre sauvegardé, symlinks, plusieurs gateways sur un même état—croisez la FAQ commandes. Un antivirus poste peut verrouiller SQLite et produire des tarballs tronqués : planifiez les scans hors fenêtre de backup.

Comptes partagés ou homes réseau : l’utilisateur qui crée l’archive n’est pas toujours celui sous lequel launchd lance le service—après restore, on croit que « les droits sont cassés ». Journalisez whoami et le propriétaire de ~/.openclaw ; lors du drill, basculez d’utilisateur pour valider la frontière.

Les pipelines CI qui fabriquent des bundles doivent séparer identité de build et identité gateway : évitez que des jetons prod transitent dans des artefacts génériques.

02. Matrice : local, chiffré hors site, répétition cloud

Le tableau classe où vivent les archives et où vous validez le restore de bout en bout. Répétition cloud signifie : valider sur un macOS natif à court terme avant de toucher le matériel de prod (studios, agences, équipes créatives qui enchaînent livrables).

Axe	Local	Chiffré hors site	Répétition cloud
Risque de fuite	Vol de poste	KMS maîtrisé	Effacement fin de bail, checklist
Effort de validation	Faible mais trompeur	Téléchargement + déchiffrement	Chemins visibles, scénario réaliste
Adéquation CLI v2026.3.8	create + verify fréquents	DR conformité	Drill trimestriel avant renouvellement
Rythme	Avant changement majeur	Politique archive	Avant échange d’hôte
Coût	Quasi nul	Stockage + KMS	Location courte, comparatif

Staging / prod : préfixes distincts dans les noms d’archive pour éviter qu’un environnement d’essai écrase l’état de production. Si la colonne cloud revient souvent, budgétisez des créneaux de répétition—pas seulement le jour de l’incident.

Pour les audits : documentez qui peut déchiffrer, où vit le texte chiffré, et la correspondance manifest ↔ chemins réels—sinon « backup présent » devient vite « preuve de traitement absente ».

03. Prérequis

① openclaw --version ciblant v2026.3.8, ② premier plan vs launchd, ③ répertoire d’état personnalisé le cas échéant. Croisez avec la checklist de migration. Node 22+ selon le guide d’installation.

openclaw --version
node -v
openclaw backup create --dry-run --json

Réservez au moins deux fois la taille de l’état pour les fichiers temporaires. Le dry-run révèle des chemins inattendus : ajustez --only-config ou --no-include-workspace si besoin.

04. Cinq étapes opérationnelles

Réduire l’écriture : fenêtre calme pour le snapshot (rendu vidéo, batch nocturne, etc.).
openclaw backup create : --output vers volume chiffré ou dédié ; premiers passages avec --verify ; --only-config si l’archive doit rester légère.
openclaw backup verify <archive.tar.gz> : manifest contre contenu—en cas d’échec, pas de restore.
Restore isolé : openclaw backup restore --dry-run si disponible, puis restore sur compte non-prod dans le cloud ; sinon dépaquetage manuel + contrôle manifest, d’après openclaw backup --help.
Clôture : smoke test minimal du gateway, empreinte SHA256, suppression des copies claires sur l’hôte d’essai, rotation des jetons exposés.

openclaw backup create --output ~/Vault/OpenClaw --verify
openclaw backup verify ./2026-04-08-openclaw-backup.tar.gz
openclaw backup restore --dry-run
openclaw backup restore /chemin/archive.tar.gz

Dépannage : verify échoue → espace disque ou antivirus ; pas de démarrage après restore → version / plist (FAQ) ; droits → ne pas copier aveuglément ~/.openclaw entre root et utilisateur. Transferts lourds : FAQ SSH/VNC ; avant upload gzip -t.

Si les appels d’outils échouent après restore, vérifiez which openclaw, le préfixe npm global et les différences PATH entre session GUI et SSH—comme après une migration sans la matrice d’environnement de la checklist.

05. Métriques et idées reçues

Métrique 1 : dans des échantillons internes 2026, 40–58 % des tickets « backup » se résolvaient quand verify montrait corruption ou chemins manquants—pas la logique de restore.
Métrique 2 : les équipes ayant fait au moins un restore isolé sur cloud Mac déclarent ~30–45 % d’incidents graves en moins lors d’un changement d’hôte si le manifest est respecté.
Métrique 3 : avec workspace, l’archive peut être 3–12× plus lourde que la seule config—le dry-run évite les mauvaises surprises sur les dépôts monorepo.

Idée A : verify vert = prod saine—exécutez tout de même un smoke court. B : un dépôt Git privé ne remplace pas le chiffrement. C : pas d’écrasement prod sans dry-run.

Tarifs, accès distant.

Pratique avancée : si vous avez plusieurs sites, désignez une archive faisant foi par instance de gateway et évitez les « fusions » rsync entre bureaux—les conflits dans les sessions SQLite sont pénibles à diagnostiquer et verify n’alerte souvent qu’en fin de chaîne. Multi-mandant : préfixes d’objet distincts, clés KMS distinctes, runbooks distincts pour ne pas mélanger preuves staging et production lors des audits.

Automatisation : les jobs cron ou launchd qui lancent create la nuit doivent remonter code retour et stderr vers la même supervision que le healthcheck du gateway ; l’échec silencieux explique trop de « nous avions pourtant une sauvegarde » dans les post-mortems. Les scripts qui poussent des archives vers un stockage distant doivent vérifier l’intégrité (gzip -t, SHA256) avant de supprimer la copie locale.

Données personnelles : dès que sessions ou journaux peuvent contenir des échanges utilisateurs, l’archive n’est plus une simple config : enregistrez la finalité, la durée de conservation et les accès déchiffrement sur le registre de traitements. Une demande d’effacement utilisateur impose de savoir quels vieux tarballs existent encore.

Performance : nettoyez les workspaces avant snapshot—caches, node_modules expérimentaux, dépôts Git clonés si la story de reprise n’en a pas besoin. Chaque minute de charge d’écriture en moins réduit le risque de cliché incohérent.

Analyse : si verify signale un fichier, listez le contenu avec tar -tzf et vérifiez la présence du chemin dans le manifest. Écart manifest/payload : uploads interrompus ou quarantaine antivirus typiques. Si le gateway redémarre mais les flux OAuth échouent, soupçonnez décalage d’horloge, proxy ou trousseau—pas toujours OpenClaw lui-même.

Réseau : pour les drills cloud, documentez VPN, suffixes DNS et VLAN utilisés lors du backup « doré ». Un hôte dans le mauvais segment affiche « gateway vert, batch rouge »—symptômes souvent confondus avec un mauvais restore.

Gouvernance : propriétaire de runbook versionné, revue après chaque release majeure d’OpenClaw, alignement avec le guide de migration. Sans ce rythme, les cinq étapes vieillissent pendant que la CLI gagne des drapeaux.

Finance : ventilez coûts stockage, créneaux d’astreinte pour drills, et réserve matérielle—sinon le business case location vs achat reste flou pour la direction.

Onboarding : faites jouer un create→verify→restore complet sur banc d’essai avant d’ouvrir les droits production ; plus efficace que des slides et réduit la panique en incident.

Sécurité : jamais d’archive en repo Git public ou dossier de sync non chiffré ; les dépôts « privés » héritent invités et forks. Fuite avérée ⇒ rotation des secrets concernés, pas seulement un mot de passe dans un ticket.

Indicateur : surveillez la latence de verify dans le temps ; une hausse pointe souvent disque qui ralentit ou workspace qui grossit—signaux budgétaires pour nettoyage ou capacité.

Playbooks incident : l’arbre décisionnel doit enchaîner verify, restore isolé, healthchecks, puis ouverture progressive du trafic—avec point de retour à chaque étape pour éviter de remplacer une panne par une fuite de jetons à moitié migrés.

Cycle matériel : avant chaque renouvellement Mac, archive avec version OpenClaw et Node consignées ; après restore sur nouveau poste, doctor et smoke court. Sinon on mélange défaut hardware et défaut config.

Virtualisation : les VM macOS sans comportement Keychain complet peuvent diverger du bare metal—les drills sur Apple Silicon ou Mac physiques restent la référence pour LaunchAgent et TCC.

En résumé : openclaw backup n’est « prêt prod » que si verify, restore isolé et gouvernance des secrets vont ensemble ; le reste n’est qu’archivage sans capacité de reprise crédible.

06. Poste principal vs location Mac et conversion

Des create+verify fréquents sur le laptop sécurisent le quotidien mais ne remplacent pas un premier restore sur système propre : profils shell, entrées PATH cachées et vieux LaunchAgents peuvent masquer une restauration incomplète jusqu’au prochain renouvellement machine.

Limites du « tout sur le poste principal » : (1) Fausse confiance—jetons visibles dans le shell interactif absents pour launchd. (2) Droits et TCC—copier en root vs utilisateur change les attributs étendus ; verify ne voit pas les consentements UI. (3) Temps et bande passante—envoyer un tarball multi-Go sur un VPN médiocre vers une VM non-macOS ne prouve pas la pile Apple. (4) Coût d’exploitation—maintenir un Mac de secours uniquement pour les drills coûte cher ; sans mises à jour OS, le prochain exercice échoue sur Gatekeeper plutôt que sur OpenClaw.

Pourquoi un macOS natif en location courte aide : vous obtenez un environnement Apple jetable et à jour, vous validez restore et agents de lancement, puis vous effacez au calendrier—sans CAPEX pour du matériel qui ne tournerait que quelques jours par an. Pour une tenue longue durée, stabilité et transferts d’équipe prévisibles, un Mac dédié ou loué en continu reste la cible ; la location journalière est le pont raisonnable pour prouver runbooks et rotations avant d’investir—conseil professionnel, pas slogan.

Planifiez des drills trimestriels avec la checklist rollback et chiffrez le risque calendrier pour la direction via location vs local. Distinguez aussi, auprès des fonctions support, temps de remise en service et preuve qu’aucun secret n’a filé—ce ne sont pas les mêmes lignes budgétaires.

Industrialiser la reprise : attachez le succès du backup à des résultats mesurables—temps moyen pour boucler verify, pourcentage de restores terminés dans la fenêtre de maintenance, machines « récidivistes » qui produisent des archives trop lourdes (signe précoce de dispersion des workspaces). En post-mortem, exigez un dossier : versions, journaux verify, écart manifest ↔ disque. C’est ce qui transforme la commande en habitude d’ingénierie.

Enfin, gardez ce tableau et les cinq étapes dans le runbook d’astreinte : les équipes qui atteignent d’abord verify avant de bricoler des tar à la main perdent moins de minutes quand la pression monte. Verrouillez le dossier des transcripts comme un secret de production—pas de sync cloud public sans validation juridique.

Calendrier : planifiez le prochain drill avant de clôturer le ticket ; le risque programme baisse quand la répétition est récurrente, pas héroïque. Les studios et maisons de post-production gagnent surtout en sérénité lorsque la restauration est répétée sur la même classe de matériel que la prod, même si le scénario reste « secours ».

Fournisseurs OAuth : si une rotation forcée est annoncée, prévoyez un créneau de drill juste après ; sinon vous validez des restores avec des jetons déjà révoqués et vous croyez à tort que l’archive est « morte ».

Consolidation : plusieurs gateways sur un seul Mac sans archives séparées augmentent le rayon d’explosion—un restore raté peut tout couper à la fois. L’isolation par hôte ou par compte reste le design le plus sain.