Backups de WordPress: recuperación segura y verificada

¿Qué ocurre si un incidente demuestra que las copias no sirven? Responsables técnicos y empresarios confían en backups del hosting, pero sin políticas verificables se pierde continuidad, se incumplen contratos y se multiplican costes de recuperación. Diseñar, auditar y automatizar una política reproducible reduce el tiempo de inactividad y los riesgos legales con acciones concretas y medibles.

Resumen del proceso

1. Diseñar política y KPIs: definir RPO, RTO, edad máxima del backup y retención.

2. Automatizar backups y checksums: generar SHA‑256 de archivos y base de datos, firmar y almacenar fuera del servidor.

3. Verificar almacenamiento remoto: comprobar objetos, versiones y políticas de ciclo de vida diariamente.

4. Ejecutar test restores documentados: restaurar en staging y medir RTO cada 3 meses.

5. Configurar alertas estructuradas: Slack/PagerDuty/e‑mail con payload estándar.

6. Registrar evidencias para auditoría: logs firmados y tickets con capturas.

Paso 1: diseñar política y KPIs

La política define qué se guarda, cuánto tiempo y cuándo se considera inservible la copia. La política fija RPO y RTO junto a la edad máxima del backup y los umbrales de alerta.

La definición práctica incluye RPO (pérdida máxima aceptable) y RTO (tiempo máximo de recuperación). Por ejemplo, RPO de 24 horas para una tienda online; 7 días para un blog corporativo.

La retención mínima debe cumplir normas aplicables y requisitos operativos. El GDPR está en vigor, NIS2 se aplica y la guía técnica ISO/IEC 27002 está publicada; estos marcos condicionan la retención y el control de claves.

KPIs operativos básicos

RPO y RTO deben medirse en horas y registrarse en el control de cambios. Edad máxima del backup: generar alerta si la copia más reciente supera 48 horas para activos críticos.

Tasa de verificación fallida: medir porcentaje de backups con hash no coincidente; activar alarma si es superior al 5% en 7 días. Tiempo medio de restauración (MTTR_restore) se obtiene de los test restores documentados.

Retención y cumplimiento

Retención legal puede variar según sector y contrato; documentar plazos en la política. Registrar la justificación legal y técnica de cada periodo de retención para auditoría.

Paso 2: automatizar checksums y verificación

Automatizar hashes SHA‑256 y firmarlos con GPG añade una capa de garantía ante corrupción y ataques silentes. Almacenar las firmas en un destino off‑site evita que un atacante borre pruebas locales.

Generar hash tanto de archivos como de volcados de base de datos crea dos puntos de verdad distintos. El hash de archivos detecta corrupción en ficheros; el hash de DB detecta inconsistencias en el volcado.

Registrar el resultado de la verificación con código de salida y enviar alertas estructuradas si falla cualquier verificación. Un script debe devolver 0 en éxito y distinto de 0 en error para integrarse con cron y orquestadores.

Script hashes de archivos

bash cd /var/www/html find wp-content -type f -print0 | sort -z | xargs -0 sha256sum > /tmp/files.sha256 gpg --batch --yes --output /tmp/files.sha256.sig --detach-sig /tmp/files.sha256 aws s3 cp /tmp/files.sha256 s3://backups.example.com/site1/ --acl private --sse aws:kms --sse-kms-key-id alias/backups-data-key aws s3 cp /tmp/files.sha256.sig s3://backups-signatures.example.com/site1/ --acl private --sse aws:kms --sse-kms-key-id alias/backups-keys-key

Script hash de base de datos

bash mysqldump --single-transaction --quick --skip-lock-tables DB_NAME | gzip -c > /tmp/db.sql.gz sha256sum /tmp/db.sql.gz > /tmp/db.sha256 gpg --batch --yes --output /tmp/db.sha256.sig --detach-sig /tmp/db.sha256 aws s3 cp /tmp/db.sql.gz s3://backups.example.com/site1/ --acl private aws s3 cp /tmp/db.sha256 s3://backups.example.com/site1/ --acl private aws s3 cp /tmp/db.sha256.sig s3://backups.example.com/site1/ --acl private

Cronjob integrado

Utilice un cron que ejecute backup y verificación y que reporte fallos. Ejemplo:

cron 0 02 * * * /usr/local/bin/backup_files.sh >/var/log/backup_files.log 2>&1 || /usr/local/bin/notify_failure.sh 'backup_files' ; /usr/local/bin/backup_db.sh >/var/log/backup_db.log 2>&1 || /usr/local/bin/notify_failure.sh 'backup_db' ; /usr/local/bin/verify_hashes.sh >/var/log/verify_hashes.log 2>&1 || /usr/local/bin/notify_failure.sh 'verify_hashes'

Gestión de claves y cifrado: además de cifrar los volcados y objetos en tránsito y en reposo, la política debe definir quién posee y controla las claves (KMS o HSM), la periodicidad de rotación, y cómo se hace el backup y el escrow de las claves mismas. Por ejemplo, usar AWS KMS con una clave administrada por la organización (BYOK) y una política que permita decrypt solo a un rol de restauración limitado, rotando la clave cada 90 días y registrando cada acceso en CloudTrail o logs equivalentes. También conviene mantener una copia cifrada de la clave maestra en un HSM o en un almacén de claves externo y documentar el procedimiento de recuperación de claves (incluyendo pasos en caso de pérdida de acceso), todo ello ligado a la retención de backups y a los requisitos de auditoría del GDPR.

La gestión de claves debe incluir separación de funciones: el operador de backups no debe tener por defecto permisos de rotación o borrado de claves.

Paso 3: pruebas de restauración documentadas

Probar restauraciones comprueba que el backup no solo existe sino que restaura funcionalmente. La frecuencia mínima recomendada es trimestral para PyMEs y mensual para comercios electrónicos.

El test restore debe correr en un entorno staging aislado y seguir un guion que verifique login, plugins críticos y rutas media. Medir el tiempo desde inicio hasta site operativo para registrar el RTO real.

Registrar evidencias: capturas, hashes pre/post y logs de restauración; adjuntar tickets en el sistema de seguimiento. Esto crea trazabilidad para auditoría y para mejora continua.

Guion de prueba paso a paso

1) Preparar staging con recursos de red aislados.

2) Restaurar archivos y DB usando los scripts y las claves correctas.

3) Ajustar wp-config.php y comprobar conexiones a servicios externos.

4) Verificar login admin, procesos de compra, formularios y búsqueda.

Qué medir en cada prueba

Medir tiempo total de restauración (RTO real), errores encontrados y diferencias de contenido. Compare hashes pre/post para confirmar integridad técnica.

Un caso habitual: una PyME restauró una copia reciente y detectó corrupción en uploads; la verificación de hashes habría detectado el problema antes de necesitar restauración.

Paso 4: monitorizar almacenamiento remoto y permisos

Vigilar la salud del destino off‑site evita perder copias por expiración de ciclo de vida o rotación de claves. Un simple listado diario de objetos y comprobación de versiones detecta borrados accidentales.

Comprobar permisos y roles evita que claves caducadas impidan restauraciones. Las políticas IAM y el versioning deben revisarse regularmente para evitar borrados definitivos.

Utilice herramientas de línea de comandos para comprobar estado y automatizar alertas si algún chequeo falla. Una comprobación que devuelve 4xx/5xx o encuentra 1+ objeto faltante debe generar alarma urgente.

Checks S3/GCS con aws cli

bash aws s3api head-object --bucket backups.example.com --key site1/files.sha256 aws s3api list-object-versions --bucket backups.example.com --prefix site1/ | jq '.Versions | length'

Permisos y ciclo de vida

Revise lifecycle rules para evitar que objetos caducen antes de la retención contractual. Mantenga claves de cifrado separadas y, si aplica, use BYOK para control de cifrado.

Comprobación de salud del almacenamiento remoto:

• más allá de listar objetos con aws s3api, active S3 Inventory (daily/weekly) para validar listas completas y checksums de objetos a gran escala, y compruebe que el bucket tiene Object Lock en modo compliance si las políticas de retención lo exigen. Utilice métricas CloudWatch (NumberOfObjects, AllRequests, 4xxErrors, 5xxErrors, FirstByteLatency) y alarmas que detecten aumento de 4xx/5xx o caídas en el recuento esperado
• automatice un job que compare el inventario contra la lista local y que valide estados de replicación y de restauración de Glacier (restore-in-progress). Integrar estos chequeos en cronjobs o en workflows serverless (Lambda) permite correlacionar fallos con resultados de verificación de integridad y notificar vía alertas Slack/PagerDuty
• registre resultados en el sistema de auditoría de backups con referencias a la retención de backups y a la política de RPO/RTO

Paso 5: alertas automáticas y plantillas

Enviar alertas con formato consistente mejora la respuesta. El payload mínimo debe incluir site, backup_id, timestamp ISO, tipo de verificación y código de error.

Configurar severidad en PagerDuty para escalado y canales separados para operaciones y cumplimiento. Un e‑mail dirigido a la dirección de protección de datos debe contener resumen y enlace a evidencias.

Las alertas deben almacenar ID de incidente para correlación y mantener logs que permitan auditoría posterior. Use campos estructurados en JSON para facilitar ingestión por SIEM.

Plantilla JSON de alerta

{

  "site_name":"tienda.example.com",

  "environment":"production",

  "backup_id":"20260610T0200",

  "timestamp":"2026-06-10T02:00:00Z",

  "check_type":"hash_verification",

  "result":"failure",

  "error_code":"HASH_MISMATCH",

  "logs_url":"https://logs.example.com/12345"

}

Ejemplo de mensaje corto para slack

ALERTA: backup failed | site: tienda.example.com | id: 20260610T0200 | error: HASH_MISMATCH | acción: revisar logs

Comparativa técnica y matriz de decisión

La elección se hace con criterios medibles: verificación automática, test restore integrado, cifrado BYOK y coste estimado. Puntuar cada proveedor frente a estos criterios permite decidir con datos.

La tabla siguiente ayuda a comparar opciones para PyMEs en España. Los precios son orientativos y varían según volumen y SLA.

La recomendación práctica: elegir una solución que incluya verificación automática y test restore integrado si el RPO/RTO son estrictos.

Esto funciona bien en teoría, pero en la práctica muchas instalaciones confían sólo en un plugin del hosting y fallan cuando el servidor sufre corrupción o el proveedor pierde datos.

Un caso concreto: un comercio restauró una copia de la semana anterior y perdió pedidos recientes porque el RPO no se había definido ni medido; la prueba de restauración habría evitado la pérdida de ventas.

Checklist técnica para elegir una solución de monitorización: la herramienta debe exponer API para obtener resultados de verificación y triggers (webhooks), soportar checksums SHA-256 y/o firmas GPG para archivos y mysqldump comprimidos, permitir test restores automatizados o programables y generar métricas RPO/RTO y MTTR_restore exportables a SIEM. Requiera también soporte para almacenamiento off-site immutable (Object Lock), integración con KMS/BYOK, logs de auditoría inmutables, escalabilidad por volumen y retención, y canales de alerta estructurados (Slack/PagerDuty/e‑mail) con payload JSON.

Evalúe latencia y coste por GB, facilidad para automatizar cronjobs o pipelines CI/CD que ejecuten backups, verificación y pruebas de restauración, y la capacidad de generar informes periódicos para cumplimiento y para el delegado de protección de datos.

Flujo de backup y verificación

Errores que arruinan el resultado

Confiar sólo en el plugin del hosting es el error más frecuente en este punto. Muchos proveedores guardan snapshots locales que no sobreviven a fallos de hardware o a ataques que afectan al almacenamiento compartido.

No hacer pruebas de restauración convierte backups en simples archivos inútiles. Se han detectado casos donde backups recientes no restauraban por permisos, rutas rotas o bases de datos incompletas.

No vigilar el destino off‑site provoca pérdidas por políticas de ciclo de vida mal configuradas o claves expiradas. Revise las reglas de expiración y los roles IAM con periodicidad.

Un fallo típico de diseño: almacenar toda la cadena de verificación en el mismo servidor que el backup. Firmas y hashes deben vivir fuera (otro bucket, HSM o servicio de almacenamiento distinto).

Cuándo no aplicar este método

Síntesis y recomendación accionable

La acción inmediata: implemente checksums SHA‑256 firmados y programe test restores trimestrales en staging. Establezca umbrales claros: edad máxima del backup 48 horas para activos críticos y tasa de verificación fallida crítica si supera el 5% en 7 días.

Registre todo en un procedimiento sencillo: quién ejecuta, cuándo, resultado y evidencia. Mantenga las firmas en un destino distinto del servidor web y use alertas estructuradas para priorizar acciones.

Esta sola medida reduce el riesgo de backups inútiles y acelera la respuesta ante incidentes, al permitir distinguir corrupción técnica de pérdida real.

Se puede solicitar una revisión técnica externa y una auditoría de restauración para firmar la política ante clientes o auditoría.

Se recomienda programar la siguiente prueba de restauración dentro de 30 días y documentarla para cumplir SLAs operativos y requisitos del delegado de protección de datos.

La empresa puede contratar soporte para automatizar integraciones si no dispone de personal técnico disponible.

Contacto para revisión técnica y auditoría: solicitar evaluación de la política de backups y un test restore documentado con registro de RTO y evidencias.

Preguntas frecuentes

¿Con qué frecuencia debo hacer test restores?

Mínimo cada 3 meses para PyMEs y mensual para comercios electrónicos. Documente tiempos y errores en cada prueba.

¿Basta con un plugin del hosting para guardar copias?

No, no basta. Un plugin local puede no detectar corrupción ni proteger contra fallos del servidor. Verifique hashes y almacene off‑site.

¿Qué hashes usar para verificar archivos y DB?

Use SHA‑256 para archivos y volcados de DB, y firme con GPG para evitar manipulaciones. Guarde firmas en otro destino.

¿Cómo se comprueba que un bucket S3 no ha sido alterado?

Liste objetos esperados y compare conteo/versiones diariamente; una ausencia de 1+ objeto esperado debe generar alerta. Use aws cli para automatizar este chequeo.

¿Qué KPIs debo reportar al cliente o auditor?

Reportar RPO, RTO, edad máxima del backup y tasa de verificación fallida (en %). Incluir resultado del último test restore y MTTR_restore.

¿Cómo gestionar claves de cifrado para backups?

Mantener control de claves, usar BYOK cuando sea posible y registrar acceso a las claves. Documente quién las gestiona y rotación periódica.

¿Qué hacer si un backup falla la verificación?

Considerar la copia inválida y activar inmediatamente un test restore desde la última copia válida. Investigue la causa antes de confiar en próximas copias.

Pasos prácticos inmediatos

Implemente los scripts de checksum y firma, programe el cron de verificación y agende el primer test restore dentro de 30 días. Asigne responsables para alertas y registre cada prueba en el sistema de tickets para auditoría.

• Recupera WordPress tras actualizaciones fallidas de plugins
• Asegura backups PCI-DSS y pasa auditorías

Josu Barrios

Somos especialistas en mantenimiento WordPress para empresas, profesionales y tiendas online. Contamos con experiencia en seguridad web, optimización de rendimiento, actualizaciones, copias de seguridad y resolución de incidencias técnicas, ayudando a que cada sitio funcione de forma rápida, estable y protegida. Nuestro enfoque combina soporte técnico profesional, buenas prácticas de seguridad y seguimiento continuo para ofrecer un servicio fiable, transparente y orientado a resultados reales.