RPO y RTO (objetivo de punto de recuperación y objetivo de tiempo de recuperación) son métricas vitales al desarrollar planes y estrategias de recuperación ante desastres (DR).
Son fundamentales para descubrir los detalles de cómo se recuperará de una interrupción no planificada, ya sea técnica o, cada vez más, como resultado de una intención maliciosa, como el ransomware.
Esto se debe a que los requisitos de su organización, en términos de cuántos datos puede permitirse perder y cuánto tiempo puede permitirse que los sistemas no estén disponibles, dictan las técnicas y los productos de almacenamiento y protección de datos que debe especificar.
Este artículo analizará cómo definimos RPO y RTO, por qué son importantes y cómo calcularlos para su organización y las funciones dentro de ella.
Definir RTO y RPO
RTO está definido por el estándar global de TIC para la recuperación ante desastres, ISO/IEC 27031:2011, como: “El período de tiempo dentro del cual se deben recuperar los niveles mínimos de servicios y/o productos y los sistemas, aplicaciones o funciones de soporte después de una interrupción ha ocurrido.”
Mientras tanto, RPO se define como: “El punto en el tiempo en el que se deben recuperar los datos después de que se haya producido una interrupción”.
En lenguaje sencillo, RTO es la cantidad de tiempo que puede permitir que los sistemas y los datos no estén disponibles. Se mide en tiempo y es el período dentro del cual necesita que los sistemas se restablezcan después de una interrupción.
RPO es la cantidad de datos que puede permitirse perder. También se mide en el tiempo, pero visto a través de la lente de la cantidad de datos que puede permitirse perder. Por lo tanto, se regirá por cuánto tiempo pasó desde la última copia de seguridad y/o instantánea o qué tan recientes son los datos en un sitio al que realiza la conmutación por error.
Entonces, por ejemplo, una organización puede determinar que puede trabajar con un RTO de una hora y un RPO de dos horas de datos.
Sin embargo, es probable que la imagen sea menos simple que eso.
¿Diferentes RTO y RPO para diferentes aplicaciones?
Pero el panorama de aplicaciones dentro de una organización no se presta a métricas generales que cubran todo.
La realidad es que los RTO y RPO granulares son probablemente lo que se requiere para responder a situaciones del mundo real.
Entonces, por ejemplo, si todos sus sistemas fallaron, la prioridad sería restaurar aquellos que están orientados al público y generan ingresos, lo que puede incluir aplicaciones transaccionales de tiempo crítico.
Estos serían de la más alta prioridad y ocuparían el extremo opuesto del continuo de, por ejemplo, datos archivados sin usar y almacenados durante mucho tiempo o datos no estructurados sin restricciones de tiempo críticas para el negocio.
Cuando se trata de consecuencias prácticas, esas diferencias se reflejarán en el uso de diferentes clases de almacenamiento y protección de datos.
Cálculo de RTO y RPO
El lugar para comenzar es determinar el nivel de riesgo para la organización de que los sistemas no estén disponibles y durante cuánto tiempo se puede tolerar.
Tiene sentido categorizar y priorizar los sistemas y hacer preguntas como:
- ¿Es un sistema orientado al cliente?
- ¿Es transaccional o solo proporciona información?
- ¿Qué sistemas tendrán el mayor impacto en los ingresos y/o la reputación del cliente?
- ¿Cuántos datos se perderían, por minuto u hora, por ejemplo, si no estuvieran disponibles?
- ¿Cuánto cuestan los datos perdidos en términos de ingresos, por minuto u hora?
- ¿Cuál es la cantidad máxima de pérdida de datos que se puede tolerar?
- ¿Cuál es el tiempo máximo que podemos permitirnos que los sistemas, categorizados por criticidad, no estén disponibles?
- ¿Existen sistemas con dependencias a otros y cuáles son sus RPO/RTO?
- ¿Cuántos empleados se verían afectados por la caída del sistema?
Ejemplos de RPO y RTO
Los RPO y RTO ideales serían cero. Pero cuanto más te acercas a cero, más cuesta.
Por lo tanto, cero no es una opción para la mayoría de los sistemas, pero algunos lo necesitarán, a saber, los sistemas transaccionales bancarios que casi no pueden soportar la pérdida de datos o la falta de disponibilidad del sistema.
De manera más realista, probablemente clasificaría las aplicaciones y los sistemas por nivel. Así por ejemplo:
- El nivel 1 serían las aplicaciones de misión crítica, como los sistemas minoristas, transaccionales y orientados al cliente, que recibirían RPO y RTO de menos de, digamos, 10 minutos.
- Los sistemas de Nivel 2 serían importantes para el negocio pero menos críticos que los de Nivel 1, por lo que sería apropiado un RPO y un RTO de una hora a tres o cuatro horas.
- El nivel 3 serían todos aquellos sistemas que se pueden volver a poner en línea durante horas y días.
Nivel RTO/RPO y método de protección de datos
El nivel, en gran parte, determina el nivel de protección de datos. Entonces, por ejemplo, los sistemas de nivel 1 necesitan escrituras duales y/o replicación frecuente de datos para protegerse contra problemas localizados. Probablemente también necesitará la capacidad de conmutación por error rápidamente a una ubicación remota en caso de amenazas a nivel del sitio.
Los sistemas de nivel 2 necesitarían una copia de datos menos frecuente, pero también tendrían que poder conmutar por error a sistemas remotos. Todos los niveles estarían respaldados por copias de seguridad diarias, así como almacenamiento en la nube y/o archivos de cinta a medida que los datos envejecen.
La capacidad de su organización para cumplir con los acuerdos de nivel de servicio (SLA) de RTO y RPO estará determinada por el alcance de la interrupción, por lo que debe trabajarse junto con una evaluación de riesgos y un análisis de impacto comercial que analice la gama probable de posibles causas. de tiempo de inactividad y los clasifica en términos de probabilidad y efecto. Una falla de disco obviamente tiene menos impacto que un sitio inundado, por ejemplo.
Almacenamiento en la nube y RTO/RPO
Cuando determine los tipos de almacenamiento y protección de datos adecuados para su organización y los diversos sistemas que debe operar y proteger, es cada vez más probable que tenga que tener en cuenta el almacenamiento en la nube.
El uso de la nube junto con el centro de datos es bastante común, con encuestas que encuentran que casi la mitad de los clientes usan la nube para la recuperación ante desastres de alguna manera.
La dificultad que trae a los requisitos y cálculos de RPO y RTO es que ahora depende de un proveedor externo. Por lo tanto, asegúrese de discutir a fondo sus requisitos de RPO y RTO para diferentes clases de datos y vincule al proveedor tanto como sea posible con acuerdos de nivel de servicio claros. Puede haber otras complejidades al trabajar con un proveedor de nube y sitios remotos.
Por lo tanto, puede incluso considerar que algunos sistemas y datos no pueden dejarse regidos por SLA con un tercero y descubrir que desea recuperarlos internamente.