Se rendre au contenu

Odoo sur OVHcloud : comment bien l'héberger

Odoo sur OVHcloud : comment bien l'héberger
octobre 29, 2026 · 22 min de lecture

La réponse courte

Pour héberger Odoo sur OVHcloud, prenez un VPS ou une instance Public Cloud avec assez de mémoire. Mettez Postgres sur le même serveur, sur une deuxième instance dans un réseau privé, ou sur le PostgreSQL managé d'OVHcloud. N'ouvrez au monde que les ports 80 et 443, et SSH seulement à votre propre adresse. Envoyez chaque nuit une copie de la base et du filestore vers un bucket Object Storage dans une autre région, avec un utilisateur qui peut seulement écrire dans ce bucket. Puis restaurez une copie sur un autre serveur avant la mise en ligne.

OVHcloud est une entreprise française avec des data centers en Europe et ailleurs. Beaucoup d'équipes le choisissent pour garder leurs données chez un fournisseur européen. Ce guide vous donne les commandes exactes pour chaque étape sur OVHcloud.

Pour l'installation elle-même (Odoo, Postgres, le fichier de configuration et le proxy), suivez notre guide sur Odoo sur un VPS. Cette page couvre ce qui change sur OVHcloud.

VPS ou Public Cloud

OVHcloud vend deux types de serveurs adaptés à Odoo :

  • VPS. Une taille fixe, un panneau de contrôle simple, et une sauvegarde quotidienne incluse. Bien pour un seul serveur Odoo avec Postgres dessus.
  • Instances Public Cloud. Beaucoup de tailles, des réseaux privés (vRack), des security groups et un outil en ligne de commande (OpenStack CLI). Mieux quand vous voulez Postgres sur son propre serveur ou sur le service managé.

Le minimum pour démarrer : 2 vCPU, 4 Go de mémoire et 50 Go de disque. Cela fait tourner Odoo et Postgres sur un seul serveur pour une petite équipe. La mémoire compte plus que le CPU : chaque worker a besoin de sa part, et Postgres veut la sienne. Pour plus d'utilisateurs, de gros imports ou Postgres sur son propre serveur, notre guide sur le nombre de workers Odoo dont vous avez besoin montre comment bien dimensionner.

Choisir la région

Vos données vivent là où vit le serveur. Mettez-le près de vos utilisateurs.

  • Sur Public Cloud, une région peut être 1-AZ (un data center, comme Gravelines GRA ou Strasbourg SBG), 3-AZ (trois zones, comme Paris EU-WEST-PAR), ou une Local Zone.
  • Évitez les Local Zones pour Odoo. Elles ne peuvent pas rejoindre un vRack, elles ne peuvent envoyer d'e-mails sur aucun port SMTP, et un VPS en Local Zone n'a ni snapshots, ni sauvegardes automatiques, ni Anti-DDoS.

Créer une instance Public Cloud en ligne de commande

D'abord, installez le client OpenStack sur votre propre ordinateur :

sudo apt install -y python3-pip python3-venv
python3 -m venv ~/openstack-env
source ~/openstack-env/bin/activate
pip install --upgrade pip
pip install python-openstackclient

Puis récupérez votre fichier de connexion. Dans le panneau de contrôle, ouvrez votre projet Public Cloud. Allez dans Settings > Users & Roles et cliquez sur Create User. Donnez-lui le rôle Administrator et enregistrez le mot de passe affiché. Il n'est affiché qu'une fois. Puis cliquez sur ... à côté de l'utilisateur et choisissez Download OpenStack's RC file. Chaque fichier vaut pour une seule région.

source ~/Downloads/openrc.sh      # asks for the user's password
openstack server list             # works if your login is right

Ajoutez votre clé SSH, puis cherchez une taille (flavor) et une image :

openstack keypair create --public-key ~/.ssh/id_ed25519.pub my-key
openstack flavor list --min-ram 7000
openstack image list --property visibility=public | grep -i ubuntu

Les noms de flavor ressemblent à b2-7 (General Purpose, 7 Go de mémoire). Choisissez-en un selon la mémoire dont vous avez besoin. Puis créez l'instance. Nous ajoutons ici un security group. La section suivante montre comment le créer.

openstack server create \
  --flavor b2-7 \
  --image "Ubuntu 24.04" \
  --key-name my-key \
  --network Ext-Net \
  --security-group odoo-web \
  odoo-web

Ext-Net est le réseau public d'OVHcloud. Il donne une IP publique à l'instance. Vérifiez que l'instance est démarrée et lisez son adresse :

openstack server show odoo-web -c status -c addresses -c security_groups
ssh ubuntu@<public-ip>

Le nom d'utilisateur dépend de l'image : ubuntu sur Ubuntu, debian sur Debian.

Créer un VPS

Un VPS n'a pas d'OpenStack CLI. Vous le commandez dans le panneau de contrôle, et vous y choisissez le système et votre clé SSH. Pour ajouter une clé plus tard, allez dans Bare Metal Cloud > Virtual private servers, choisissez votre VPS, cliquez sur ... à côté de OS/Distribution, puis Reinstall my VPS. Choisissez votre clé sous SSH Key to pre-install. Cela efface les disques, faites-le donc avant d'installer quoi que ce soit.

Connectez-vous avec ssh ubuntu@<vps-ip> sur Ubuntu, ou debian@ sur Debian.

Où mettre Postgres

Vous avez trois choix.

1. Sur le même serveur

C'est le plus simple. Très bien pour beaucoup d'équipes. Le guide VPS le couvre. Postgres écoute uniquement sur localhost, il n'y a donc rien à ouvrir.

2. Sur une deuxième instance, par un réseau privé

Sur Public Cloud, vous pouvez mettre Postgres sur sa propre instance et lui parler par un réseau privé. Les nouveaux projets ont déjà un vRack, il suffit donc de créer le réseau.

openstack network create odoo-private
openstack subnet create odoo-private-subnet \
  --network odoo-private \
  --subnet-range 10.1.0.0/24 \
  --dhcp --gateway none

--gateway none empêche le réseau privé d'envoyer une deuxième route par défaut à vos serveurs. Leur trafic internet continue de passer par Ext-Net.

Créez les deux serveurs avec les deux réseaux. Donnez au serveur de base de données son propre security group (voir la section pare-feu) :

openstack server create --flavor b2-7 --image "Ubuntu 24.04" --key-name my-key \
  --network Ext-Net --network odoo-private --security-group odoo-web odoo-web

openstack server create --flavor b2-15 --image "Ubuntu 24.04" --key-name my-key \
  --network Ext-Net --network odoo-private --security-group odoo-db odoo-db

Si le serveur Odoo existe déjà, attachez-le avec openstack server add network odoo-web odoo-private. Puis redémarrez-le une fois et vérifiez que les noms de ses réseaux n'ont pas été inversés.

Trouvez l'adresse privée de chaque serveur :

openstack server show odoo-db -c addresses
# addresses | Ext-Net=..., 51.x.x.x ; odoo-private=10.1.0.12

Sur le serveur de base de données, faites aussi écouter Postgres sur son adresse privée. Dans /etc/postgresql/16/main/postgresql.conf (remplacez 16 par votre version) :

listen_addresses = 'localhost,10.1.0.12'

Dans /etc/postgresql/16/main/pg_hba.conf, ne laissez entrer que le rôle odoo, seulement depuis le réseau privé, et seulement vers yourdb et postgres. Le chat en direct d'Odoo se connecte à la base postgres, gardez-la donc dans la liste :

hostssl  yourdb,postgres  odoo  10.1.0.0/24  scram-sha-256

Redémarrez et testez depuis le serveur Odoo :

sudo systemctl restart postgresql            # on odoo-db
psql "host=10.1.0.12 dbname=yourdb user=odoo sslmode=require" -c "select 1"   # on odoo-web

Puis, dans odoo.conf sur le serveur Odoo, mettez db_host = 10.1.0.12 et db_sslmode = require.

3. Sur le PostgreSQL managé d'OVHcloud

OVHcloud gère le serveur de base de données pour vous : mises à jour, bascule en cas de panne et sauvegardes.

Créer le service. Dans votre projet Public Cloud, allez dans Databases et cliquez sur Create a service. Choisissez PostgreSQL et une version que votre version d'Odoo prend en charge. Choisissez la même région que votre serveur Odoo, puis une offre et une taille. Côté réseau, vous pouvez choisir un réseau privé (vRack) si votre serveur Odoo est sur Public Cloud.

Autoriser votre serveur Odoo. Par défaut, le service n'accepte aucune connexion. Il a même l'air prêt alors qu'il refuse tout le monde. Ouvrez l'onglet Configuration, trouvez IPs, et ajoutez l'IP publique de votre serveur Odoo en /32 (par exemple 203.0.113.10/32). Sur un réseau privé, ajoutez plutôt votre sous-réseau privé. N'ajoutez jamais 0.0.0.0/0 en production.

Récupérer l'accès admin. Le premier utilisateur s'appelle avnadmin. Ouvrez l'onglet Users, cliquez sur ... à côté de lui, et choisissez Reset password. Enregistrez le mot de passe tout de suite. OVHcloud ne le garde pas. L'onglet Dashboard affiche le nom d'hôte et le port. Le port n'est pas 5432. Il ressemble à 20184.

Télécharger le certificat CA. Dans l'onglet Dashboard, la section Connection information contient le certificat. Enregistrez-le sur le serveur Odoo sous /etc/odoo/ovh-db-ca.pem.

Créer l'utilisateur odoo et la base. avnadmin peut créer des utilisateurs et des bases, mais ce n'est pas un superuser. Il doit donc d'abord devenir membre du rôle odoo avant de pouvoir faire de odoo le propriétaire d'une base. Connectez-vous depuis le serveur Odoo :

psql "postgres://avnadmin@<host>:<port>/defaultdb?sslmode=verify-full&sslrootcert=/etc/odoo/ovh-db-ca.pem"

CREATE ROLE odoo LOGIN;
\password odoo
GRANT odoo TO avnadmin;
CREATE DATABASE yourdb OWNER odoo ENCODING 'UTF8';
\l yourdb

Les utilisateurs créés en SQL n'apparaissent pas dans l'onglet Users du panneau de contrôle. C'est normal. odoo est propriétaire de sa base, donc Odoo peut y travailler. Il ne peut pas créer d'autres bases, et c'est ce que vous voulez.

Relier Odoo à la base. Dans odoo.conf :

db_host = postgresql-xxxxxxxx-xxxxxxxx.database.cloud.ovh.net
db_port = 20184
db_user = odoo
db_password = <odoo password>
db_name = yourdb
dbfilter = ^yourdb$
db_sslmode = require

require chiffre la connexion. Pour vérifier aussi que vous parlez au bon serveur, utilisez db_sslmode = verify-full. Puis indiquez au service Odoo où se trouve le certificat avec sudo systemctl edit odoo :

[Service]
Environment=PGSSLROOTCERT=/etc/odoo/ovh-db-ca.pem

Utilisez toujours le nom d'hôte du panneau de contrôle, jamais l'IP. L'IP peut changer, et verify-full échoue sur une IP.

Surveiller la limite de connexions. Le service permet environ 100 connexions par 4 Go de mémoire. Chaque worker Odoo peut ouvrir jusqu'à db_maxconn connexions (64 par défaut). Gardez (workers + max_cron_threads + 1) × db_maxconn sous votre limite. Par exemple, mettez db_maxconn = 16.

Ce que couvrent ses sauvegardes. Le service managé sauvegarde la base en continu. Vous pouvez la restaurer à n'importe quel moment de la période de rétention de votre offre. Une copie part dans une deuxième région (par exemple, de GRA vers SBG). Il ne sauvegarde pas le filestore. Les pièces jointes et les images vivent toujours sur le serveur Odoo, dans /var/lib/odoo/filestore. Vous les sauvegardez vous-même, plus bas.

Pare-feu

N'autorisez que ceci depuis internet :

  • 80 et 443 depuis partout
  • 22 uniquement depuis vos propres adresses IP

Bloquez tout le reste. Les ports d'Odoo (8069 et 8072) ne doivent être joints que par le proxy, sur le serveur lui-même.

Public Cloud : security groups

Le security group default laisse tout entrer. Ne le modifiez pas et ne le supprimez pas. Les outils d'OVHcloud le remettent à zéro. Créez votre propre groupe, et donnez-le à l'instance à la place de default.

openstack security group create odoo-web --description "Odoo web server"

openstack security group rule create --ingress --protocol tcp --dst-port 80  --remote-ip 0.0.0.0/0 odoo-web
openstack security group rule create --ingress --protocol tcp --dst-port 443 --remote-ip 0.0.0.0/0 odoo-web
openstack security group rule create --ingress --ethertype IPv6 --protocol tcp --dst-port 80  --remote-ip ::/0 odoo-web
openstack security group rule create --ingress --ethertype IPv6 --protocol tcp --dst-port 443 --remote-ip ::/0 odoo-web
openstack security group rule create --ingress --protocol tcp --dst-port 22  --remote-ip 198.51.100.7/32 odoo-web

Remplacez 198.51.100.7 par l'adresse de votre bureau ou de votre VPN. Un nouveau groupe laisse déjà sortir tout le trafic sortant, et les security groups se souviennent des connexions ouvertes. Les réponses aux requêtes de votre serveur reviennent donc toutes seules.

Pour un serveur de base de données sur le réseau privé, n'autorisez Postgres que depuis les serveurs du groupe odoo-web :

openstack security group create odoo-db --description "Postgres server"
openstack security group rule create --ingress --protocol tcp --dst-port 5432 --remote-group odoo-web odoo-db
openstack security group rule create --ingress --protocol tcp --dst-port 22 --remote-ip 198.51.100.7/32 odoo-db

Si vous avez créé le serveur avec default, échangez les groupes :

openstack server add security group odoo-web odoo-web
openstack server remove security group odoo-web default
openstack server show odoo-web -c security_groups

Puis testez depuis votre ordinateur. Le port 443 doit répondre, et le 8069 non :

nc -zv -w 5 <public-ip> 443
nc -zv -w 5 <public-ip> 8069    # must time out

VPS : Edge Network Firewall

Un VPS n'a pas de security groups. OVHcloud vous donne à la place l'Edge Network Firewall. Il filtre le trafic en bordure du réseau d'OVHcloud, avant qu'il n'arrive à votre serveur. Vous le trouvez dans le panneau de contrôle sous Network > Public IP Addresses. Cliquez sur ... à côté de l'adresse IPv4 de votre VPS, puis sur Configure Edge Network Firewall.

Trois choses à savoir avant d'ajouter des règles :

  • Il est stateless. Il ne se souvient pas des connexions. Si vous n'autorisez pas les réponses, votre serveur ne peut ni télécharger les mises à jour ni joindre Object Storage. La règle 0 ci-dessous règle ce problème.
  • L'ordre compte. Les règles passent de la priorité 0 à 19. La première règle qui correspond gagne. La dernière règle doit refuser le reste. Une liste avec seulement des règles « Accept » ne bloque rien.
  • Il ne couvre que l'IPv4, et seulement le trafic venant de l'extérieur d'OVHcloud. Il vous faut quand même un pare-feu sur le serveur.

Ajoutez ces règles (jusqu'à 20 par IP) :

Priorité Action Protocole IP source Port de destination Autre
0 Accept TCP TCP state: established
1 Accept ICMP
2 Accept TCP votre IP/32 22
3 Accept TCP 80
4 Accept TCP 443
5 Accept UDP Port source 53 (réponses DNS)
6 Accept UDP Port source 123 (réponses de synchro de l'heure)
19 Deny IPv4

Laissez le port source vide sur les règles 2 à 4. Le client en choisit un au hasard. Puis activez le pare-feu avec l'interrupteur.

Même si vous le laissez désactivé, OVHcloud l'active tout seul pendant une attaque DDoS, avec vos règles. Gardez donc des règles justes dans tous les cas. Vous pouvez aussi utiliser ce pare-feu sur l'IP publique d'une instance Public Cloud, mais les security groups font déjà le travail là-bas.

Sur le serveur : ufw

Sur un VPS comme sur une instance, activez aussi le pare-feu dans Ubuntu. Autorisez d'abord SSH, pour ne pas vous enfermer dehors :

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow from 198.51.100.7 to any port 22 proto tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

Sur un serveur de base de données à part, n'autorisez Postgres que depuis le réseau privé : sudo ufw allow from 10.1.0.0/24 to any port 5432 proto tcp.

Sauvegardes vers Object Storage

Ce qu'OVHcloud sauvegarde pour vous

  • Sauvegarde automatique du VPS. Une sauvegarde quotidienne de tout le serveur est incluse avec un VPS. L'option premium garde les 7 derniers jours. Elle n'inclut pas les disques supplémentaires.
  • Snapshot de VPS. Une option payante. Vous gardez un seul snapshot à la fois, et le restaurer le supprime. Utilisez-le avant une mise à jour.
  • Sauvegardes d'instance Public Cloud. Ponctuelles, ou planifiées chaque jour en gardant les 7 ou 14 dernières. Vous pouvez ajouter une copie dans une autre région. Depuis la CLI : openstack server image create --name odoo-web-before-upgrade odoo-web.

Toutes copient le disque entier pendant que Postgres tourne. Elles sont utiles pour reconstruire un serveur. Elles ne suffisent pas seules pour Odoo. Il vous faut aussi une copie propre de la base et du filestore, prises ensemble, gardées hors du serveur, et testées. Si vous utilisez les sauvegardes de VPS, installez l'agent QEMU pour que le disque soit figé proprement pendant la copie :

sudo apt install -y qemu-guest-agent
sudo systemctl start qemu-guest-agent

Créer le bucket et un utilisateur réservé aux sauvegardes

Choisissez pour le bucket une autre région que celle du serveur. Par exemple, serveur à GRA, bucket à SBG. Les endpoints ressemblent à https://s3.<region>.io.cloud.ovh.net, donc https://s3.sbg.io.cloud.ovh.net pour Strasbourg.

Il vous faut deux utilisateurs Object Storage. Voici pourquoi. Les politiques utilisateur d'OVHcloud ne peuvent pas limiter l'utilisateur propriétaire d'un bucket. Le propriétaire peut toujours tout faire.

  1. Utilisateur propriétaire. Dans votre projet Public Cloud, ouvrez Object Storage et créez le bucket your-odoo-backups. Activez le versioning dans le formulaire. Liez-y un nouvel utilisateur. Gardez les clés de cet utilisateur sur votre propre ordinateur, jamais sur le serveur Odoo.
  2. Utilisateur de sauvegarde. Dans la liste des utilisateurs Object Storage, cliquez sur Create User et enregistrez sa clé d'accès et sa clé secrète. Cliquez sur ... à côté de lui, choisissez Import JSON file, et envoyez cette politique :
{
  "Statement": [
    {
      "Sid": "OdooBackupWriteOnly",
      "Effect": "Allow",
      "Action": [
        "s3:PutObject",
        "s3:GetObject",
        "s3:ListBucket",
        "s3:GetBucketLocation",
        "s3:ListBucketMultipartUploads",
        "s3:ListMultipartUploadParts",
        "s3:AbortMultipartUpload"
      ],
      "Resource": [
        "arn:aws:s3:::your-odoo-backups",
        "arn:aws:s3:::your-odoo-backups/*"
      ]
    },
    {
      "Sid": "HideOtherBuckets",
      "Effect": "Deny",
      "Action": ["s3:ListAllMyBuckets"],
      "Resource": ["*"]
    }
  ]
}

Cet utilisateur peut ajouter et lire des sauvegardes dans ce seul bucket. Il ne peut pas les supprimer, et il ne voit pas les autres buckets. Si quelqu'un entre dans le serveur Odoo, il ne peut pas effacer vos sauvegardes. Le versioning garde aussi l'ancienne copie si un fichier est écrasé.

Versioning et expiration

Les anciennes sauvegardes doivent partir toutes seules. Réglez ceci depuis votre propre ordinateur avec les clés de l'utilisateur propriétaire, une fois le versioning activé. Enregistrez-le sous lifecycle.json :

{
  "Rules": [
    {
      "ID": "expire-odoo-backups",
      "Status": "Enabled",
      "Filter": { "Prefix": "" },
      "Expiration": { "Days": 30 },
      "NoncurrentVersionExpiration": { "NoncurrentDays": 7 },
      "AbortIncompleteMultipartUpload": { "DaysAfterInitiation": 3 }
    },
    {
      "ID": "clean-delete-markers",
      "Status": "Enabled",
      "Filter": { "Prefix": "" },
      "Expiration": { "ExpiredObjectDeleteMarker": true }
    }
  ]
}

aws s3api get-bucket-versioning --bucket your-odoo-backups --profile ovh-owner
aws s3api put-bucket-lifecycle-configuration --bucket your-odoo-backups \
  --lifecycle-configuration file://lifecycle.json --profile ovh-owner
aws s3api get-bucket-lifecycle-configuration --bucket your-odoo-backups --profile ovh-owner

Les sauvegardes de plus de 30 jours sont supprimées, et les versions remplacées partent 7 jours plus tard. OVHcloud applique ces règles environ une fois par jour, pas à la minute près. Activez d'abord le versioning : OVHcloud refuse une règle de cycle de vie tant que le versioning est en pause.

Configurer l'AWS CLI sur le serveur

sudo snap install aws-cli --classic
sudo mkdir -p /backups && sudo chown odoo: /backups && sudo chmod 700 /backups
sudo -u odoo -H aws configure --profile ovh
# Access key and secret key: the backup user's keys
# Default region name: sbg
# Default output format: json
sudo -u odoo -H aws configure set endpoint_url https://s3.sbg.io.cloud.ovh.net --profile ovh

Le fichier ~/.aws/config de l'utilisateur odoo ressemble maintenant à ceci :

[profile ovh]
region = sbg
output = json
endpoint_url = https://s3.sbg.io.cloud.ovh.net

Testez-le, et vérifiez que la suppression est refusée :

echo test | sudo -u odoo -H aws s3 cp - s3://your-odoo-backups/test.txt --profile ovh
sudo -u odoo -H aws s3 ls s3://your-odoo-backups/ --profile ovh
sudo -u odoo -H aws s3 rm s3://your-odoo-backups/test.txt --profile ovh   # must fail: AccessDenied

Si les envois échouent avec une erreur « invalid argument » sur une AWS CLI récente, ajoutez ces deux lignes sous [profile ovh] :

request_checksum_calculation = when_required
response_checksum_validation = when_required

Le script de sauvegarde

#!/bin/bash
# /usr/local/bin/odoo-backup.sh, run as the odoo user
set -euo pipefail
DB=yourdb
DAY=$(date +%F)
DIR=/backups/$DAY
mkdir -p "$DIR"
pg_dump -Fc "$DB" > "$DIR/$DB.dump"
tar -czf "$DIR/$DB-filestore.tar.gz" -C /var/lib/odoo/filestore "$DB"
aws s3 cp "$DIR" "s3://your-odoo-backups/$DAY/" --recursive --profile ovh
find /backups -mindepth 1 -maxdepth 1 -type d -mtime +3 -exec rm -rf {} +

sudo chmod 755 /usr/local/bin/odoo-backup.sh

Avec le PostgreSQL managé ou un deuxième serveur, pg_dump doit joindre la base distante. Remplacez la ligne du dump par :

pg_dump -h postgresql-xxxxxxxx-xxxxxxxx.database.cloud.ovh.net -p 20184 -U odoo -Fc "$DB" > "$DIR/$DB.dump"

Ajoutez export PGSSLMODE=require en haut du script. Stockez le mot de passe dans le ~/.pgpass de l'utilisateur odoo, avec chmod 600 :

postgresql-xxxxxxxx-xxxxxxxx.database.cloud.ovh.net:20184:*:odoo:<odoo password>

Votre pg_dump doit avoir la même version majeure que le serveur, ou une plus récente. Le client fourni par Ubuntu peut être plus ancien que le service managé. Installez le client correspondant depuis le dépôt PostgreSQL :

sudo apt install -y postgresql-common
sudo /usr/share/postgresql-common/pgdg/apt.postgresql.org.sh
sudo apt install -y postgresql-client-17     # match your server's version

Le planifier avec systemd

/etc/systemd/system/odoo-backup.service :

[Unit]
Description=Back up Odoo database and filestore to OVHcloud Object Storage
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
User=odoo
ExecStart=/usr/local/bin/odoo-backup.sh

/etc/systemd/system/odoo-backup.timer :

[Unit]
Description=Nightly Odoo backup

[Timer]
OnCalendar=*-*-* 02:30:00
RandomizedDelaySec=15m
Persistent=true

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now odoo-backup.timer
sudo systemctl start odoo-backup.service       # run once now
journalctl -u odoo-backup.service -n 50        # read the result
systemctl list-timers odoo-backup.timer        # next run

Tester une restauration

Faites-le sur un deuxième serveur, pas sur la production. D'abord, téléchargez la sauvegarde d'un jour :

aws s3 cp s3://your-odoo-backups/2026-10-26/ ./restore/ --recursive --profile ovh
cd restore

Puis restaurez-la :

createdb -O odoo yourdb_restored
pg_restore -d yourdb_restored --no-owner --role=odoo yourdb.dump
mkdir -p /var/lib/odoo/filestore/yourdb_restored
tar -xzf yourdb-filestore.tar.gz -C /var/lib/odoo/filestore/yourdb_restored --strip-components=1

Sur le PostgreSQL managé, odoo ne peut pas créer de bases. Créez-la en tant que avnadmin dans psql avec CREATE DATABASE yourdb_restored OWNER odoo;. Puis lancez pg_restore avec -h, -p et -U odoo. Vérifiez que l'IP du serveur de restauration est autorisée dans la liste IPs.

Avant de démarrer Odoo sur la copie, neutralisez-la. Une copie de la production garde vos serveurs de messagerie et vos tâches planifiées, elle peut donc envoyer des e-mails à de vrais clients. En tant qu'utilisateur odoo, lancez :

odoo neutralize -c /etc/odoo/odoo.conf -d yourdb_restored

Utilisez odoo-bin au lieu de odoo si vous faites tourner Odoo depuis les sources. Cela désactive dans la copie les serveurs de messagerie sortants, les actions planifiées et les moyens de paiement. Notre guide sur la copie de la production vers le staging explique ce qu'elle couvre et ce qu'elle oublie.

Démarrez Odoo sur la base restaurée. Connectez-vous, ouvrez quelques fiches avec des pièces jointes, et vérifiez que les fichiers s'ouvrent. Notre guide sur comment savoir si une sauvegarde Odoo se restaurera explique quoi vérifier.

Surveillance et alertes

Ce qu'OVHcloud surveille pour vous :

  • Le PostgreSQL managé vous envoie un e-mail quand son disque est presque plein. S'il se remplit, le service passe en lecture seule, et Odoo n'enregistre plus rien.
  • L'Anti-DDoS est actif par défaut sur tous les services OVHcloud.

À l'intérieur de votre serveur, le disque et Odoo lui-même sont à vous de surveiller. Deux checks simples couvrent la plupart des problèmes :

  1. Disponibilité. Pointez n'importe quel service de surveillance externe vers https://your-odoo-domain/web/login, avec une alerte par e-mail ou SMS.
  2. Disque. Utilisez un check « heartbeat » du même service : il vous alerte quand un ping n'arrive plus. Ce script envoie un ping seulement tant que le disque est rempli à moins de 80 %. Ainsi, un disque plein et un serveur mort vous arrivent de la même façon.
#!/bin/bash
# /usr/local/bin/disk-check.sh
USED=$(df --output=pcent / | tail -1 | tr -dc '0-9')
if [ "$USED" -lt 80 ]; then
  curl -fsS -m 10 --retry 3 "https://your-heartbeat-url" > /dev/null
fi

Lancez-le toutes les 10 minutes avec un timer systemd, construit comme celui de la sauvegarde, avec OnCalendar=*:0/10. Vérifiez aussi /var/lib/odoo et /backups s'ils sont sur d'autres disques. Faites tourner le log d'Odoo avec logrotate, pour qu'il ne puisse pas remplir le disque.

Envoyer des e-mails depuis Odoo

Sur les instances Public Cloud, le port sortant 25 est bloqué par défaut. Sur un VPS, il est ouvert. En Local Zone, tous les ports SMTP sont fermés pour de bon.

Dans tous les cas, n'envoyez pas les e-mails directement depuis le serveur. Dans Odoo, configurez un serveur de messagerie sortant qui passe par votre fournisseur d'e-mails sur le port 587 (STARTTLS) ou 465 (SSL). Puis ajoutez des enregistrements SPF, DKIM et DMARC pour votre domaine, pour que vos e-mails ne finissent pas en spam.

Les pièges Odoo sur tout serveur, OVHcloud compris

Dans odoo.conf :

proxy_mode = True
list_db = False
admin_passwd = <a long random password>
workers = 5
gevent_port = 8072

En production, workers doit être au-dessus de 0, réglé selon votre mémoire. C'est seulement alors qu'Odoo démarre le processus à part, sur le port 8072, qui sert /websocket.

Dans nginx, envoyez /websocket vers le port 8072, et transmettez le vrai hôte et le vrai protocole :

location /websocket {
    proxy_pass http://127.0.0.1:8072;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header X-Forwarded-Host $host;
    proxy_set_header X-Forwarded-Proto $scheme;
}

Sans proxy_mode et ces en-têtes, les liens dans les e-mails sortent en http://.

Avant la mise en ligne

  • Odoo tourne avec workers au-dessus de 0, réglé selon la mémoire du serveur
  • /websocket va vers le port 8072, et le chat fonctionne
  • proxy_mode = True, et les liens dans les e-mails commencent par https://
  • list_db = False et un admin_passwd solide
  • Seuls les ports 80, 443 et votre propre SSH sont ouverts : security group ou Edge Network Firewall, plus ufw
  • Le port 8069 ne répond pas depuis l'extérieur
  • Sur le PostgreSQL managé, seule l'IP de votre serveur Odoo est dans la liste IPs
  • Le certificat SSL se renouvelle tout seul
  • Le timer de sauvegarde a tourné, et les fichiers sont dans le bucket
  • L'utilisateur de sauvegarde reçoit « AccessDenied » quand il essaie de supprimer
  • Les logs tournent, et vous recevez une alerte quand le disque se remplit ou que le site est en panne
  • Odoo envoie des e-mails par le port 587 ou 465
  • Une sauvegarde de la base et des fichiers a été restaurée sur un autre serveur, et les pièces jointes s'ouvrent

Gardez OVHcloud, confiez-nous le travail Odoo

Vous pouvez garder votre serveur OVHcloud sans gérer Odoo vous-même. Avec bring your own server, le serveur reste dans votre compte OVHcloud et dans la région de votre choix. Nous faisons tourner Odoo dessus : déploiements depuis Git, staging, sauvegardes, mises à jour et l'aide d'experts Odoo. Vous gardez le serveur en marche et assez grand. Notre logiciel se connecte depuis votre serveur vers l'extérieur, vous n'ouvrez donc aucun port pour nous.

Skysize est conçu par d'anciens ingénieurs d'Odoo et certifié ISO 27001.

Parlez à un expert en hébergement Odoo

FAQ

OVHcloud est-il un bon choix pour Odoo ? Oui. C'est un fournisseur européen avec beaucoup de régions. Prenez un serveur avec assez de mémoire. Choisissez une instance Public Cloud si vous voulez un réseau privé ou un PostgreSQL managé.

Odoo peut-il utiliser le PostgreSQL managé d'OVHcloud ? Oui. Créez le rôle odoo en tant que avnadmin, lancez GRANT odoo TO avnadmin;, puis créez la base avec OWNER odoo. Autorisez l'IP de votre serveur Odoo, et réglez db_sslmode. Sauvegardez le filestore à part.

Les snapshots OVHcloud suffisent-ils pour sauvegarder Odoo ? Pas seuls. Sauvegardez aussi la base et le filestore ensemble, hors du serveur, et testez une restauration.

Pourquoi Odoo ne peut-il pas envoyer d'e-mails depuis mon instance Public Cloud ? Le port sortant 25 est bloqué par défaut sur les instances Public Cloud. Utilisez le serveur SMTP de votre fournisseur d'e-mails sur le port 587 ou 465.

Pourquoi ma base managée est-elle injoignable alors qu'elle s'affiche comme prête ? Aucune IP n'est autorisée par défaut. Ajoutez l'IP de votre serveur Odoo dans l'onglet Configuration, sous IPs.

Puis-je limiter un utilisateur Object Storage à un seul bucket ? Oui, avec une politique utilisateur en JSON. Cela ne fonctionne pas sur l'utilisateur propriétaire du bucket. Créez un deuxième utilisateur pour le serveur.

Odoo sur OVHcloud : comment bien l'héberger
Écrit sur l'infrastructure Odoo chez Skysize, un hébergeur Odoo basé en Belgique, créé par d'anciens ingénieurs Odoo et certifié ISO 27001, servant des entreprises et des agences dans le monde entier.

Continuez à lire

Tous les articles →