Ir al contenido

Odoo en OVHcloud: cómo alojarlo bien

Odoo en OVHcloud: cómo alojarlo bien
octubre 29, 2026 · 22 min leído

La respuesta corta

Para alojar Odoo en OVHcloud, elige un VPS o una instancia Public Cloud con suficiente memoria. Pon Postgres en el mismo servidor, en una segunda instancia en una red privada, o en el PostgreSQL gestionado de OVHcloud. Abre al mundo solo los puertos 80 y 443, y el SSH solo a tu propia dirección. Envía cada noche una copia de la base de datos y del filestore a un bucket de Object Storage en otra región, con un usuario que solo puede escribir en ese bucket. Luego restaura una copia en otro servidor antes de salir en vivo.

OVHcloud es una empresa francesa con centros de datos en Europa y otras partes del mundo. Muchos equipos lo eligen para dejar sus datos con un proveedor europeo. Esta guía te da los comandos exactos para cada paso en OVHcloud.

Para la instalación en sí (Odoo, Postgres, el archivo de configuración y el proxy), sigue nuestra guía sobre Odoo en un VPS. Esta página cubre lo que cambia en OVHcloud.

VPS o Public Cloud

OVHcloud vende dos tipos de servidor que sirven para Odoo:

  • VPS. Un tamaño fijo, un panel de control simple y una copia de seguridad diaria incluida. Bien para un servidor de Odoo con Postgres dentro.
  • Instancias Public Cloud. Muchos tamaños, redes privadas (vRack), security groups y una herramienta de línea de comandos (OpenStack CLI). Mejor cuando quieres Postgres en su propio servidor o en el servicio gestionado.

El mínimo para empezar: 2 vCPU, 4 GB de memoria y 50 GB de disco. Con eso corren Odoo y Postgres en un solo servidor para un equipo pequeño. La memoria importa más que la CPU: cada worker necesita su parte, y Postgres quiere la suya. Para más usuarios, importaciones grandes o Postgres en su propio servidor, nuestra guía sobre cuántos workers de Odoo necesitas muestra cómo calcularlo.

Elige la región

Tus datos viven donde vive el servidor. Ponlo cerca de tus usuarios.

  • En Public Cloud, una región puede ser 1-AZ (un centro de datos, como Gravelines GRA o Estrasburgo SBG), 3-AZ (tres zonas, como París EU-WEST-PAR) o una Local Zone.
  • Evita las Local Zones para Odoo. No pueden unirse a un vRack, no pueden enviar correo por ningún puerto SMTP, y un VPS en una Local Zone no tiene snapshots, ni copias automáticas, ni Anti-DDoS.

Crea una instancia Public Cloud desde la línea de comandos

Primero, instala el cliente de OpenStack en tu propio equipo:

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

Luego consigue tu archivo de acceso. En el panel de control, abre tu proyecto Public Cloud. Ve a Settings > Users & Roles y haz clic en Create User. Dale el rol Administrator y guarda la contraseña que te muestra. Solo se muestra una vez. Luego haz clic en ... junto al usuario y elige Download OpenStack's RC file. Cada archivo es para una región.

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

Añade tu clave SSH, y luego busca un tamaño (flavor) y una imagen:

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

Los nombres de flavor son como b2-7 (General Purpose, 7 GB de memoria). Elige uno según la memoria que necesitas. Luego crea la instancia. Aquí añadimos un security group. La sección siguiente muestra cómo crearlo.

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 es la red pública de OVHcloud. Le da a la instancia una IP pública. Comprueba que la instancia está en marcha y lee su dirección:

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

El nombre de usuario depende de la imagen: ubuntu en Ubuntu, debian en Debian.

Crea un VPS

Un VPS no tiene OpenStack CLI. Lo pides en el panel de control y eliges allí el sistema operativo y tu clave SSH. Para añadir una clave más tarde, ve a Bare Metal Cloud > Virtual private servers, elige tu VPS, haz clic en ... junto a OS/Distribution y luego en Reinstall my VPS. Elige tu clave en SSH Key to pre-install. Esto borra los discos, así que hazlo antes de instalar nada.

Entra con ssh ubuntu@<vps-ip> en Ubuntu, o debian@ en Debian.

Dónde va Postgres

Tienes tres opciones.

1. En el mismo servidor

Es lo más simple. Está bien para muchos equipos. La guía del VPS lo cubre. Postgres escucha solo en localhost, así que no hay nada que abrir.

2. En una segunda instancia, por una red privada

En Public Cloud, puedes poner Postgres en su propia instancia y hablar con ella por una red privada. Los proyectos nuevos vienen con un vRack, así que solo tienes que crear la red.

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 impide que la red privada envíe una segunda ruta por defecto a tus servidores. Su tráfico a internet sigue pasando por Ext-Net.

Crea los dos servidores con las dos redes. Dale al servidor de base de datos su propio security group (mira la sección del firewall):

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 el servidor de Odoo ya existe, conéctalo con openstack server add network odoo-web odoo-private. Luego reinícialo una vez y comprueba que los nombres de sus redes no se intercambiaron.

Busca la dirección privada de cada servidor:

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

En el servidor de base de datos, haz que Postgres escuche también en su dirección privada. En /etc/postgresql/16/main/postgresql.conf (cambia 16 por tu versión):

listen_addresses = 'localhost,10.1.0.12'

En /etc/postgresql/16/main/pg_hba.conf, deja entrar solo al rol odoo, solo desde la red privada, y solo a yourdb y postgres. El chat en vivo de Odoo se conecta a la base de datos postgres, así que déjala en la lista:

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

Reinicia y prueba desde el servidor de 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

Luego, en el odoo.conf del servidor de Odoo, pon db_host = 10.1.0.12 y db_sslmode = require.

3. En el PostgreSQL gestionado de OVHcloud

OVHcloud se encarga del servidor de base de datos por ti: actualizaciones, failover y copias.

Crea el servicio. En tu proyecto Public Cloud, ve a Databases y haz clic en Create a service. Elige PostgreSQL y una versión que soporte tu versión de Odoo. Elige la misma región que tu servidor de Odoo, y luego un plan y un tamaño. En la red, puedes elegir una red privada (vRack) si tu servidor de Odoo está en Public Cloud.

Permite tu servidor de Odoo. Por defecto, el servicio no acepta ninguna conexión. Incluso parece listo mientras rechaza a todo el mundo. Abre la pestaña Configuration, busca IPs y añade la IP pública de tu servidor de Odoo como /32 (por ejemplo 203.0.113.10/32). En una red privada, añade tu subred privada. Nunca añadas 0.0.0.0/0 en producción.

Consigue el acceso de admin. El primer usuario se llama avnadmin. Abre la pestaña Users, haz clic en ... junto a él y elige Reset password. Guarda la contraseña ahora. OVHcloud no la guarda. La pestaña Dashboard muestra el nombre del host y el puerto. El puerto no es 5432. Se parece a 20184.

Descarga el certificado de la CA. En la pestaña Dashboard, la sección Connection information tiene el certificado. Guárdalo en el servidor de Odoo como /etc/odoo/ovh-db-ca.pem.

Crea el usuario odoo y la base de datos. avnadmin puede crear usuarios y bases de datos, pero no es superusuario. Así que primero debe hacerse miembro del rol odoo para poder hacer a odoo dueño de una base de datos. Conéctate desde el servidor de 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

Los usuarios que creas con SQL no aparecen en la pestaña Users del panel de control. Es normal. odoo es dueño de su base de datos, así que Odoo puede trabajar en ella. No puede crear otras bases de datos, y eso es lo que quieres.

Apunta Odoo a ella. En 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 cifra la conexión. Para comprobar también que hablas con el servidor correcto, usa db_sslmode = verify-full. Luego dile al servicio de Odoo dónde está el certificado con sudo systemctl edit odoo:

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

Usa siempre el nombre de host del panel de control, nunca la IP. La IP puede cambiar, y verify-full falla con una IP.

Vigila el límite de conexiones. El servicio permite unas 100 conexiones por cada 4 GB de memoria. Cada worker de Odoo puede abrir hasta db_maxconn conexiones (64 por defecto). Mantén (workers + max_cron_threads + 1) × db_maxconn por debajo de tu límite. Por ejemplo, pon db_maxconn = 16.

Qué cubren sus copias. El servicio gestionado hace copia de la base de datos todo el tiempo. Puedes restaurarla a cualquier momento dentro de la retención de tu plan. Una copia va a una segunda región (por ejemplo, de GRA a SBG). No hace copia del filestore. Los adjuntos y las imágenes siguen en el servidor de Odoo, en /var/lib/odoo/filestore. Esos los copias tú, más abajo.

Firewall

Permite solo esto desde internet:

  • 80 y 443 desde cualquier lugar
  • 22 solo desde tus propias direcciones IP

Bloquea todo lo demás. Los puertos propios de Odoo (8069 y 8072) solo debe alcanzarlos el proxy, en el mismo servidor.

Public Cloud: security groups

El security group default deja entrar todo. No lo cambies ni lo borres. Las herramientas de OVHcloud lo restablecen. Crea tu propio grupo, y dáselo a la instancia en lugar 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

Cambia 198.51.100.7 por la dirección de tu oficina o de tu VPN. Un grupo nuevo ya deja salir todo el tráfico, y los security groups recuerdan las conexiones abiertas. Así que las respuestas a las peticiones de tu servidor vuelven a entrar solas.

Para un servidor de base de datos en la red privada, permite Postgres solo desde los servidores del grupo 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 creaste el servidor con default, cambia los grupos:

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

Luego prueba desde tu equipo. El puerto 443 debe responder y el 8069 no:

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

VPS: Edge Network Firewall

Un VPS no tiene security groups. En su lugar, OVHcloud te da el Edge Network Firewall. Filtra el tráfico en el borde de la red de OVHcloud, antes de que llegue a tu servidor. Lo encuentras en el panel de control, en Network > Public IP Addresses. Haz clic en ... junto a la dirección IPv4 de tu VPS, y luego en Configure Edge Network Firewall.

Tres cosas que debes saber antes de añadir reglas:

  • No guarda estado (stateless). No recuerda las conexiones. Si no permites las respuestas, tu servidor no puede descargar actualizaciones ni llegar a Object Storage. La regla 0 de abajo lo resuelve.
  • El orden importa. Las reglas van de la prioridad 0 a la 19. Gana la primera regla que coincide. La última regla debe denegar el resto. Una lista con solo reglas "Accept" no bloquea nada.
  • Solo cubre IPv4, y solo el tráfico que viene de fuera de OVHcloud. Sigues necesitando un firewall en el servidor.

Añade estas reglas (hasta 20 por IP):

Prioridad Acción Protocolo IP de origen Puerto de destino Otros
0 Accept TCP TCP state: established
1 Accept ICMP
2 Accept TCP tu IP/32 22
3 Accept TCP 80
4 Accept TCP 443
5 Accept UDP Puerto de origen 53 (respuestas DNS)
6 Accept UDP Puerto de origen 123 (respuestas de sincronización de hora)
19 Deny IPv4

Deja vacío el puerto de origen en las reglas 2 a 4. El cliente elige uno al azar. Luego activa el firewall con el interruptor.

Aunque lo dejes apagado, OVHcloud lo enciende solo durante un ataque DDoS, con tus reglas. Así que mantén las reglas bien en cualquier caso. También puedes usar el mismo firewall en la IP pública de una instancia Public Cloud, pero allí los security groups ya hacen el trabajo.

En el servidor: ufw

Tanto en un VPS como en una instancia, activa también el firewall dentro de Ubuntu. Permite primero el SSH, para no quedarte fuera:

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

En un servidor de base de datos aparte, permite Postgres solo desde la red privada: sudo ufw allow from 10.1.0.0/24 to any port 5432 proto tcp.

Copias de seguridad en Object Storage

Lo que OVHcloud copia por ti

  • Copia automática del VPS. Una copia diaria de todo el servidor viene con el VPS. La opción premium guarda los últimos 7 días. No incluye los discos extra.
  • Snapshot del VPS. Una opción de pago. Guardas un snapshot a la vez, y restaurarlo lo borra. Úsalo antes de una actualización.
  • Copias de instancias Public Cloud. Puntuales, o con un horario diario que guarda las últimas 7 o 14. Puedes añadir una copia en otra región. Desde la CLI: openstack server image create --name odoo-web-before-upgrade odoo-web.

Todas estas copian todo el disco mientras Postgres está corriendo. Son útiles para reconstruir un servidor. Solas no bastan para Odoo. También necesitas una copia limpia de la base de datos y del filestore, hechas juntas, guardadas fuera del servidor y probadas. Si usas las copias del VPS, instala el agente QEMU para que el disco se congele bien durante la copia:

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

Crea el bucket y un usuario solo para copias

Elige para el bucket una región distinta a la de tu servidor. Por ejemplo, servidor en GRA, bucket en SBG. Los endpoints tienen la forma https://s3.<region>.io.cloud.ovh.net, así que https://s3.sbg.io.cloud.ovh.net para Estrasburgo.

Necesitas dos usuarios de Object Storage. Este es el motivo. Las políticas de usuario de OVHcloud no pueden limitar al usuario dueño de un bucket. El dueño siempre puede hacerlo todo.

  1. Usuario dueño. En tu proyecto Public Cloud, abre Object Storage y crea el bucket your-odoo-backups. Activa el versionado en el formulario. Enlaza un usuario nuevo a él. Guarda las claves de este usuario en tu propio equipo, nunca en el servidor de Odoo.
  2. Usuario de copias. En la lista de usuarios de Object Storage, haz clic en Create User y guarda su access key y su secret key. Haz clic en ... junto a él, elige Import JSON file y sube esta política:
{
  "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": ["*"]
    }
  ]
}

Este usuario puede añadir y leer copias en ese único bucket. No puede borrarlas, y no puede ver otros buckets. Si alguien entra en el servidor de Odoo, no puede borrar tus copias. El versionado también guarda la copia anterior si un archivo se sobrescribe.

Versionado y caducidad

Las copias viejas deben irse solas. Configúralo desde tu propio equipo con las claves del usuario dueño, después de activar el versionado. Guarda esto como 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

Las copias de más de 30 días se eliminan, y las versiones sustituidas se van 7 días después. OVHcloud aplica estas reglas más o menos una vez al día, no al minuto. Activa primero el versionado: OVHcloud no acepta una regla de ciclo de vida mientras el versionado está en pausa.

Configura la AWS CLI en el servidor

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

El ~/.aws/config del usuario odoo ahora se ve así:

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

Pruébalo, y comprueba que el borrado se rechaza:

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 las subidas fallan con un error "invalid argument" en una AWS CLI reciente, añade estas dos líneas bajo [profile ovh]:

request_checksum_calculation = when_required
response_checksum_validation = when_required

El script de copia

#!/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

Con PostgreSQL gestionado o un segundo servidor, pg_dump debe llegar a la base de datos remota. Cambia la línea del dump por:

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

Añade export PGSSLMODE=require cerca del principio del script. Guarda la contraseña en el ~/.pgpass del usuario odoo, con chmod 600:

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

Tu pg_dump debe ser de la misma versión mayor que el servidor, o más nueva. El cliente propio de Ubuntu puede ser más viejo que el servicio gestionado. Instala el cliente que corresponde desde el repositorio de 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

Prográmalo con 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

Prueba una restauración

Hazlo en un segundo servidor, no en producción. Primero, descarga la copia de un día:

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

Luego restáurala:

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

En PostgreSQL gestionado, odoo no puede crear bases de datos. Créala como avnadmin en psql con CREATE DATABASE yourdb_restored OWNER odoo;. Luego ejecuta pg_restore con -h, -p y -U odoo. Asegúrate de que la IP del servidor de restauración está permitida en la lista IPs.

Antes de arrancar Odoo en la copia, neutralízala. Una copia de producción sigue teniendo tus servidores de correo y tus tareas programadas, así que puede enviar correos a clientes reales. Como usuario odoo, ejecuta:

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

Usa odoo-bin en lugar de odoo si ejecutas Odoo desde el código fuente. Esto apaga en la copia los servidores de correo saliente, las acciones programadas y los proveedores de pago. Nuestra guía sobre copiar producción a staging explica lo que cubre y lo que se le escapa.

Arranca Odoo en la base de datos restaurada. Entra, abre algunos registros con adjuntos y comprueba que los archivos se abren. Nuestra guía sobre cómo saber si una copia de Odoo se restaurará cubre qué revisar.

Monitorización y alertas

Lo que OVHcloud vigila por ti:

  • PostgreSQL gestionado te envía un correo cuando su disco está casi lleno. Si se llena, el servicio pasa a solo lectura, y Odoo deja de guardar.
  • Anti-DDoS está activo por defecto en todos los servicios de OVHcloud.

Dentro de tu servidor, el disco y el propio Odoo los vigilas tú. Dos checks simples cubren la mayoría de los problemas:

  1. Uptime. Apunta cualquier servicio externo de uptime a https://your-odoo-domain/web/login, con una alerta por correo o SMS.
  2. Disco. Usa un check de tipo "heartbeat" del mismo servicio: te avisa cuando deja de llegar un ping. Este script solo envía el ping mientras el disco está por debajo del 80%. Así te enteras de un disco lleno y de un servidor caído de la misma forma.
#!/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

Ejecútalo cada 10 minutos con un timer de systemd, hecho como el de la copia, con OnCalendar=*:0/10. Revisa también /var/lib/odoo y /backups si están en otros discos. Rota el log de Odoo con logrotate para que no pueda llenar el disco.

Enviar correo desde Odoo

En las instancias Public Cloud, el puerto de salida 25 está bloqueado por defecto. En un VPS, está abierto. En las Local Zones, todos los puertos SMTP están cerrados para siempre.

En ningún caso envíes correo directamente desde el servidor. En Odoo, configura un servidor de correo saliente que use tu proveedor de correo en el puerto 587 (STARTTLS) o 465 (SSL). Luego añade registros SPF, DKIM y DMARC para tu dominio, para que tus correos no acaben en spam.

Trampas de Odoo en cualquier servidor, OVHcloud incluido

En odoo.conf:

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

workers debe estar por encima de 0 en producción, ajustado a tu memoria. Solo así Odoo arranca el proceso aparte en el puerto 8072 que sirve /websocket.

En nginx, envía /websocket al puerto 8072, y pasa el host y el esquema reales:

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;
}

Sin proxy_mode y esas cabeceras, los enlaces de los correos salen como http://.

Antes de salir en vivo

  • Odoo corre con workers por encima de 0, ajustado a la memoria del servidor
  • /websocket va al puerto 8072, y el chat funciona
  • proxy_mode = True, y los enlaces de los correos empiezan por https://
  • list_db = False y un admin_passwd fuerte
  • Solo están abiertos los puertos 80, 443 y tu propio SSH: security group o Edge Network Firewall, más ufw
  • El puerto 8069 no responde desde fuera
  • En PostgreSQL gestionado, solo la IP de tu servidor de Odoo está en la lista IPs
  • El certificado SSL se renueva solo
  • El timer de la copia se ejecutó, y los archivos están en el bucket
  • El usuario de copias recibe "AccessDenied" cuando intenta borrar
  • Los logs rotan, y recibes una alerta cuando el disco se llena o el sitio está caído
  • Odoo envía correo por el puerto 587 o 465
  • Una copia de la base de datos y de los archivos se ha restaurado en otro servidor, y los adjuntos se abren

Quédate con OVHcloud, déjanos el trabajo de Odoo

Puedes quedarte con tu servidor de OVHcloud y aun así no gestionar Odoo tú mismo. Con bring your own server, el servidor sigue en tu cuenta de OVHcloud y en la región que elijas. Nosotros hacemos funcionar Odoo en él: despliegues desde Git, staging, copias de seguridad, actualizaciones y ayuda de expertos en Odoo. Tú mantienes el servidor en marcha y con el tamaño suficiente. Nuestro software se conecta desde tu servidor hacia fuera, así que no nos abres ningún puerto.

Skysize está hecho por ex ingenieros de Odoo y tiene la certificación ISO 27001.

Habla con un experto en hosting de Odoo

Preguntas frecuentes

¿Es OVHcloud bueno para Odoo? Sí. Es un proveedor europeo con muchas regiones. Elige un servidor con suficiente memoria. Elige una instancia Public Cloud si quieres una red privada o PostgreSQL gestionado.

¿Puede Odoo usar el PostgreSQL gestionado de OVHcloud? Sí. Crea el rol odoo como avnadmin, ejecuta GRANT odoo TO avnadmin; y luego crea la base de datos con OWNER odoo. Permite la IP de tu servidor de Odoo, y configura db_sslmode. Haz copia del filestore aparte.

¿Bastan los snapshots de OVHcloud para las copias de Odoo? Solos no. Guarda también la base de datos y el filestore juntos, fuera del servidor, y prueba una restauración.

¿Por qué Odoo no puede enviar correo desde mi instancia Public Cloud? El puerto de salida 25 está bloqueado por defecto en las instancias Public Cloud. Usa el servidor SMTP de tu proveedor de correo en el puerto 587 o 465.

¿Por qué no llego a mi base de datos gestionada aunque aparece como lista? Por defecto no hay ninguna IP permitida. Añade la IP de tu servidor de Odoo en la pestaña Configuration, en IPs.

¿Puedo limitar un usuario de Object Storage a un solo bucket? Sí, con una política de usuario en JSON. No funciona con el usuario dueño del bucket. Crea un segundo usuario para el servidor.

Odoo en OVHcloud: cómo alojarlo bien
Escribe sobre la infraestructura de Odoo en Skysize, un proveedor de hosting de Odoo con sede en Bélgica, creado por exingenieros de Odoo y certificado ISO 27001, que sirve a empresas y agencias en todo el mundo.

Sigue leyendo

Todos los artículos →