Toute base de données Odoo finit par devenir la source unique de vérité d'une entreprise : factures, niveaux de stock, éléments de paie, historique client et documents signés y sont tous conservés. La perdre, ou restaurer une copie incomplète, peut paralyser l'activité pendant des jours. Pourtant, de nombreuses entreprises ne découvrent les lacunes de leur stratégie de sauvegarde que le jour où elles en ont besoin.
Cet article présente l'essentiel de la gestion des bases de données, des sauvegardes et de la reprise après sinistre pour Odoo 19 Enterprise, en précisant les différences propres aux installations Community auto-hébergées. Il s'adresse aux dirigeants, aux directeurs financiers et aux responsables informatiques qui ont besoin d'une vision claire sans lire chaque page technique.
Une remarque sur les sources : ce guide s'appuie sur la documentation officielle d'Odoo pour la version 19. Les plateformes d'hébergement et leurs options évoluent ; vérifiez donc chaque étape dans une base de test et au regard de la documentation officielle en vigueur avant de vous y fier en production.
Ce que contient une sauvegarde Odoo complète
Une base de données Odoo n'est pas seulement une base PostgreSQL. Les pièces jointes, comme les documents téléversés, les images et les autres contenus binaires, sont stockées sous forme de fichiers dans ce qu'Odoo appelle le filestore, et Odoo en contrôle l'accès. Une sauvegarde qui ne contient que le dump de la base restaurera vos enregistrements, mais les pièces jointes manqueront.
La documentation d'Odoo.sh décrit ses sauvegardes comme comprenant le dump de la base de données, le filestore (pièces jointes et champs binaires), les journaux et les sessions. C'est une référence utile pour savoir à quoi ressemble une sauvegarde complète, quel que soit le type d'hébergement.
- Dump de la base de données : tous les enregistrements, la configuration, les utilisateurs, les écritures comptables et les paramètres.
- Filestore : les pièces jointes et les champs binaires, comme les factures fournisseurs numérisées, les images de produits et les PDF signés.
- Code personnalisé : sur Odoo.sh et sur site, vos modules personnalisés se trouvent dans votre dépôt de code, qui nécessite sa propre protection.
- Configuration : sur site, le fichier de configuration d'Odoo et le paramétrage du serveur doivent également être documentés et conservés en lieu sûr.
Lorsque vous vérifiez une sauvegarde, assurez-vous toujours que le dump et le filestore sont tous deux présents. L'absence du filestore est l'une des raisons les plus fréquentes pour lesquelles une base restaurée semble correcte au premier abord, puis affiche des images cassées et des documents manquants.
Les sauvegardes selon le type d'hébergement
La responsabilité des sauvegardes dépend de l'endroit où tourne votre base de données. Odoo Online et Odoo.sh sont hébergés par Odoo et incluent des sauvegardes automatiques, alors qu'avec un serveur sur site, votre propre équipe en est entièrement responsable. L'édition Community étant généralement auto-hébergée, les responsabilités décrites ci-dessous pour l'hébergement sur site s'y appliquent.
Odoo Online : le gestionnaire de bases de données
Sur Odoo Online, la documentation officielle indique que les bases de données sont sauvegardées quotidiennement conformément au SLA Odoo Cloud Hosting. Vous n'avez rien à planifier pour que ces sauvegardes de la plateforme aient lieu.
Le gestionnaire de bases de données, accessible en vous connectant en tant qu'administrateur de la base, propose une option Gérer regroupant les principales actions nécessaires aux sauvegardes et aux tests.
- Télécharger la sauvegarde produit un fichier ZIP de la base de données que vous pouvez conserver dans vos propres archives.
- Si Télécharger la sauvegarde est désactivé, la base est trop volumineuse pour le gestionnaire, et il faut contacter le support Odoo pour obtenir une autre méthode de téléchargement.
- Dupliquer crée une copie de la base de données ; l'option À des fins de test est activée par défaut et désactive les actions externes telles que les e-mails, les paiements et les bons de livraison.
- Supprimer efface instantanément la base pour tous les utilisateurs, sans retour possible ; téléchargez donc d'abord une sauvegarde.
D'après la documentation, les copies dupliquées sur Odoo Online expirent au bout de 15 jours et chaque base peut avoir jusqu'à cinq copies. Considérez ces copies comme des environnements de test éphémères, et non comme une stratégie de sauvegarde.
Odoo.sh : sauvegardes automatiques et manuelles
Sur Odoo.sh, la base de production est sauvegardée automatiquement chaque jour. La documentation indique que sept sauvegardes quotidiennes, quatre hebdomadaires et trois mensuelles sont conservées, les copies mensuelles étant stockées sur des serveurs de sauvegarde dédiés. Pour restaurer ou télécharger ces sauvegardes mensuelles, il faut contacter le support Odoo.
Les branches de préproduction et de développement ne sont pas sauvegardées automatiquement. Des sauvegardes manuelles peuvent être réalisées pour la production et la préproduction afin de capturer un instantané précis, par exemple avant une modification de configuration risquée. Elles restent disponibles pendant trois jours, et la documentation mentionne une limite de cinq sauvegardes manuelles par jour. Les bases de développement ne peuvent pas être sauvegardées manuellement.
Odoo.sh crée également une sauvegarde automatique, signalée comme sauvegarde de mise à jour, lorsqu'un commit fusionné modifie des versions de modules ou des dépendances Python associées. Si une fusion ne modifie pas ces éléments, aucune sauvegarde n'est déclenchée ; réalisez donc une sauvegarde manuelle avant toute modification importante de la production.
- Utilisez l'onglet Sauvegardes de la branche de production pour consulter, télécharger ou restaurer des sauvegardes.
- Restaurez une sauvegarde de production dans une branche de préproduction lorsque vous souhaitez tester sur des données réelles.
- Utilisez la fonction Importer une base de données pour importer des archives provenant du gestionnaire de bases de données standard, du gestionnaire de bases de données d'Odoo Online, de l'onglet Sauvegardes ou de l'option de téléchargement du dump de la base d'un build.
Sur site : votre équipe est responsable de tout
Sur votre propre serveur, rien n'est sauvegardé tant que vous ne l'avez pas mis en place. Les recommandations officielles de déploiement sont sans détour : mettez en place des sauvegardes quotidiennes de vos bases de données et des données du filestore, et copiez-les vers un serveur d'archivage distant qui n'est pas accessible depuis le serveur lui-même.
Ces mêmes recommandations avertissent que le gestionnaire de bases de données web est conçu comme un outil de développement et de démonstration et n'est pas prévu pour un usage en production. Il est vivement recommandé de le désactiver sur tout système exposé à Internet, et les opérations de production telles que les sauvegardes automatisées doivent être prises en charge par l'administrateur système.
- Protégez les écrans de gestion des bases de données par un mot de passe maître robuste, généré aléatoirement et défini dans le fichier de configuration, jamais par la valeur par défaut.
- Désactivez la liste des bases de données sur les serveurs exposés à Internet et utilisez un filtre de bases de données afin que chaque nom d'hôte corresponde à la bonne base.
- Exécutez l'utilisateur PostgreSQL d'Odoo sans droits de superutilisateur, comme l'exige la documentation de déploiement.
- Sauvegardez ensemble la base de données et le filestore, afin que les deux restent cohérents entre eux.
Avant des changements majeurs, comme le passage de Community à Enterprise, la documentation officielle indique comme première étape la sauvegarde de la base Community. Adoptez le même réflexe avant toute mise à niveau, installation de module ou import de données.
Dupliquer des bases en toute sécurité : la neutralisation
Tester sur une copie de la production est la manière la plus sûre d'essayer de nouveaux flux, des imports ou des mises à niveau, mais une copie réalisée sans précaution peut envoyer de vrais e-mails aux clients ou déclencher de vrais paiements. Odoo gère ce risque avec des bases neutralisées, que la documentation définit comme des bases hors production sur lesquelles plusieurs paramètres sont désactivés.
Les bases de test sont toujours neutralisées, y compris les copies de sauvegarde, les copies dupliquées et les bases de préproduction et de développement d'Odoo.sh. La liste des éléments désactivés fournie par la documentation est explicitement non exhaustive et comprend notamment les suivants.
- Les actions planifiées, comme la facturation automatique des abonnements et les envois d'e-mails en masse.
- Les e-mails sortants, qui, en préproduction sur Odoo.sh, sont captés par un intercepteur de courriels au lieu d'être envoyés.
- La synchronisation bancaire, les fournisseurs de paiement et les modes de livraison.
- Les jetons IAP, ainsi que la visibilité du site web pour les moteurs de recherche.
Une bannière rouge en haut de l'écran signale une base neutralisée, afin que les utilisateurs voient immédiatement qu'ils ne sont pas en production. Formez votre équipe à vérifier la présence de cette bannière avant toute saisie, et ne retirez jamais la neutralisation d'une copie sans en mesurer pleinement les conséquences.
Rétention, copies externalisées, RPO et RTO
Les sauvegardes de la plateforme constituent un solide filet de sécurité, mais une politique saine prévoit aussi des copies indépendantes sous votre contrôle. Pour les bases hébergées, téléchargez périodiquement une sauvegarde complète et stockez-la dans un emplacement distinct à accès contrôlé. Pour les serveurs sur site, les copies externalisées sont indispensables, et non facultatives.
Deux indicateurs simples vous aident à déterminer le niveau de protection nécessaire. L'objectif de point de reprise, ou RPO, correspond à la quantité de données récentes que vous pouvez vous permettre de perdre ; une sauvegarde quotidienne implique que vous pouvez perdre jusqu'à une journée de travail. L'objectif de temps de reprise, ou RTO, correspond à la durée pendant laquelle l'entreprise peut fonctionner sans le système pendant sa restauration.
Fixez ces objectifs avec la direction, puis vérifiez si votre dispositif actuel les respecte. Si perdre une journée entière de commandes client est inacceptable, des sauvegardes quotidiennes ne suffisent pas, et vous devez envisager des instantanés plus fréquents ou d'autres mesures avec votre hébergeur ou votre équipe informatique.
Tests de restauration et liste de contrôle pratique
Une sauvegarde n'est validée qu'une fois restaurée. Planifiez un test de restauration à intervalle régulier, restaurez dans un environnement de test neutralisé et vérifiez que les utilisateurs peuvent se connecter, que les enregistrements récents sont présents et que les pièces jointes s'ouvrent correctement. Chronométrez l'opération pour connaître votre RTO réel.
- Identifiez le type d'hébergement utilisé et la personne responsable des sauvegardes.
- Vérifiez que les sauvegardes contiennent à la fois le dump de la base et le filestore.
- Conservez une copie téléchargée indépendante dans un emplacement distinct et sécurisé.
- Réalisez une sauvegarde manuelle avant les mises à niveau, les imports volumineux ou les modifications majeures de configuration.
- Utilisez des copies neutralisées ou des branches de préproduction pour tous les tests.
- Restaurez régulièrement une sauvegarde dans un environnement de test et consignez les résultats.
- Documentez vos objectifs de RPO et de RTO et révisez-les chaque année.
- Sur site, désactivez le gestionnaire de bases de données public et protégez le mot de passe maître.
Comment 1CBMS peut vous aider
1CBMS conçoit et audite des routines de sauvegarde et de restauration pour des projets Odoo 19 en Égypte et en Irak, sur Odoo Online, Odoo.sh et des serveurs sur site. Nous pouvons auditer votre dispositif actuel, définir avec votre direction des objectifs de RPO et de RTO réalistes, mettre en place des environnements de test neutralisés et mener avec votre équipe un test de restauration documenté, afin que la restauration soit une procédure répétée plutôt qu'une urgence.