DR Disaster Recovery.

Dónde se sitúa la recuperación ante desastres dentro de la continuidad

La recuperación ante desastres es la sala de máquinas técnica de la continuidad de negocio. La gestión de la continuidad de negocio se pregunta cómo la organización sigue prestando sus actividades críticas durante una interrupción, abarcando personas, instalaciones, proveedores y procesos. La recuperación ante desastres responde a una pregunta más estrecha: cómo recuperamos las TI. Servidores, redes, aplicaciones, bases de datos y los propios datos. Cuando un centro de datos se inunda, una cepa de ransomware cifra la producción o una región de nube se apaga, el plan de recuperación es el documento y la memoria muscular que vuelve a poner los sistemas en marcha en un orden conocido, hasta un punto en el tiempo conocido.

Esa distinción importa porque ambas a menudo se confunden. Un plan de continuidad puede describir soluciones manuales que mantienen vivo un servicio mientras las TI están caídas. Un plan de recuperación no tiene ese lujo. Se juzga únicamente por si los sistemas vuelven, con qué rapidez y cuántos datos se perdieron. Tratar la recuperación como un subconjunto de la continuidad en lugar de como un sinónimo mantiene el alcance honesto e impide que los equipos asuman que un servidor recuperado significa un servicio de negocio recuperado.

RTO, RPO y el runbook

Dos cifras gobiernan cada decisión de recuperación. El objetivo de tiempo de recuperación (RTO) es el tiempo máximo tolerable que un sistema puede estar caído antes de que el impacto se vuelva inaceptable. El objetivo de punto de recuperación (RPO) es la cantidad máxima tolerable de pérdida de datos, expresada como una ventana de tiempo, lo que en la práctica dicta con qué frecuencia replica o realiza copias de seguridad. Un RTO de cuatro horas con un RPO de quince minutos es una arquitectura muy diferente, y un presupuesto muy diferente, de un RTO para el siguiente día hábil con una copia de seguridad diaria. Estos objetivos deben provenir de un análisis de impacto en el negocio, no del nivel de comodidad del equipo de infraestructura.

• El RTO determina la arquitectura de recuperación: redundancia en caliente y replicación para objetivos estrictos, restauración desde copia de seguridad para los más flexibles.
• El RPO determina la estrategia de protección de datos: replicación síncrona, instantáneas o copias de seguridad periódicas.
• El runbook convierte esos objetivos en un procedimiento de recuperación probado, paso a paso, que alguien bajo presión puede seguir realmente.

Normas, amenazas y práctica actual

El panorama normativo ha cambiado. ISO/IEC 24762 ofreció en su día orientación específica sobre los servicios de recuperación ante desastres de las TIC, pero se ha retirado, y la práctica actual remite de nuevo a ISO 22301 para el sistema de gestión de la continuidad de negocio, mientras que ISO/IEC 27031 cubre la preparación de las TIC para la continuidad de negocio.

En ese modelo, la recuperación no es una disciplina independiente; es la capa operativa que materializa la estrategia de continuidad, gobernada por el mismo sistema de gestión y el mismo apetito de riesgo. Los sectores regulados añaden su propia presión: el régimen de resiliencia del sector financiero de la UE, por ejemplo, espera que las firmas demuestren que la recuperación y la continuidad de las funciones críticas se prueban, no solo se documentan.

La recuperación moderna también está moldeada por las amenazas que debe absorber. El ransomware en particular ha reescrito el guion, porque si sus copias de seguridad son accesibles y escribibles desde el entorno de producción, un atacante también las cifra. Los profesionales ahora prefieren copias de seguridad inmutables y aisladas, entornos de recuperación segmentados y reconstrucciones en sala limpia para que la restauración no vuelva a infectar sin más.

La nube y la infraestructura como código han hecho que algunas recuperaciones sean más rápidas de automatizar, pero introducen sus propios puntos únicos de fallo en las capas de región, cuenta e identidad. La disciplina es la misma de siempre: conozca sus objetivos, proteja sus datos para que sobrevivan al desastre, escriba un runbook que alguien pueda seguir y demuestre que funciona antes de necesitarlo.