Guía de recuperación ante desastres para equipos de hosting
Publicado el 26 de septiembre de 2026
Una buena guía de recuperación ante desastres comienza antes de que llegue el ticket de interrupción. Tu equipo ya debería saber qué servicios importan primero, dónde se encuentran las copias de seguridad limpias, quién puede autorizar cambios y cómo se informará a los clientes. Durante un incidente, la incertidumbre cuesta más tiempo que la mayoría de los fallos de servidor. Puede que el servicio no esté disponible, pero el proceso de recuperación debe mantener la calma.
Para una pequeña empresa, agencia, operador de SaaS o tienda online, la recuperación ante desastres no consiste únicamente en sobrevivir a un fallo total del servidor. También abarca eliminaciones accidentales, implementaciones fallidas, ransomware, corrupción de bases de datos, certificados caducados, registros DNS dañados y una cuenta en la nube que se configuró de forma un poco demasiado creativa. Los distintos eventos requieren respuestas diferentes, pero la preparación es prácticamente la misma.
Define qué significa la recuperación para tu empresa
Empieza con dos cifras: Recovery Time Objective (RTO) y Recovery Point Objective (RPO). No son papeleo por el mero hecho de hacer papeleo. Establecen los límites de una interrupción y una pérdida de datos aceptables.
El RTO es el tiempo máximo durante el que un servicio puede no estar disponible. Si tu proceso de pago debe volver a estar disponible en una hora, su RTO es de una hora. El RPO es la cantidad máxima de datos que puedes perder. Un RPO de 15 minutos significa que las copias de seguridad, la replicación o los registros de transacciones deben permitir restaurar los datos hasta un punto situado como máximo 15 minutos antes del incidente.
No asignes el mismo objetivo a todas las cargas de trabajo. Un sitio web informativo suele poder tolerar un RTO más largo que un sistema de pedidos. Un servidor de desarrollo puede esperar mientras se restauran el correo electrónico de producción, las bases de datos de clientes y las integraciones de pago. Coloca cada servicio en un nivel de prioridad y documenta su responsable, sus dependencias y su objetivo de recuperación.
Mapea las dependencias antes de que fallen
Una aplicación web rara vez vive únicamente en un servidor. Puede depender de DNS, un certificado SSL, un equilibrador de carga, almacenamiento de objetos, una base de datos, un proveedor de correo, una API y un trabajador en segundo plano. Restaurar primero el servidor web no sirve de nada si falta su base de datos o si el DNS sigue dirigiendo a los visitantes a una dirección no disponible.
Crea un mapa de dependencias sencillo para cada servicio crítico. Registra los nombres de los servidores, las direcciones IP, los sistemas operativos, las versiones de las aplicaciones, las ubicaciones de las bases de datos, el almacenamiento de credenciales, las reglas del cortafuegos, las tareas programadas, las zonas DNS y los servicios de terceros. Conserva esta información en un lugar disponible fuera de la infraestructura afectada. Un documento de recuperación almacenado únicamente en el servidor fallido es una forma muy silenciosa de optimismo.
Crea copias de seguridad que realmente puedas restaurar
Una copia de seguridad solo es una opción de recuperación después de haberla restaurado y verificado. Los registros de copias de seguridad correctas muestran que un proceso finalizó. No demuestran que los datos copiados sean legibles, completos, actuales o utilizables con la aplicación.
Usa el principio 3-2-1 como referencia práctica: conserva al menos tres copias de los datos importantes, en dos tipos de almacenamiento diferentes, con una copia almacenada fuera del sitio o en una cuenta independiente. En muchos entornos de hosting, esto significa usar instantáneas locales para realizar reversiones rápidas, almacenamiento de copias de seguridad programadas fuera del servidor de producción y una copia protegida adicional en otra ubicación.
Haz copias de seguridad de algo más que los archivos del sitio web. Incluye bases de datos, configuraciones de máquinas virtuales, variables de entorno de las aplicaciones, archivos de infraestructura como código, exportaciones de DNS, detalles de certificados y documentación de implementaciones. Si tu empresa depende de una plataforma administrada, confirma qué protege y qué sigue siendo responsabilidad tuya. «Pensábamos que estaba incluido» no es una estrategia de recuperación recomendable.
Adapta la frecuencia de las copias de seguridad a los cambios de los datos
Un sitio web corporativo estático puede necesitar una copia de seguridad diaria. Una base de datos de comercio electrónico con mucha actividad puede requerir copias de seguridad cada hora, retención de binlogs o replicación para cumplir su RPO. La elección adecuada depende de la rapidez con la que cambian tus datos y de cuánta actividad perdida se puede conciliar manualmente.
La retención también importa. Conservar únicamente la copia de seguridad más reciente es arriesgado cuando la corrupción o el malware han estado presentes durante días. Mantén varios puntos de restauración para poder retroceder más allá del primer síntoma visible. Cifra las copias de seguridad, limita el acceso y, cuando sea posible, utiliza credenciales diferentes de las de producción. Un atacante con acceso total a producción no debería recibir automáticamente las claves de todas las copias de seguridad.
Crea un procedimiento operativo claro para incidentes
Durante una interrupción, las personas necesitan decisiones que ya estén tomadas. Tu procedimiento debe ser lo bastante breve para utilizarlo bajo presión y lo bastante detallado para que otra persona cualificada pueda seguirlo. Organízalo por escenario en lugar de redactar un documento enorme.
Por ejemplo, escribe procedimientos individuales para un VPS fallido, una base de datos eliminada, un sitio web comprometido, una implementación fallida y una interrupción regional de la infraestructura. Cada procedimiento debe indicar cómo detectar el problema, cómo detener daños adicionales, dónde se encuentra la fuente de recuperación, la secuencia de restauración, las comprobaciones de validación, los contactos de escalado y los pasos de comunicación con los clientes.
Ante una sospecha de compromiso, conserva las pruebas antes de reconstruir el sistema cuando sea viable. Aísla el servidor afectado, rota las credenciales, revisa los registros de acceso e identifica el punto de entrada probable. Restaurar una copia de seguridad limpia sin corregir un complemento vulnerable, un servicio expuesto o una contraseña filtrada puede devolverte al mismo incidente antes de la hora de comer.
Asigna funciones, incluso en un equipo pequeño
Los equipos pequeños no necesitan un comité formal de emergencias, pero sí necesitan responsables. Una persona dirige la recuperación técnica, otra coordina las actualizaciones a clientes o internas y otra aprueba las decisiones de gran impacto cuando sea necesario. La misma persona puede desempeñar más de una función, pero las responsabilidades deben ser explícitas.
Prepara las actualizaciones de estado con antelación. Indica qué está afectado, qué se está comprobando, qué solución alternativa existe, si la hay, y cuándo se proporcionará la próxima actualización. Evita adivinar el tiempo de restauración. Por lo general, los clientes afrontan mejor un incidente difícil que el silencio o las estimaciones optimistas que después se desvanecen.
Elige métodos de recuperación adecuados para el fallo
Las instantáneas son útiles para revertir rápidamente un cambio incorrecto, pero no constituyen una política completa de copias de seguridad. Si las instantáneas permanecen en el mismo sistema de almacenamiento o equipo comprometido, pueden desaparecer junto con la carga de trabajo principal. Úsalas por rapidez y, después, mantén copias de seguridad independientes para mayor resiliencia.
Restaurar en una infraestructura de sustitución suele ser más seguro que reparar un servidor dañado en su lugar. Se puede aprovisionar y aplicar parches a un VPS nuevo o un servidor dedicado, y comprobarlo antes de trasladar el tráfico. Este enfoque también conserva el sistema original para su investigación. Puede tardar más que revertir una instantánea, por lo que implica elegir entre velocidad, confianza y la naturaleza del incidente.
En los servicios de alta disponibilidad, la replicación y la conmutación por error pueden reducir el tiempo de inactividad, pero aumentan la complejidad operativa. La replicación puede copiar datos incorrectos con la misma eficacia que datos correctos. Usa monitorización, réplicas retardadas cuando corresponda y procedimientos de conmutación por error probados, en lugar de asumir que la redundancia por sí sola ha resuelto la recuperación.
Prueba el plan periódicamente
Un plan de recuperación que no se ha probado es una suposición con un documento adjunto. Programa pruebas de restauración al menos trimestrales para los sistemas críticos y después de cambios importantes en la arquitectura. Restaura una copia de seguridad en un entorno aislado, confirma que la aplicación se inicia, comprueba la integridad de la base de datos, prueba las rutas de inicio de sesión y transacciones, y compara los datos recuperados con el punto de restauración esperado.
Registra cuánto tarda cada paso. Si restaurar una base de datos tarda cuatro horas, pero su RTO es de una hora, el plan no está fallando sobre el papel. Está fallando en el único lugar que importa. Puede que necesites un método de copia de seguridad más rápido, unidades de recuperación más pequeñas, infraestructura de reserva o un objetivo empresarial revisado.
La monitorización también debe contribuir a la recuperación. Las alertas sobre capacidad de almacenamiento, fallos de copias de seguridad, caducidad de certificados, comportamiento inusual de la CPU, retraso de la replicación de bases de datos y tareas programadas fallidas pueden convertir un desastre en una corrección rutinaria. Con la monitorización administrada, como FASTCARE, el objetivo no es simplemente recibir una alerta. Consiste en que un técnico empiece a comprobar las señales adecuadas mientras el problema aún es pequeño.
Restaura, valida y cierra el incidente
Una vez restaurado el servicio, no declares inmediatamente la victoria. Valida la resolución DNS, el comportamiento de SSL, el acceso del cortafuegos, el estado de la aplicación, las tareas programadas, la conectividad de la base de datos, la entrega de correo electrónico y los recorridos clave de los clientes. En una tienda online, prueba la navegación, la actividad del carrito, el proceso de pago, las notificaciones de pedidos y las devoluciones de llamada de pago. En una plataforma SaaS, prueba la autenticación, las colas en segundo plano, las respuestas de la API y el acceso a los datos de los inquilinos.
Después, revisa el incidente mientras los detalles aún están frescos. ¿Qué lo detectó? ¿Qué retrasó la recuperación? ¿Qué paso del procedimiento no estaba claro? ¿Las copias de seguridad cumplieron el RPO requerido? Convierte esas respuestas en cambios específicos con un responsable y una fecha límite. La mejor revisión posterior a un incidente es práctica, no teatral.
los clientes de kodu.cloud pueden combinar infraestructura administrada, servicios de copias de seguridad, monitorización y soporte humano para reducir el número de tareas de recuperación que recaen sobre una sola persona ocupada a las 2 de la madrugada. Eso no elimina la necesidad de un plan, pero proporciona al plan manos expertas cuando las condiciones son menos favorables.
El objetivo no es prometer que nada fallará. Los servidores, el software y las personas a veces toman decisiones sorprendentes. El objetivo es hacer que la recuperación sea lo bastante predecible para que tu equipo sepa cuál es la siguiente acción segura, tus clientes reciban actualizaciones claras y el servicio vuelva a estar tranquilo.
Andres Saar Ingeniero de atención al cliente