Dupliquer la production pour tester

Reproduire un bug sur des données réelles ne devrait pas être un projet. Une sauvegarde de la production se restaure dans un environnement neuf en quelques clics, et celui d'origine ne bouge pas.

La seule chose à bien comprendre avant de cliquer, c'est qu'il existe deux restaurations, et qu'elles ne font pas du tout la même chose.

Ce qu'une sauvegarde contient

Une sauvegarde prend la base PostgreSQL de l'environnement et son filestore — les pièces jointes, les images, les documents. Les deux, ensemble : une base restaurée sans son filestore donne un Odoo qui s'ouvre et dont chaque pièce jointe est cassée.

Elle est stockée séparément de l'environnement, pas sur son disque — c'est ce qui permet à une sauvegarde de survivre à un environnement cassé. Elle ne survit pas à un environnement supprimé : supprimer un environnement purge toutes ses sauvegardes, archives comprises. Téléchargez ce que vous voulez garder avant de supprimer.

Chaque sauvegarde porte une taille, une date et une date d'expiration. L'expiration vient de la politique de rétention, pas de vous : une sauvegarde peut disparaître d'elle-même, et c'est le paramètre à regarder avant de compter sur une copie ancienne.

Prendre une sauvegarde

Onglet Sauvegardes de l'environnement. Le bouton lance une sauvegarde immédiate ; elle apparaît dans la liste avec son statut pendant qu'elle s'exécute.

À côté, Sauvegardes automatiques définit une politique : une fréquence et une rétention en jours. Une politique quotidienne à 02:00 UTC est le réglage habituel. La rétention est plafonnée par votre offre — le guide des sauvegardes explique comment.

La sauvegarde manuelle et la politique ne s'excluent pas. Avant une opération risquée — une montée de version, un import de modules — prenez-en une à la main : la plus récente de la politique peut avoir plusieurs heures.

Deux façons de restaurer

C'est ici que la distinction compte, et les deux actions sont côte à côte sur la ligne de la sauvegarde. Elles ne se ressemblent pourtant pas : Restaurer est un bouton avec son libellé, le clone est l'icône de copie juste à côté — son infobulle dit « Créer un environnement à partir de cette sauvegarde ». Le titre « Cloner vers un nouvel environnement » n'apparaît qu'une fois la fenêtre ouverte.

Restaurer remet cette sauvegarde dans l'environnement actuel. Il écrase ce qui s'y trouve. Deux choses se produisent avant que vous ayez le temps d'hésiter : une copie de sécurité est prise automatiquement, et l'environnement redémarre. Vous perdez donc tout ce qui a été écrit depuis la sauvegarde choisie — et la copie de sécurité n'est pas le bouton d'annulation qu'elle laisse imaginer : elle est conservée par la plateforme, elle n'apparaît pas dans cette liste, et vous ne pouvez pas la restaurer depuis cet écran. Si vous voulez une copie de l'état actuel que vous maîtrisez, prenez une sauvegarde avant de restaurer. Le guide sur les sauvegardes le détaille.

Cloner vers un nouvel environnement crée un environnement neuf à partir de cette sauvegarde. La source n'est pas touchée du tout. C'est l'opération à choisir dans neuf cas sur dix : pour reproduire un bug, faire une recette, ou montrer quelque chose à un client, il n'y a aucune raison de risquer la production.

Le clone vous demande trois choses : une clé d'environnement (l'identifiant en minuscules, unique dans l'instance), un nom affiché, et une branche Git. Les trois sont pré-remplies à partir de la source — nom suivi de « (copy) », clé suffixée par « -copy », branche identique — et les trois restent obligatoires. La copie peut garder la branche de la source : plusieurs environnements peuvent suivre la même. Autre branche… crée dans le dépôt la branche que vous saisissez, à partir de celle de la source.

Il indique aussi où naît la base de données de la copie : par défaut au même endroit que celle de la source — le même cluster de bases de votre équipe, ou la base de la plateforme — et vous pouvez en choisir un autre. Sur votre propre serveur, la copie y naît aussi, avec sa base.

Ce que le clone reprend, et ce qu'il ne reprend pas

Il reprend le dépôt et le modèle de ressources de l'environnement source : le nouvel environnement construit donc le même code, sur la même taille de machine.

Il ne reprend pas trois choses :

• La vie de la production, par défaut. La case Copie de test, cochée d'office, neutralise le clone avant qu'il ne réponde : serveurs de mail sortant et entrant, actions planifiées et fournisseurs de paiement désactivés, alias de messagerie retirés, tous les utilisateurs désactivés sauf l'administrateur (qui reçoit un nouvel accès), et Odoo affiche son bandeau « base neutralisée ». Deux cases, indépendantes, gardent des utilisateurs actifs : Garder les utilisateurs internes laisse à vos équipes leurs accès habituels, pour une recette ; Garder les comptes du portail laisse actifs ceux de vos clients et fournisseurs, pour tester un parcours tel qu'ils le voient. Le reste de la neutralisation ne change pas. Sur une instance Odoo Enterprise, la copie ne reprend pas non plus l'abonnement de la production : Odoo n'admet qu'une base par code de souscription, et la copie reçoit sa propre identité de base. Elle tourne donc en période d'essai Odoo, par conception — le bandeau d'expiration qu'elle affiche est attendu. Refaites-la depuis la production quand vous en avez besoin. Décochez-la uniquement pour une vraie migration : un clone laissé vivant envoie les e-mails de la production et rejoue ses tâches planifiées — jusqu'au 18/09/2026 c'était le comportement, sans case. Il garde aussi l'abonnement de la production ; enregistrez alors le code sur le nouvel environnement, et retirez l'ancien une fois la bascule faite.
• Le déploiement automatique est désactivé. Un clone existe pour figer un état, pas pour suivre la branche. S'il se redéployait au premier push, l'état que vous vouliez examiner disparaîtrait pendant que vous l'examinez.
• La facturation démarre à l'état « en attente ». Un clone est un environnement à part entière : il consomme des ressources et il est facturé comme tel une fois actif. Ce n'est pas une copie gratuite, et la meilleure habitude est de le supprimer quand la question qui l'a fait naître est répondue.

Importer un dump existant

Vous pouvez aussi restaurer une base qui ne vient pas d'ici. L'import se fait en deux temps : le navigateur téléverse le fichier directement vers le stockage objet, puis la plateforme l'enregistre comme une sauvegarde de cet environnement. Elle apparaît ensuite dans la liste et se restaure comme les autres.

Le téléversement va du navigateur vers le stockage, sans passer par la plateforme. C'est ce qui permet d'envoyer un fichier de plusieurs gigaoctets — et c'est aussi pourquoi un échec à cette étape ne dit pas grand-chose : l'erreur vient du stockage, pas de l'application. Si un import échoue tout de suite, c'est presque toujours la taille du fichier ou une coupure réseau, pas la sauvegarde elle-même.

Suivre une restauration

L'onglet garde un historique des restaurations : celles que vous lancez depuis cet écran, sur place comme depuis une sauvegarde. Chacune expose ses journaux.

Les restaurations exécutées pendant la création d'un environnement sont ailleurs — derrière le bouton Journaux de provisionnement, sur le même onglet. C'est la distinction utile quand un clone n'arrive pas à démarrer : la restauration qui a échoué n'est pas dans l'historique, elle est dans les journaux de provisionnement.

Une restauration prend le temps que prend la base. Une base volumineuse met des dizaines de minutes, et un environnement qui reste en cours de création n'est pas forcément bloqué.

Tester une restauration avant d'en avoir besoin

Une sauvegarde jamais restaurée est une croyance, pas une garantie. La seule façon de savoir qu'elle contient ce que vous imaginez est d'en restaurer une — et le clone rend ce test gratuit en risque.

Un test utile tient en quatre points :

1. Cloner la sauvegarde la plus récente vers un environnement jetable.
2. Ouvrir Odoo et se connecter.
3. Vérifier une pièce jointe, pas seulement un enregistrement : c'est le filestore qui manque quand quelque chose manque.
4. Supprimer le clone.

Faites-le une fois après la mise en production, puis après chaque changement d'offre ou de version. Le jour où vous restaurez pour de vrai, vous saurez déjà combien de temps ça prend et à quoi ressemble le résultat.