Una estrategia de backup por tenant para WordPress multi-tenant

Correr una flota de sitios de clientes en una sola instalación de WordPress es eficiente hasta el día en que alguien necesita un restore. Si tus herramientas de backup solo piensan en términos de “todo el server”, el error de un solo cliente se convierte en tiempo de inactividad para todos. Una estrategia de backup para multi-tenancy tiene que funcionar con la granularidad de un solo tenant: hacer backup, limpiar, hacer offload y restaurar cada cliente de forma independiente. Esta guía te muestra cómo diseñar esto con GrabWP Tenancy Pro.

Por qué los backups de flota necesitan granularidad por tenant

El punto clave del multi-tenancy es que los tenants comparten el código pero mantienen su data aislada. Tu estrategia de backup debería respetar ese mismo límite. Un snapshot de todo el server está bien para recuperarse de desastres, pero es la herramienta equivocada cuando el Cliente A borra una página y quiere recuperarla. Restaurar una imagen completa del server para arreglar un solo tenant significa revertir también los pedidos, comentarios y ediciones de todos los demás.

GrabWP Tenancy Pro trata a cada tenant como su propia unidad de backup. Un backup captura la database, los uploads, el contenido y la configuración de ese tenant; un restore reconstruye exactamente eso, y nada más. Eso significa que puedes recuperar al Cliente A a como estaba ayer, mientras el Cliente B sigue recibiendo registros esta mañana. Para las agencias y los servicios de hosting, esta es la diferencia entre un arreglo de cinco minutos y un incidente en toda la flota. También mantiene pequeño el radio de impacto: un mal restore solo puede afectar al tenant específico que seleccionaste.

Programación: valores predeterminados globales con excepciones por tenant

Los backups manuales no escalan más allá de un puñado de sitios, así que la programación es donde realmente empieza una estrategia de verdad. GrabWP te permite configurar valores predeterminados globales para los backups automáticos de los tenants y luego sobrescribirlos por tenant. Cada tenant tiene su propio estado de activación, programación y límite de retención, para que tu cliente principal pueda tener backups más frecuentes que un sitio tipo folleto de poco tráfico sin que tengas que administrar docenas de tareas cron a mano.

Las opciones de recurrencia cubren lo que la mayoría de las flotas necesitan: cada hora, dos veces al día, diario, semanal, quincenal y mensual. Elige una base global que tenga sentido, y luego aumenta la frecuencia para los tenants con mucho movimiento y redúcela para los más tranquilos.

La retención es la otra mitad de la programación. GrabWP limpia tanto los backups locales como los remotos después de una ejecución exitosa, guardando solo la cantidad de retención que configuraste. Esto mantiene controlado el uso del disco y evita que los backups antiguos se acumulen en silencio. Configura la retención por tenant para que una tienda con muchos cambios guarde un historial más profundo que un sitio estático. Elige números que se ajusten a tu propio presupuesto de almacenamiento y expectativas de recuperación en lugar de copiar un valor predeterminado genérico.

Seguridad externa con S3

Los backups que viven solo en el mismo server que los sitios que protegen no son realmente backups. GrabWP soporta almacenamiento remoto compatible con S3 para que los backups de cada tenant puedan salir del server. El registro de drivers te permite reutilizar las credenciales de S3 que ya tienes configuradas o proveer unas personalizadas para un bucket dedicado.

Algunas características hacen que esto sea práctico a escala de flota:

• El auto-offload inicia la subida a S3 inmediatamente después de que se completa un backup, para que no haya ningún momento en el que la única copia sea local.
• El pull-to-local descarga un backup remoto de S3 de vuelta al server cuando lo necesitas para un restore, lo que te permite mantener el server ligero y aun así recuperarte rápido.
• El borrado remoto desde la UI de la lista de backups te permite eliminar una copia en S3 sin salir del dashboard.
• Los límites de archivos por tenant limpian automáticamente los backups remotos antiguos una vez que un tenant supera la cantidad de archivos configurada en S3, manteniendo el almacenamiento remoto tan controlado como el almacenamiento local.

La lista de tenants muestra una etiqueta del driver de almacenamiento (S3 o Local) para que puedas ver de un vistazo qué tenants están protegidos de forma externa y cuáles no. Úsalo como una lista de control: ningún cliente debería quedarse solo en Local por mucho tiempo.

El flujo de trabajo del restore

Un backup que nunca has restaurado es una esperanza, no un plan. El restore de GrabWP es un proceso estructurado de varios pasos con una UI de progreso con AJAX, para que puedas ver cómo se completa cada etapa en lugar de quedarte mirando un spinner en blanco. El backup en sí se ejecuta como un trabajo de 7 pasos; el restore se ejecuta como un trabajo de 8 pasos, cubriendo la database, los uploads, el contenido y la configuración del tenant.

La página de restore te da dos pestañas. La pestaña de backups existentes restaura desde una copia que ya está en el disco, que es el camino común para “deshacer lo de ayer”. La pestaña de subida te permite restaurar desde un archivo de backup que traes al server, que es como mueves un tenant entre entornos o te recuperas desde una copia archivada. El restore cross-database está soportado entre distintos tipos de DB, así que un tenant capturado en un motor de base de datos puede reconstruirse en otro sin tener que editar dumps a mano.

Desde la UI de administración de backups puedes listar, descargar, borrar y restaurar backups locales previos, por lo que todo el ciclo de vida vive en un solo lugar. El hábito práctico que vale la pena adoptar: restaura periódicamente un tenant en un entorno de pruebas y confirma que vuelve a funcionar limpio. Así es como te enteras de que tu estrategia funciona antes de necesitarla.

Ten en cuenta el límite aquí. Este es el backup y restore por tenant dentro de GrabWP Tenancy Pro. El plugin gratuito separado GrabWP Restore es una herramienta diferente que reconstruye un archivo ZIP de exportación de la versión Pro en un sitio independiente. Úsalo cuando vayas a sacar a un tenant de la flota, no para la recuperación rutinaria de la flota.

Automatización con WP-CLI y Schedule Assurance

Todo lo anterior se puede programar. GrabWP incluye comandos de WP-CLI para ejecutar un backup, configurar la programación de un tenant, ver el estado junto al historial reciente, y reprogramar a todos los tenants a la vez. Esto convierte a los backups en una parte de primera clase de tus flujos de trabajo de aprovisionamiento y CI: despliegas un tenant, configuras su programación y sigues adelante. Reprogramar a toda la flota en un solo comando es muy útil después de cambiar tu política global.

La advertencia con cualquier programación en WordPress es WP-Cron, que solo se dispara cuando el sitio recibe tráfico. En un tenant tranquilo, un backup que “debería” correr a diario podría retrasarse. Schedule Assurance en los Pro Settings existe exactamente para esto: muestra el estado de WP-Cron, el próximo backup programado, los intervalos disponibles y, cuando WP-Cron está desactivado, una guía para conectar un cron del sistema real. La configuración confiable para una flota seria es desactivar WP-Cron y ejecutar wp en un crontab del sistema, para que los backups programados de los tenants se ejecuyan con un reloj fijo sin importar el tráfico.

Una estrategia base recomendada

Para resumir, aquí tienes un punto de partida razonable que puedes ajustar a tus propias necesidades de almacenamiento y recuperación:

1. Configura una programación global diaria como base, y luego aumenta la de los tenants ocupados (dos veces al día o cada hora) y reduce la de los más tranquilos (semanal).
2. Configura una cantidad de retención por tenant que coincida con el ritmo de cambios de cada tenant, de modo que las tiendas de alto tráfico guarden un historial más profundo.
3. Activa el auto-offload a S3 para cada tenant y configura un límite de archivos por tenant para que el almacenamiento remoto se limpie solo.
4. Controla las programaciones desde el cron del sistema con WP-Cron desactivado, y revisa Schedule Assurance después de cualquier cambio.
5. Prueba los restores regularmente reconstruyendo un tenant en un entorno de pruebas.

Eso te da una recuperación granular, almacenamiento limitado en ambos extremos y copias externas sin necesidad de supervisión constante.

El plugin base GrabWP Tenancy es gratis en WordPress.org, y el backup por tenant, la programación, el offload a S3 y el restore cross-database vienen con GrabWP Tenancy Pro a $9.99/month. Si todavía estás decidiendo cómo aislar la data de los tenants en primer lugar, lee nuestra guía complementaria sobre WordPress por tenant con MySQL dedicado vs SQLite.