À la date du 14 octobre 2026, l’index officiel d’OpenClaw présente v2026.10.3 comme la version la plus récente (index des versions OpenClaw). Cette version ne prouve pas qu’une sauvegarde est restaurable.
Tâche déclarée réussie → ne concluez pas que la reprise est possible.
Périmètre vérifié, restauration dans un répertoire isolé et contrôles de service → sauvegarde recevable pour votre procédure de reprise.
Cet article s’adresse aux responsables IT qui administrent le Gateway et les données persistantes des Agents.
Il concerne aussi les responsables plateforme qui doivent rejouer une restauration sur un Mac cible.
Les responsables sécurité y trouveront les contrôles à appliquer aux conversations, aux configurations et aux identifiants.
Dernière mise à jour : 14 octobre 2026 ; état de version vérifié dans l’index officiel des versions OpenClaw et procédures recoupées avec la documentation de sauvegarde, de CLI et de structure de base de données d’OpenClaw.
SECTION 01Avant l’incident : définissez le périmètre de reprise
Une sauvegarde OpenClaw n’est utile que si elle permet de retrouver un état exploitable : le Gateway, les Agents attendus, leurs conversations, les configurations requises et les actifs dont ils ont besoin. Le nom d’un fichier SQLite ne décrit pas, à lui seul, la totalité de cet état.
Commencez par inventorier ce que vous exploitez réellement. L’organisation documentée des données OpenClaw sert de repère pour identifier les emplacements habituels. Comparez-la à votre configuration effective : les chemins peuvent avoir été personnalisés, et un Agent déplacé hors du répertoire attendu ne sera pas nécessairement inclus par un processus qui ne sauvegarde que l’emplacement par défaut.
Dans votre inventaire, distinguez au minimum :
- l’état partagé utilisé par l’installation et le Gateway ;
- les données de chaque Agent configuré, notamment ses conversations ;
- la configuration nécessaire au démarrage et au fonctionnement ;
- les espaces de travail et les fichiers que les Agents doivent retrouver ;
- les identifiants ou fichiers d’authentification requis par vos intégrations ;
- les répertoires d’Agent dont l’emplacement a été personnalisé.
Il faut ensuite distinguer le scénario de panne. Après une défaillance de l’hôte, vous cherchez à recréer un ensemble de travail complet sur une autre machine. Après une mise à niveau que vous devez annuler, la question centrale est la compatibilité entre la version de l’application et l’état restauré. Après une suppression accidentelle, vous devez d’abord déterminer quelles données ont été effacées et si d’autres fichiers ont changé depuis la sauvegarde. Le même jeu d’archives ne suffit pas nécessairement à satisfaire ces besoins.
| Scénario à tester | État à retrouver | Contrôle qui évite une fausse validation |
|---|---|---|
| Hôte indisponible | Gateway, données des Agents, configuration et actifs nécessaires sur la cible | Confirmer que les chemins personnalisés sont présents et accessibles |
| Retour arrière après changement de version | Données et configuration compatibles avec la version retenue | Vérifier les exigences de précontrôle de compatibilité documentées |
| Suppression ou altération de données | Éléments supprimés ou modifiés, sans écraser l’état encore sain | Restaurer d’abord ailleurs et comparer les résultats avant toute bascule |
Ne transformez pas cet inventaire en simple liste de fichiers présents. Pour chaque élément, indiquez son emplacement, son propriétaire opérationnel, sa méthode de sauvegarde et la personne qui peut confirmer qu’il est nécessaire. Cette correspondance donne à l’équipe de reprise un moyen concret de repérer les trous, notamment lorsque la personne qui a créé un chemin personnalisé n’est pas disponible.
SECTION 02Pendant la préparation : choisissez une sauvegarde adaptée
La documentation OpenClaw décrit des voies de sauvegarde et de restauration à suivre pour l’installation concernée. Consultez la documentation officielle des sauvegardes et la référence de la commande de sauvegarde en ligne de commande avant de figer votre procédure. Ce sont ces instructions, et non une copie improvisée du fichier principal, qui doivent déterminer la méthode et les contrôles à effectuer.
| Méthode envisagée | Ce qu’elle peut apporter | Limite à traiter dans votre procédure |
|---|---|---|
| Archive complète conforme à la documentation | Un ensemble regroupé, plus facile à transporter et à examiner comme unité | Confirmer que l’archive inclut aussi chaque chemin personnalisé, les espaces de travail et les éléments sensibles requis |
| Sauvegarde SQLite par la voie documentée | Une méthode orientée base de données, avec les contrôles prévus par la documentation | Elle ne remplace pas à elle seule la sauvegarde des configurations, des autres répertoires d’Agent ou des espaces de travail |
| Sauvegarde versionnée | Des points de reprise identifiables et une comparaison possible entre états | Vérifier la conservation, les droits d’accès et la possibilité de restaurer réellement chaque état |
Si votre base SQLite est utilisée par le service, ne traitez pas la copie directe du seul fichier principal comme preuve d’une sauvegarde cohérente. Les fichiers associés au journal WAL participent à la situation de la base pendant son activité. Suivez la méthode de sauvegarde recommandée par OpenClaw et vérifiez le résultat avec les contrôles associés à cette méthode ; ne supposez pas que le seul fichier portant l’extension de la base suffit (guide de sauvegarde OpenClaw).
À retenir : « le fichier existe » indique seulement qu’un artefact a été écrit. Un contrôle d’intégrité réussi indique qu’une vérification documentée a abouti. Aucun des deux ne démontre encore que le Gateway et les Agents peuvent redémarrer avec les données attendues.
Les sauvegardes peuvent contenir des informations plus sensibles que leur nom ne le laisse penser. Si les chemins inclus couvrent des conversations, des paramètres d’authentification ou des secrets nécessaires aux intégrations, appliquez à l’archive des restrictions d’accès et des règles de chiffrement adaptées à la sensibilité de ces éléments. N’envoyez pas une archive à un emplacement partagé au seul motif qu’il est pratique pour l’équipe de reprise.
Enregistrez aussi les éléments utiles à un audit : identifiant de sauvegarde, date de création, périmètre prévu, destination, résultat de la vérification et responsable. Ne consignez pas les secrets eux-mêmes dans le registre. Il doit permettre de retrouver l’artefact et d’expliquer les contrôles effectués, sans devenir une copie supplémentaire des informations protégées.
SECTION 03Après la sauvegarde : contrôlez le résultat et ses limites
À ce stade, vous devez pouvoir répondre à une question simple : qu’est-ce qui a été sauvegardé, par quel procédé, et quelle preuve avez-vous que l’artefact peut être examiné ? Consultez les étapes de vérification indiquées dans la documentation de la commande de sauvegarde, puis conservez le résultat avec les informations de périmètre.
Séparez explicitement trois états dans votre compte rendu :
- Présence : l’artefact attendu se trouve à la destination prévue.
- Vérification : le contrôle prévu par la documentation a été exécuté et son résultat est conservé.
- Récupérabilité : une restauration a permis de démarrer et de vérifier les fonctions et données réellement nécessaires.
Cette séparation évite une erreur de gouvernance fréquente : transformer le succès du travail de sauvegarde en preuve de reprise. Elle aide aussi à attribuer le bon statut à une sauvegarde dont le contrôle d’intégrité réussit, mais dont les chemins d’Agent n’ont pas encore été retrouvés sur le Mac cible.
Décision conditionnelle pour accepter ou refuser une sauvegarde
- Si le périmètre inclut la base, les données de chaque Agent, les configurations, les espaces de travail et les chemins personnalisés nécessaires, alors passez à la restauration isolée. Sinon, corrigez d’abord la sélection et ne qualifiez pas la sauvegarde de complète.
- Si la méthode suit la documentation OpenClaw et que son contrôle documenté aboutit, alors consignez le résultat et préparez la reprise. Sinon, conservez le statut « à vérifier » et recherchez la cause avant d’utiliser l’artefact.
- Si la restauration isolée démarre et que les données attendues sont retrouvées, alors poursuivez les contrôles du Gateway et des intégrations. Sinon, ne basculez pas la production : corrigez le chemin, la compatibilité ou le périmètre, puis rejouez le test.
- Si les vérifications de service, de données et d’accès aboutissent, alors la sauvegarde peut être acceptée pour le scénario testé. Sinon, classez-la en correction obligatoire ou suspendez l’extension des charges d’Agent concernées.
SECTION 04Pendant la répétition : restaurez dans une cible isolée
Une restauration de validation ne doit pas remplacer immédiatement l’état en cours d’utilisation. Choisissez un nouveau répertoire de destination ou un Mac de préparation autorisé, et vérifiez avant l’opération qu’il ne contient pas un état que vous souhaitez conserver. Suivez la procédure officielle de restauration plutôt que de déduire les étapes à partir de la seule présence d’un fichier d’archive (procédure officielle de sauvegarde et de restauration).
La répétition doit être reproductible, pas seulement réussie une fois. Notez l’identifiant de la sauvegarde, l’état de la cible avant l’essai, la méthode employée et les écarts observés. Si l’essai nécessite de l’espace disque supplémentaire pour accueillir l’archive et l’état restauré, vérifiez cette contrainte dans votre environnement avant de lancer l’opération. La documentation disponible ne justifie pas de promettre une capacité universelle ou une durée de restauration : mesurez ces besoins dans votre propre installation.
Avant d’ouvrir le service, contrôlez la correspondance des chemins. Une migration entre Mac peut laisser les données restaurées dans un emplacement que la configuration cible ne consulte pas. Comparez les répertoires d’Agent réellement utilisés, leurs espaces de travail et les chemins personnalisés consignés dans l’inventaire. Une base présente au bon endroit ne répare pas, à elle seule, un lien manquant vers un espace de travail ou une configuration nécessaire.
La version est un autre point de contrôle, en particulier si l’essai vise un retour arrière ou une migration. Les notes officielles ne doivent pas être interprétées comme une garantie générale de compatibilité des données. Vérifiez les indications de précontrôle et les changements de structure documentés avant de restaurer un état dans une version différente (changements de structure et contrôles préalables). Si un contrôle signale une incompatibilité, interrompez l’essai et documentez l’écart au lieu de forcer le démarrage.
FAQ : WAL, Agents et éléments sensibles
Les réponses ci-dessous servent à compléter les contrôles de l’essai ; elles ne remplacent ni l’inventaire local, ni les procédures officielles adaptées à votre version.
Comment éviter d’omettre les données WAL ?
Ne considérez pas la copie du seul fichier principal d’une base en cours d’utilisation comme une sauvegarde validée. Utilisez la méthode OpenClaw documentée pour votre installation, puis effectuez son contrôle prévu et restaurez l’artefact dans une cible isolée. La vérification décisive consiste à ouvrir l’état restauré et à confirmer que les données nécessaires sont accessibles.
Comment vérifier les Agents après restauration ?
Distinguez la présence des répertoires de la disponibilité fonctionnelle. Retrouvez chaque Agent attendu, vérifiez sa configuration et ses conversations, puis contrôlez qu’il peut accéder à son espace de travail. Consignez les écarts au lieu de les masquer par une copie manuelle non tracée. La structure des données documentée par OpenClaw peut guider l’inventaire, mais votre configuration effective reste la référence.
Les archives contiennent-elles des identifiants et des conversations ?
Cela dépend des fichiers et des répertoires effectivement inclus. Un chemin de sauvegarde ne garantit pas automatiquement que tous les secrets ou toutes les conversations soient inclus, et une archive peut contenir des données sensibles sans que son nom le révèle. Vérifiez chaque emplacement, limitez l’accès à l’archive et évitez de copier des secrets dans le compte rendu d’audit.
Que vérifier lors du déplacement vers un autre Mac ?
Comparez les répertoires d’Agent et les espaces de travail, y compris leurs chemins personnalisés, puis contrôlez que la cible utilise la version prévue et peut retrouver les actifs restaurés. Gardez l’état source intact pendant la répétition. Ne considérez pas la base comme une migration complète tant que les configurations, les identifiants requis et les intégrations n’ont pas été examinés.
SECTION 05Avant l’activation : vérifiez le service et les dépendances
Une restauration de base peut réussir alors qu’une fonction attendue reste indisponible. Avant de réintroduire l’état restauré dans un environnement actif, suivez les préconditions officielles de la procédure et arrêtez les composants qui écrivent dans l’état concerné lorsque la documentation le demande. L’objectif est de ne pas mélanger l’ancien état, la restauration et de nouvelles écritures sans savoir lequel des trois fait foi.
Une fois l’état préparé, appliquez les diagnostics demandés avant le redémarrage, puis vérifiez le Gateway et les Agents selon votre inventaire. Contrôlez la visibilité des conversations attendues, la lecture des configurations et l’accès aux espaces de travail. Pour chaque intégration importante, testez séparément les dépendances externes nécessaires : une base lisible ne prouve ni le rétablissement d’un canal de messagerie, ni la validité d’une authentification auprès d’un service externe.
Interprétez aussi prudemment les données restaurées. Après un retour à un état antérieur, les décisions ou approbations enregistrées depuis ce point peuvent ne plus apparaître dans l’état restauré ; des messages traités après ce point peuvent également devoir être examinés selon la logique de déduplication de votre intégration. Ne supposez pas que ces conséquences sont identiques dans toutes les installations : confrontez-les à votre version et aux composants effectivement utilisés, puis définissez la procédure de reprise adaptée avant la bascule.
Pour une migration sur Mac, vérifiez enfin les permissions nécessaires à l’exécution, la disponibilité des répertoires configurés et la résolution des chemins. Un démarrage apparemment sain ne suffit pas si l’Agent ne peut pas lire son espace de travail ou si une intégration dépend d’un identifiant absent. Gardez les résultats de ces essais séparés des contrôles de la base : ils attestent des couches différentes.
SECTION 06À la clôture : consignez l’essai et décidez du statut
Le dossier de répétition doit permettre à une autre personne de comprendre ce qui a été restauré, ce qui a été vérifié et ce qui reste à corriger. Utilisez un registre sobre, sans y inscrire de secret :
| Champ du compte rendu | Information à consigner |
|---|---|
| Référence de l’essai | Identifiant de sauvegarde, date et personne responsable |
| Périmètre prévu | Base, Agents, configurations, espaces de travail et chemins personnalisés concernés |
| Vérification de l’artefact | Méthode documentée suivie et résultat obtenu |
| Cible de restauration | Mac ou répertoire isolé, état initial et compatibilité examinée |
| Contrôles après restauration | Gateway, données attendues, Agents et intégrations testées |
| Écarts et décision | Échecs, correction requise et statut d’acceptation |
Attribuez ensuite un statut compréhensible par l’exploitation et la sécurité :
- Acceptée pour le scénario testé si le périmètre est documenté, que l’artefact a été vérifié et que la restauration isolée a passé les contrôles prévus.
- À corriger avant acceptation si des données ou chemins manquent, si le contrôle de l’artefact échoue ou si un test fonctionnel reste incomplet.
- Extension des charges suspendue si les données sensibles, la compatibilité ou les dépendances indispensables ne peuvent pas être validées.
Une répétition réussie n’autorise pas à conclure que tous les scénarios sont couverts. Elle prouve uniquement ce qui a été restauré et testé, dans les conditions consignées. Réexaminez donc le périmètre lorsqu’un Agent change de répertoire, qu’une intégration ajoute des identifiants, ou que la documentation officielle annonce une évolution des versions ou du stockage. L’index des versions OpenClaw et la documentation des changements de structure sont des points de départ pour détecter ces changements ; ils ne remplacent pas un nouvel essai local.
Si votre restauration exige un Mac accessible pendant la préparation ou la répétition, commencez par définir l’environnement, les accès autorisés et les données de test que vous pouvez y traiter. Vous pouvez comparer les possibilités présentées par MACNOX et ses environnements Mac distants, puis examiner les informations de tarification de MACNOX si vous avez besoin d’évaluer cette option. N’en déduisez pas une capacité de reprise, une configuration ou un niveau de service qui ne serait pas explicitement documenté : votre compte rendu d’essai reste la preuve de ce qui fonctionne pour votre charge OpenClaw.
SECTION 07FAQ
Comment éviter de perdre les données du journal WAL lors d’une sauvegarde SQLite d’OpenClaw ?
Ne traitez pas la copie du seul fichier de base de données en cours d’utilisation comme une sauvegarde validée. Repérez d’abord la méthode de sauvegarde recommandée par la documentation OpenClaw pour votre installation, puis exécutez-la et vérifiez l’archive avec le contrôle prévu. La preuve décisive reste une restauration isolée qui ouvre les données attendues.
Quels contrôles effectuer après avoir restauré OpenClaw sur Mac ?
Vérifiez que le Gateway démarre, que les Agents prévus sont présents et que leurs conversations et configurations correspondent au périmètre sauvegardé. Contrôlez aussi les chemins personnalisés et les intégrations indispensables. Une base lisible ne prouve pas à elle seule que les canaux de messagerie, les extensions ou l’authentification externe fonctionnent.
Une sauvegarde OpenClaw contient-elle les clés API et les conversations ?
Cela dépend des chemins inclus et de la méthode de sauvegarde utilisée. Les bases, les fichiers de configuration et les répertoires d’Agent ne sont pas interchangeables : inventorie-les séparément et consulte la structure réelle de ton installation. Par précaution, traite toute archive susceptible de contenir des conversations ou des identifiants comme une donnée sensible.
Que faut-il vérifier lors d’une migration d’OpenClaw vers un autre Mac ?
Compare les répertoires d’Agent et les espaces de travail de la source et de la cible, en portant une attention particulière aux chemins personnalisés. Vérifie que la cible peut retrouver les actifs restaurés, que la version envisagée est compatible selon la documentation et que les secrets sont transférés par un canal autorisé. Garde l’ancien état intact jusqu’à la validation.