¿Qué es la recuperación ante desastres (RTO y RPO)?

Recuperación ante desastres: definición y objetivos

La recuperación ante desastres (DR) responde a la pregunta: ¿qué hacemos cuando la TI falla y el funcionamiento normal no vuelve con rapidez? Las causas van desde ataques de ransomware, averías de hardware y errores de manejo hasta incendios, daños por agua o el fallo de un centro de datos. Un plan de DR establece qué sistemas se restauran, en qué orden, por quién y cómo.

Forma parte de la gestión de emergencias y de la continuidad del negocio (business continuity) y complementa la copia de seguridad y la alta disponibilidad: la alta disponibilidad absorbe fallos parciales, la copia de seguridad aporta los datos y la recuperación ante desastres organiza el regreso a la operación en su conjunto, con objetivos claros, un orden fijo, responsables designados y procedimientos que se ensayan con regularidad.

RTO y RPO: las dos cifras clave

El Recovery Time Objective (RTO) es el plazo en el que un sistema debe volver a funcionar tras una caída. El Recovery Point Objective (RPO) fija cuánta pérdida de datos es tolerable en términos de tiempo. Si se hace una copia una vez por la noche, el RPO es de hasta 24 horas: todo lo ocurrido desde la última copia se perdería.

Ambos valores se derivan de un análisis de lo que cuestan las caídas a la empresa (business impact analysis). Cuanto más cortos son el RTO y el RPO, más complicada es la tecnología: desde una simple copia de seguridad y reconstrucción, pasando por un sistema de reserva preparado, hasta el reflejo continuo de datos en un segundo emplazamiento.

Ejemplo práctico: un fabricante de maquinaria tras un ataque de ransomware

Una empresa de maquinaria es víctima de un ataque de cifrado: ERP, servidor de archivos y planificación de la producción quedan parados. La empresa tiene copias de seguridad nocturnas, pero nunca ha ensayado una puesta en marcha. No está claro en qué orden deben arrancar los sistemas, dónde están los medios de instalación y si las propias copias están intactas.

Después fija objetivos: ERP con un RTO de ocho horas y un RPO de una hora, el resto de sistemas más tarde. Las copias se guardan además de forma inmutable en un lugar separado, se redacta un manual de reanudación y se ensaya dos veces al año. De un propósito vago surge un procedimiento fiable.

Errores habituales e imple­menta­ción

Los errores más frecuentes: copias de seguridad que nunca se probaron, copias en la misma red que los sistemas de producción, falta de priorización y un plan que solo está en el sistema averiado. También suelen faltar listas de contactos y vías de decisión. Un plan de DR es tan bueno como su último ensayo con éxito.

Nano Concepts le apoya en el análisis, los valores objetivo y la arquitectura: desde el plan de copias y la recuperación en la nube hasta los planes de reanudación y los ensayos. Así sabe, antes de una emergencia, qué aguanta realmente su empresa y con qué rapidez vuelve a funcionar, y puede justificar con argumentos objetivos las inversiones en medidas de protección.

• Priorizar los sistemas según su importancia para el negocio y fijar RTO y RPO por sistema
• Guardar las copias sin conexión o de forma inmutable y en un lugar separado
• Probar la restauración con regularidad, no solo la copia
• Tener a mano el plan de reanudación y la lista de contactos fuera de la propia TI
• Designar responsabilidades para la emergencia