Un backup mal configurado puede dejar una tienda WordPress horas o días inaccesible y generar miles en pérdidas; muchos responsables técnicos subestiman la coherencia entre discos y base de datos, la encriptación offsite y los permisos IAM, lo que provoca restauraciones fallidas y costes inesperados.
Backup en Google Cloud Platform: Implementar backups robustos en GCP para WordPress combina Cloud SQL backups, snapshots de Persistent Disk y exportes a Cloud Storage; automatiza con Cloud Scheduler/Cloud Functions o Terraform, cifra con CMEK/Cloud KMS, aplica IAM mínimo y lifecycle para ahorrar costes. Así consigues RTO/RPO predecibles, pruebas de restauración y control de costes, ideal para quien planifica, audita o automatiza.
Resumen del proceso
Este resumen permite ejecutar un plan en pocas horas y verificarlo en menos de 48 horas.
- Exportar la base de datos de Cloud SQL de forma coherente (gcloud sql export o backups gestionados).
- Hacer snapshot de Persistent Disk o sincronizar ficheros a Cloud Storage.
- Automatizar con Cloud Scheduler y Cloud Functions o usar Terraform para recursos y políticas.
- Aplicar lifecycle rules y cifrado CMEK; vigilar integridad con checksums y alertas.
Prioridad: definir RTO y RPO
Definir RTO y RPO guía la frecuencia y el método.
Para entornos críticos conviene definir un objetivo concreto de RTO y RPO acorde al negocio (por ejemplo RTO ≤ 60 minutos, RPO ≤ 15 minutos), y luego validar que la combinación de soluciones (backups gestionados de Cloud SQL, export SQL, snapshots de Persistent Disk) logra esos objetivos; la tabla comparativa ofrece rangos estimados que deben contrastarse con pruebas de restauración reales porque la RPO efectiva puede variar entre 5 y 60 minutos según la configuración y la frecuencia de exportes.
Resultado objetivo en 48 horas
Al completar los pasos se obtiene un pipeline automatizado y probado listo para restauración.
Paso 1: copia coherente de la base de datos
La copia coherente de la base de datos evita pérdida de transacciones y corrupción en restauración.
Cloud SQL ofrece backups gestionados y exportaciones SQL; las restauraciones punto en el tiempo (PITR) requieren habilitar binary logging y configurar la retención de binlogs además de backups gestionados. Las exportaciones SQL generan ficheros portables útiles para migración y verificación, pero no sustituyen a PITR si no se dispone de binlogs configurados.
Para coherencia, exportar con gcloud sql export antes, o pausar la escritura temporalmente durante el snapshot de ficheros.
Backup gestionado vs export SQL
El backup gestionado guarda copias incrementales automatizadas y facilita restauraciones punto en el tiempo.
La exportación SQL produce un fichero .sql legible y portable, útil para verificaciones y migraciones.
Comando gcloud para exportar SQL
Ejemplo reproducible que exporta una base de datos a un bucket en la región correcta.
Bash
gcloud sql export sql INSTANCE gs://BUCKET_NAME/backup-$(date +%F-%H%M).sql.gz /
--database=wordpress --offload
Comprobación de integridad de la exportación
Calcular checksum del .sql.gz detecta corrupción en la transferencia.
Un checksum simple con sha256 permite comparar origen y destino tras la copia.
Guía práctica: habilitar backups gestionados y exportes
Para garantizar restauraciones con RTO y RPO definidos conviene combinar backups gestionados de Cloud SQL con export SQL automatizados a Cloud Storage. Primero habilite los backups automáticos desde la instancia Cloud SQL (console o gcloud) y, si necesita Point‑In‑Time Recovery (PITR), active binary logging y configure la retención de binlogs adecuada; sin binary logging no podrá recuperar transacciones entre backups. Después automatice exportes periódicos con Cloud Scheduler + Cloud Functions (o un job en Build) que invoque gcloud sql export sql INSTANCE gs://BUCKET/backup-$(date +%F-%H%M).sql.gz para tener copias portables además de los backups gestionados. Use Terraform para versionar recursos (google_sql_database_instance, google_storage_bucket y google_cloud_scheduler_job) y documente el RTO y RPO objetivo en los metadatos del bucket para facilitar pruebas de restauración y auditoría.
Paso 2: ficheros y snapshots de disco
Los ficheros de WordPress requieren copias coherentes que incluyan uploads, themes y plugins.
Los snapshots de Persistent Disk son rápidos, pero son crash‑consistent, no transaccionales.
Por eso conviene combinar snapshot con export SQL o rsync coherente.
Snapshot de Persistent Disk
Crear snapshot con gcloud es directo y rápido para discos de Compute Engine.
Ejemplo de comando para snapshot del disco principal.
Bash
gcloud compute disks snapshot DISK_NAME /
--project=PROJECT_ID --zone=ZONE --snapshot-names=wp-snapshot-$(date +%F-%H%M)
Sincronizar archivos a Cloud Storage
Rsync a Cloud Storage con gsutil o usar rsync hacia un bucket reduce tiempo de restauración en instancias nuevas.
Ejemplo de sincronización segura con gsutil.
Bash
gsutil -m rsync -r /var/www/html gs://BUCKET_NAME/backups/files/$(date +%F-%H%M)/
Casos prácticos por arquitectura: GKE
Las estrategias cambian según arquitectura: en Compute Engine + Cloud SQL combine snapshots de Persistent Disk para ficheros con export SQL; en GKE + Filestore use snapshots de Filestore (o exporte contenido a Cloud Storage) y confirme coherencia con una exportación SQL del servicio de base de datos (Cloud SQL o external MySQL). Para App Engine standard, centralice assets en Cloud Storage y dependa de backups gestionados de Cloud SQL, exportando periódicamente objetos críticos y aplicando lifecycle rules. En todos los casos ajuste expectativas de RTO/RPO: Filestore snapshots restauran ficheros rápido pero requieren sincronización con la base de datos para evitar pérdida de transacciones; documente procedimientos de restauración y pruebas de restauración por arquitectura y automatícelos con Cloud Scheduler, Cloud Functions y Terraform para reproducir infraestructuras de ensayo.
Automatizar reduce errores humanos y garantiza ejecución regular y verificable del pipeline de backups.
Terraform crea buckets, roles y jobs de Cloud Scheduler para mantener infraestructura reproducible.
Cloud Functions orquesta export SQL, snapshots y copia de objetos entre buckets cuando sea necesario.
Recurso mínimo: bucket, cuenta de servicio, rol y job de scheduler. Ejemplo simplificado.
Hcl
resource "google_storage_bucket" "backups" {
name = "project-backups-bucket"
location = "europe-west1"
versioning { enabled = true }
}
resource "google_service_account" "backup_sa" {
account_id = "backup-sa"
}
Cloud Scheduler lanza una Cloud Function que ejecuta gcloud sql export y snapshot.
Hcl
resource "google_cloud_scheduler_job" "daily_backup" {
name = "daily-backup"
schedule = "/15 * * * " # cada 15 minutos como ejemplo
http_target { uri = google_cloud_function.backup_function.https_trigger_url }
}
Flujo de backup
Flujo mínimo recomendado de backup
1. Cloud Scheduler
2. Cloud Function (orquestador)
3. Export SQL → Cloud Storage
4. Snapshot PD → Snapshot bucket
5. Lifecycle rules y alertas
Comparativa: plugins frente a soluciones nativas
La elección entre plugin y solución nativa debe basarse en RTO, RPO, coste y coherencia de la base de datos.
Las soluciones nativas ofrecen RTO y RPO más predecibles y mayor control sobre cifrado y permisos.
Los plugins son prácticos pero con RPO/RTO menos garantizados y pruebas de restauración más complejas.
Tabla comparativa técnica y de costes
| Solución |
RTO estimado (min) |
RPO estimado |
Coste mensual aprox. (€) |
Consistencia DB |
| Cloud SQL backups + PD snapshots |
10–60 |
5–60 min |
50–300 |
Sí (si se usa export coherente) |
| Backup and DR (servicio) |
10–30 |
5–30 min |
200–600 |
Sí |
| UpdraftPlus a Cloud Storage |
30–1440 |
30 min–24 h |
5–50 |
No (sin export SQL) |
| rsync + mysqldump a Cloud Storage |
30–120 |
15 min–6 h |
10–100 |
Sí (si se hace mysqldump coherente) |
Criterios prácticos para decidir
Elegir nativo cuando se necesiten RTO/RPO predecibles y cumplimiento legal.
Elegir plugin cuando el coste limitado y la simplicidad sean prioritarios y el sitio no sea crítico.
Error frecuente de evaluadores
El error más frecuente en este punto es elegir un plugin por ahorro sin validar restauraciones.
Esa decisión provoca fallos en pruebas y tiempos de recuperación mayores del esperado.
Playbook de restauración probado con tiempos
Un playbook claro reduce el tiempo de recuperación y evita pasos improvisados.
La secuencia es: restaurar base de datos, restaurar ficheros, ajustar configuración y validar con pruebas funcionales.
Con backups frecuentes y tamaño medio (1–10 GB), importar SQL suele tomar entre 5 y 20 minutos.
Pasos cronológicos para Compute Engine
Restaurar Cloud SQL desde backup o importar SQL al servicio gestionado.
Adjuntar snapshot del disco a una instancia nueva o restaurar ficheros desde Cloud Storage.
Actualizar wp‑config.php, ejecutar wp‑cli search‑replace y reiniciar servicios web.
Comandos de restauración útiles
Ejemplo de importación SQL con gcloud.
Bash
gcloud sql import sql INSTANCE gs://BUCKET_NAME/backup-2024-05-01.sql.gz --database=wordpress
Ejemplo para crear disco desde snapshot.
Bash
gcloud compute disks create wp-disk-restore --source-snapshot=wp-snapshot-2024-05-01 --zone=ZONE
Verificación post‑restore
Comparar checksums de ficheros y tamaño de base de datos confirma integridad.
Ejecutar pruebas funcionales básicas: login admin, compra de prueba, carga de imágenes.
Seguridad, permisos y cifrado para backups
Dar permisos mínimos reduce el riesgo de exposición de backups.
Usar cuentas de servicio con roles concretos, no permisos amplios por defecto.
CMEK con Cloud KMS permite que el cliente controle la clave de cifrado en reposo.
Roles IAM mínimos recomendados
Para el pipeline: storage.objectAdmin en el bucket de backups y roles/cloudsql.client para exportes.
Evitar roles como owner o editor en cuentas de servicio de backup.
Configurar CMEK y KMS
Crear key ring en la región y usar clave CMEK para buckets sensibles.
Cifrar en tránsito y en reposo cumple requisitos de RGPD y de la AEPD.
Caso práctico anónimo
Un caso habitual: una tienda con backups solo de ficheros sufrió pérdida de transacciones tras restaurar usando solo snapshots.
El resultado fue pérdida de pedidos por falta de export coherente de la base de datos.
Recomendaciones concretas de IAM y gestión de secretos
Para minimizar riesgo es mejor asignar roles IAM mínimos a la cuenta de servicio que ejecuta los backups: storage.objectCreator/storage.objectViewer para escribir y listar objetos en el bucket de backups, storage.objectAdmin solo para tareas de retención/versionado si es necesario, y roles/cloudsql.client (+ permiso específico de exportación) para Cloud SQL. Evite claves JSON a largo plazo: use Workload Identity para Cloud Functions y Cloud Scheduler o asigne la cuenta de servicio directamente sin exportar claves. Para CMEK y Cloud KMS asigne el rol roles/cloudkms.cryptoKeyEncrypterDecrypter exclusivamente a la cuenta que realiza las operaciones de escritura; registre y rote las claves periódicamente. Finalmente, audite bindings con IAM Conditions cuando quiera limitar accesos por proyecto, servicio o rango horario y registre accesos en Audit Logs junto a checksums e integridad de cada backup.
Retención y optimización de costes en cloud storage
Mover objetos antiguos a Nearline o Coldline reduce costes manteniendo opción de recuperación.
Una regla típica es 30/90/365 días para Nearline, Coldline y Archive.
Esto reduce costes de almacenamiento a largo plazo en más de la mitad frente a mantener todo en Standard.
Reglas lifecycle ejemplo
Regla de mover a Nearline a 30 días, Coldline a 90 días, Archive a 365 días.
Aplicar versionado y borrar versiones antiguas tras periodo legal necesario.
Selección de región por soberanía
Elegir europe‑southwest1 o europe‑west1 según requisitos de residencia de datos.
Documentar ubicación en el registro de tratamiento para cumplir RGPD y LOPDGDD.
Monitorización, alertas e integridad
Vigilar que los jobs de backup se ejecutan según lo programado evita sorpresas.
Configurar alertas en Monitoring para fallos de export, errores de snapshot y transferencias.
Verificar checksums y alertar si un checksum difiere entre origen y destino.
Comprobaciones automáticas
Una Cloud Function puede calcular sha256 de los objetos y escribir resultados en BigQuery o Pub/Sub.
Alertas por correo o Slack notifican fallos críticos en menos de 5 minutos.
Integración con auditoría y cumplimiento
Conservar registros de auditoría y accesos por al menos el periodo legal aplicable.
La AEPD recomienda documentar accesos y transferencias de datos personales según RGPD (aplicable desde el 25 de mayo de 2018).
Errores que arruinan el resultado
No probar la restauración es la causa más común de fallos en recuperación.
Dar permisos excesivos a cuentas de servicio expone las copias y las claves KMS.
Confiar solo en plugins que copian ficheros sin export coherente de la base de datos lleva a inconsistencias.
Pruebas de restauración insuficientes
Muchas organizaciones no realizan restauraciones periódicas y descubren fallos en el desastre real.
Se recomienda probar restauraciones completas al menos cada trimestre.
Permisos y secretos mal gestionados
Almacenar claves en cuentas con permisos globales provoca riesgos que no se detectan hasta un incidente.
Rotar claves y revisar roles cada 90 días reduce exposición.
Cuándo no funciona este método / alternativas
Este enfoque no es recomendable si se usa un servicio 'managed' de WordPress que ya incluye backups verificados y SLA que cubran RTO/RPO requeridos. Tampoco conviene para sitios estáticos muy pequeños donde el proveedor ofrece snapshots automatizados sin coste adicional. Si el equipo no puede asumir la complejidad operativa o el coste de GCP, escoger un plan gestionado con pruebas de restauración regulares resulta más barato y seguro.
Síntesis final y siguientes pasos
La entrega práctica es clara: definir RTO/RPO, garantizar coherencia de la base de datos y automatizar con Terraform y Cloud Functions.
Aplicar lifecycle rules reduce costes al mover datos a Nearline/Coldline/Archive según antigüedad; por su parte, cifrado con CMEK (Cloud KMS) aporta control sobre las claves y cumplimiento normativo, pero no reduce directamente el coste de almacenamiento. Ambas prácticas son complementarias: lifecycle rules optimizan gasto y CMEK refuerza gobernanza y cumplimiento.
Comprobar restauración completa en un entorno de ensayo en menos de 48 horas valida todo el pipeline.
Para comprobar diseño y restauración en 24–48 horas, se puede contratar una auditoría técnica que ejecute pruebas de restauración y entregue un plan de mejoras detallado.
Preguntas frecuentes
¿Cómo hago backup de WordPress en Google Drive?
Sí se puede hacer respaldo a Google Drive usando rclone o plugins que soporten Drive.
Primero exportar la base de datos con gcloud sql export o mysqldump y luego sincronizar ficheros con rclone.
Tenga en cuenta que la sincronización típica ofrece RPO de 6–24 horas según frecuencia.
¿Puedo usar solo snapshots de disco para backups?
No, los snapshots son crash‑consistent y no garantizan coherencia transaccional.
Combinar snapshot con export SQL o backups gestionados de Cloud SQL asegura que no falten transacciones.
¿Qué roles IAM necesita la cuenta de backup?
La cuenta de backup necesita storage.objectAdmin para buckets y permisos limitados de Cloud SQL para exportes.
Evitar dar owner o editor; aplicar separación de funciones y revisión periódica.
¿Cómo reduzco costes de almacenamiento de backups?
Mover objetos antiguos a Nearline/Coldline/Archive según 30/90/365 días reduce costes a largo plazo.
Usar lifecycle rules y desactivar versionado innecesario baja el gasto mensual.
¿Con qué frecuencia probar restauraciones?
Probar restauraciones completas al menos cada tres meses.
En entornos críticos evaluar pruebas mensuales y verificar que RTO objetivo se cumple.
¿Qué opciones hay para entornos en España?
Usar regiones europeas como europe‑southwest1 garantiza residencia de datos y reduce latencia.
Documentar la región en el registro de tratamiento para cumplir RGPD y LOPDGDD.
¿Qué hago si la copia está corrupta al restaurar?
Si el checksum difiere, restaurar desde una copia anterior y revisar logs de transferencias.
Mantener múltiples versiones en buckets y registrar metadatos ayuda a elegir la mejor versión.
Documentación oficial de Cloud SQL
Preguntas finales y pasos recomendados
Para poner en marcha: definir RTO/RPO, crear bucket con versionado y lifecycle, habilitar backups gestionados de Cloud SQL, programar exportes frecuentes y automatizar con Cloud Scheduler o Terraform.
Vigilar integridad con checksums, auditar IAM y probar restauraciones en un entorno de ensayo.
La evidencia indica que los planes con pruebas periódicas reducen fallos en recuperación en más del 50% cuando se aplican correctamente.
