Toda base de datos de Odoo termina convirtiéndose en la única fuente de verdad de un negocio: facturas, niveles de inventario, datos para la nómina, historial de clientes y documentos firmados viven en ella. Perderla, o restaurar una copia incompleta, puede detener las operaciones durante días. Aun así, muchas empresas solo descubren las carencias de su estrategia de respaldo el día que la necesitan.
Este artículo recorre lo esencial de la gestión de bases de datos, los respaldos y la recuperación ante desastres en Odoo 19 Enterprise, con notas sobre en qué difieren las instalaciones de Community en servidor propio. Está escrito para dueños de negocios, gerentes de finanzas y responsables de TI que necesitan una visión clara sin leer cada página técnica.
Una nota sobre las fuentes: esta guía se basa en la documentación oficial de Odoo para la versión 19. Las plataformas de alojamiento y sus opciones evolucionan, así que confirme cada paso en una base de datos de prueba y contra la documentación oficial vigente antes de depender de él en producción.
Qué contiene un respaldo completo de Odoo
Una base de datos de Odoo no es solo una base de datos PostgreSQL. Los adjuntos, como documentos cargados, imágenes y otro contenido binario, se almacenan como archivos en lo que Odoo llama el filestore, y Odoo regula el acceso a ellos. Un respaldo que solo contiene el volcado de la base de datos restaurará sus registros, pero dejará los adjuntos fuera.
La documentación de Odoo.sh describe que sus respaldos incluyen el volcado de la base de datos, el filestore (adjuntos y campos binarios), los registros y las sesiones. Es una referencia útil de cómo luce un respaldo completo en cualquier tipo de alojamiento.
- Volcado de la base de datos: todos los registros, la configuración, los usuarios, los asientos contables y los ajustes.
- Filestore: adjuntos y campos binarios, como facturas de proveedor escaneadas, imágenes de productos y PDF firmados.
- Código personalizado: en Odoo.sh y on-premise, sus módulos personalizados residen en su repositorio de código, que necesita su propia protección.
- Configuración: en on-premise, el archivo de configuración de Odoo y la configuración del servidor también deben documentarse y resguardarse.
Al revisar un respaldo, confirme siempre que estén presentes tanto el volcado como el filestore. La falta del filestore es una de las razones más comunes por las que una base de datos restaurada parece correcta al principio y después muestra imágenes rotas y documentos faltantes.
Respaldos según el tipo de alojamiento
La responsabilidad de los respaldos depende de dónde se ejecute su base de datos. Odoo Online y Odoo.sh están alojados por Odoo e incluyen respaldos automáticos, mientras que un servidor on-premise hace que su propio equipo sea totalmente responsable. La edición Community suele alojarse en servidor propio, por lo que le aplican las responsabilidades on-premise descritas más abajo.
Odoo Online: el administrador de bases de datos
En Odoo Online, la documentación oficial indica que las bases de datos se respaldan a diario conforme al SLA de Odoo Cloud Hosting. No necesita programar nada para que se realicen los respaldos de la plataforma.
El administrador de bases de datos, al que se accede iniciando sesión como administrador de la base de datos, ofrece una opción Administrar con las acciones principales que necesita para respaldos y pruebas.
- Descargar respaldo genera un archivo ZIP de la base de datos que puede conservar en su propio archivo.
- Si Descargar respaldo está desactivado, la base de datos es demasiado grande para el administrador y debe contactar al soporte de Odoo para obtener otro método de descarga.
- Duplicar crea una copia de la base de datos; la opción Para propósitos de prueba está activada por defecto y desactiva acciones externas como correos electrónicos, pagos y órdenes de entrega.
- Eliminar borra la base de datos al instante para todos los usuarios y no se puede deshacer, así que descargue antes un respaldo.
Según la documentación, los duplicados en Odoo Online caducan a los 15 días y cada base de datos puede tener hasta cinco duplicados. Trate los duplicados como entornos de prueba de corta duración, no como una estrategia de respaldo.
Odoo.sh: respaldos automáticos y manuales
En Odoo.sh, la base de datos de producción se respalda automáticamente todos los días. La documentación indica que se conservan siete respaldos diarios, cuatro semanales y tres mensuales, y que las copias mensuales se guardan en servidores de respaldo dedicados. Para restaurar o descargar esos respaldos mensuales hay que contactar al soporte de Odoo.
Las ramas de preproducción y de desarrollo no se respaldan automáticamente. Se pueden hacer respaldos manuales de producción y de preproducción para capturar un momento específico, por ejemplo antes de un cambio de configuración riesgoso. Permanecen disponibles durante tres días, y la documentación menciona un límite de cinco respaldos manuales por día. Las bases de datos de desarrollo no pueden respaldarse manualmente.
Odoo.sh también crea un respaldo automático, marcado como respaldo de actualización (Update), cuando un commit fusionado cambia las versiones de los módulos o las dependencias de Python vinculadas. Si una fusión no cambia esos elementos, no se genera ningún respaldo, así que haga un respaldo manual antes de cambios importantes en producción.
- Use la pestaña Respaldos de la rama de producción para revisar, descargar o restaurar respaldos.
- Restaure un respaldo de producción en una rama de preproducción cuando quiera hacer pruebas con datos reales.
- Use la función Importar base de datos para traer archivos del administrador de bases de datos estándar, del administrador de bases de datos de Odoo Online, de la pestaña Respaldos o de la opción Descargar volcado de BD de una compilación.
On-premise: su equipo es responsable de todo
En su propio servidor, nada se respalda a menos que usted lo configure. Las pautas oficiales de despliegue son directas: configure respaldos diarios de sus bases de datos y de los datos del filestore, y cópielos a un servidor de archivo remoto que no sea accesible desde el propio servidor.
Esas mismas pautas advierten que el administrador web de bases de datos está pensado como herramienta de desarrollo y demostración y no está diseñado para producción. Se recomienda encarecidamente desactivarlo en cualquier sistema expuesto a internet, y las operaciones de producción como los respaldos automatizados deben quedar a cargo del administrador del sistema.
- Proteja las pantallas de gestión de bases de datos con una contraseña maestra robusta y generada aleatoriamente en el archivo de configuración, nunca con el valor predeterminado.
- Desactive el listado de bases de datos en servidores expuestos a internet y use un filtro de bases de datos para que cada nombre de host apunte a la base de datos correcta.
- Ejecute el usuario de PostgreSQL de Odoo sin privilegios de superusuario, como exige la documentación de despliegue.
- Respalde la base de datos y el filestore juntos, para que ambos se mantengan coherentes entre sí.
Antes de cambios importantes como pasar de Community a Enterprise, la documentación oficial indica como primer paso respaldar la base de datos de Community. Aplique el mismo hábito antes de cualquier actualización, instalación de módulos o importación de datos.
Duplicar bases de datos de forma segura: la neutralización
Probar en una copia de producción es la forma más segura de ensayar nuevos flujos, importaciones o actualizaciones, pero una copia descuidada puede enviar correos reales a clientes o generar pagos reales. Odoo lo resuelve con bases de datos neutralizadas, que la documentación define como bases de datos que no son de producción en las que se desactivan varios parámetros.
Las bases de datos de prueba siempre están neutralizadas, incluidas las copias de respaldo, los duplicados y las bases de datos de preproducción y desarrollo de Odoo.sh. La lista de lo que se desactiva, según la documentación, no es exhaustiva de forma explícita e incluye lo siguiente.
- Las acciones planificadas, como la facturación automática de suscripciones y los envíos masivos de correo.
- Los correos salientes, que en la preproducción de Odoo.sh se capturan con un capturador de correos en lugar de enviarse.
- La sincronización bancaria, los proveedores de pago y los métodos de envío.
- Los tokens de IAP y la visibilidad del sitio web para los motores de búsqueda.
Un banner rojo en la parte superior de la pantalla identifica una base de datos neutralizada para que los usuarios vean de inmediato que no están en producción. Capacite a su equipo para buscar ese banner antes de capturar cualquier dato, y nunca quite la neutralización de una copia a menos que comprenda plenamente las consecuencias.
Retención, copias externas, RPO y RTO
Los respaldos de la plataforma son una red de seguridad sólida, pero una buena política también mantiene copias independientes bajo su control. En las bases de datos alojadas, descargue periódicamente un respaldo completo y guárdelo en una ubicación separada y con acceso controlado. En los servidores on-premise, las copias externas son imprescindibles, no opcionales.
Dos medidas sencillas le ayudan a decidir cuánta protección necesita. El objetivo de punto de recuperación, o RPO, es cuántos datos recientes puede permitirse perder; un respaldo diario implica que podría perder hasta un día de trabajo. El objetivo de tiempo de recuperación, o RTO, es cuánto tiempo puede operar el negocio sin el sistema mientras se restaura.
Acuerde estos objetivos con la dirección y luego verifique si su configuración actual los cumple. Si perder un día completo de órdenes de venta es inaceptable, los respaldos diarios por sí solos no bastan, y debería analizar con su proveedor de alojamiento o su equipo de TI copias más frecuentes u otras medidas.
Pruebas de restauración y una lista de verificación práctica
Un respaldo solo está comprobado cuando se ha restaurado. Programe una prueba de restauración a intervalos regulares, restaure en un entorno de prueba neutralizado y confirme que los usuarios pueden iniciar sesión, que los registros recientes están presentes y que los adjuntos se abren correctamente. Mida el tiempo del proceso para conocer su RTO real.
- Confirme qué tipo de alojamiento usa y quién es responsable de los respaldos.
- Verifique que los respaldos incluyan tanto el volcado de la base de datos como el filestore.
- Conserve una copia descargada independiente en una ubicación separada y protegida.
- Haga un respaldo manual antes de actualizaciones, importaciones grandes o cambios de configuración importantes.
- Use duplicados neutralizados o ramas de preproducción para todas las pruebas.
- Restaure un respaldo en un entorno de prueba con regularidad y registre los resultados.
- Documente sus objetivos de RPO y RTO y revíselos cada año.
- En on-premise, desactive el administrador público de bases de datos y proteja la contraseña maestra.
Cómo puede ayudarle 1CBMS
1CBMS diseña y revisa rutinas de respaldo y recuperación para proyectos de Odoo 19 en Egipto e Irak, en Odoo Online, Odoo.sh y servidores on-premise. Podemos auditar su configuración actual, definir con su dirección objetivos de RPO y RTO realistas, configurar entornos de prueba neutralizados y realizar con su equipo una prueba de restauración documentada, para que la recuperación sea un procedimiento ensayado y no una emergencia.