¿Sabe que muchas restauraciones fallan en entornos headless por desincronización entre CMS y front-end? Errores típicos: archivos de medios ausentes en el storage, artefactos front obsoletos o esquemas GraphQL cambiados, que provocan páginas rotas y pérdida de negocio tras una restauración.
Backups para WordPress headless: qué cambiar. Al pasar a un WordPress headless hay que adaptar los backups: no basta con copiar la base de datos. Respalde también la librería de medios (y su storage/CDN), versiones del front-end (artefactos o repositorio), esquemas/API (WPGraphQL/REST) y variables/secretos. Defina orden de restauración, automatice rebuilds en Vercel/Netlify y pruebe restores regularmente para garantizar consistencia. Se incluyen playbooks y comandos ejecutables para implementarlo.
Resumen del proceso
Este resumen ofrece la lista de pasos ejecutables y el resultado inmediato en 30-90 minutos.
Pasos en orden
- Exportar y versionar la base de datos y el esquema GraphQL/REST.
- Sincronizar y versionar la librería de medios y los thumbnails.
- Guardar artefactos del front-end y taggear el repositorio.
- Respaldar secretos y variables en un vault cifrado.
- Automatizar webhooks de rebuild para Vercel/Netlify y validar con tests.
Tras completar estos pasos, el equipo puede restaurar un entorno de staging funcional que refleje la web pública en condiciones normales; tenga en cuenta que el éxito depende de factores operativos: ancho de banda disponible para buckets grandes, tiempo necesario para invalidar CDN, accesos y permisos a secretos, y la integridad de los artefactos almacenados.
Si alguno de estos factores falla (por ejemplo, un bucket incompleto o secrets no cargados), el staging no será representativo hasta que se corrija la dependencia externa.
Tiempos estimados
Cada paso se puede dejar automatizado en 30 a 90 minutos por sitio mediano. Las pruebas de restore completas suelen tardar entre 1 y 4 horas según el tamaño del sitio.
Automatice pruebas de restore periódicas en un entorno efímero para asegurarse de que los backups son recuperables: cree un job que provisione un staging (o use snapshots RDS con PITR), restaure la DB con gunzip | mysql/pg_restore, sincronice medios con aws s3 sync y despliegue el artefacto front-end guardado. A continuación ejecute smoke tests: comprobaciones HTTP en páginas críticas, queries de WPGraphQL para validar tipos y campos, verificación de thumbnails y URLs de CDN, y checksum de archivos en uploads.
Si alguna verificación falla, el job debe alertar al canal de on-call y abrir un ticket. Monitorice métricas de éxito/fracaso de backup, tiempo medio de restore y retención y configure alertas en caso de backups corruptos o fallidos para reducir el RTO y garantizar que los rebuilds CI/CD no propaguen inconsistencias.
Respaldos: base de datos, esquema y medios (incl. offload y CDN)
Respaldar la base de datos, el esquema y la librería de medios mantiene la integridad del contenido, las consultas del front-end y evita páginas rotas tras un restore. Planifique backups y restores considerando tanto la DB como los objetos estáticos y la definición de la API (por ejemplo GraphQL).
Comandos básicos de DB
Use mysqldump o pg_dump según la base instalada. Ejemplo MySQL local:
mysqldump --single-transaction --routines --events --triggers -u root -p DBNAME > backup-$(date +%F).sql
gzip backup-$(date +%F).sql
Backups gestionados y PITR
Si la base está en RDS o Cloud SQL, active snapshots y Point-in-time recovery (PITR) para reducir el RPO a minutos. En entornos gestionados aproveche las copias automáticas y las opciones de retención que ofrece el proveedor.
Qué incluir del esquema y cómo manejar exports
Por defecto, planifique el restore completo de la base de datos. Solo opte por exports parciales (p. ej. wp_options o wp_postmeta) como optimización si dispone de:
- Un inventario explícito de tablas personalizadas y de plugins (prefix_pluginname).
- Un proceso automatizado que restaure esas tablas adicionales para evitar inconsistencias funcionales.
Documente y liste explícitamente las tablas que añaden plugins y asegúrese de incluirlas o versionarlas también. En entornos headless, además, versione y almacene el esquema de la API: exporte la definición GraphQL mediante una introspección para detectar cambios no deseados.
⚠️ No omita las tablas de plugins (prefix_pluginname). Restaurar sin ellas rompe funcionalidades críticas.
Respaldar medios y offload
Incluya la librería de medios: thumbnails, avatares y archivos generados deben estar incluidos para evitar URLs rotas o páginas incompletas tras el restore. Guarde también las versiones de imágenes generadas por plugins y cualquier variante procesada.
Sincronizar object storage
Si usa S3, Google Cloud Storage u otro object storage, sincronice el bucket con herramientas como aws-cli o rclone. Ejemplo con S3:
aws s3 sync s3://bucket-name/uploads/ backups/uploads/ --delete --storage-class STANDARD_IA
Si los medios están offloaded, sincronizar solo wp-content/uploads no es suficiente: sincronice el bucket completo y verifique que las URLs públicas funcionen.
⚠️ Si los medios están offloaded, no basta con copiar wp-content/uploads. Sincronice el bucket y pruebe URLs públicas.
CDN e invalidaciones
Registre las rutas servidas por CDN y prepare invalidaciones después del restore. Un fallo común: se restaura el bucket S3 pero no se invalidan las cachés de CloudFront (u otra CDN), por lo que el sitio sigue mostrando URLs rotas o contenido antiguo. Automatice o documente el proceso de invalidación para cada restore.
Archivar thumbnails y verificar integridad
Archivar versiones de imágenes y thumbnails generados por plugins. Use checksums para verificar integridad antes de restaurar y evite sobrescribir activos críticos sin validación.
Buenas prácticas finales
- Pruebe restores completos periódicamente (DB + medios + CDN invalidado + esquema de API) en un entorno de staging.
- Mantenga inventarios de tablas y buckets relacionados con plugins y funcionalidades personalizadas.
- Automatice el proceso de export/import y documente los pasos para minimizar errores humanos en restores.
Paso 3: versionar frontend y artefactos
Tratar el front-end como parte del backup permite restaurar exactamente la versión que entregó la web pública.
Taggear releases y almacenar builds
Taggear el commit que corresponde al snapshot de producción. Ejemplo:
bash
git tag -a v1.2.3-$(date +%F) -m "Snapshot for backup"
git push origin --tags
npm run build && tar -czf build-v1.2.3-$(date +%F).tar.gz .next/
aws s3 cp build-v1.2.3-$(date +%F).tar.gz s3://artifacts-bucket/
Archivo de configuración de build
Guarde netlify.toml, vercel.json o next.config.js con versiones. Sin estos archivos el rebuild puede fallar por cambios en variables de entorno.
Artefactos vs repositorio
Almacenar artefactos acelera rollback. Mantener también el repositorio permite reconstruir builds si los artefactos están corruptos.
Restauración y rebuilds CI/CD
Restaurar en el orden correcto evita errores de consistencia entre CMS y front-end.
Orden de restauración imprescindible
- DB y esquema
- Medios
- Configuración y plugins
- Secrets
- Rebuild del front-end
Comandos de restore y tiempo
Restaurar una DB de 2-5 GB local suele tardar 5-20 minutos. Restaurar medios de 50 GB puede tardar varias horas según ancho de banda. Ejemplo de restore DB:
bash
gunzip -c backup-2024-04-01.sql.gz | mysql -u root -p DBNAME
Disparar rebuilds en vercel y netlify
Vercel webhook ejemplo:
bash
curl -X POST "https://api.vercel.com/v1/integrations/deploy/prj_XXXX/webhook" -H "Authorization: Bearer $VERCEL_TOKEN"
Netlify webhook ejemplo:
bash
curl -X POST -d {} https://api.netlify.com/build_hooks/HOOK_ID
La recomendación central es esta: restaurar datos y medios antes de disparar cualquier build, y cargar los secrets en el vault antes del deploy. Esto asegura que las variables de entorno necesarias estén presentes para el proceso de build.
El equipo debe incluir un párrafo con criterios:
La elección entre almacenar artefactos o reconstruir desde repositorio funciona bien, pero solo si el entorno de build es estable. Si las dependencias cambian con frecuencia, guardar artefactos reduce el tiempo de recuperación y evita builds rotos.
Para integrar la restauración con CI/CD, describa workflows reproducibles: un pipeline típico ejecuta (1) restore de DB (mysqldump/pg_dump o snapshot RDS), (2) sync de object storage (aws s3 sync s3://bucket/uploads/ ./uploads/), (3) carga de secrets al vault y (4) disparo del rebuild. En GitHub Actions puede crear un job que, tras completar los pasos anteriores, haga curl a la build hook de Netlify o llame a la API de Vercel con un token para forzar un deploy del tag específico (por ejemplo, git tag -a restore-2026-04-30 && git push --tags; luego curl -X POST https://api.netlify.com/build_hooks/HOOK_ID).
Añada comprobaciones que esperen a que el pipeline confirme que las variables de entorno están presentes antes de iniciar el build y use artefactos almacenados en S3 para acelerar rollback si las dependencias han cambiado.
Errores y comparativa de soluciones
Comparar soluciones permite elegir según cobertura, coste y facilidad de restore.
Errores que arruinan el resultado
El error más habitual es confiar solo en backups del CMS desde el panel de WordPress. Otro error es no probar restores, por eso los backups pueden fallar cuando más se necesitan.
Tabla comparativa
| Solución |
Cobertura |
Automatización |
Coste estimado |
Facilidad de restore |
| Hosting gestionado (Kinsta, WP Engine) |
DB + archivos básicos; variable para S3 |
Alta; panel integrado |
Medio-alto por sitio |
Rápido, pero puede no incluir artefactos front-end |
| Solución cloud (AWS S3 + RDS + EBS) |
Completa si se configura: DB, objetos, snapshots |
Alta con scripts y lifecycle |
Variable; pago por uso |
Muy controlable; requiere operativa |
| Plugins (UpdraftPlus, BlogVault) |
DB + uploads; offload limitado |
Media con cron; artefactos no incluidos |
Bajo-medio |
Fácil para sitios pequeños; no cubre front-end headless |
Pros y contras resumidos
Hosting gestionado simplifica y reduce errores operativos. Solución cloud da control y PITR, pero exige personal. Plugins son económicos, pero no reemplazan backups de artefactos y secrets.
Cuándo no funciona este método / alternativas
Costes ocultos y compensaciones
Guardar artefactos y snapshots incrementa coste de almacenamiento y operaciones. Estime entre 10% y 40% adicional sobre el coste básico de backups según el tamaño del front-end y la retención.
Cuándo externalizar
Externalice si el equipo no puede mantener PITR, rotaciones de secretos y DR drills. Para eCommerce con alto tráfico se recomienda externalizar a equipos con experiencia en recoveries.
Para asegurar cumplimiento recuerde las normas: RGPD (2018), LOPDGDD (2018) y NIS2 (2022) y mantenga cifrado en reposo y en tránsito. Consulte la Agencia Española de Protección de Datos para detalles sobre conservación y trato de datos personales: AEPD.
Para una auditoría técnica y una prueba de restore en staging en 48 horas, pida revisión y pruebas controladas por el equipo de mantenimiento.
Preguntas frecuentes
¿Qué plugin es útil para realizar copias de seguridad?
UpdraftPlus y BlogVault cubren DB y archivos y ofrecen opciones de offsite. Jetpack/VaultPress aporta integración con Automattic.
Estos plugins facilitan backups, pero pueden no incluir S3 offload ni artefactos de frontend; para entornos headless combine plugin con sincronización de buckets y versionado de artefactos.
¿Cómo hacer una copia de seguridad gratuita de un sitio?
Use WP-CLI para exportar la base de datos y aws-cli o rclone para sincronizar uploads. Git y tags guardan el repositorio.
Este método requiere scripts y gestión manual de retención. Es válido para proyectos con equipos técnicos que desean control total sin coste de licencia.
¿Cómo hacer backups de WordPress correctamente?
Respaldar DB, wp-content/uploads, wp-config.php, lista de plugins, esquema WPGraphQL/REST, artefactos frontend y secrets.
Incluya pruebas de restore y rotación de secrets. Sin tests, un backup no garantiza recuperabilidad.
¿Cómo puedo restaurar mi sitio WordPress desde un backup?
Restaurar DB primero, luego medios, a continuación restaurar configuración y secrets, después disparar rebuild del frontend y validar con smoke tests.
Si el rebuild falla, mantenga artefactos previos para rollback y revise variables de entorno antes de reintentar.
¿Cada cuánto probar los restores?
Probar restores trimestralmente (cada 3 meses) en un entorno aislado asegura recuperación práctica. Para sitios críticos, pruebe mensualmente.
Registre RTO y RPO y documente hallazgos para mejorar el plan.
¿Cómo gestionar y versionar secretos y variables?
Use HashiCorp Vault, AWS Secrets Manager o Azure Key Vault para almacenar secrets y registre auditoría de accesos.
Versione cambios y automatice cargas de secrets en pipeline antes de cualquier build. Sin secrets, los rebuilds fallan frecuentemente.
¿Qué no cubre un plugin de backup común?
La mayoría no guarda artefactos del front-end ni versiona esquemas GraphQL ni guarda secrets en un vault. Por eso, combine soluciones para cubrir todas las capas.
Si su instalación no es headless o si el hosting aporta snapshots atómicos con pruebas de restore y SLAs, siga la política del proveedor. Esta guía aplica cuando el front-end está separado y los artefactos, medios y secretos quedan fuera del backup típico del CMS.
