Cuando la actualización de un cliente rompe su sitio: Cómo recuperar un solo tenant sin tocar al resto
Todo freelancer que gestiona sitios de clientes ha recibido alguna vez este mensaje: “el sitio está caído y no toqué nada”. Por lo general algo sí cambió, un plugin se actualizó automáticamente, una edición salió mal, un cambio de theme rompió el diseño, y ahora un cliente está esperando mientras descubres cómo deshacerlo. Si tu única opción es reconstruir a mano o hacer un restore de un backup de todo el server que también revierte a tus otros clientes, un solo sitio roto se convierte en una tarde de riesgos.
Esta guía cubre la etapa de recuperación en el ciclo de vida del sitio de un cliente: cómo hacer que un sitio vuelva a un estado funcional conocido de forma rápida, sin alterar nada más de lo que administras. Es la red de seguridad del flujo de trabajo de mantenimiento desde un dashboard, porque la razón por la que puedes actualizar con confianza es porque sabes que puedes revertir los cambios limpiamente.
Por qué la recuperación es riesgosa en una configuración compartida
La forma en que la mayoría de los freelancers alojan a sus clientes hace que la recuperación sea una apuesta de todo o nada:
- Un backup del server abarca a todos. Si todos tus clientes comparten una instalación y haces un restore del backup completo de anoche, también deshaces los cambios de hoy de todos los demás clientes. Arreglar un sitio rompe otros cuatro.
- La reparación manual es lenta bajo presión. Reconstruir un sitio roto a mano, o investigar qué actualización de un plugin causó la falla, es exactamente la tarea equivocada para hacer mientras un cliente observa.
- Puede que no tengas un punto de restore reciente. Si los backups son manuales, la última copia buena podría tener una semana de antigüedad, por lo que la recuperación implica perder trabajo real incluso cuando tiene éxito.
El objetivo es recuperar el sitio de un solo cliente, desde un backup reciente, en cuestión de minutos, mientras todos los demás sitios que administras se mantienen tal como estaban.
Recupera un tenant, deja los demás tranquilos
GrabWP Tenancy Pro aloja a cada cliente como un tenant aislado con su propia database y contenido, y su backup y restore se ejecutan por tenant. Ese aislamiento es el objetivo principal durante la recuperación: hacer el restore de un cliente solo afecta a ese cliente.
Ya tienes puntos de restore

Si seguiste el flujo de mantenimiento y activaste los backups automáticos programados, la recuperación comienza desde una buena posición. Esos backups te dieron puntos de restore recientes en un horario que tú elegiste, desde cada hora hasta cada mes, con las copias antiguas eliminadas de forma automática. Cuando un sitio se rompe, no estás corriendo para encontrar un backup, sino que estás eligiendo cuál de los recientes vas a usar para el restore.
Revierte usando los propios backups del tenant

Desde la pantalla de restore del tenant, Pro te permite listar, descargar, eliminar y restaurar backups previos almacenados en el disco, con pestañas de restore para elegir un backup existente o subir un archivo nuevo. Seleccionas el último backup bueno conocido y ejecutas el restore. El flujo de restore de 8 pasos cubre la database, las subidas, el contenido y la configuración del tenant, con una interfaz de progreso AJAX para que puedas ver cómo se completa cada paso en lugar de adivinar si funcionó.
Como el restore está limitado a ese único tenant, ninguno de tus otros clientes se ve afectado. El sitio roto vuelve a su estado funcional, y el resto de tu cartera sigue operando.
Recupera incluso entre distintos tipos de database
El restore de Pro funciona entre tipos de database, por lo que un tenant se puede restaurar entre MySQL compartido, MySQL dedicado y SQLite. Si moviste a un cliente entre estructuras de database durante el mantenimiento, un backup sigue siendo útil. El sitio no está bloqueado a la configuración exacta en la que fue capturado.
Cuando el problema es el propio server
Los backups programados se pueden enviar a un almacenamiento de objetos compatible con S3 después de cada ejecución, con aislamiento por tenant en el lado del almacenamiento. Si la falla es mayor que una mala actualización, como un problema de disco o del host, todavía tienes copias externas del sitio de cada cliente desde las cuales hacer un restore, en lugar de depender del mismo server que te acaba de fallar.
Un manual de recuperación en el que puedes confiar
Al juntar todas las piezas, la recuperación se convierte en una rutina en lugar de algo aterrador:
- Confirma el alcance. Solo el sitio de ese cliente está afectado, porque los tenants están aislados. No vas a tocar a nadie más.
- Elige un punto de restore. Los backups programados significan que ya existe una buena copia reciente en el disco o en S3.
- Restaura ese tenant. Ejecuta el restore de 8 pasos desde la pantalla de restore del tenant y observa cómo se completa.
- Verifica y sigue adelante. Comprueba que el sitio del cliente funciona, dile al cliente que está solucionado, y tus otros clientes nunca se enterarán de que algo pasó.
La experiencia para el cliente es una interrupción corta y un arreglo rápido en lugar de un día perdido, y tu exposición es de un sitio en lugar de toda tu instalación.
La recuperación cierra el ciclo de vida
Ser capaz de recuperar a un cliente limpiamente es lo que hace que el resto del flujo de trabajo sea seguro. Puedes clonar un sitio base para un cliente nuevo, mantener cada sitio desde un dashboard, y entregar un sitio terminado sin depender de un proveedor, todo con la confianza de que una mala actualización significa revertir cambios en pocos minutos en lugar de un desastre. La incorporación, el mantenimiento, la entrega y la recuperación juntos te permiten administrar una cartera completa de sitios de clientes desde una sola instalación sin que el riesgo aumente con la cantidad de clientes.
¿Administras sitios de clientes y quieres backups por tenant a los que puedas hacer restore en minutos sin tocar a tus otros clientes? El plan Pro incluye backups programados, restore por tenant y recuperación cruzada entre bases de datos desde $9.99/month.
Preguntas frecuentes
- ¿Puedo hacer un restore del sitio de un cliente sin afectar a mis otros clientes?
- Sí. En GrabWP Tenancy Pro cada tenant está aislado con su propia database y contenido, y el restore se ejecuta por tenant. Puedes revertir el sitio roto del cliente a uno de sus propios backups mientras todos los demás tenants de la instalación siguen funcionando intactos.
- ¿Qué tan rápido puedo revertir los cambios después de una mala actualización?
- Si los backups programados están activados, ya tienes puntos de restore recientes. Desde la pantalla de restore del tenant, seleccionas un backup existente en el disco y ejecutas el restore de 8 pasos con una interfaz de progreso, por lo que la recuperación requiere solo unos minutos de supervisión en lugar de una reconstrucción manual.
- ¿Necesito guardar archivos de backup separados en otro lugar para poder recuperar un sitio?
- La versión Pro lista, descarga, elimina y restaura backups previos almacenados en el disco desde el admin, y los backups programados se pueden exportar a un almacenamiento compatible con S3. Haces un restore desde un backup existente de forma directa, y también tienes copias externas si el problema radica en el propio server.
- ¿Puedo recuperar un sitio incluso si cambió su tipo de database?
- Sí. El restore de Pro funciona entre distintos tipos de database, por lo que puedes hacer un restore entre MySQL compartido, MySQL dedicado y SQLite. Un tenant no está atado a la estructura exacta de database desde la que se hizo el backup.
Editorial standards: Our content is written by WordPress experts with hands-on multi-tenancy experience. Articles are fact-checked and regularly updated to ensure accuracy.