RPO y RTO - Objetivo de punto de recuperación y tiempo de tiempo de recuperación - son métricas vitales al desarrollar planes y estrategia de recuperación de desastres (DR).
Son fundamentales para determinar 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 la cantidad de datos que puede permitirse perder y cuánto tiempo puede permitir que los sistemas no estén disponibles, dicten las técnicas y 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 de desastres, ISO/IEC 27031: 2011, como: “El período de tiempo dentro del cual los niveles mínimos de servicios y/o productos y los sistemas de soporte, aplicaciones o funciones deben recuperarse después de una interrupciónha ocurrido."
Mientras tanto, RPO se define como: “El punto en el tiempo al que se deben recuperar los datos después de que se haya producido una interrupción."
En inglés sencillo, RTO es la cantidad de tiempo que puede permitir que los sistemas y los datos no estén disponibles.Se mide en el tiempo y es el período dentro del cual necesita que se restablezcan los sistemas después de una interrupción.
RPO es la cantidad de datos que puede permitirse perder.También se mide en el tiempo, pero se ve a través de la lente de la cantidad de datos que puede permitirse perder.Por lo tanto, se regirá por cuánto tiempo hace la última copia de seguridad y/o instantánea o cuán recientes son los datos en un sitio en el que su conmutación por error.
Entonces, por ejemplo, una organización puede determinar que puede funcionar con un RTO de una hora y un RPO de dos horas de datos..
Es probable que la imagen sea menos simple que eso, sin embargo.
¿Diferentes RTO y RPO para diferentes aplicaciones?
Pero el panorama de la aplicación dentro de una organización no se presta a métricas generales que cubren todo.
La realidad es que los RTO granulares y los RPO son probablemente lo que se requiere para responder a situaciones del mundo real.
Entonces, por ejemplo, si todos sus sistemas cayeran, la prioridad sería restaurar aquellos que son de orientación pública y productores de ingresos, que pueden incluir aplicaciones transaccionales altamente críticas en el tiempo.
Estos serían de la más alta prioridad y ocuparían el extremo opuesto del continuo de, por ejemplo, datos archivados archivados o datos no estructurados sin restricciones de tiempo crítico de negocios..
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.
Calculando RTO y RPO
El lugar para comenzar es determinar el nivel de riesgo para la organización de los sistemas que no están disponibles y para qué tiempo se puede tolerar.
Tiene sentido clasificar y priorizar sistemas y hacer preguntas como:
Ejemplos de RPO y RTO
RPO y RTO ideales serían cero.Pero cuanto más se acerca a cero, más cuesta.
Por lo tanto, cero no es una opción para la mayoría de los sistemas, pero algunos la necesitarán, a saber, sistemas transaccionales bancarios que casi no pueden resistir la pérdida de datos o la falta de disponibilidad del sistema.
De manera más realista, probablemente clasificaría aplicaciones y sistemas por nivel.Así por ejemplo:
Método de nivel RTO/RPO y 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 una replicación frecuente de datos para proteger 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 de sitio..
Los sistemas de nivel 2 necesitarían una copia menos frecuente de los datos, pero también necesitarían ser capaz de conmutación por error a sistemas remotos.Todos los niveles estarían respaldados por copias de seguridad diarias, así como puestos de puesta en escena en la nube y/o los archivos de cintas a medida que los datos envejecen.
La capacidad de su organización para cumplir con los acuerdos de nivel de servicio RTO y RPO (SLA) estará determinada por el alcance de la interrupción, por lo que debe resolverse junto con una evaluación de riesgos y un análisis de impacto comercial que analiza el rango probable de causas potencialesde tiempo de inactividad y los clasifica en términos de probabilidad y efecto.Una falla en el disco es obviamente menos impactante que un sitio inundado, por ejemplo.
Almacenamiento en la nube y RTO/RPO
Cuando resuelve 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 prácticamente convencional, con encuestas que encuentran casi la mitad de los clientes que usan la nube para la recuperación de desastres de alguna manera.
La dificultad que aporta 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 atar al proveedor tanto como sea posible con SLAS transparentes.Puede haber otras complejidades trabajando con un proveedor de nube y sitios remotos.
Por lo tanto, incluso puede considerar que algunos sistemas y datos no pueden ser gobernados por SLA con un tercero y descubrir que quiere traerlos de vuelta en la casa..
