RPO y RTO

RPO y RTO son conceptos fundamentales pero fáciles de entender. En base a ellos se puede planificar y decidir qué tipo de soluciones son necesarias para cada negocio.

RPO (Recovery Point Objective)

RPO se refiere al volumen de datos en riesgo de pérdida que la organización considera tolerable. ¿Las transacciones de cuánto tiempo estamos dispuestos a perder, o a tener que reintroducir al sistema?

La respuesta va a depender del volumen de transacciones por unidad de tiempo, y de los mecanismos de backup, pero siempre aumenta el volumen de datos ‘huérfanos’ a medida que pasa el tiempo desde la última copia de seguridad.

El RPO determina el objetivo de posible pérdida máxima de datos introducidos desde el último backup, hasta la caída del sistema, y no depende del tiempo de recuperación. La casuística es amplísima, y aquí se ilustran algunos casos:

Dependiendo del tipo de Backup:

Caso 1: Backup diario en cinta a las 09:00 PM.

Caso 2: Varios ‘Snapshots’ durante el día.

Dependiendo de la naturaleza del negocio:

Caso 3: La gestión de las transacciones bursátiles no puede parar, no se puede perder ni demorar ni una sola transacción, su RPO es 0.
Caso 4: Un almacén robotizado se parará si no tiene sistema, y con mucho movimiento estará en situación de colapso en pocos minutos.

RTO (Recovery Time Objective)

Expresa el tiempo durante el cual una organización pueda tolerar la falta de funcionamiento de sus aplicaciones y la caída de nivel de servicio asociada, sin afectar a la continuidad del negocio.

La respuesta dependerá de la criticidad de cada aplicación. Aquí de nuevo debemos analizar cada caso; no será lo mismo la aplicación que da servicio a las cajas en una gran superficie, que la aplicación para el cálculo de la nómina, que se ejecuta una vez al mes.

Recuperación de desastres

Pasos a seguir para recuperar las aplicaciones y los datos en caso de contingencia:

Restaurar el ordenador (dependiendo del tipo de problema pueden ser minutos, horas o días).
Restaurar las copias de seguridad
Reanudar la operación

A partir de este punto se deberán repetir las transacciones que faltan, desde el momento de la caída hasta el momento de la recuperación, que serán más cuanto mayor sean RPO y RTO.

Costes de Recuperación de Desastres

Definir los valores de RPO y RTO le puede proporcionar resultados sorprendentes que podrían no ser aceptables para la gestión. Una vez fijados, podrá establecer su estrategia de recuperación, que llevará asociados unos costes que varían en función precisamente del RPO y del RTO.

Ver ejemplo de cálculo de costes

Te ofrecemos una consultoría gratuita para calcular tus RTO y RPO óptimos.

"Schematic ITSC and RTO, RPO, MI" by ITSCM - Own work. Licensed under CC BY-SA 3.0 via Wikimedia Commons.

Consultoría gratuita para el cálculo del RTO y RPO

Recovery Point Objetive y Recovery Time Objective son conceptos fundamentales para fijar nuestra estrategia de continuidad de negocio, y en base a ellos se puede planificar y decidir qué tipo de soluciones son necesarias para cada organización.

Su cálculo no es complejo, existe mucha literatura que te puede ayudar en su cálculo, sin embargo es algo laborioso, y nosotros queremos ayudarte, e ir directos al grano para que no pierdas tempo, por ello te proponemos una consultoria gratuita, de forma que con la mínima dedicación podrás conocer cuáles son los RPO y RTO óptimos para tu organización, bla, bla, bla.

Pásanos tus datos de contacto y un consultor nuestro se pondrá en contacto contigo para proceder al cálculo de tu RPO y RTO óptimos. Todos los datos son opcionales, facilítanos los que tu prefieras.

CDP: Continuous Data Protection (Protección Continuada de Datos)

"Yesterday", no somos ni los únicos ni los primeros en asociar esta canción con el problema de pérdida de datos. Mira esta versión producida por “St Francis Bonaventure” y publicada en YouTube:

¿Quién no recuerda una situación que tuviese un deseo muy fuerte de volver atrás en una base de datos? "Yesterday… ¿Qué es “Protección Continuada de Datos”?

La necesidad de deshacer algo que no debía haber ocurrido en las aplicaciones (Rollback) se presenta, con cierta frecuencia, en cada instalación. Una corrupción de datos por un error de programación, pérdida de objetos por un error de operación, una contaminación de virus…

La solución elemental es volver al último Backup, pero entonces se deshacen también procesos y transacciones correctas y válidas. Éstas habrá que repetirlas, y toda la operación será laboriosa.

Las tecnologías de Alta Disponibilidad y Recuperación de Desastres no resuelven, por definición, estas situaciones. Su objetivo es replicar inmediatamente cualquier actualización, de manera que todo lo que se ha contaminado o perdido en la producción se refleja inmediatamente en el Backup Online.

Sin embargo, Syncsort incorporó a algunas de sus herramientas un log interno, que permite retroceder en las aplicaciones, como si tuvieran una tecla “Rewind”. Se puede volver a determinada hora o a un checkpoint establecido con anterioridad (como por ejemplo, el comienzo de la actualización diaria de saldos).