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 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.

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 deux choses :

• 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 — dans les « Journaux de restauration au 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.