¿Qué es un plan de recuperación ante desastres? Componentes, RTO/RPO, pruebas y lista de comprobación

Un plan de recuperación ante desastres (DR, por sus siglas en inglés) es un procedimiento escrito y probado para restaurar los sistemas y los datos de TI tras una caída grave, un ciberataque o la pérdida de una sede. Indica quién declara un desastre, qué sistemas se recuperan primero, con qué rapidez (RTO), cuánta pérdida de datos es aceptable (RPO) y los pasos para conmutar y volver a la situación original.

Puntos clave

• Un plan de DR restaura la tecnología; un plan de continuidad del negocio mantiene en marcha toda la empresa. Se necesitan ambos, y el plan de DR debe ser un subconjunto del de continuidad.
• Toda decisión de recuperación parte de dos cifras por sistema: el objetivo de tiempo de recuperación (RTO) y el objetivo de punto de recuperación (RPO).
• El DR en la nube sigue cuatro estrategias estándar: copia de seguridad y restauración, pilot light, warm standby y multisitio activo/activo. El coste y la velocidad de recuperación crecen a la vez.
• Un plan sin probar es una conjetura. Pruebe al menos una vez al año, y con más frecuencia los sistemas críticos, con ejercicios que van desde la mesa de trabajo hasta la conmutación completa.
• En la UE, el artículo 21 de NIS2 incluye la «gestión de copias de seguridad y la recuperación ante desastres» como medida de seguridad mínima. En Suecia se aplica mediante la ley de ciberseguridad (Cybersäkerhetslagen) desde el 15 de enero de 2026.

¿Qué es un plan de recuperación ante desastres?

Es el manual técnico para recuperar los sistemas tras un suceso que la resiliencia normal no puede absorber. Los desencadenantes habituales son el ransomware, la caída de un centro de datos o de una región de la nube, una base de datos corrupta, un cambio fallido, un incendio o una inundación.

NIST SP 800-34 define un plan de DR como «un plan escrito para recuperar uno o varios sistemas de información en una instalación alternativa en respuesta a un fallo grave de hardware o software o a la destrucción de las instalaciones» (NIST SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems). La misma guía subraya que un plan de DR se centra en los sistemas de información, mientras que un plan de continuidad del negocio abarca procesos de negocio como la nómina o la atención al cliente.

También verá los términos «plan de DR de TI» y «DRP». Significan lo mismo. Un buen plan es lo bastante breve como para usarlo bajo presión: derechos de decisión, prioridades, runbooks, contactos y pruebas de que se ha probado. Un documento de política extenso que nadie ha abierto desde la última auditoría no cuenta.

Recuperación ante desastres frente a continuidad del negocio

La recuperación ante desastres restaura las TI. La continuidad del negocio mantiene a la organización entregando sus productos y servicios mientras las TI, las personas, las instalaciones o los proveedores sufren una interrupción. El whitepaper de AWS sobre DR lo expresa con claridad: el plan de DR «debería ser un subconjunto del plan de continuidad del negocio (BCP) de su organización, no un documento independiente».

Para una comparación más extensa, incluido BCDR en AWS, Azure y Google Cloud, lea nuestra guía de recuperación ante desastres y continuidad del negocio en la nube.

Copia de seguridad frente a recuperación ante desastres

Una copia de seguridad es una copia de los datos. La recuperación ante desastres es la capacidad de volver a poner en marcha el servicio. Puede tener copias perfectas y seguir días sin servicio si nadie ha automatizado cómo reconstruir los servidores, las redes, las identidades y el DNS a su alrededor. Las copias de seguridad son una de las entradas del plan de DR; la regla 3-2-1 (tres copias, dos tipos de soporte, una fuera de las instalaciones) es una base sensata para ellas.

¿Cuál es el propósito de un plan de DR?

El propósito es hacer predecible la recuperación. Cuando llega un desastre, el plan sustituye la improvisación por decisiones tomadas con calma de antemano.

• Limitar la inactividad. Los sistemas críticos vuelven en un plazo acordado y en un orden acordado.
• Limitar la pérdida de datos. Las copias de seguridad y la replicación se ejecutan con la frecuencia que el negocio aprobó.
• Eliminar la ambigüedad. Todos saben quién puede declarar un desastre, quién lidera y quién habla con los clientes y las autoridades.
• Controlar el coste. No todos los sistemas necesitan un hot standby. El plan deja constancia de cuáles lo necesitan y por qué.
• Demostrar el cumplimiento. Los reguladores, los auditores, las aseguradoras y los clientes corporativos piden cada vez más una capacidad de recuperación probada, no solo una política.

Estos son también los beneficios por los que preguntan los compradores. Un plan que se ha ejercitado acorta las caídas reales porque las personas ya han practicado los pasos.

RTO y RPO: las dos cifras que guían el plan

El objetivo de tiempo de recuperación (RTO) es cuánto tiempo puede estar caído un sistema. El objetivo de punto de recuperación (RPO) es cuántos datos, medidos en tiempo, puede permitirse perder. AWS define el RTO como «el retraso máximo aceptable entre la interrupción del servicio y su restablecimiento» y el RPO como «la cantidad máxima de tiempo aceptable desde el último punto de recuperación de datos».

Ejemplo práctico. Una tienda en línea acuerda un RTO de 4 horas y un RPO de 15 minutos para su sistema de pedidos. Si la base de datos falla a las 10:00, los pedidos deben volver a aceptarse como muy tarde a las 14:00, y como máximo los pedidos realizados entre las 09:45 y las 10:00 pueden tener que volver a introducirse o recuperarse por otros medios. Una copia de seguridad nocturna no puede cumplir ese RPO; la tienda necesita envío de registros o replicación al menos cada 15 minutos. Su wiki interna, en cambio, podría aceptar un RTO de 3 días y un RPO de 24 horas, que cubre una copia diaria.

Dos reglas prácticas ayudan:

• Fije los objetivos por sistema, mediante un análisis de impacto en el negocio, no una sola cifra para «las TI». El impacto también puede cambiar con el tiempo: AWS señala que una caída de la nómina justo antes del día de pago perjudica mucho más que una justo después.
• Mantenga el RTO por debajo del tiempo máximo tolerable de inactividad del proceso de negocio. NIST SP 800-34 explica que el RTO «normalmente debe ser más corto» que ese límite, porque los datos todavía deben reprocesarse cuando los sistemas vuelven.

Para más ejemplos y un método paso a paso para fijar ambos objetivos, consulte RPO y RTO en la recuperación ante desastres explicados.

Estrategias de DR: de la copia y restauración al activo/activo

El whitepaper de AWS Disaster Recovery of Workloads on AWS agrupa el DR en la nube en cuatro estrategias. Los mismos patrones se aplican en Azure (donde Azure Site Recovery replica máquinas virtuales a una región secundaria) y en Google Cloud.

La distinción entre pilot light y warm standby confunde a muchos equipos. AWS lo expresa así: un entorno pilot light «no puede procesar solicitudes sin que antes se realice una acción adicional», mientras que un warm standby «puede gestionar tráfico (con niveles de capacidad reducidos) de inmediato». Nuestro artículo sobre la recuperación ante desastres pilot light trata ese patrón en detalle.

Dos puntos del whitepaper suelen pasarse por alto. Primero, un diseño multi-AZ dentro de una región «puede cubrir ya buena parte de sus necesidades de mitigación de riesgos» ante fallos a nivel de centro de datos; una segunda región es para sucesos que afectan a toda una región o para exigencias regulatorias. Segundo, la copia de seguridad y restauración solo es rápida si la infraestructura está definida como código, porque hay que volver a desplegar redes, servidores y configuración además de los datos.

DRaaS y recuperación ante desastres en la nube

La recuperación ante desastres como servicio (DRaaS) significa que un proveedor replica sus servidores en su nube y gestiona las herramientas de conmutación. AWS Elastic Disaster Recovery y Azure Site Recovery son las opciones nativas; los proveedores de servicios gestionados construyen runbooks, monitorización y pruebas a su alrededor. DRaaS convierte un proyecto de capital (un segundo centro de datos) en un coste corriente, pero no elimina su responsabilidad de fijar el RTO y el RPO, aprobar el plan y participar en las pruebas.

Sitios hot, warm y cold

Antes de las regiones de la nube, las estrategias de DR se describían por el grado de preparación del sitio alternativo. NIST SP 800-34 describe los cold sites como espacio con energía, refrigeración y conectividad pero sin equipos, los warm sites como parcialmente equipados con hardware y telecomunicaciones, y los hot sites como totalmente configurados con hardware, infraestructura y personal. Un cold site es el más barato, pero puede tardar días o semanas en ponerse en marcha. Los equivalentes en la nube se corresponden a grandes rasgos con copia de seguridad y restauración (cold), pilot light o warm standby (warm) y activo/activo (hot). Más información en qué es un hot site en la recuperación ante desastres.

¿Qué debe incluir un plan de DR? Lista de comprobación

Use esta lista para crear un plan nuevo o auditar uno existente. Cada línea debe existir como un documento con nombre y fecha, no como una promesa.

Cómo crear un plan de DR en siete pasos

1. Realice un análisis de impacto en el negocio y una evaluación de riesgos. Es el primer paso de cualquier esfuerzo de DR. Enumere los procesos de negocio, lo que cuesta una caída por hora y qué sistemas necesita cada uno.
2. Fije el RTO y el RPO por sistema. Agrupe los sistemas en tres o cuatro niveles para diseñar por niveles y no para cientos de servidores individuales.
3. Elija una estrategia por nivel. Asigne cada nivel a copia y restauración, pilot light, warm standby o activo/activo. Compare el coste con el impacto que midió en el paso 1.
4. Construya la capacidad técnica. Copias de seguridad, copias entre regiones o entre cuentas, replicación, infraestructura como código, monitorización y alertas también en el entorno de recuperación.
5. Escriba los runbooks. Pasos breves y numerados que un ingeniero de guardia pueda seguir a las 03:00, incluido el retorno.
6. Pruebe y corrija. Empiece con un ejercicio de mesa, después pruebas de restauración y luego una conmutación. Registre el RTO y el RPO medidos.
7. Manténgalo. Revíselo al menos una vez al año y tras cada cambio significativo en los sistemas, los proveedores o la organización.

Recuperación ante desastres para ciberincidentes y ransomware

Para muchas empresas, el desastre para el que realmente deben planificar es el ransomware o una cuenta de administración comprometida, más que una inundación. Eso cambia el plan de tres maneras.

• La replicación no basta. AWS advierte de que la replicación continua «puede no proteger frente a sucesos de desastre como la corrupción de datos o un ataque malicioso (como el borrado no autorizado de datos) tan bien como las copias de seguridad a un punto en el tiempo». Conserve copias a un punto en el tiempo que los atacantes no puedan borrar, idealmente en una cuenta aparte con credenciales distintas.
• La recuperación empieza tras la contención. El plan de respuesta a incidentes decide cuándo el entorno está lo bastante limpio como para restaurar en él. Restaurar sobre una infraestructura comprometida la vuelve a infectar.
• La identidad es una dependencia. Si su proveedor de identidad o su gestor de contraseñas está caído o comprometido, los runbooks deben indicar cómo acceden los equipos de respuesta.

¿Cuándo se activa un plan de DR?

El plan se activa cuando una caída supera, o claramente va a superar, lo que la gestión normal de incidentes puede resolver dentro del RTO. Escriba los criterios, por ejemplo «región principal no disponible durante más de 30 minutos» o «datos de producción cifrados por ransomware», y nombre quién decide. Consulte cuándo debe activarse un plan de recuperación ante desastres para ver los desencadenantes típicos.

¿Con qué frecuencia debe probarse un plan de DR?

Pruébelo al menos una vez al año y tras cada cambio significativo. Los sistemas críticos merecen ejercicios más frecuentes. La política de contingencia de ejemplo del NIST indica que las capacidades de recuperación «se probarán anualmente», y la guía recomienda revisar el plan «al menos una vez al año» y tras cambios significativos.

El NIST también adapta la profundidad de las pruebas al nivel de impacto del sistema. Para los sistemas de bajo impacto basta un ejercicio de mesa; los de impacto moderado necesitan un ejercicio funcional que incluya la recuperación desde una copia de seguridad; los de impacto alto necesitan un ejercicio funcional a gran escala que incluya «una conmutación del sistema a la ubicación alternativa».

La columna de frecuencia es nuestra recomendación para una empresa mediana típica; su regulador o sus clientes pueden exigir más. AWS resume por qué importan las pruebas: «la única recuperación de errores que funciona es el camino que se prueba con frecuencia». Tras cada prueba, registre el tiempo de recuperación y la pérdida de datos medidos, compárelos con sus objetivos y asigne responsables a cada brecha.

NIS2 y la ley sueca de ciberseguridad

Para las organizaciones dentro del ámbito de NIS2, la recuperación ante desastres ya no es una buena práctica opcional. El artículo 21, apartado 2, letra c), de la Directiva (UE) 2022/2555 (NIS2) exige que las medidas de gestión de riesgos incluyan como mínimo «la continuidad de las actividades, como la gestión de copias de seguridad y la recuperación ante desastres, y la gestión de crisis». El artículo 23 añade plazos de notificación para los incidentes significativos: una alerta temprana en las 24 horas siguientes a tener conocimiento y una notificación del incidente en 72 horas. Por tanto, su plan de DR y su proceso de notificación de incidentes deben funcionar juntos.

En Suecia, NIS2 se aplica mediante la ley de ciberseguridad (Cybersäkerhetslag, SFS 2025:1506), que entró en vigor el 15 de enero de 2026. El capítulo 2, sección 3, enumera «kontinuitetshantering och krishantering» (gestión de la continuidad y gestión de crisis) entre las medidas de seguridad mínimas. Cabe esperar que los supervisores pidan pruebas: un plan actualizado, informes de pruebas y hallazgos cerrados.

Cómo ayuda Opsio

Opsio diseña, opera y prueba el DR de las cargas de trabajo en AWS y Azure dentro de su servicio de recuperación ante desastres en la nube.

Preguntas frecuentes

¿Cuáles son los componentes clave de un plan de recuperación ante desastres?

Los componentes principales son un análisis de impacto en el negocio y una evaluación de riesgos, el RTO y el RPO por sistema, una estrategia de recuperación por nivel, copia de seguridad y replicación, criterios de activación, roles y contactos, runbooks paso a paso con retorno, un plan de comunicación y un calendario de pruebas y mantenimiento.

¿Cuál es el primer paso en un esfuerzo de recuperación ante desastres?

El primer paso es un análisis de impacto en el negocio combinado con una evaluación de riesgos. Le indica qué procesos y sistemas son más importantes y cuánto tiempo pueden estar caídos, lo que fija el RTO y el RPO de los que depende cada decisión posterior.

¿Con qué frecuencia debe probarse un plan de recuperación ante desastres?

Al menos una vez al año y tras cada cambio importante en los sistemas o los proveedores. Haga ejercicios de mesa para todos los planes y pruebas de restauración o de conmutación para los sistemas críticos, como recomienda NIST SP 800-34 para los sistemas de mayor impacto.

¿Cuál es la diferencia entre recuperación ante desastres y continuidad del negocio?

La recuperación ante desastres restaura los sistemas y los datos de TI. La continuidad del negocio mantiene la actividad durante una interrupción y abarca también a las personas, las instalaciones, los proveedores y la comunicación. El plan de DR debe formar parte del plan de continuidad del negocio.

¿Cuáles son las cuatro estrategias de recuperación ante desastres en la nube?

Copia de seguridad y restauración, pilot light, warm standby y multisitio activo/activo. Van desde horas de tiempo de recuperación al menor coste hasta una recuperación casi en tiempo real al mayor coste, según el whitepaper de DR de AWS.

¿Exige NIS2 una planificación de la recuperación ante desastres?

El artículo 21, apartado 2, letra c), de NIS2 exige a las entidades esenciales e importantes cubrir la continuidad de las actividades, «como la gestión de copias de seguridad y la recuperación ante desastres, y la gestión de crisis». En la práctica, significa una capacidad de DR documentada y probada que pueda mostrar a la autoridad de supervisión.

Más de nuestra base de conocimiento: Lista de verificación de pruebas de recuperación ante desastres: valide su plan de recuperación ante desastres en 2026