En una empresa tuvieron un incidente el año pasado, el cual dañó por completo su sistema de facturación, el servidor donde estaba alojado este servicio tuvo un desperfecto por lo cual ya no pudo emitir más facturas, el tiempo que tardó en recuperarse fue de 12 horas, y la pérdida de información fue de media día, se perdieron facturas por un valor de 250 mil pesos, El tiempo que la empresa tardó en recuperar la información usando métodos manuales y tradicionales fue de 12 horas aproximadamente. Si esta empresa hubiera contado con un plan de continuidad de negocio o un plan de acción adecuado de recuperación de información, los tiempos de afectación se hubieran reducido.

RTO y RPO son conceptos muy importantes que entendamos su significado para aplicarlos en una estrategia de recuperación en caso de desastre, estos términos son básicos así como cruciales al momento de definir y aplicar un DRP en tu plan de continuidad de negocios (BCP).

DRP (Disaster Recovery Point) es un plan de recuperación de desastres de la infraestructura tecnológica, este es muy importante ya que en caso de alguna eventualidad, es necesario contar con los planes de acción para recuperar la operación de infraestructura en el menor tiempo posible ante un desastre no previsto en una empresa u organización.

BCP (Bussines Continuity Plan) es el plan de la continuidad del negocio, este plan es más amplio ya que abarca no solamente tu DRP, te permite evaluar e identificar riesgos potenciales para el negocio.

Estos dos puntos hablaremos en próximas publicaciones, ahora nos enfocaremos en definir RTO y RPO.

RPO “Recovery Point Objetive”

Es la mínima cantidad de información que una empresa puede permitirse perder, debido a un incidente; La cual podrá recuperar utilizando la última copia de seguridad o respaldos íntegro que se haya realizado Para definir este parámetro lo más recomendable es analizar la criticidad de la información que se está respaldando o protegiendo, Por ejemplo; una empresa u organización cuenta con un sistema de facturación informático, que se utiliza en diferentes sucursales de la empresa y está distribuido en diferentes zonas del territorio nacional. Este sistema es muy crítico y no debe perder algún tipo de información, ya que si sucediera alguna falla afectaría temas contables y financieros de la empresa. 

RTO “Recovery Time Objetive”

Es el tiempo que una empresa puede tolerar la falta de operación de sus sistemas o aplicaciones con mínima afectación a su negocio. La mejor recomendación para definir los tiempos que una empresa puede tener abajo sus servicios informáticos, tales como los aplicativos, la infraestructura tecnológica, entre otros, es definir qué tan críticos son estos servicios dentro de la organización. No es lo mismo perder el servicio por un periodo de una hora de una aplicación o sistema que es altamente utilizado, como por ejemplo un sistema de facturación o embarques versus un sistema de nómina que se usa cada quince días o cada semana. 

Entonces podemos resumir que RPO mide la cantidad de información que puede permitirse perder y el RTO es el tiempo en el cual puede estar abajo un servicio, aplicación, o infraestructura.

La recomendación para definir los parámetros del RPO y RTO se define en conjunto con todas las áreas involucradas (redes, aplicación, respaldos, wintel, DBA, etc.).

Ya teniendo definido el RTO y RPO se puede identificar, analizar las estrategias de recuperación, además de las herramientas necesarias, hablamos de las soluciones de respaldo, alta disponibilidad, replicación de información, hardware, aplicaciones, así como asesorarse con una empresa que puedan apoyarlo en definir estos parámetros y darte las mejores prácticas 

Teniendo esta información podemos determinar los  tiempos deseables y los tiempos reales de recuperación.