Un plan de recuperación ante desastres cloud debe permitir reiniciar sus servicios en una región independiente si un centro de datos entero deja de estar disponible. Fija dos objetivos de negocio, el tiempo máximo de interrupción y la pérdida de datos aceptable, y después organiza las copias de seguridad, la infraestructura, los accesos y la conmutación. Sin pruebas periódicas, una replicación activa o una copia de seguridad completada no demuestra que la actividad pueda reanudarse realmente.
¿Por qué preparar la pérdida completa de un centro de datos cloud?
La pérdida de un centro de datos cloud puede interrumpir una aplicación incluso si sus servidores están virtualizados. En octubre de 2026, tres centros de datos de Yandex resultaron físicamente afectados por ataques con drones. Los servicios de taxi, banca, mensajería y reparto también sufrieron interrupciones, según Yandex y Associated Press.
La nube abstrae las máquinas, no su existencia física. Los servidores, los equipos de red, las fuentes de alimentación y las fibras siguen instalados en algún lugar. Le Monde indicaba el 13 de octubre de 2026 que los tres emplazamientos afectados figuraban entre los seis grandes centros de datos de Yandex conocidos públicamente.
Un plan de recuperación ante desastres cloud, o PRA cloud, es un dispositivo técnico y organizativo que restaura un servicio informático después de un siniestro. Se distingue del plan de continuidad de negocio, que busca mantener las funciones esenciales durante la crisis. Para situar estas nociones en un enfoque global, consulte esta guía sobre el PRA, el PCA y los ciberataques en pymes.
La diferencia entre centro de datos, zona de disponibilidad y región cambia directamente el nivel de riesgo. Una zona de disponibilidad agrupa infraestructuras separadas dentro de una misma región cloud. Una interrupción regional exige, según las recomendaciones de AWS publicadas entre 2024 y 2026, que los datos, los recursos y las configuraciones estén ya disponibles en otra región.
¿Cómo definir el RTO y el RPO de un plan de recuperación ante desastres cloud?
El RTO es el tiempo máximo aceptable antes de restablecer un servicio, mientras que el RPO representa el periodo máximo de datos que la empresa acepta perder. Microsoft Azure recomienda en 2026 fijar estos dos objetivos mediante un análisis de impacto en el negocio antes de elegir la arquitectura del plan de recuperación ante desastres cloud.
Un RTO de cuatro horas significa que la aplicación debe restablecerse como máximo cuatro horas después del incidente. Un RPO de quince minutos significa que una pérdida de los últimos quince minutos de datos sigue siendo tolerable. Estos valores no deben copiarse de un modelo técnico: se derivan de las consecuencias comerciales, normativas y operativas de una interrupción.
Empiece por cuantificar las consecuencias de pasar una hora sin pedidos, un día sin extranet o perder las operaciones recientes. La dirección, las áreas de negocio y el responsable informático deben decidirlo conjuntamente. Cuanto más cortos sean el RTO y el RPO, más disponible y sincronizada deberá estar la infraestructura de respaldo y, por tanto, más costosa será.
Atención a las cifras comerciales presentadas sin contexto. En 2026, AWS Prescriptive Guidance asocia, a título orientativo, la restauración desde una copia de seguridad con un plazo de varias horas e inferior a 24 horas, el pilot light con unas decenas de minutos, el warm standby con unos minutos y la arquitectura active-active con objetivos cercanos a cero. No son garantías universales.
¿Qué arquitectura de recuperación elegir según los plazos del negocio?
Cuatro arquitecturas cubren la mayor parte de los planes de recuperación ante desastres cloud: copia de seguridad y restauración, un entorno mínimo denominado pilot light, una infraestructura de respaldo activa con capacidad reducida y una configuración multi-región active-active. La elección adecuada depende del RTO, el RPO y el coste de una interrupción, no del nivel de sofisticación buscado.
| Arquitectura | Principio | Restablecimiento orientativo | Principal decisión de equilibrio |
|---|---|---|---|
| Copia de seguridad y restauración | Reconstrucción después del siniestro | Varias horas, generalmente menos de 24 horas según AWS en 2026 | Coste reducido, recuperación lenta |
| Pilot light | Base crítica mantenida en otra región | Unas decenas de minutos según AWS en 2026 | Es necesario desplegar y aumentar la capacidad |
| Warm standby | Copia activa con capacidad reducida | Unos minutos según AWS en 2026 | Coste permanente más elevado |
| Active-active | Producción distribuida entre varias regiones | RTO y RPO cercanos a cero en el ejemplo de AWS de 2026 | Complejidad y costes elevados |
Para una pyme cuya actividad pueda esperar medio día, una restauración automatizada y probada puede ser más racional que un sistema active-active. Sinceramente, el active-active solo se justifica si unos pocos minutos de interrupción cuestan más que su diseño, su explotación permanente y sus pruebas.
Google Cloud documentaba en 2024 una arquitectura ilustrativa de nivel 2 con un RTO de 24 horas y un RPO de 4 horas para una interrupción regional. Este ejemplo muestra que una arquitectura cloud seria puede asumir una recuperación diferida. La mayor disponibilidad no es siempre la mejor inversión.
Desde la perspectiva de una agencia, lo primero es vincular cada componente al recorrido de negocio: autenticación, pago, generación de documentos, envío de correos electrónicos y herramientas internas. Una aplicación reiniciada pero incapaz de aceptar un pago no ha reanudado realmente su actividad.
¿Por qué la replicación no sustituye a las copias de seguridad?
La replicación entre regiones reduce la cantidad de datos perdidos, pero también puede copiar una eliminación, una corrupción o datos cifrados por un ransomware. Por tanto, un plan de recuperación ante desastres cloud debe conservar copias de seguridad fechadas, cifradas y aisladas del entorno de producción, de conformidad con las recomendaciones de AWS y CISA de 2024 a 2026.
Una copia aislada utiliza una frontera de seguridad diferente: una cuenta cloud independiente, una bóveda lógicamente aislada o un soporte sin conexión. Si el mismo administrador comprometido puede eliminar la producción y todas sus copias de seguridad, la redundancia geográfica ofrece poca protección contra un ataque.
El aspecto menos visible está relacionado con la duración de la replicación. Microsoft indica en 2026 que las copias de seguridad con redundancia geográfica de Azure pueden exponer hasta 36 horas de pérdida de datos en el caso regional general documentado: un RPO primario de 24 horas al que pueden añadirse hasta 12 horas de replicación. Por tanto, la palabra «redundante geográficamente» no basta para establecer su RPO real.
La recuperación también debe integrar los derechos de acceso, los registros y los procedimientos de respuesta ante incidentes. Estas medidas amplían las conceptos básicos de la ciberseguridad, especialmente la limitación de privilegios y la separación de los entornos.
¿Cómo probar un PRA cloud sin perturbar la producción?
Una prueba de PRA cloud debe restaurar realmente los datos, desplegar la aplicación en una región independiente y medir el plazo obtenido. AWS recomienda en 2026 realizar restauraciones periódicas, ejercicios de conmutación y controles de capacidad. El estado «copia de seguridad correcta» confirma que existe una copia, no que sea posible reiniciar la actividad.
Un ejercicio controlado puede utilizar datos anonimizados y un dominio de prueba antes de realizar una conmutación completa. El objetivo es observar las acciones humanas, las autorizaciones que faltan y las dependencias olvidadas. En los proyectos que llevamos a cabo, a menudo vemos que el DNS, los certificados o las cuotas cloud retrasan la recuperación más que el redespliegue de los servidores.
El siguiente escenario para pymes sintetiza en 2026 los procedimientos recomendados por Amazon Web Services, Microsoft Azure y Google Cloud:
- declarar no disponible la región principal y activar el procedimiento con las personas autorizadas;
- restaurar o promover la base de datos en una región independiente;
- desplegar la aplicación desde la infraestructura como código, es decir, una descripción versionada de la infraestructura;
- restablecer los secretos, certificados, cuentas de identidad, rutas de red y cadenas de conexión;
- redirigir el DNS, el servicio que asocia un nombre de dominio a la aplicación, y después controlar su propagación;
- verificar los pagos, correos electrónicos, API de terceros y herramientas de supervisión, y después procesar pedidos de prueba;
- medir la pérdida de datos y el tiempo total antes de probar el regreso controlado a la región principal.
El cambio de DNS merece un cronómetro preciso. La detección de fallos, los controles de estado de los servidores y la propagación de los cambios pueden alargar el RTO observado en la práctica. Un equilibrador de carga global acelera algunos escenarios, pero también debe configurarse, supervisarse y probarse.
La infraestructura como código reduce las manipulaciones manuales y las desviaciones de configuración. Las plantillas Terraform, AWS CloudFormation o Azure Bicep, así como las versiones de la aplicación, deben conservarse forera de la única región afectada. La misma disciplina se aplica a las actualizaciones, como explica esta guía sobre el patch management sin interrupción de la producción.
¿Qué elementos debe documentar un plan de recuperación ante desastres en la nube?
Un plan completo de recuperación ante desastres en la nube documenta a los responsables, los criterios de activación, las dependencias, los accesos de emergencia, los pasos del cambio y las condiciones para regresar a la normalidad. Microsoft Azure recuerda en 2026 que la informática, la base de datos y el almacenamiento no son suficientes: la identidad, el DNS, los certificados, los secretos, la red, las cuotas y las API de terceros deben estar cubiertos.
El documento debe precisar quién puede declarar el desastre, quién se comunica con los clientes y quién autorriza el regreso a producción. Debe seguir siendo accesible cuando el sistema de información principal deje de estar disponible. Un procedimiento almacenado únicamente en la intranet no disponible se vuelve inutilizable en el momento crítico.
Añada las coroordenadas de los proveedores, las cuentas cloud de emergencia, los límites contractuales y las condiciones de soporrte. Para cada dependencia externa, compruebe si el proveedor acepta conexiones desde la región de respaldo: las listas de direcciones IP autorrizadas, los certificados, las restricciones geográficas y los límites de las API pueden bloquear la recuperación.
El cumplimiento normativo no se delega por completo en el proveedor de alojamiento. Las empresas sujetas a obligaciones reforzadas también pueden examinar el efecto de NIS2 en los subcontratistas y las pequeñas empresas. El plan de recuperación ante desastres debe seguir siendo coherente con los contratos, la protección de datos y los compromisos asumidos con los clientes.
Definir el plan de recuperación ante desastres en la nube antes de elegir la arquitectura evita pagar por una redundancia inadecuada o descubrir demasiado tarde una dependencia bloqueante. Una perspectiva externa puede ayudar sobre todo a contrastar los objetivos empresariales con los plazos que realmente pueden medirse.
Preguntas frecuentes sobre la recuperación ante desastres en la nube
¿Basta una copia de seguridad en la nube para reanudar la actividad?
Una copia de seguridad en la nube solo es suficiente si se han probado su restauración, los accesos, la infraestructura y las dependencias. Una copia completada puede estar corrompida, ser inaccesible o tardar demasiado en restaurarse para cumplir el RTO.
¿Cuál es la diferencia entre alta disponibilidad y recuperación ante desastres?
La alta disponibilidad absorrbe las interrupciones habituales con poca o ninguna interrupción del servicio. La recuperación ante desastres aborda un acontecimiento grave, como la pérdida de una región cloud, y suele aceptar un procedimiento de restauración más largo.
¿Con qué frecuencia debe probarse una restauración en la nube?
La frecuencia de una prueba de restauración cloud depende del ritmo de los cambios y del impacto en la actividad. Cada modificación importante de la arquitectura, la identidad, la red o la base de datos debe llevar a verificar el procedimiento, además de los ejercicios planificados.
¿Se puede construir un PRA con el mismo proveedor de servicios en la nube?
Un plan de recuperación ante desastres puede utilizar dos regiones independientes del mismo proveedor cloud si los riesgos residuales se aceptan y se prueban. Un segundo proveedor reduce algunas dependencias comunes, pero aumenta la complejidad de las competencias, los datos, la red y la explotación.