RTO y RPO

¿Qué es RPO (Recovery Point Objective) y RTO (Recovery Time Objective)?

RPO

Definición en una frase:

RPO, “Recovery Point Objective” o “Punto Objetivo de Recuperación”, es el volumen de datos recientes (desde la última copia de seguridad) en riesgo de pérdida que la organización puede asumir.

En realidad todos hemos definido un RPO alguna vez y no es más que la frecuencia con la que se hacen las copias de seguridad. Si consideramos que nos vale una copia de seguridad cada hora, en el minuto 00, es porque asumimos que, en caso de una pérdida del servicio en el minuto 40, podemos perder esos datos que no ha dado tiempo a respaldar.

Si por ejemplo tenemos un sistema de mensajería que almacena los datos antes de ser procesados (con una infraestructura que tolere caídas de nodos sin pérdidas de datos, por supuesto), el RPO se podría definir con la cantidad de tiempo que tardaría en llenar las colas.

El RPO también se entiende como el tiempo que transcurre desde que se hizo la última copia de seguridad hasta que el sistema entra en estado de contingencia para no perder la continuidad de negocio (o lo que es peor, evitar la pérdida de los últimos datos).

Los niveles más severos de RPO suelen estar asociados a sistemas transaccionales, en los que un error en las inserciones puede derivar en una inconsistencia de los datos y por lo tanto tener que recuperar el último estado consistente. Por ejemplo la gestión de las transacciones bursátiles no puede parar nunca y por lo tanto no se puede perder ni demorar ni una sola transacción, por lo que su RPO es 0.

RTO

Definición en una frase:

RTO, “Recovery Time Objective” o “Tiempo Objetivo de Recuperación”, es el tiempo que el sistema va a tardar en recuperarse desde que entra en estado de contingencia.

Entrar en estado de contingencia no implica que el sistema quede parado, sino que parte de su funcionalidad deja de estar disponible (por ejemplo se queda en modo de solo lectura).

Se suele definir un RTO distinto para cada servicio y un nivel mínimo de funcionamiento: por ejemplo, no es lo mismo una aplicación que da servicio a las cajas en un supermercado que una aplicación para el cálculo de las nóminas, que se ejecuta una vez al mes.

Para evitar entrar en RTO lo mejor es disponer de un buen sistema de monitorización que nos permita anticiparnos a dicha falla. Si descubrimos un problema en tiempo de RPO (cuanto antes, mejor) tendremos margen de maniobra para solucionarlo antes de llegar al fin de dicho RPO.