¿Qué es la recuperación ante desastres en la nube?

La recuperación ante desastres en la nube tiene como objetivo minimizar el tiempo de inactividad y reducir el impacto que crisis como fallas del sistema, desastres naturales o ciberataques pueden tener en una organización.

Existen múltiples estrategias que una organización puede emplear para desplegar la recuperación ante desastres en la nube, pero todas están diseñadas para proporcionar resiliencia empresarial frente al caos. Según el Informe del costo de una filtración de datos de IBM 2026, el costo global promedio de una violación de seguridad es de 4.99 millones, de dólares con un promedio de 11.5 millones de dólares en los Estados Unidos. El tiempo de inactividad cuesta a las organizaciones aproximadamente 1100 USD por hora durante el evento, y puede causar daños a la reputación y pérdida de negocios futuros posteriormente. La recuperación ante desastres en la nube puede ayudar a mitigar parte de este riesgo.

Se diferencia de las estrategias tradicionales de recuperación ante desastres en que utiliza una infraestructura basada en la nube en lugar de un centro de datos físico. Una solución de recuperación ante desastres basada en la nube puede ofrecer algunos beneficios clave, como mayor flexibilidad y escalabilidad que una copia de seguridad física, reducción de la inversión inicial y protección frente a fallas en el sitio.

Las dos métricas más importantes en cualquier programa de recuperación ante desastres son el objetivo de punto de recuperación (RPO) y el objetivo de tiempo de recuperación (RTO). En conjunto, estas métricas se utilizan para diseñar y evaluar la eficacia de una estrategia de recuperación ante desastres en la nube. 

Normalmente, una organización grande utiliza una estrategia multinivel en la que distintos tipos de datos tienen diferentes valores específicos de RPO y RTO. Las organizaciones pueden utilizar un análisis de impacto empresarial (BIA) para determinar los objetivos para diferentes departamentos y tipos de datos.

El RPO expresa la cantidad máxima de pérdida de datos que una organización puede tolerar. Se utiliza para decidir con qué frecuencia replicar datos, como archivos, bases de datos y aplicaciones y, por lo tanto, se mide en unidades de tiempo. Si el RPO se establece en una hora, significa que el sistema actualiza sus copias de seguridad una vez por hora y, a su vez, puede perder un máximo de una hora de datos nuevos. Es un poco como un guardado automático en un documento o juego: cuanto más pequeño es el RPO, menos progreso se pierde.

El RPO se vuelve más costoso a medida que disminuye, debido a la mayor frecuencia de carga de datos. Afortunadamente, los valores específicos bajos del RPO —que van de un minuto a apenas unos segundos— no son necesarios para todas las operaciones de recuperación ante desastres en la nube. 

Por ejemplo, mientras que una gran operación de comercio electrónico puede necesitar un RPO muy bajo para ayudar a garantizar que los datos de ventas se mantengan actualizados, esa misma operación puede necesitar solo un RPO de 24 horas para otros datos, como archivos de personal o archivos de analytics. Estos ejemplos de RPO más largos no requieren un ancho de banda de red significativo ni conexiones de red ultrarrápidas y, por lo tanto, son menos costosos. 

Algunos software de DR en la nube incluyen mecanismos de recuperación en un punto en el tiempo (point‑in‑time), que transmiten de manera continua microcambios en los datos hacia un registro dinámico con caducidad. Esto permite a las organizaciones “retroceder” al segundo justo antes de que ocurriera un desastre.

Optar por un sistema basado en la nube permite a las organizaciones aprovechar esta flexibilidad: pueden ejecutar un RPO cercano a cero para datos críticos y, al mismo tiempo, aprovechar la replicación de RPO más económica y prolongada para archivos, todo sin preocuparse por el sobreaprovisionamiento. Esa elasticidad proporciona eficiencia y reducción de costos. 

El RTO define el tiempo máximo aceptable que un sistema o proceso puede estar desconectado después de una interrupción antes de que el tiempo de inactividad cause daños inaceptables. Es el tiempo que transcurre desde el momento en que ocurre un desastre hasta que el negocio vuelve a funcionar plenamente. Aunque tanto el RPO como el RTO se miden en unidades de tiempo —como minutos, horas o días—, el RPO es un objetivo de referencia para la pérdida máxima de datos, mientras que el RTO es la meta para el tiempo de inactividad.

“Vuelve a funcionar plenamente” no es necesariamente tan claro como parece. El simple hecho de reiniciar el hardware no debería marcar el final de la medición del RTO. Existen varios puntos de control que deben cumplirse antes de que el negocio esté plenamente recuperado para uso de los clientes: más allá de reiniciar el hardware, los servicios de backend, el enrutamiento de red y el DNS deben estar operativos. 

La recuperación ante desastres en la nube puede ayudar a reducir el RTO al externalizar una parte significativa del esfuerzo de recuperación a proveedores dedicados. En una configuración de recuperación ante desastres on premises, es posible que los ingenieros tengan que ingresar físicamente a un edificio y reiniciar o reemplazar el hardware manualmente; no es así con la DR en la nube. La escalabilidad instantánea significa que cualquier nuevo servidor o almacenamiento necesario está disponible siempre que sea necesario. 

Si bien la recuperación ante desastres en la nube reduce el RTO durante la recuperación, el RTO alcanzable aún depende de factores como el volumen de datos, el método de replicación y la forma en que está construido el sistema de conmutación por error (por ejemplo, si se trata de un warm standby (standby cálido) o si todo debe iniciarse desde cero en frío.) Estas estrategias se analizan más a fondo en la siguiente sección. 

Existen cuatro estrategias principales utilizadas en la recuperación ante desastres en la nube, que varían según el uso del ancho de banda, los requisitos de velocidad y los valores específicos de objetivos de RPO y RTO.

La más sencilla de las estrategias de recuperación ante desastres en la nube — copia de seguridad y restauración—, funciona creando una copia básica de las imágenes del servidor, archivos y otros datos y guardándolos periódicamente en la nube. Si ocurre un desastre, los scripts de automatización se restauran desde las copias de seguridad y lanzan servidores operativos.

Las copias de seguridad pueden ser mutables o inmutables, y estas últimas tienen protección contra escritura, por lo que no se pueden editar, eliminar ni sobrescribir. Las copias de seguridad inmutables son especialmente útiles para protegerse contra ransomware, ya que no se pueden modificar. Copia de seguridad y restauración generalmente conlleva RTO y RPO más altos que otras estrategias.

El RTO para un sistema de copia de seguridad y restauración es alto porque aún no se está ejecutando ninguna infraestructura informática; este sistema simplemente almacena datos para su reconstitución posterior. Esa restauración puede implicar copiar cantidades considerables de datos a nuevos servidores y puede requerir un importante aprovisionamiento, enrutamiento e indexación para poder funcionar.

El RPO para un sistema de copia de seguridad y restauración también es alto porque las copias de seguridad se capturan de manera periódica y no continua. Los datos capturados en el intervalo entre copias de seguridad son los datos perdidos. Estos sistemas a menudo dependen del almacenamiento en frío, donde los datos se escriben en hardware, como unidades de disco duro (HDD) o cintas magnéticas, que luego se apagan. Esto resulta rentable, ya que requiere poca energía o ancho de banda durante periodos prolongados, pero poner en marcha esas unidades para recuperar los datos puede ser lento, lo que incrementa el RTO.

La estrategia de luz piloto toma su nombre de la luz piloto de una caldera de gas, calentador de agua o chimenea: una pequeña llama que arde perpetuamente y que consume el menor combustible posible permite un encendido, En el contexto de la recuperación ante desastres en la nube, la estrategia de luz piloto consiste en mantener un elemento activo, normalmente una base de datos réplica que se actualiza continuamente con los cambios que se van dando en la base de datos principal. 

Otros elementos, incluidas las imágenes de aplicaciones y servidores web y las plantillas de contenedores, se encuentran en un almacenamiento en la nube más económico, a veces llamado almacenamiento cálido. El almacenamiento cálido se refiere a un nivel de almacenamiento (que tiene diferentes nombres según el proveedor) cuyo precio es de acceso poco frecuente pero instantáneo. Es más económico que mantener esos elementos en constante actualización, pero aún accesibles muy rápidamente, a diferencia del almacenamiento en frío y su recuperación más lenta.

Las imágenes y las plantillas suelen actualizarse solo cuando se realizan cambios en el código subyacente. Cuando ocurre un desastre, el proveedor de la nube puede lanzar rápidamente nuevos servidores y conectarlos a la base de datos, minimizando así los tiempos de inactividad.

La estrategia de luz piloto aprovecha los precios más económicos para los niveles de almacenamiento a los que se accede con poca frecuencia, al tiempo que mantiene la base de datos activa y siempre actualizada, a menudo un “punto medio” ideal para muchas organizaciones.

El modo warm standby supone una mejora con respecto al modo de luz piloto, tanto en términos de costo como de tiempo de RTO. Mientras que la estrategia de luz piloto mantiene los servidores de aplicaciones como imágenes que se pueden reconstruir, una configuración de warm standby ejecuta esos servidores continuamente, solo que a menor escala para ahorrar energía y costos.

Una forma de pensarlo es que, en una estrategia de luz piloto, la recuperación ante desastres utiliza instrucciones almacenadas para recrear entornos; en warm standby, siempre hay una instancia más pequeña disponible para tomar tráfico, mientras que más servidores pueden escalar en segundo plano. Estas instancias suelen ejecutarse en máquinas virtuales (VM), tanto en sistemas de standby tanto cálido como caliente.

Escalar o ampliar el uso del servidor existente es más rápido que crear y arrancar nuevos servidores porque se elimina la etapa de reconstrucción. Eso puede reducir el RTO a solo unos minutos, con un RPO cercano a cero (porque una instancia siempre está activa). Sin embargo, esas cifras conllevan un mayor costo. 

El modo de standby cálido también requiere una consideración adicional para evitar el problema de la “manada atronadora”: una gran cantidad de tráfico sobrecargando servidores en espera más pequeños. Los proveedores de la nube tienen varias formas de gestionar esto, como escalar los servidores antes de cambiar el tráfico. Esto da como resultado un corto tiempo de inactividad inicial, pero protege contra la saturación de las unidades centrales de procesamiento (CPU).

El modo hot standby (standby caliente) utiliza dos o más instancias simultáneas en múltiples ubicaciones físicas, todas ejecutándose en vivo. Al igual que un motor a reacción, si un entorno deja de funcionar, los entornos funcionales restantes pueden manejar la carga mientras reparan los daños. Por lo general, las organizaciones limitan la carga en cada instancia para que cada una tenga la capacidad de manejar toda la operación en caso de que sea la única instancia en pie. 

El modo hot standby suele combinarse con algún otro tipo de sistema de copia de seguridad; es un sistema diseñado para mantener una alta disponibilidad en caso de situaciones como fallas de hardware. En el caso de ataques de malware que apuntan a la integridad de los datos, el modo hot standby es insuficiente ya que todos los datos están contaminados. Por lo tanto, la estrategia de luz piloto, los modos warm standby y hot standby suelen combinarse con algún tipo de copia de seguridad de instantáneas en un punto en el tiempo. 

Si bien la DR en la nube, la copia de seguridad en la nube y la recuperación ante desastres como servicio (DRaaS) tienen objetivos similares de proteger los datos en caso de emergencia, difieren en dos líneas: qué parte del entorno y la automatización se incluye en la copia de seguridad, y quién lo gestiona. 

La copia de seguridad en la nube es un término básico que describe una situación en la que los datos se copian en el almacenamiento en la nube. La copia de seguridad en la nube mantiene una copia segura de todos estos datos, pero no incluye ningún entorno de aplicaciones, servidores ni computación, lo que significa que un equipo interno de recuperación ante desastres de TI tendrá que descargar y reconstruir manualmente el sistema. 

La DR en la nube agrega automatización y orquestación además de la copia de seguridad en la nube. Captura todo el entorno de las aplicaciones y los scripts de automatización y las reglas utilizadas para aprovisionar servidores, restaurar datos y redirigir el tráfico. Esto permite la recuperación del sistema con mucho menos esfuerzo manual que la copia de seguridad en la nube más limitada. 

DRaaS es esencialmente una versión gestionada por terceros de DR en la nube. En lugar de crear sus propios scripts y reglas para la replicación de datos y la conmutación por error, una organización puede externalizar ese trabajo a un proveedor de DRaaS. Algunos DRaaS se presentan en forma de panel de autoservicio para pruebas y activación, mientras que otras plataformas DRaaS están totalmente gestionadas por un tercero.

La recuperación ante desastres en la nube es un segmento de rápido crecimiento; según H2Vantix, se espera que la industria de la recuperación ante desastres en la nube crezca de 12 100 millones de dólares en 2025 a 14 460 millones en 2026. Las organizaciones eligen cada vez más sistemas de nube basada en la nube o de nube híbrida para la recuperación ante desastres. Según Global Growth Insights, el 59 % de las empresas han migrado al menos parte de su infraestructura de recuperación a la nube. Existen varias razones por las que la recuperación ante desastres en la nube es cada vez más popular.

Uno de los mayores beneficios de la recuperación ante desastres en la nube frente a los sistemas físicos tradicionales de recuperación ante desastres es el ahorro de costos inicial. En un esquema tradicional de recuperación ante desastres, el propietario debe adquirir todo el hardware e instalación por adelantado, además de los servicios y el mantenimiento continuos. La recuperación ante desastres en la nube permite a una organización pagar únicamente por lo que usa.

La opinión convencional sobre el cómputo general es que, aunque la nube reduce la puesta en marcha inicial, los costos a largo plazo para cargas de trabajo predecibles y de gran volumen suelen favorecer las soluciones en sitio. Esto se debe a que la inversión inicial se amortiza con el tiempo en un costo fijo previsible, además de las comisiones por la transferencia de datos, suscripciones y otros costos asociados a la computación en la nube. El caso de la recuperación ante desastres es menos sencillo y, en realidad, todo se reduce a la utilización y la propiedad.

En muchos casos, el costo total de propiedad puede ser más bajo a largo plazo en materia de recuperación ante desastres, ya que los recursos de DR permanecen inactivos la mayor parte del tiempo, y la nube permite a la organización evitar la inversión en estos recursos si aún no los posee 

Sin embargo, si una organización ya tiene un segundo sitio físico y solo necesita agregar recuperación ante desastres a la carga, o ejecuta una carga de trabajo estable, de gran volumen las 24 horas del día que es lo suficientemente pesada como para mantener el hardware suficientemente utilizado, el CTP podría ser menor para una copia de seguridad física.

La escalabilidad puede ser un problema con la copia de seguridad on premises y la recuperación ante desastres, ya que requiere la compra de almacenamiento adicional o potencia de cómputo, así como instalación y configuración. Además del gasto descrito anteriormente, esto lleva tiempo. Con la recuperación ante desastres en la nube, la escalabilidad está integrada y, a menudo, automatizada: el almacenamiento y la computación pueden escalar rápidamente con la demanda. 

Esta escalabilidad puede ser especialmente beneficiosa para las organizaciones cuyas necesidades de recuperación ante desastres fluctúan. Es más evidente en hardware no utilizado: es muy difícil hacer una reducción de capacidad para evitar pagar por almacenamiento o computación sin uso si ya tiene el hardware. Tendría que vender dispositivos usados y luego volver a comprarlos según sea necesario o simplemente vivir pagando por equipos que no necesita. Evitar los costos del sobreaprovisionamiento es un factor importante para la adopción de la DR en la nube.

Mantener una instalación de recuperación ante desastres on premises puede ser una propuesta arriesgada cuando se trata de desastres naturales. Una inundación, incendio u otro desastre natural puede ser devastador para la infraestructura de TI on-prem, operando como un único punto de falla. La recuperación ante desastres en la nube permite a una organización separar el almacenamiento en diferentes ubicaciones físicas, todas accesibles a través de una red, protegiendo contra fallas de sitios individuales y ayudando a mantener la continuidad de negocio.

Existen varios pasos comunes para una implementación inicial, entre ellos:

Un análisis inicial tanto de los riesgos como del impacto en el negocio es un buen primer paso para establecer lo que la organización necesita en términos de protección de datos. Esto podría significar establecer métricas de valores específicos de RTO y RPO para diferentes aplicaciones, mapear todas las dependencias del sistema y clasificar los datos en categorías prioritarias para almacenamiento en frío, cálido o caliente. 

La evaluación de riesgos puede implicar la identificación de posibles tipos de riesgo (ataques de ransomware, robo de datos, desastres ambientales o errores humanos, por ejemplo). Pero es necesario hacer otras evaluaciones. El vendor lock-in (dependencia de proveedores) siempre es un riesgo a la hora de elegir un proveedor de servicios, en la nube o de otro tipo, un hecho que puede hacer que un entorno multinube sea una inversión que merezca la pena. Además, podría haber normas que rijan el almacenamiento de cierta información en nubes públicas que deben tenerse en cuenta.

Una vez que una organización sabe lo que necesita, puede comparar formas de lograr esos objetivos. Las diferentes estrategias(copia de seguridad y restauración, luz piloto, warm standby y hot standby) se pueden utilizar simultáneamente para diferentes categorías de recuperación ante desastres. 

Si la organización ha optado por un sistema DRaaS, gran parte de la configuración y la gestión estarán a cargo del proveedor. En otros casos, la organización deberá configurar sus propios intervalos de sincronización de datos, orquestación de conmutación por error y reglas de almacenamiento. 

Las pruebas y el mantenimiento periódicos de un sistema de DR en la nube son vitales para ayudar a garantizar que dicho sistema funcione correctamente y esté preparado para los peores escenarios. Tanto los equipos de TI internos como los equipos de gestión de DRaaS de terceros pueden realizar pruebas aisladas de forma periódica para asegurarse de que todo esté en orden. 

Estas pruebas pueden medir el RTO y el RPO, confirmar que las aplicaciones realmente funcionan tras un desastre, garantizar que la conmutación por error funcione como se espera y también pueden servir como ensayo general para los equipos de TI. Ese ensayo también puede ayudar a probar la conmutación por error, es decir, el proceso de volver a las operaciones normales.