Punto de recuperación objetivo (RPO)

¿Qué es RPO?
Se trata de la medición de la cantidad máxima de información que se puede perder. Esta ayuda a
medir cuánto tiempo puede pasar entre el último respaldo y el desastre sin causar demasiado
daño al negocio. También es de utilidad para determinar qué tan frecuentes deben ser los
respaldos de datos.
El RPO es importante porque, en la mayoría de los casos, la pérdida de datos será inevitable.
Incluso la información respaldada en tiempo real corre el riesgo de perderse para siempre; es por
eso que la mayoría de los negocios fijan intervalos de tiempo (una vez cada semana, día u hora).
En suma, el RPO mide cuánta información se puede perder producto de un desastre.

Aunque para algunas aplicaciones es aceptable perder hasta 24 horas, para otros simplemente no
es posible.

Ejemplo de Punto de recuperación objetivo

Una organización sufre un desastre que le provoca la pérdida de todos los datos. Esta
organización, preocupada y comprometida con la gestión de riesgos, definió que cada 24 horas en
otro servidor externo al que está físicamente en la organización, se realizara copias de seguridad.
Con esto ha conseguido que la pérdida máxima de información sea toda la que exceda la copia de
estas 24 horas que han definido.

DIFERENCIAS ENTRE RTO Y RPO

El RTO refleja las necesidades generales del negocio. Se trata de una medición de qué tanto puede
sobrevivir una compañía con su infraestructura de TI y servicios inactivos. Por otro lado, el RPO
solo abarca información, por lo que no representa otro aspecto del negocio.

Aunque ambos objetivos son similares en métricas de medición, sus objetivos difieren según la
aplicación y la prioridad de los datos:
Propósito

El RPO se ocupa de la pérdida de datos y ayuda a informar el desarrollo de una estrategia de

respaldo. Mientras que, el RTO trata con el tiempo para recuperarse, ayuda a informar el
desarrollo de una estrategia de recuperación ante desastres.

Prioridad

Mientras que los RTO se centran en la restauración de aplicaciones y sistemas, los RPO se
preocupan únicamente por la cantidad de datos que se pierden después de un evento de falla,
calculando el riesgo y el impacto en la transacción general del cliente en lugar del tiempo de
inactividad de la productividad.

Relevancia de costos

Los costos asociados con mantener un RTO pueden ser más grandes que los de un RPO. Ya que los
mantenimientos de un RTO exigente pueden ser mayores que los de un RPO granular, Eso es
debido a que el RTO involucra toda su infraestructura empresarial y no solo el elemento de los
datos.

Automatización

Alcanzar los objetivos del RPO simplemente requiere de realizar respaldos o copias de seguridad
en los intervalos correctos. Esto se puede automatizar fácilmente, resultando en una estrategia de
RPO fácil de implementar. El RTO, por otro lado, es más complicado y es virtualmente imposible
alcanzar las metas de RTO de una forma totalmente automatizada, ya que implica restaurar todas
las operaciones de TI. de cualquier manera, se recomienda automatizar la mayor cantidad posible
de procesos de recuperación.

Facilidad de cálculo

El RPO es más fácil de implementar debido a que el uso de datos es relativamente consistente y
tiene menos variables. Debido a que los tiempos de restauración tienen que ver con toda la
operación, y no solo con los datos, estos son más complicados. Los tiempos de restauración
pueden cambiar basándose en factores como el momento del día o semana en el que ocurre el
desastre.

El RTO debe estar alineado con las posibilidades de TI. Si el tiempo de restauración mínimo es de 2
horas, entonces un RTO de 1 hora nunca podrá ser alcanzado. Los administradores de TI deben
comprender muy bien las velocidades de los distintos tipos de restauración. Solo así se puede
negociar y alcanzar apropiadamente un RTO basándose en las necesidades del negocio.

Variables de cálculo

Con base en la menor cantidad de variables, los RPO pueden ser más fáciles de calcular debido a la
consistencia del uso de datos. Los RTO son un poco más complicados ya que los tiempos de
restauración dependen de varios factores, incluidos los marcos de tiempo analógicos y el día en
que ocurre el evento. Un RPO más corto implica perder menos datos, pero requiere más copias de
seguridad, mayor capacidad de almacenamiento y más recursos informáticos y de red para que se
ejecute la copia de seguridad. Un RPO más largo es más asequible, pero implica perder más datos.

Las variables de cálculo también pueden diferir según la clasificación de los datos. Una buena
práctica para cualquier empresa es clasificar los datos en niveles críticos y no críticos que luego
predeterminarán sus RPOS y RTO en orden de prioridad.

Puntos esenciales de diferencias entre RTO y RPO

Siendo realistas, una comprensión sólida del objetivo del tiempo de recuperación frente al
objetivo del punto de recuperación puede reducir la brecha de conocimiento y ayudarlo a
establecer sus objetivos por presupuesto, recursos y, por supuesto, la prioridad de la aplicación.
Echar un vistazo.

 El RTO se mide desde el inicio de una interrupción, mientras que puede medir el RPO
después de una interrupción del servicio.
 RTO determina el tiempo en el futuro para recuperar aplicaciones y procesos para
respaldarlos y ejecutarlos. RPO se ocupa del tiempo en el pasado antes de la pérdida de
datos cuando los datos se conservaron hasta la última copia de seguridad reciente, que la
empresa puede recuperar para reanudar las operaciones normales.
 RTO no tiene nada que ver con la pérdida de datos y principalmente se ocupa del tiempo
objetivo para la restauración del sistema de TI después de un desastre. Considerando que,
RPO es la cantidad aceptable de tiempo de inactividad empresarial que causa la pérdida de
datos desde el momento de la interrupción hasta su última copia de seguridad.
 RTO incluye los pasos tomados por TI para mitigar o recuperarse de diferentes desastres.
Pero, RPO determina qué tan atrás debe retroceder el equipo de TI hasta el último punto
en el tiempo y qué se debe hacer para que las operaciones regresen al estado anterior al
desastre.
 RTO tiene diversos tiempos de restauración que dependen de varios factores, como
marcos de tiempo lineales, día del evento, etc., lo que complica aún más su cálculo. RPO
es más fácil de calcular e implementar, ya que el uso de datos es en gran medida
consistente e incluye menos variables.
 Dado que RTO incluye la recuperación de toda la infraestructura, el costo de recuperación
aumenta drásticamente al cumplir con el requisito de RTO casi nulo. Sin embargo, la
replicación granular de RPO casi nula simplifica el costo y la efectividad de la recuperación,
ya que la información aislada se puede recuperar más rápido. Además, un RPO más
prolongado es asequible, a diferencia de la restauración de toda la infraestructura.

Conclusión

En muchas organizaciones, el departamento de TI tiene la responsabilidad de implementar y

manejar las estrategias de recuperación ante desastres, aunque esta carga sin duda debería
compartirse. Un programa efectivo requiere un esfuerzo coordinado de múltiples partes.
La gerencia, TI y los tomadores de decisiones deben trabajar en equipo para alinear los objetivos
de recuperación con los resultados de los análisis de impacto de negocios y las necesidades
individuales de la organización. Definir métricas como RTO Y RPO antes de un desastre puede
hacer toda la diferencia cuando se trata de poner el plan en marcha.

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.