¿qué ocurre si el contenedor de WordPress o la base de datos falla y no hay una copia fiable disponible? Muchas empresas subestiman la complejidad de respaldar WordPress cuando se ejecuta en contenedores Docker. Existen soluciones simples para desarrollos locales, pero en entornos productivos es imprescindible una estrategia coherente que cubra volúmenes, bases de datos, consistencia transaccional y restauración verificada. La solución inmediata es diseñar copias que incluyan: exportación consistente de la base de datos (hot backups para MySQL/MariaDB), copia de volúmenes persistentes (wp-content, uploads y plugins), automatización con contenedores de backup o jobs y almacenamiento cifrado en la nube con políticas de retención y verificación automatizada.
Puntos clave: pasos rápidos y decisiones críticas
- Volúmenes y bases de datos deben respaldarse por separado y con coherencia (consistencia transaccional): usar mysqldump con bloqueo o snapshots + flush/WAL si se dispone de motores compatibles.
- Automatización con contenedores o tareas programadas: evitar procesos manuales; implementar backups como servicio (contenedor restic/borg/rclone).
- Backups incrementales y deduplicación para ahorrar espacio: restic o Borg son opciones recomendadas por eficiencia y cifrado integrado.
- Almacenamiento remoto cifrado (S3/Wasabi/GCS) y políticas de retención: guardar varias copias y comprobar integridad.
- Pruebas de restauración regulares y documentación: una copia sin verificación no protege. Documentar y practicar el procedimiento de restauración.
Cómo hacer backup en contenedores Docker para WordPress
Hacer backup de WordPress en Docker requiere identificar los componentes críticos: volúmenes con archivos PHP y uploads, la base de datos, y la configuración de servicios (env, redes, compose). La técnica más segura en producción mezcla dos enfoques: snapshots de volúmenes o del host (si el proveedor lo soporta) y dumps consistentes de la base de datos. Para bases MySQL/MariaDB en contenedores, realizar dump con mysqldump --single-transaction --quick es suficiente para motores InnoDB en la mayoría de casos; para cargas muy altas o para motores con WAL (PostgreSQL), usar pg_dump/pg_basebackup o snapshots coordinados. En entornos con alta concurrencia, coordinar un breve bloqueo de escritura o usar réplicas para hacer backups sin impacto de I/O es la opción profesional.
Docker-compose reproducible (backup + restore)
A continuación, plantilla reducida pero funcional de docker-compose para WordPress y MariaDB que permite volúmenes externos. La plantilla incluye volúmenes nombrados, que son los objetos a respaldar.
version: '3.8'
services:
db:
image: mariadb:10.6
environment:
MYSQL_ROOT_PASSWORD: example
MYSQL_DATABASE: wp
MYSQL_USER: wp
MYSQL_PASSWORD: wppass
volumes:
- db_data:/var/lib/mysql
networks:
- wpnet
wordpress:
image: wordpress:6.3
environment:
WORDPRESS_DB_HOST: db:3306
WORDPRESS_DB_USER: wp
WORDPRESS_DB_PASSWORD: wppass
WORDPRESS_DB_NAME: wp
volumes:
- wp_data:/var/www/html
networks:
- wpnet
volumes:
db_data:
wp_data:
networks:
wpnet:
Con esta estructura, los backups deben enfocarse sobre db_data y wp_data. Copias simples de volúmenes con docker run --rm -v db_data:/from -v /backup:/to alpine ash -c "cd /from && tar czf /to/db_data.tar.gz ." son útiles para desarrollo, pero no garantizan consistencia de la base de datos en producción.
Consistencia de base de datos: cómo evitar corrupción
Para MySQL/MariaDB (InnoDB): usar mysqldump con --single-transaction --quick o realizar snapshot del sistema de ficheros coordinado con FLUSH TABLES WITH READ LOCK si se usa archivo binlog y no hay réplica. Otra opción superior es realizar backups desde una réplica esclava para evitar impacto en la primaria. Para PostgreSQL, pg_basebackup o backups WAL gestionados son recomendables. Para sitios con alta escritura, incorporar replicación y backups desde réplicas garantiza mínima latencia.
Estrategias de copias: volúmenes, bases de datos y archivos
Existen tres enfoques principales: copia de volúmenes, exportar la base de datos, y crear imágenes del contenedor. Cada uno tiene ventajas y limitaciones. Los volúmenes contienen todo el filesystem de WordPress (plugins, themes, uploads) pero no la estructura interna de la base de datos. Exportar la base de datos asegura la capa de datos relacionales; combinar ambos garantiza restauraciones completas. Crear una imagen del contenedor (docker commit) no es una solución de backup fiable para datos persistentes porque los volúmenes no se incorporan en la imagen por defecto.
Tabla comparativa: volúmenes vs snapshots vs export (HTML)
| Método |
Descripción |
Ventajas |
Limitaciones |
Coste típico |
| Copias de volúmenes (tar/rsync) |
Exportar archivos del volumen al host o almacenamiento |
Fácil, portable |
Riesgo de inconsistencia de DB; lento para grandes volúmenes |
Bajo |
| Snapshots a nivel de host/FS (LVM/ZFS/EBS) |
Instant snapshot del volumen en bloque |
Rápido, consistente si se coordina |
Requiere soporte del proveedor; puede necesitar freeze de DB |
Medio-Alto |
| Export DB (mysqldump/pg_dump) |
Dump lógico de la base de datos |
Consistente, portable, pequeño |
Tiempo de dump en bases grandes; restauración más lenta |
Bajo-Medio |
| Backups incrementales (restic/Borg) |
Deduplicación e incrementales sobre datos cambiantes |
Alta eficiencia de almacenamiento y cifrado |
Proceso más complejo y curva de aprendizaje |
Medio |
Recomendación práctica
Para entornos empresariales, la estrategia líder combina: snapshots rápidos del volumen (si están disponibles), dumps lógicos o backups desde réplicas para la base de datos y backup incremental con deduplicación para archivos (restic/Borg). Mantener una política 3-2-1: tres copias, dos medios diferentes, una fuera de sitio.
Automatizar backups con Docker Compose y cron jobs
Automatizar reduce errores humanos y asegura regularidad. Dos patrones comunes: a) contenedor de backup dedicado que ejecuta restic/borg/rclone según cron o systemd timer; b) tareas programadas en el host que ejecutan scripts docker exec/docker run para generar dumps y subirlos al almacenamiento remoto. El enfoque recomendado es encapsular la lógica en un contenedor no invasivo que tenga acceso a volúmenes y credenciales (mediante secretos) y que envíe logs a un sistema centralizado (SIEM o monitorización).
Contenedor de backup con restic en docker-compose
- Crear repositorio restic en S3/Wasabi.
- Montar volúmenes wp_data y db_data en el contenedor restic (lectura) o usar docker exec para exportar dumps en /backup.
- Programar backups incrementales diarios y full semanales.
Es crucial que las credenciales AWS/S3 se gestionen como secretos (Docker Secrets o variables de entorno en un orquestador). Además, configurar alertas (email/Slack) para fallos y sumar verificaciones automáticas (restic check) al pipeline.
Backups incrementales y snapshots: ahorrar espacio y tiempo
Backups incrementales permiten almacenar solo los cambios desde la última copia, reduciendo coste de almacenamiento y tiempo de operación. Herramientas recomendadas: restic (2026: activo, soportado, cifrado y deduplicación), Borg (excepcional deduplicación local), y rclone para sincronización con múltiples backends. Para entornos con soporte de snapshots a nivel cloud (EBS, GCE PD), combinar snapshot + backup incremental de ficheros reduce las ventanas de backup.
Implementación técnica: restic + S3 (ejemplo resumido)
1) Inicializar repositorio cifrado: RESTIC_REPOSITORY=s3:s3.amazonaws.com/bucket/restic_repo RESTIC_PASSWORD=secret restic init
2) Backups diarios: restic backup /var/www/html --tag wordpress --exclude .cache
3) Política de retención: restic forget --prune --keep-daily 7 --keep-weekly 4 --keep-monthly 12
Restic permite comprobación de integridad con restic check y restauración selectiva por ruta o tag.
Almacenamiento en la nube: S3, Wasabi y compatibilidad
S3 es el estándar de facto: alta durabilidad, integración directa con herramientas, regionabilidad y lifecycle policies. Wasabi ofrece compatibilidad S3 con coste menor y sin cargos por egress en muchas ofertas; es una alternativa válida para backups que no requieran características avanzadas de AWS. Google Cloud Storage y Backblaze B2 también son opciones a considerar. Las prácticas recomendadas incluyen: cifrado en tránsito y reposo, versionado de objetos para evitar borrados accidentales, y uso de lifecycle para gestión de retención.
Costes y límites (indicative, actual at time of writing 2026)
- AWS S3 Standard: coste por GB y egress; políticas de lifecycle para mover a Glacier Deep Archive.
- Wasabi: tarifa plana más baja por GB y sin egress en muchos planes; comprobar SLA y replicación regional.
- Backblaze B2: económico para almacenamiento frio.
Evaluar costes en función de volumen enlazado: un sitio WordPress con 20 GB de uploads y base de datos de 2 GB, con retención de 30 días y backups diarios incrementales, típicamente consumirá 25-40 GB de almacenamiento efectivo con deduplicación.
Pruebas de restauración y procedimientos ante incidentes
La prueba de restauración es obligación. Cada backup debe tener asociado un procedimiento documentado que incluya tiempo objetivo de recuperación (RTO) y punto objetivo de recuperación (RPO). Las pruebas deben realizarse en entornos aislados y registrarse. Un procedimiento típico: restaurar DB en réplica, montar volúmenes restaurados, verificar integridad de archivos y pruebas funcionales (login, carga de homepage, compra si hay eCommerce). Automatizar pruebas básicas (smoke tests) con scripts es recomendable.
Checklist de recuperación ante desastre
- Validar acceso a la cuenta cloud y permisos.
- Restaurar última copia completa + incrementales necesarios.
- Ejecutar scripts de actualización de configuración (env, claves).
- Probar funcionalidad crítica: login admin, checkout, formularios.
- Verificar certificados TLS y DNS.
Flujo de backup para WordPress en Docker
Flujo de backup
Contenedor WordPress ➜ Volúmenes (wp_data) ➜ Dump DB (mysqldump o réplica) ➜ Contenedor backup (restic) ➜ Envío cifrado a S3/Wasabi ➜ Verificación
2
Enviar a repositorio cifrado
Análisis estratégico: elegir la estrategia según riesgo y presupuesto
Monitorización, alertas y verificación automática
Implementar notificaciones por fallo de backup (email/Slack), métricas de éxito/fracaso, retención y verificación automática (restic check). Registrar logs en central y rotarlos. Un backup sin alertas útiles es un riesgo oculto.
Enlaces útiles y referencias
Preguntas frecuentes (FAQ)
¿Es suficiente copiar el volumen con tar para producción?
No. Copiar volúmenes con tar puede dejar la base de datos en estado inconsistente durante operaciones activas; para bases de datos se recomienda mysqldump o snapshots coordinados.
¿Se puede usar docker commit como backup?
No se recomienda: docker commit no incluye volúmenes persistentes y no garantiza consistencia de la base de datos o del sistema de archivos de datos.
¿Qué herramienta ofrece mejor deduplicación: restic o Borg?
Borg suele tener deduplicación local muy eficiente; restic ofrece deduplicación, cifrado y backend S3 nativo con mayor simplicidad para almacenamiento remoto.
¿Con qué frecuencia probar las restauraciones?
Se recomienda probar al menos una restauración completa mensual y pruebas automáticas de integridad tras cada backup crítico.
¿Dónde guardar las credenciales de backup?
Usar secretos gestionados (Docker Secrets, gestores de secretos del proveedor cloud) y no variables de entorno sin cifrado.
Plan de acción (3 pasos rápidos <10min cada uno)
1) Auditar volúmenes y bases de datos
Listar volúmenes Docker relevantes (/var/lib/docker/volumes) y comprobar tamaño aproximado. Identificar si la base de datos admite snapshot o requiere dump.
2) Implementar backup básico automatizado
Configurar un job cron/contendor que ejecute mysqldump con --single-transaction y copie wp-content a S3/Wasabi usando rclone/restic; añadir notificaciones en caso de fallo.
3) Verificar restauración en entorno de staging
Restaurar el dump y los archivos en un entorno aislado y ejecutar pruebas funcionales. Documentar tiempos de RTO y RPO.
Contacto y recursos adicionales: soporte técnico y servicios profesionales disponibles en mantenwp.com o por correo a [email protected].
