Cuando se trata de planeación para recuperación ante desastres, las métricas no solo permiten medir la efectividad, sino alcanzar los objetivos que resultan cruciales para los esfuerzos de restablecimiento de una organización.

Los desastres llegan en muchas formas: pérdida de información, robo, catástrofes naturales… Cualquiera de estas tiene el potencial de destruir la información; pero en un mundo ideal, todas las aplicaciones y datos se restauran inmediatamente.

Por supuesto, la realidad es distinta. Aunque teóricamente sí es posible lograrlo, este tipo de operaciones son costosas e implican el uso de muchos recursos. Por esta razón, TI se vale del Tiempo Objetivo de Recuperación (RTO por sus siglas en inglés) y Punto Objetivo de Recuperación (RPO), de acuerdo a su presupuesto, recursos y prioridades para cumplir con sus objetivos.

¿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 RPO

Si se tiene un RPO de 4 horas para una aplicación, la brecha máxima entre el respaldo y la pérdida de información será de 4 horas. Esto no necesariamente significa que se perderán 4 horas de datos. Si la falla ocurre durante un momento de poca actividad, el impacto sería casi nulo; sin embargo, si esta sucede en una hora pico, la pérdida sí podría ser equivalente al tiempo de inactividad. En este caso, un respaldo más frecuente permitirá alcanzar el RPO deseado.

Dependiendo de la prioridad de cada aplicación, un RPO individual puede ir desde 25 a 12, 8, 4 horas o hasta algunos cuantos segundos. Un RPO de 8 horas puede aprovechar la solución de respaldo existente siempre y cuando tenga un impacto mínimo en los sistemas de producción. Por otro lado, un RPO de 4 horas necesita replicación instantánea.

Finalmente, un RPO de casi cero requiere replicación continua. En los casos en los que el RPO y RTO es cero, la replicación continua se combina con los servicios de conmutación por error para una aplicación del casi 100 por ciento y disponibilidad de datos.

¿Qué es RTO?

RTO se refiere al tiempo que una aplicación puede estar fuera de servicio sin causar un daño significativo al negocio. Si bien algunas aplicaciones pueden mantenerse inactivas por días sin mayores consecuencias, otras más generan molestia cuando quedan fuera de servicio por tan solo unos segundos.

Por esta razón, RTO no es exclusivamente el tiempo que pasa entre la pérdida y la recuperación. También tiene que ver con los pasos que TI debe tomar para restaurar la aplicación y sus datos. Si el departamento ha invertido en servicios de conmutación por error para aplicaciones de alta prioridad, entonces sí se puede expresar el RTO en segundos. TI también debe restaurar la actividad en sitio; pero debido a que la aplicación está procesando en la Nube, en realidad se puede dar el tiempo que necesite.

El objetivo del RTO es categorizar aplicaciones por prioridad y potencial de pérdida para ajustar los recursos en consecuencia.

Ejemplo de RTO

Los planes para un RTO de casi cero requieren de servicios de conmutación por error. Uno de 4 horas permite una recuperación en sitio empezando por el bare metal y terminando con una disponibilidad completa de aplicaciones y datos. Finalmente, para un RTO de 8 horas, TI suele firmar contratos con integradores de sistemas locales.

RTA (Tiempo de Recuperación Real)

La cantidad de tiempo verificada requerida para restaurar los sistemas de TI después de un desastre. Este objetivo puede determinarse durante la misma emergencia o un simulacro. El RTA puede ayudar a una organización a alcanzar su RTO y determinar estrategias o recursos adicionales para lograrlo.

Lee también: 7 consejos para mantener la eficiencia del service desk durante la pandemia

Diferencias entre RTO y RPO

Base para la evaluación

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.

Relevancia de costos

Los costos asociados con mantener un RTO pueden ser más grandes que los de un RPO. Eso es porque el primero involucra toda la infraestructura del negocio, y no solo los datos.

Automatización

Alcanzar los objetivos del RPO solamente requiere de realizar respaldos en el intervalo correcto. 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 porque involucra la restauración de todas las operaciones de TI. Es virtualmente imposible alcanzar las metas de RTO de una forma totalmente automatizada; 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.

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.

¿Necesitas ayuda con tu Plan de Recuperación ante Desastres?

En icorp podemos ayudarte a diseñar una estrategia con las diferentes soluciones tecnológicas.

Fuentes: StorageCraft, Databarracks