Plan de Recuperación ante Desastres (DRP): Guía para Empresas
Un Plan de Recuperación ante Desastres (DRP —Disaster Recovery Plan) define cómo una empresa retoma sus operaciones tras un incidente grave: incendio, inundación, ransomware, fallo de servidor o corte eléctrico prolongado. Sin un DRP documentado y probado, muchas pymes españolas tardan semanas en recuperarse de incidentes que podrían resolverse en horas.
RTO y RPO: los dos indicadores fundamentales del DRP
Antes de diseñar cualquier plan de recuperación, es imprescindible definir dos parámetros que delimitan los objetivos del plan:
El RTO (Recovery Time Objective) es el tiempo máximo que un sistema o proceso puede estar inoperativo antes de que el impacto sea inaceptable para el negocio. Por ejemplo, si su empresa no puede operar más de 4 horas sin acceso al ERP, su RTO es de 4 horas. Definir el RTO correctamente es un ejercicio de análisis de impacto empresarial, no una decisión técnica: son los propietarios del negocio quienes deben establecer qué nivel de interrupción es tolerable para cada proceso.
El RPO (Recovery Point Objective) define la cantidad máxima de datos que la empresa puede permitirse perder, medida en tiempo. Si su empresa hace backup diario a las 23:00 y un incidente ocurre a las 17:00 del día siguiente, perderá 18 horas de datos. Si eso es inaceptable, necesita un RPO menor que 18 horas, lo que implica backups más frecuentes o replicación continua de los sistemas críticos.
| Escenario | RTO recomendado | RPO recomendado | Tecnología habitual |
|---|---|---|---|
| Comercio electrónico 24/7 | < 15 minutos | < 1 hora | Hot site, replicación síncrona |
| Empresa de servicios profesionales | 4-8 horas | 4-8 horas | Warm site, backup continuo |
| Pyme con horario comercial | 24 horas | 24 horas | Cold site, backup diario |
| Empresa industrial con planta física | 2-4 horas (sistemas críticos) | 1 hora | Warm site + replicación |
La relación entre RTO/RPO y coste es directamente proporcional: conseguir un RTO de minutos y un RPO de segundos requiere una infraestructura de alta disponibilidad costosa. El objetivo del DRP es encontrar el equilibrio óptimo entre el coste de la solución de DR y el coste real del tiempo de inactividad para el negocio concreto.
BIA: Análisis de Impacto Empresarial
El BIA (Business Impact Analysis) es el paso previo imprescindible a cualquier DRP. Consiste en identificar y cuantificar el impacto que tendría la interrupción de cada sistema o proceso de negocio. El BIA debe responder:
- ¿Qué procesos de negocio son críticos para la supervivencia de la empresa?
- ¿Qué sistemas IT soportan esos procesos críticos?
- ¿Cuál es el impacto económico de cada hora de interrupción (coste directo, penalizaciones contractuales, daño reputacional)?
- ¿Existen dependencias entre sistemas? (¿el CRM depende del servidor de Active Directory? ¿El ERP depende de la base de datos en el servidor de ficheros?)
- ¿Qué obligaciones legales o contractuales exigen tiempos máximos de disponibilidad (SLA con clientes, RGPD, normativa sectorial)?
El resultado del BIA es una matriz de criticidad que clasifica los sistemas en niveles (crítico, importante, deseable) y asigna RTO y RPO específicos a cada uno. Esta matriz es el fundamento sobre el que se construye todo el DRP. Sin BIA, el plan será arbitrario y probablemente desajustado con la realidad del negocio.
Niveles de DR: Hot Site, Warm Site y Cold Site
La infraestructura de recuperación se clasifica tradicionalmente en tres niveles según su tiempo de activación y coste:
Hot Site (sitio caliente): infraestructura completamente replicada, operativa en todo momento, con datos sincronizados en tiempo real o casi real. El failover puede realizarse en minutos. Es la opción más cara pero proporciona los menores RTO y RPO posibles. Indicada para servicios con tolerancia cero a la interrupción: banca en línea, comercio electrónico de alto volumen, servicios de salud críticos.
Warm Site (sitio tibio): infraestructura parcialmente preparada, con hardware listo pero que requiere algunas horas de configuración y restauración de datos para estar operativa. Los backups se restauran desde copias recientes (horas o día anterior). RTO típico: 4-12 horas. Es la opción más común para pymes con presupuesto moderado que necesitan protección real sin el coste de un hot site completo.
Cold Site (sitio frío): espacio físico con infraestructura básica (electricidad, conectividad, aire acondicionado) pero sin hardware dedicado. En caso de desastre, hay que adquirir o trasladar hardware y restaurar desde cero. RTO típico: 24-72 horas. Es la opción más económica, adecuada para empresas donde una interrupción de 1-3 días es operativamente tolerable.
Opciones de DR en la nube: Azure, AWS y Veeam
La nube ha democratizado el acceso al DR para las pymes españolas, haciendo accesibles soluciones que antes requerían una segunda sede física. Las principales opciones del mercado actual:
Azure Site Recovery (ASR): servicio de Microsoft que replica máquinas virtuales (Hyper-V, VMware, Azure VM) a Azure. En caso de desastre, las VMs replicadas pueden iniciarse en Azure en minutos. El RPO puede ser de 30 segundos para VMs críticas. El coste de ASR incluye la licencia del servicio más el almacenamiento de la réplica; las VMs no consumen coste de cómputo hasta que se activa el failover. Muy adecuado para empresas ya en el ecosistema Microsoft 365 y Azure.
AWS Disaster Recovery Service (DRS): equivalente de Amazon, anteriormente conocido como CloudEndure. Replica servidores físicos y virtuales a AWS con replicación continua a nivel de bloque. RTO de minutos, RPO de segundos. Acepta como origen servidores físicos, VMs VMware, Hyper-V, y máquinas en otras nubes. Útil para empresas con infraestructura heterogénea que no están comprometidas con un proveedor cloud concreto.
Veeam Cloud Connect: solución de backup y DR que permite enviar copias Veeam a un proveedor de servicio gestionado (MSP) en la nube. A diferencia de ASR o AWS DRS, Veeam Cloud Connect permite contratar el servicio a través de partners locales españoles, con datos almacenados en centros de datos en España o la UE (importante para el cumplimiento del RGPD). Muchas pymes que ya usan Veeam Backup & Replication pueden extender su solución existente a la nube sin cambiar de plataforma.
Cumplimiento ENS para el sector público español
El ENS (Esquema Nacional de Seguridad), regulado por el Real Decreto 311/2022, establece los requisitos de seguridad para los sistemas de información de las Administraciones Públicas españolas y sus proveedores tecnológicos. El ENS clasifica los sistemas en tres niveles (Básico, Medio, Alto) y establece requisitos específicos de continuidad de servicio en cada uno:
- Nivel Básico: el plan de continuidad debe cubrir la recuperación de los servicios esenciales. Se requiere identificar los sistemas críticos y documentar procedimientos de recuperación. Los backups deben realizarse y verificarse periódicamente, con registro de las pruebas de restauración.
- Nivel Medio: se añaden requisitos de prueba del plan de continuidad al menos anualmente, con documentación formal de los resultados. Los RTO/RPO deben estar formalmente definidos en documentación aprobada. Se requiere un análisis de riesgos previo al diseño del plan, actualizado cuando cambien los sistemas.
- Nivel Alto: el plan debe cubrir escenarios de desastre completo incluyendo pérdida total de instalaciones. Se requiere una segunda infraestructura (hot o warm site) operativa y probada. Los planes se prueban trimestralmente con simulacros completos documentados. La recuperación debe ser posible incluso con la pérdida total del site principal.
Para entidades públicas o empresas que licitan contratos con la Administración que implican tratamiento de datos clasificados, acreditar el cumplimiento ENS (mediante certificación de entidad acreditada por ENAC) puede ser requisito obligatorio en el pliego de condiciones. El DRP documentado y probado es un componente esencial de esta certificación.
Cómo documentar y probar el DRP: elementos esenciales
Un DRP que no se prueba es una ficción. La documentación mínima de un DRP efectivo incluye:
- Inventario de sistemas: lista completa de servidores, aplicaciones y datos, con su nivel de criticidad, RTO y RPO asignados, y responsable técnico designado.
- Procedimientos de recuperación paso a paso: instrucciones detalladas, con capturas de pantalla si es necesario, para restaurar cada sistema. Deben poder seguirlos personas que no estén familiarizadas con el sistema en cuestión.
- Árbol de contactos y escalado: quién debe ser notificado en cada tipo de incidente, en qué orden, y qué proveedor externo de recuperación contactar si la recuperación interna no es posible en el tiempo establecido.
- Plan de comunicación externa: cómo y cuándo comunicar a clientes, proveedores y empleados sobre el incidente y el estado de la recuperación, cumpliendo con las obligaciones de notificación del RGPD si hay brechas de datos.
- Registro de pruebas: fecha, tipo de prueba realizada, resultados, desviaciones respecto a los objetivos RTO/RPO y acciones correctoras tomadas. Este registro es exigido por el ENS nivel Medio y Alto.
Los tipos de prueba del DRP, de menor a mayor alcance:
- Prueba de escritorio (tabletop exercise): los responsables del plan se reúnen y repasan mentalmente el escenario de desastre, identificando lagunas en los procedimientos sin intervenir en los sistemas reales.
- Prueba de recuperación de backup: restauración de una copia de seguridad en un entorno de prueba para verificar que los datos son recuperables y que los procedimientos documentados funcionan correctamente.
- Prueba de failover parcial: activación del sistema de DR para un subconjunto de aplicaciones no críticas, midiendo el RTO real obtenido y comparando con el objetivo definido.
- Simulacro completo (full DR test): simulación de pérdida total del site principal. Todo el tráfico y operaciones se redirigen al site de DR. Es la prueba más fiable pero también la más disruptiva; suele realizarse fuera del horario habitual con aviso previo a usuarios.
El DRP como complemento de los servicios de recuperación de datos
Un DRP bien diseñado reduce significativamente la probabilidad de necesitar servicios de recuperación de datos de emergencia. Sin embargo, ningún DRP es infalible: los backups también pueden fallar, los sistemas de replicación pueden propagar corrupciones de datos silenciosamente, y los desastres físicos pueden afectar simultáneamente al site principal y al de DR.
Por eso, el servicio de recuperación de datos de laboratorio es la última línea de defensa: cuando todas las capas del DRP han fallado, la recuperación física de los datos desde los discos originales dañados es la única opción. Contar con un proveedor de recuperación de datos de confianza, con acuerdo de servicio previo y tarifa preferente, debe ser parte integral de cualquier DRP serio. Incluir el número de contacto de emergencia de su proveedor de recuperación en el árbol de contactos del DRP puede marcar la diferencia entre un incidente manejable y una crisis empresarial.
WhatsApp