Backups programados Multisite que reducen RTO y costes

¿Cuánto tiempo y cuánto coste asume una organización cuando un sub‑sitio crítico de WordPress Multisite queda inaccesible? Fallos en backups monolíticos o programaciones mal calibradas multiplican RTO y consumo de recursos, afectando rendimiento de la red y la factura del hosting.

Backups programados para Multisite: mejor opción en la mayoría de casos. Para redes Multisite con cambios frecuentes, la opción preferible suele ser la de backups programados automáticos que combinen copias incrementales, backup offsite cifrado y restauración granular por sub‑sitio; no obstante, si el proveedor de hosting ofrece snapshots offsite con RPO/RTO garantizados y pruebas de restauración documentadas, esas snapshots pueden ser una alternativa o complemento válido. Evaluar cada caso según RPO/RTO, rendimiento y costes antes de decidir.

Se recomienda programar según la frecuencia de cambios (diario o varias veces al día), monitorizar fallos y probar restauraciones periódicas para garantizar recuperación rápida. Siguiendo las plantillas y los comandos cron/WP‑CLI se despliega y valida la solución.

Resumen del proceso: pasos y objetivos

1. Planificar política de retención y RPO/RTO: definir frecuencias y destino.
2. Preparar baseline full: crear copia completa inicial y verificar checksums.
3. Implantar incrementales y throttling: programar cron/WP‑CLI y limitar I/O.
4. Enviar offsite cifrado: AWS/GCP/Azure o proveedor con SLA.
5. Probar restauraciones granulares: restaurar sub‑sitio en staging y documentar.

Paso 1: planificar política de retención y objetivos

La política de retención define cuánto histórico se guarda y cómo se recupera.
La política enlaza RPO (pérdida aceptable) y RTO (tiempo para volver a funcionar).
Definir estos números evita backups innecesarios y reduce costes operativos.

¿Qué RPO y RTO elegir según tamaño?

Pequeñas redes (<50 sitios) suelen aplicar RPO 24 h y RTO <12 h.
Redes medianas (50–500) usan RPO 4–12 h y RTO <6 h.
Grandes redes (>500) piden RPO <1 h y RTO <2 h en servicios críticos.

¿Cómo calcular almacenamiento y costes?

Estimar tamaño medio por sitio y multiplicar por número de sitios para dimensionar S3/GCS.
Configurar lifecycle rules para pasar a almacenamiento frío tras 30–90 días.
Controlar llamadas API y egress que encarecen la cuenta en AWS o GCP.

Proporcionar plantillas de retención ajustadas al tamaño de la red facilita gobernanza y control de costes.

• Ejemplos prácticos: para redes pequeñas (<50 sitios) una política válida puede ser: full semanal, incrementales diarios, retención diarios 14 días / semanales 8 semanas / mensuales 6 meses
• reglas de ciclo de vida en S3: mover a Standard‑IA tras 30 días y a Glacier tras 90 días. Para redes medianas (50–500 sitios): full quincenal, incrementales cada 4–12 h, retención diaria 30 días / semanales 12 semanas / mensuales 12 meses
• aplicar reglas de ciclo de vida que conviertan backups frecuentes a almacenamiento frío antes de 60–90 días para optimizar costes. Para redes grandes (>500 sitios y/o RPO exigente): full mensual, incrementales cada 1 h o replicación binlog, retención diaria 7–30 días con snapshots regionales y replicación multirregión
• usar políticas de retención por SLAs que prioricen servicios críticos y reduzcan retención de sitios no críticos para la reducción de costes de hosting

Indicar siempre RPO y RTO asociados a cada tier y reflejarlos en la regla de ciclo de vida del bucket (almacenamiento S3) para automatizar movimiento a clases más económicas.

Paso 2: preparar baseline full y copias incrementales

La copia full inicial es imprescindible para que los incrementales funcionen.
Sin baseline completo, los incrementales no se pueden reconstruir correctamente.
Verificar checksum y metadatos de cada backup tras la creación.

¿Qué incluir en el full inicial?

Incluir base de datos completa, mu‑plugins, themes activos y uploads por sitio.
Marcar y guardar metadatos: fecha, tamaño, checksum, lista de tablas incluidas.
Guardar un manifiesto JSON por backup con mapping de tablas por blog_id.

¿Cómo funcionan los incrementales en multisite?

Los incrementales guardan cambios en archivos y bloques de base de datos desde el último full.
Deben referenciar el ID del baseline para su aplicación correcta.
Controlar que las operaciones de la base de datos usen single‑transaction para consistencia.

Paso 3: implementar backups programados con cron y WP‑CLI

Usar cron y scripts evita depender de WP‑Cron en redes grandes y reduce fallos.
WP‑CLI aporta exportaciones y operaciones deserializadas que facilitan restauraciones.
Programar en ventanas de baja carga y usar bloqueo para evitar solapamientos.

¿Ejemplo práctico de crontab y script?

Crontab sugerido: ejecutar script a las 03:00 con logging rotado.
Ejemplo de entrada: 0 3 * * * /usr/local/bin/backup_multisite.sh >> /var/log/backup_multisite.log 2>&1
Usar flock o mecanismos similares para impedir ejecuciones concurrentes.

Bash LOCKFILE=/var/lock/backup_multisite.lock exec 200>$LOCKFILE flock -n 200 || exit 1 DATE=$(date +%F) mysqldump --single-transaction -h DB_HOST -u DB_USER -p'PASS' DB_NAME > /backups/full/db-$DATE.sql gzip /backups/full/db-$DATE.sql tar -czf /backups/full/files-$DATE.tar.gz wp-content mu-plugins themes --exclude='wp-content/cache' aws s3 cp /backups/full/ s3://mi-bucket/ --recursive --storage-class STANDARD_IA sha256sum /backups/full/* > /backups/metadata/checksums-$DATE.txt

¿Cómo usar WP‑CLI para tareas granulares?

WP‑CLI exporta contenidos por site y ejecuta search‑replace con soporte deserializado.
Comando útil: wp --url=sub.example.com export --dir=/tmp/exports --filename_format=subsite-{site_id}-%Y%m%d.xml
Para search/replace deserializado: wp search-replace 'old' 'new' --recurse-objects --all-tables

Para redes grandes es imprescindible cuantificar el impacto que generan los backups programados: calcular el tamaño total a respaldar como tamaño_medio_por_sitio × número_de_sitios y planificar I/O y egress en función de ese número. Por ejemplo, si el tamaño medio por sitio es 200 MB y la red tiene 500 sitios, el baseline full inicial puede ocupar ~100 GB; un mysqldump y un tar de archivos generarán picos de I/O y uso de CPU que pueden afectar a la latencia de las peticiones. Para minimizar el impacto conviene usar backups incrementales Multisite, aplicar throttling con ionice/pv/rsync --bwlimit, limitar concurrencia de multipart uploads a S3 y escalonar jobs por bloques de sitios.

Monitorizar con iostat, vmstat y métricas de la base de datos, y calcular el coste de egress a partir del volumen transferido hacia almacenamiento S3/GCS para estimar la reducción de costes de hosting si se reduce la frecuencia de fulls y se optimizan incrementales. Documentar estos números (IOPS promedio, MB/s transferidos, CPU % durante el backup) permite decidir ventanas y RTO aceptables.

Paso 4: restauración granular y pruebas documentadas

Restaurar solo un sub‑sitio exige extraer tablas wp_{blogid}_* y uploads del blog_id.
También exige reconciliar usuarios globales y deserializar opciones con cambios de dominio.
Probar la restauración en un entorno staging idéntico y medir tiempos reales.

¿Pasos básicos para restaurar un sub‑sitio?

Identificar blog_id y enumerar tablas asociadas antes de extraer.
Dump específico: mysqldump DB_NAME wp_3_posts wp_3_postmeta wp_3_options > subsite-3.sql
Copiar uploads: rsync -av /backups/uploads/sites/3/ /var/www/html/wp-content/uploads/sites/3/

¿Cómo tratar usuarios y colisiones?

Los usuarios son globales en Multisite; mapear IDs evita sobrescribir cuentas.
Si hay colisiones, exportar solo wp_usermeta relevante y usar scripts de reconciliación.
Registrar la relación de user_id original vs nuevo en el informe de restauración.

Una prueba de restauración granular debe ser reproducible y medible. Procedimiento resumido:

1. Elegir un sub‑sitio de prueba y anotar blog_id, tamaño de DB y uploads
2. En staging, restaurar dump específico: mysqldump DB_NAME wp_3_posts wp_3_postmeta wp_3_options > subsite-3.sql && mysql DB_STAGING < subsite-3.sql
3. Restaurar archivos: rsync -av --checksum /backups/uploads/sites/3/ /var/www/html/wp-content/uploads/sites/3/
4. Ejecutar WP‑CLI para ajustar URLs y serialized data: wp search-replace 'https://prod.example' 'https://staging.example' --url=sub.example.com --recurse-objects --all-tables
5. Verificar checklist: login admin, conteo de posts coincidente, integridad de media por checksum, formas y endpoints críticos con curl, pruebas funcionales básicas (crear post, subir media), tiempos medidos de inicio a servicio funcional para calcular RTO. Registrar resultados en un informe (timestamp, pasos, errores, checksum, duración) y repetir la prueba tras cambios en cron backups o en la configuración de offsite para validar la consistencia de las copias incrementales y la eficacia de las pruebas de restauración

Comparativa práctica: plugins, cron, S3 y hosting

La tabla compara criterios decisivos para elegir solución: programación, incrementales, restauración granular, límite de red, destino offsite, cifrado y coste estimado.

Flujo rápido de backups programados

Errores que arruinan el resultado

Confiar solo en backups alojados en el mismo servidor deja la red expuesta a fallo total de host.
Programar fulls frecuentes sin estrategia de retención dispara I/O y costes.
Asumir que "soporta Multisite" implica restauración por sub‑sitio suele ser incorrecto.

¿Qué pasa si falta el baseline full?

Los incrementales no se pueden aplicar y la restauración será incompleta.
La única solución suele ser recuperar el full desde copia antigua o generar un full nuevo.
Eso aumenta RTO y complica auditorías de cumplimiento.

¿Errores en tablas compartidas y serialización?

Ignorar tablas wp_sitemeta, wp_blogs y wp_##_options rompe la red al restaurar.
Cambios de dominio sin deserializar opciones provocan arrays corruptos.
Mapear tablas y usar wp‑cli search-replace con --recurse-objects evita estos fallos.

Cuándo no funciona este método y alternativas

Síntesis y recomendación accionable antes de desplegar

La recomendación es clara: implantar backups programados que combinen un full inicial, incrementales con checksum, almacenamiento offsite cifrado y pruebas periódicas de restauración por sub‑sitio.
Dimensionar ventanas de backup para minimizar I/O y aplicar throttling en redes grandes.
Formalizar una política de retención alineada con RPO/RTO y normativa (GDPR/LOPDGDD).

Para avanzar con una puesta en marcha segura, se ofrece diagnóstico técnico y plan de retención adaptado.

Preguntas frecuentes

¿Puedo usar un plugin para todo el proceso?

Sí, algunos plugins cubren cron, incrementales y destino offsite, pero hay que verificar la restauración por sub‑sitio.
No todos documentan el mapping de tablas por blog_id; confirmar antes de comprar.

¿Con qué frecuencia hacer backups en una red de sitios?

La opción práctica es incrementales cada 4 horas y full semanal.
Esto ofrece RPO aceptable sin costes extremos en I/O.

¿Cómo se prueba que un backup es válido?

Restaurando el backup en un entorno staging y validando login, posts y media.
Registrar RTO real y errores para la auditoría.

¿Es suficiente almacenar en el mismo datacenter?

No es suficiente.
El almacenamiento offsite evita pérdida por fallo físico del host o del datacenter.

¿Qué requisitos de cumplimiento hay en españa?

GDPR aplica y exige protección y trazabilidad de datos personales.
La LOPDGDD adapta el RGPD en España; conservar backups sin control puede vulnerar obligaciones.

¿Cuánto cuesta mantener backups para 100 sitios?

Coste variable; una estimación práctica: €500–€2.000/año según frecuencia y uso de snapshot vs S3.
El mayor coste suele ser egress y llamadas API en proveedores cloud.

¿Qué herramientas ayudan a automatizar

Algunas soluciones SaaS automatizan este flujo; otras requieren scripts WP‑CLI y dump/rsync.
Verificar que el proveedor documenta y prueba el proceso.

Cierre con pasos prácticos finales

Comprobar ahora el último backup: revisar timestamp, checksum y metadatos.
Programar una prueba de restauración de un sub‑sitio en staging y documentar el resultado.
Si se necesita respaldo técnico para diseñar el plan, la revisión técnica puede incluir scripts cron/WP‑CLI, policy templates y pruebas reproducibles.

Los datos muestran el contexto:

• el RGPD está en vigor y exige control sobre datos personales
• en la actualidad WordPress supera el 43% de cuota de mercado según W3Techs
• Actualmente, UpdraftPlus acumula más de 3 millones de instalaciones activas en WordPress.org

La evidencia obliga a diseñar backups que cumplan normativas y ofrezcan restauración comprobada.

• Reduce downtime con seguridad WordPress Multisite y backups
• Validación de seguridad post-actualización en WordPress

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.