Multisite: backup centralizado o por sitio, qué elegir

¿Le resulta frustrante no saber si hacer backups a nivel de red o por cada site en un WordPress Multisite? ¿Se precisa recuperación rápida de un cliente o reducir costes de almacenamiento sin sacrificar cumplimiento? Aquí se ofrece la solución directa y accionable para decidir entre backup centralizado y backup por sitio en Multisite.

Prepárate para tomar una decisión basada en RTO, RPO, costes y requisitos legales, con pasos concretos y comandos útiles para implementar la opción elegida.

Multisite: ¿backup centralizado o por sitio? en 60 segundos

• Si se necesita restauración rápida y granular, elegir backup por sitio. Permite RTO bajo y recuperaciones selectivas.
• Si la prioridad es simplicidad y coherencia, elegir backup centralizado. Copia base de datos y ficheros de red de forma completa y menos compleja.
• Para ahorrar almacenamiento y optimizar RPO, combinar snapshots del servidor con backups incrementales centralizados. Híbrido recomendado para redes grandes.
• En cumplimiento GDPR y separación de datos de clientes, backup por sitio o particionado es más seguro. El control de retenciones por cliente es crítico.
• Si hay clientes distintos con SLAs propios, el backup por sitio suele valer la pena. Evita conflictos de retención y simplifies restauraciones.

Por qué esta decisión importa para Multisite: ¿backup centralizado o por sitio?

WordPress Multisite comparte base de datos y archivos entre múltiples sitios; eso cambia la estrategia de copias de seguridad respecto a un single-site. La decisión impacta directamente en tiempos de recuperación (RTO), frecuencia de backups (RPO), coste de almacenamiento, cumplimiento legal y la complejidad técnica de restauración.

Se incluyen referencias prácticas a herramientas y documentación: la guía oficial de Multisite en WordPress: WordPress.org: create a network, el manual de WP-CLI: WP-CLI y la referencia de mysqldump: MySQL: mysqldump.

Arquitectura básica que condiciona la elección

• La base de datos utiliza tablas compartidas (wp_blogs, wp_site) y tablas por site (wp_2_posts, wp_3_posts...).
• Los ficheros media suelen almacenarse en /wp-content/uploads/sites/X/ para cada site.
• Algunos plugins comparten datos entre sites; otros mantienen tablas propias por site.

Comprender este mapeo es imprescindible para restauraciones selectivas.

Centralizado vs por sitio para restauración rápida

¿Qué significa restauración rápida en Multisite?

Restauración rápida es recuperar un site funcional en el menor tiempo posible tras un incidente. La métrica clave es RTO (objetivo de tiempo de recuperación).

Ventajas del backup por sitio para RTO

• Restauración granular: solo restauran tablas wp_## y uploads del site afectado.
• Menor tiempo de recuperación real al no tocar la base de datos global completa.
• Menor riesgo de romper otros sites al evitar restaurar tablas globales.

Ventajas del backup centralizado para RTO

• Proceso coherente: restauración de toda la red puede ser más rápida si se dispone de snapshots completos del servidor (imagen del disco + base de datos completa).
• Menos pasos manuales cuando el fallo afecta a la infraestructura global (por ejemplo corrupción de tablas globales).

Cómo recuperar un solo site desde backup centralizado (pasos resumidos)

1. Extraer del backup central la copia de la base de datos y localizar las tablas del site: wp_{blog_id}posts, wppostmeta, wp_options, etc.
2. Extraer uploads del path /wp-content/uploads/sites/{blog_id}/
3. Importar tablas específicas con mysqldump o mysql y ajustar el prefijo si es necesario.
4. Ejecutar búsquedas y reemplazos con WP-CLI para ajustar URLs: wp search-replace 'https://old' 'https://new' --url=site.example.com.

Comandos útiles (indicativos):

• Exportar tablas del site desde dump completo:

mysqldump -u user -p --single-transaction --quick --lock-tables=false dbname wp_2_* > site2_tables.sql

• Exportar uploads:

tar -czf site2_uploads.tar.gz wp-content/uploads/sites/2/

• Importar tablas específicas:

mysql -u user -p dbname < site2_tables.sql

(Estos comandos son indicativos y deben adaptarse al entorno y permisos del hosting.)

Comparativa técnica: centralizado vs por sitio (tabla)

¿Qué opción reduce costes de almacenamiento en Multisite?

La reducción de costes depende del tamaño relativo de la base de datos global vs los uploads por site y de la estrategia (full vs incremental vs snapshot).

• Snapshots a nivel de servidor suelen ser eficientes para RPO si se usan incremental snapshots del almacenamiento (ej: LVM, ZFS, AWS EBS snapshots). Reducen costes cuando se retienen pocos puntos.
• Backups incrementales por sitio reducen duplicidad de datos y son adecuados si se mide que solo un 10-20% del contenido cambia entre copias.
• Backup centralizado con deduplicación en soluciones profesionales (Veeam, Bacula, restic con almacenamiento compatible) puede ser más barato que múltiples backups por site si existe mucha duplicidad.

Recomendación indicativa (2026): para redes con >50 sites, usar snapshot central combinado con backups incrementales por site para los 10-20 sitios críticos.

¿Centralizado o por sitio para cumplimiento y GDPR?

• Backup centralizado: obliga a definir políticas internas claras sobre acceso, retención y pruebas de borrado. La mezcla de datos de clientes complica la obligación de atender solicitudes de supresión.
• Backup por sitio o particionado: facilita aplicar retenciones específicas por cliente y probar cumplimiento. Si un cliente exige eliminación completa, es más sencillo demostrar que los datos se han purgado si los backups están separados.

Normativa y referencias: la información del RGPD y borrado debe considerarse junto a la política de retención; ver guía práctica: gdpr.eu.

Consejo legal técnico: documentar las políticas de retención y los procesos de purgado para incluirlos en contratos con clientes y en auditorías.

Multisite: copias incrementales centralizadas o por sitio?

• Incrementales centralizadas: hacen snapshot de la base de datos completa y solo guardan cambios. Requieren herramientas que soporten deduplicación y restauración de tablas individuales.
• Incrementales por sitio: ejecutan rsync/rsnapshot o backups de BD por export de tablas y guardan solo diffs por site. Más trabajo operativo pero granularidad máxima.

Técnicas recomendadas:

• Usar binlogs de MySQL para replicación de cambios y recovery point objectives más ajustados.
• Aplicar herramientas como restic o Borg para deduplicación eficiente de ficheros.
• Automatizar exportaciones de tablas por site con scripts que usen mysqldump o mydumper para alta velocidad.

Vale la pena backup por sitio para clientes distintos?

Sí, cuando existen requisitos contractuales o SLAs que exigen:

• Retenciones distintas por cliente.
• Restauraciones individuales frecuentes.
• Separación legal de datos (por ejemplo agencias que gestionan contenidos de terceros).

Si la red es de sitios normales sin requisitos legales o SLAs, el coste operativo puede no justificar backups por sitio. En casos mixtos, una estrategia híbrida (centralizado + backups por sitio solo para clientes críticos) suele ser la mejor relación coste-beneficio.

Procedimiento práctico para restaurar un site desde backup de red (pasos detallados)

Paso 1: identificar el blog_id

• En la base de datos, consultar wp_blogs para obtener blog_id del site afectado.

Paso 2: extraer tablas del backup completo

• Usar mysqldump con patrón: mysqldump dbname wp_123_* > site123.sql

Paso 3: extraer uploads

• Extraer /wp-content/uploads/sites/123/ del snapshot o backup central.

Paso 4: importar y ajustar URLs

• Importar las tablas con mysql
• Ejecutar wp search-replace para corregir URLs y rutas si cambia dominio

Paso 5: pruebas de integridad

• Revisar posts, imágenes incrustadas y enlaces rotos
• Ejecutar comprobación de permisos de archivos

Flujo decisionable para elegir estrategia

Balance estratégico: lo que ganas y lo que arriesgas con Multisite: ¿backup centralizado o por sitio?

Cuándo es tu mejor opción ✅

• Backup centralizado: redes pequeñas, equipo limitado, necesidad de coherencia en restauraciones completas.
• Backup por sitio: clientes con SLAs, necesidad de restauración granular, cumplimiento de retenciones.
• Estrategia híbrida: redes medias-grandes con 10-20 sites críticos.

Puntos críticos de fracaso ⚠️

• No probar restauraciones periódicas: los backups sin test restores son inútiles.
• No documentar retenciones y accesos: riesgo GDPR.
• Ignorar dependencias entre plugins o tablas compartidas: restauración parcial puede romper integridad.

Script básico para exportar tablas de un site (indicativo)

#!/bin/bash

DB_USER="user"

DB_PASS="pass"

DB_NAME="dbname"

BLOG_ID=12

mysqldump -u${DB_USER} -p${DB_PASS} --single-transaction --quick --lock-tables=false ${DB_NAME} $(mysql -u${DB_USER} -p${DB_PASS} -N -B -e "SHOW TABLES LIKE 'wp_${BLOG_ID}_%';" ${DB_NAME}) > site${BLOG_ID}_tables.sql

(Este script es indicativo; adaptar credenciales y asegurar no almacenar contraseñas en claro.)

Lo que otros usuarios preguntan sobre Multisite: ¿backup centralizado o por sitio?

Cómo recuperar solo un site desde un backup central

Restaurar solo las tablas wp_{id}_* y los uploads del site; luego ejecutar wp search-replace para corregir URLs. Contexto: requiere identificar dependencias entre tablas globales y locales.

Por qué un backup por sitio reduce riesgos legales

Porque facilita aplicar políticas de retención y eliminar datos específicos de un cliente sin tocar backups de otros.

Qué pasa si se restaura la base de datos completa en una red activa

Puede sobrescribir cambios recientes de otros sites; siempre probar en entorno staging antes de restaurar en producción.

Cómo minimizar costes usando backups incrementales

Usar snapshots del almacenamiento con deduplicación y combinar con backups incrementales por site para los más críticos.

Cuál es la mejor herramienta para backups en Multisite

Depende del entorno: para hosting gestionado se recomiendan soluciones del proveedor; para VPS/Cloud, restic, Borg, Veeam o soluciones gestionadas que soporten MySQL y ficheros.

Elección óptima y beneficio a largo plazo

La mejor estrategia depende de objetivos claros: si la prioridad es recuperación granular y cumplimiento, elegir backup por sitio (o híbrido). Si la prioridad es simplicidad operativa con restauraciones completas frecuentes, el backup centralizado es más eficiente. A largo plazo, la política que combine snapshots, backups incrementales y pruebas de restauración periódicas ofrece el mejor equilibrio entre coste, velocidad y cumplimiento.

Plan de acción rápido: pasos para ver resultados en 10 minutos

1. Identificar 3 sites críticos y obtener su blog_id desde la tabla wp_blogs.
2. Ejecutar un mysqldump de las tablas de uno de esos sites y empaquetar su uploads (comando ejemplo provisto).
3. Configurar una política de retención mínima y programar un test restore mensual para ese site.

• Cómo usar backups incrementales en Multisite sin riesgos
• Traslada tu WordPress Multisite sin romper URLs ni ventas

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.