RPO y RTO: Comprender las diferencias

RPO y RTO: Comprender las diferencias.Un profesional TI necesita establecer diferentes tiempos de recuperación y objetivos puntuales de acuerdo con su presupuesto, recursos y prioridad de aplicación. Estos dos objetivos se conocen como objetivo de tiempo de recuperación (RTO) y objetivo de punto de recuperación (RPO).
Los desastres vienen en muchas formas. La corrupción, el robo, la pérdida o el desastre natural pueden eliminar sus aplicaciones y destruir sus datos. En un mundo ideal, su infraestructura de protección de datos restauraría inmediatamente todas las aplicaciones y datos en el momento y el punto de falla.

Pero este es el mundo real. Es posible realizar una conmutación por error inmediata de una aplicación y replicar continuamente sus datos para una pérdida cercana a cero. Pero estas operaciones consumen muchos recursos y son caras. De manera realista, TI necesita establecer diferentes tiempos de recuperación y objetivos puntuales de acuerdo con su presupuesto, recursos y prioridad de aplicación.

A estos dos objetivos los llamamos Objetivo de tiempo de recuperación (RTO) y Objetivo de punto de recuperación (RPO). Están relacionados y ambos son necesarios para la aplicación y la recuperación de datos. También son diferentes métricas con diferentes propósitos.

Hablemos de lo que son, sus similitudes y diferencias, y por qué necesita analizar la prioridad de su aplicación para equilibrar los recursos y la disponibilidad de la aplicación.

Definiendo RTO y RPO

RTO: objetivo de tiempo de recuperación

RTO se refiere a la cantidad de tiempo que una aplicación puede estar inactiva sin causar daños significativos al negocio. Algunas aplicaciones pueden estar inactivas durante días sin consecuencias significativas. Algunas aplicaciones de alta prioridad solo pueden estar inactivas por unos segundos sin incurrir en irritación de los empleados, enojo del cliente y pérdida de negocios.

RTO no es simplemente la duración del tiempo entre la pérdida y la recuperación. El objetivo también explica los pasos que TI debe tomar para restaurar la aplicación y sus datos. Si TI ha invertido en servicios de conmutación por error para aplicaciones de alta prioridad, entonces pueden expresar RTO de forma segura en segundos. (TI aún debe restaurar el entorno local. Pero dado que la aplicación se está procesando en la nube, TI puede tomar el tiempo que necesita).

Su misión de RTO es clasificar las aplicaciones por prioridad y pérdida potencial de negocios y hacer coincidir sus recursos en consecuencia. Por ejemplo, los planes típicos para RTO casi cero requerirán servicios de conmutación por error. Los RTO de 4 horas permiten la recuperación local, comenzando con la restauración completa y terminando con la disponibilidad completa de aplicaciones y datos. Para RTO de más de 8 horas, TI puede firmar contratos de mantenimiento con integradores de sistemas locales.

RPO: objetivo de punto de recuperación

Los objetivos del punto de recuperación se refieren a la tolerancia a la pérdida de su empresa: la cantidad de datos que se pueden perder antes de que ocurra un daño significativo al negocio. El objetivo se expresa como una medición de tiempo desde el evento de pérdida hasta el respaldo anterior más reciente.

Si realiza una copia de seguridad de todos o la mayoría de sus datos en incrementos programados regularmente de 24 horas, entonces, en el peor de los casos, perderá 24 horas de datos. Para algunas aplicaciones esto es aceptable. Para otros, absolutamente no lo es.

Por ejemplo, si tiene un RPO de 4 horas para una aplicación, tendrá un espacio máximo de 4 horas entre la copia de seguridad y la pérdida de datos. Tener un RPO de 4 horas no significa necesariamente que perderá 4 horas de datos. Si una aplicación de procesamiento de texto deja de funcionar a medianoche y aparece a la 1:15 a.m., es posible que no tenga mucha (o ninguna) información que perder. Pero si una aplicación ocupada deja de funcionar a las 10 a.m. y no se restaura hasta las 2:00 p.m., posiblemente perderá 4 horas de datos altamente valiosos, quizás irremplazables. En este caso, organice una copia de seguridad más frecuente que le permita alcanzar su RPO específico de la aplicación.

Dependiendo de la prioridad de la aplicación, los RPO individuales generalmente varían de 24 horas, a 12, a 8, a 4; hasta casi cero medido en segundos. Los RPO de más de 8 horas pueden aprovechar su solución de respaldo existente siempre que tenga un impacto mínimo en sus sistemas de producción. Los RPO de 4 horas necesitarán una replicación de instantánea programada, y los RPO cercanos a cero requerirán una replicación continua. En los casos en que tanto el RPO como el RTO están cerca de cero, combine la replicación continua con los servicios de conmutación por error para una disponibilidad de datos y aplicaciones cercana al 100%.

En qué se parecen RTO y RPO, y la gran razón por la que son diferentes

RTO y RPO comparten varias características

* El tiempo de recuperación y los objetivos del punto de recuperación difieren según la aplicación y la prioridad de datos. Incluso la corporación más profunda no puede permitirse entregar RTO o RPO casi cero para todas las aplicaciones, ni deberían hacerlo.

* La única forma de asegurar el 100% de tiempo de actividad (RTO) y la no pérdida de datos (RPO) es mediante la inversión en entornos virtuales de conmutación por error con replicación continua de datos.

* TI prioriza las aplicaciones y los datos para que coincidan con los gastos de lograr RTO y RPO. Tenga en cuenta que la prioridad no solo está guiada por los ingresos sino también por el riesgo. Una empresa puede usar una aplicación con poca frecuencia, pero si sus datos están regulados, la pérdida de datos puede generar grandes multas.

* Tanto RTO como RPO se miden en unidades de tiempo. Para RTO, la métrica es la cantidad de tiempo que transcurre entre la falla de la aplicación y la disponibilidad total, incluida la recuperación de datos. RPO también se mide en unidades de tiempo. La métrica es la cantidad de tiempo entre la pérdida de datos y la copia de seguridad anterior. Tanto para RTO como para RPO, la prioridad de aplicación / datos se traduce directamente en unidades de tiempo más cortas.

La gran diferencia: propósito

A pesar de sus similitudes, RPO y RTO tienen diferentes propósitos. RTO se refiere a aplicaciones y sistemas. La medición incluye la recuperación de datos, pero describe principalmente las limitaciones de tiempo en el tiempo de inactividad de la aplicación.

A RPO le preocupa la cantidad de datos que se pierden después de un evento de falla. Un usuario molesto es una cosa. Pero perder cientos de miles de dólares en transacciones de clientes es mucho más que una simple molestia. Es catastrófico.

Ejemplos de RTO y RPO en acción

• Recuperación de elementos granulares: un abogado de la empresa elimina accidentalmente un correo electrónico urgente y luego vacía el contenido de la carpeta Papelera. Dado que Microsoft Exchange es una aplicación crítica para el negocio de esta empresa ocupada, TI respalda continuamente los cambios de nivel delta en Exchange. Y dado que su aplicación de copia de seguridad es capaz de realizar una copia de seguridad y recuperación granulares, pueden recuperar el mensaje individual en un RTO de 5 minutos en lugar de restaurar una máquina virtual completa para un solo mensaje.
• Sitio de comercio electrónico: el sitio de comercio electrónico autohospedado de una tienda minorista utiliza tres bases de datos diferentes: una base de datos relacional que almacena el catálogo de productos, una base de datos de documentos que informa datos de pedidos históricos y una base de datos API que se conecta a la puerta de enlace de su procesador de pagos. La base de datos de documentos puede reconstruir datos de otras bases de datos para que su RTO y RPO estén dentro de las 24 horas. La empresa solo agrega productos a la base de datos relacional una vez por semana, por lo que RPO no es crítico. RTO es: si la base de datos se cae, las transacciones de los clientes se detienen.

Para mantener una alta disponibilidad, la empresa invirtió en un servicio de conmutación por error, por lo que la base de datos gira inmediatamente en servidores virtuales. La compañía replica los pocos cambios que realiza durante la semana en la plataforma DR de su proveedor. La base de datos API contiene información de pedidos y necesita tanto RPO como RTO en segundos. TI replica continuamente los datos en el sitio de conmutación por error, que inmediatamente se hace cargo del procesamiento en caso de que la base de datos API caiga.

Consideraciones de costos

Según Zerto , una corporación con un ingreso anual de $ 100 millones perdería alrededor de $ 275,000 durante un tiempo de inactividad de 24 horas. La compañía perdería alrededor de $ 45,000 en un programa de replicación de instantáneas de 4 horas y alrededor de $ 7600 usando una replicación continua casi nula.

En la práctica, ese número podría ser menor o mayor dependiendo de la hora del día y la actividad de la aplicación. Una aplicación ocupada de misión crítica o negocio perdería más datos y datos de mayor prioridad que una aplicación menos frecuente. ¿Pero perder un cuarto de millón de dólares en 24 horas? Muy posible e inaceptable.

Planifique sus RPO y RTO en consecuencia y compre los recursos que necesita antes de que los necesite. Al igual que los seguros, es posible que nunca tenga que usarlos, y como los seguros, pueden salvar su negocio.

Leer también: ¿Qué es BCP (Business Continuity Plan, Plan de continuidad comercial)?; ¿Qué es es DRP (Disaster Recovery Plan o Plan de recuperación de Desastres)?; Diferencias entre BaaS y DRaaS