¿Cuántas ventas se pierden cuando una restauración falla y nadie alerta a tiempo? Quien gestiona una web o tienda suele confiar en copias locales y notificaciones básicas sin revisar permisos en la nube ni simulacros de recuperación; eso provoca downtime, carritos perdidos y urgencias fuera de horario. Hace falta una estrategia profesional que reduzca riesgos y acelere la recuperación.
Índice
Anuncio
Resumen del proceso
Este resumen ofrece los pasos cortos para ejecutar hoy la protección. Cada paso se explica y luego se desarrolla.
- Elegir destino remoto y crear credenciales con permisos mínimos.
- Configurar copia de ficheros y base de datos en WordPress.
- Activar alertas por email, Slack y webhook y dar reintentos.
- Verificar integridad con checksums y programar restauraciones de prueba.
- Definir RTO/RPO y ajustar frecuencia, retención y coste.
Destino y permisos
Elegir entre S3, Backblaze B2 o Google Cloud según coste y cumplimiento. Seleccionar región EU si aplica RGPD.
Plugins y cron
Instalar un plugin robusto o script que haga dumps de base de datos y tar de ficheros. Programar con cron o systemd timers.
Verificación y pruebas
Generar checksums sha256 y restaurar en staging trimestralmente. Registrar resultados y tiempos.
Paso 1: elegir destino y permisos mínimos
Este paso define dónde se almacenan las copias y qué credenciales usar. Elegir bien reduce fugas y costes.
Amazon S3: configuración mínima
Usar región EU (Irlanda o Frankfurt) para datos de la UE. Habilitar versionado y SSE-KMS.
El error más frecuente en este punto es usar credenciales con permisos totales desde el inicio.
A continuación un ejemplo de política IAM mínima que permite subir y leer el bucket:
{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":["s3:PutObject","s3:GetObject","s3:ListBucket"],"Resource":["arn:aws:s3:::mi-bucket-backups/*","arn:aws:s3:::mi-bucket-backups"]}]}
Backblaze B2: claves de aplicación
Crear Application Key con scope limitado. Usar lifecycle para mover a almacenamiento frío.
Backblaze es una opción de bajo coste para backups de gran volumen y facilidad de uso.
Google cloud / drive
Para grandes volúmenes usar Google Cloud Storage con IAM por bucket. Para backups ligeros usar Drive con cuenta de servicio.
El uso de región EU ayuda a cumplir RGPD; consultar documentación oficial de AWS para precios y regiones AWS S3 pricing.
Para que un destino remoto sea realmente operativo conviene incluir instrucciones paso a paso para crear las credenciales con permisos mínimos. En Amazon S3, por ejemplo, cree un usuario IAM específico para backups, anexe una política que permita solo s3:ListBucket sobre arn:aws:s3:::mi-bucket-backups y s3:PutObject/GetObject sobre arn:aws:s3:::mi-bucket-backups/*; habilite versionado en el bucket y, si usa SSE-KMS, conceda al usuario permisos kms:GenerateDataKey y kms:Decrypt sobre la clave KMS concreta. En Backblaze B2 genere un Application Key limitado al bucket de destino y con permisos de lectura/escritura según necesite, activando lifecycle para mover a almacenamiento frío.
En Google Cloud cree un service account, asigne el rol roles/storage.objectAdmin (o un rol custom que limite al bucket) y descargue la clave JSON en un almacén de secretos; evitar usar claves de proyecto con permisos globales. Estos pasos reducen el blast radius de una clave comprometida y son esenciales para cumplir políticas de copias de seguridad remotas y RGPD.
Anuncio
Paso 2: configurar backups en WordPress
La copia debe incluir ficheros y base de datos. Hay que elegir backup completo e incremental según RTO/RPO.
Plugins recomendados
Seleccionar soluciones con pruebas de restauración integradas: UpdraftPlus, BlogVault, ManageWP o VaultPress.
Lo que omiten la mayoría de guías sobre plugins es comprobar la recuperación real en staging después de una actualización.
Scripts y cron
Si el entorno es VPS, combinar snapshots con scripts que hagan mysqldump y tar de wp-content.
Ejemplo práctico de script para cron (ajustar rutas y usuarios):
bash fecha=$(date +"%Y%m%d-%H%M") cd /var/www/wordpress mysqldump --single-transaction -u backupuser -p"pass" wp_database > /backups/db-$fecha.sql tar -czf /backups/site-$fecha.tgz wp-content sha256sum /backups/db-$fecha.sql > /backups/db-$fecha.sql.sha256
Incremental vs completo
Hacer un backup completo semanal y backups incrementales diarios para equilibrar coste y RPO.
Un backup completo semanal con incrementales diarios mantiene RPO bajo sin multiplicar costes.
Paso 3: alertas y monitorización práctica
Las alertas deben ser legibles, accionables y llegar por varios canales. Evitar falsos positivos es esencial.
Alertas por email: plantilla
Asunto: [] ejemplo.com. RESULTADO | ID: 20260511-01
Cuerpo breve que incluya: estado, destino, tamaño, tiempo, checksum y enlace a logs.
Plantilla de cuerpo:
Resultado: ERROR/ÉXITO Sitio: ejemplo.com ID: 20260511-01 Destino: s3://mi-bucket-backups Tamaño: 1.2 GB Tiempo: 00:12:34 Checksum: sha256:abcd1234... Logs: https://logs.empresa.example/backup/20260511-01 Runbook: https://docs.empresa.example/runbook-backup
Slack y webhooks: payload
Enviar mensaje conciso al canal #backups con enlace a logs. Ejemplo JSON para webhook:
json
Recomendación: Escalar a SMS o llamada si el backup falla dos veces consecutivas.
SMS y escalado
Usar SMS solo para incidencias críticas según política de escalado. Integrar Twilio o proveedor local.
Plantilla SMS:
Backup ERROR ejemplo.com ID:20260511-01. Ver https://logs.example/20260511-01
Paso 4: verificación, checksums y restauraciones
Una copia no valida es un riesgo. Verificar integridad y restaurabilidad evita sorpresas.
Comprobación con checksums
Calcular sha256 antes y después de la transferencia. Comparar suma local y remota.
Comando básico:
bash sha256sum backup.sql > backup.sql.sha256 sha256sum -c backup.sql.sha256
Esto funciona bien en teoría, pero en la práctica hay que automatizar la verificación para cada fichero subido.
Pruebas de restauración programadas
Restaurar en staging al menos cada trimestre y ejecutar pruebas funcionales básicas.
Checklist de smoke tests: home, login, proceso de compra, formularios críticos.
Registro y auditoría
Almacenar logs de cada backup y restauración en un sistema centralizado para trazabilidad.
Registrar metadatos: ID de backup, usuario que ejecutó, IP y versión del sitio.
La encriptación debe detallarse más allá de una mención: las copias deben viajar siempre por TLS (HTTPS) y almacenarse cifradas en reposo, preferiblemente con una solución de gestión de claves. Para S3 es habitual usar SSE-KMS (server-side encryption con AWS KMS) para controlar el ciclo de vida y rotación de claves; si se necesita control total sobre las claves, aplicar cifrado cliente (client-side encryption) con AES-256 y almacenar la clave maestra en un HSM o Vault. En Backblaze B2 puede usarse cifrado del lado cliente antes de enviar objetos, y en Google Cloud Storage emplear Cloud KMS.
Defina una política de rotación (p. ej. 90 días), registre los ID de clave en los metadatos del backup y separe el acceso a las claves del acceso a los backups (principio de menor privilegio). Además, registre el algoritmo y el checksum sha256 junto a cada backup para verificar integridad tras desencriptar.
Anuncio
Costes, RTO/RPO y matriz de decisión
Definir RTO y RPO antes de elegir frecuencia y destino. Esto condiciona coste y arquitectura.
Matriz RTO/RPO práctica
RTO y RPO orientativos y solución recomendada:
| RTO | RPO | Solución | Coste aproximado/mes |
|---|---|---|---|
| < 1 hora | < 15 minutos | Hot replica / backup continuo | Desde 500 EUR |
| 2–6 horas | 1 hora | Snapshots + incrementales a S3/B2 | 50–300 EUR |
| 24 horas | 24 horas | Backups diarios a Backblaze/GCS | 5–50 EUR |
Comparativa de destinos
| Proveedor | Precio/GB (2024) | Ventaja | Limitación |
|---|---|---|---|
| Amazon S3 | 0.023 USD/GB | Alta disponibilidad y KMS | Coste de requests y egress |
| Backblaze B2 | 0.005 USD/GB | Bajo coste por almacenamiento | Menos integraciones nativas |
| Google Cloud Storage | Similar a S3 | Integración con GCP y BigQuery | Coste comparable a AWS |
Valores de precio referenciales para 2024. Estos datos ayudan a prever presupuesto mensual.
Errores que arruinan el resultado
Hay fallos recurrentes que conviene evitar. Detectarlos reduce tiempos de recuperación.
Guardar backups en el mismo servidor
Almacenar copias en el mismo disco como el sitio expone a pérdida total si falla el servidor.
No verificar ni probar restauraciones
Confiar en que una copia existe sin restaurarla puede llevar a backups inútiles.
Un caso habitual: tienda WooCommerce con backups automáticos en el servidor → fallo de disco borró sitio y copia. Recuperación imposible por falta de copia offsite.
Credenciales con permisos excesivos
Dejar claves con permiso total permite exfiltrar datos si se filtran.
Cuándo no funciona este método y alternativas
Alternativas gestionadas
Si el proveedor ofrece backups con pruebas de restauración y SLA, documentar tiempos y recuperaciones.
Caso de sitios estáticos
Para sitios estáticos bastan copias periódicas y un sistema de versionado en Git con mirror remoto.
Anuncio
Síntesis y recomendación final
La prioridad es definir RTO/RPO, elegir destino en EU y automatizar verificaciones con checksums. Configurar alertas en varios canales y practicar restauraciones cada trimestre.
Para comprobar esta configuración en un sitio de producción, se puede pedir una revisión técnica por un proveedor de mantenimiento especializado que valide credenciales, políticas de retención y pruebas de restauración.
Un playbook de recuperación ante desastre convierte la teoría en acción. Ejemplo condensado:
- Triage inicial (0–10 min): identificar alcance y declarar incidente; notificar equipo de respuesta y abrir un canal (#incidentes)
- Contención y mitigación (10–30 min): subir página de mantenimiento si procede, bloquear transacciones críticas
- Selección de backup y restauración (30–90 min): elegir la copia más reciente que cumpla RPO, restaurar base de datos primero (mysqldump o snapshot point-in-time), restaurar ficheros y activar registro de cambios; estimación: DB (30–45 min), ficheros (20–60 min según tamaño)
- Verificación (90–120 min): ejecutar smoke tests (login, compra, formularios) y validar checksums sha256
- Post-mortem y rotación de claves (>120 min): documentar causa raíz, rotar credenciales afectadas y ajustar frecuencia/retención según RTO/RPO. Incluya responsables en cada paso (SRE, dev, soporte) y thresholds para escalar por SMS en caso de fallos repetidos
Preguntas frecuentes
¿Cómo hacer un backup completo de WordPress?
Crear copia de ficheros y dump consistente de la base de datos. Automatizar con plugin o script y almacenar en destino offsite.
Luego verificar checksum y ejecutar una restauración de prueba en staging.
¿Qué plugin de backup elegir para WordPress?
UpdraftPlus, BlogVault, ManageWP y VaultPress son opciones maduras. Elegir según necesidades de restauración y destinos soportados.
Verificar siempre que permitan pruebas de restauración automática.
¿Con qué frecuencia hacer backups?
Depende del RPO: para tiendas con transacciones, backups cada hora. Para blogs, diarios.
Una regla práctica: menor RPO exige mayor frecuencia y coste.
¿Cómo comprobar que un backup es válido?
Comparar checksums sha256 locales y remotos. Restaurar en staging y ejecutar smoke tests.
Registrar resultados y tiempos en logs centralizados.
¿Dónde guardar las claves y credenciales?
Usar Secret Manager o Vault. No guardar claves en repositorios ni ficheros de configuración visibles.
Rotar claves periódicamente y aplicar principio de menor privilegio.
¿Qué hacer si falla un backup repetidamente?
Revisar logs, verificar permisos de escritura y espacio en destino, y escalar si hay fallos consecutivos.
Configurar reintentos automáticos y notificación por SMS si el fallo persiste.
Pasos inmediatos para aplicar hoy
- Crear bucket en región EU y una IAM con permisos mínimos
- Configurar plugin para backups incrementales diarios
- Activar alertas por email y Slack con checksum adjunto
- Programar restauración en staging trimestral
La evidencia apunta a que los equipos que practican restauraciones trimestrales reducen el tiempo medio de recuperación en más de un 40%.
Snippets y plantillas útiles
IAM policy mínima S3
json {"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":["s3:PutObject","s3:GetObject","s3:ListBucket"],"Resource":["arn:aws:s3:::mi-bucket-backups/*","arn:aws:s3:::mi-bucket-backups"]}]}
Script básico de backup
bash fecha=$(date +"%Y%m%d-%H%M") cd /var/www/wordpress mysqldump --single-transaction -u backupuser -p"pass" wp_database > /backups/db-$fecha.sql tar -czf /backups/site-$fecha.tgz wp-content sha256sum /backups/db-$fecha.sql > /backups/db-$fecha.sql.sha256 aws s3 cp /backups/site-$fecha.tgz s3://mi-bucket-backups/ --sse aws:kms
Plantilla email de alerta
Asunto: [Backup] {sitio} — {RESULTADO} | ID: {id}
Cuerpo:
Resultado: {RESULTADO} Sitio: {sitio} ID: {id} Destino: {destino} Tamaño: {tamaño} Tiempo: {duración} Checksum: {sha256} Logs: {url_logs} Runbook: {url_runbook}
Payload slack
json {"text":"Backup {sitio} — {RESULTADO}. ID:{id}. Logs: {url_logs}"}
Fuentes y referencias: documentación de AWS S3 para precios y regiones, y guías sobre cumplimiento RGPD. Para más información consultar GDPR guidance.
- Copias de seguridad para Divi: guía práctica y comparativa
- El error al cachear objetos con Redis deja datos viejos
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.