Odoo · DevOps · Mantenimiento
Un backup que nunca se ha restaurado no es un backup, es una suposición. El mantenimiento de una instancia Odoo en producción se mide por lo aburrido que es el día que algo falla, y eso solo se consigue habiendo practicado el recovery antes de necesitarlo de verdad.
Lo que se olvida
Backup completo: base de datos y filestore, siempre juntos
Es habitual automatizar el pg_dump y olvidar el filestore (/var/lib/odoo/filestore/<db>), donde viven los adjuntos e imágenes que la base de datos solo referencia por hash. Restaurar solo la base de datos deja facturas, informes y fotos de producto rotos silenciosamente: el registro existe, el fichero no.
# Backup completo, base de datos + filestore, con fecha en el nombre
DB_NAME="produccion"
FECHA=$(date +%Y%m%d_%H%M%S)
pg_dump -Fc "$DB_NAME" > "/backups/${DB_NAME}_${FECHA}.dump"
tar -czf "/backups/${DB_NAME}_filestore_${FECHA}.tar.gz" \
-C /var/lib/odoo/filestore "$DB_NAME"Actualizar sin miedo
Snapshot antes de cada -u, no solo antes de migrar de versión
La costumbre de hacer backup "para migraciones grandes" deja desprotegidas las actualizaciones rutinarias (-u mi_modulo) que en teoría son de bajo riesgo. Un script de migración con un bug puede corromper datos igual de rápido en una actualización menor que en un salto de versión mayor. El snapshot debe ser el paso 0 de cualquier -u contra producción, sin excepciones.
# deploy.sh — fragmento
./backup_completo.sh "$DB_NAME"
odoo-bin -d "$DB_NAME" -u mi_modulo --stop-after-init \
|| { echo "FALLÓ LA ACTUALIZACIÓN, restaurar backup"; exit 1; }La parte que nadie hace
Practicar el restore, no solo generarlo
Un backup nunca probado puede llevar meses corrupto sin que nadie lo sepa: permisos cambiados, disco lleno a mitad de dump, o un cron que silenciosamente dejó de ejecutarse. Restaurar periódicamente el backup en una base de datos de prueba (aunque sea mensual, en local) es la única forma de confirmar que, el día que haga falta de verdad, funciona.
| Tarea | Frecuencia recomendada |
|---|---|
| Backup BD + filestore | Diario, retención de al menos 7-14 días |
Snapshot previo a -u | Cada actualización contra producción, sin excepción |
| Prueba de restore completo | Mensual, en un entorno aislado |
| Verificar espacio en disco del backup | Alerta automática antes de que falle en silencio |
Resumen
Un plan de mantenimiento serio cubre base de datos y filestore juntos, convierte el snapshot en paso obligatorio antes de cualquier actualización, y valida el restore periódicamente en lugar de confiar en que "seguro que funciona". El recovery no se improvisa el día del incidente: se ensaya antes.