Ver demo×
×

¡Vean a NinjaOne en acción!

Al enviar este formulario, acepto la política de privacidad de NinjaOne.

RPO frente a RTO: Descúbre cuál es la diferencia

Los MSP tienen el deber con sus clientes de minimizar el tiempo de inactividad y mantenerlos en línea y en pleno funcionamiento. Con ese fin, una parte de mantener bajo el tiempo de inactividad es prepararse para lo inesperado. El proceso de establecer objetivos para resolver problemas y volver a estar en línea es fundamental para reducir el tiempo de inactividad del cliente.

El objetivo de tiempo de recuperación (RTO) y el objetivo de punto de recuperación (RPO) son conceptos que desempeñan funciones clave en los procesos que se planifica la recuperación ante desastres. Los proveedores de servicios gestionados deben examinar cada una de estas métricas, definir su función en el proceso de recuperación y trabajar para incorporar estos objetivos en los planes de resiliencia de los clientes.

De qué va a tratar este artículo:

  • ¿En qué consiste el RTO y RPO?
  • Las diferencias entre los objetivos de tiempo de recuperación y los objetivos de punto de recuperación
  • Por qué el RTO y RPO son importantes para los proveedores de servicios gestionados
  • Cómo calcular el RTO y RPO
  • Cómo las herramientas de TI le ayudan a cumplir los objetivos de recuperación

¿Qué es un RTO?

El objetivo de tiempo de recuperación (RTO) define los parámetros sobre la rapidez con la que una empresa debe recuperar sus sistemas del tiempo de inactividad después de un incidente. Esto se calcula para cada cliente individual y es único para su operación.

Definir un RTO le permite tomar decisiones más informadas sobre las soluciones y la implementación de la copia de seguridad y recuperación de desastres (BDR). Los números concretos hacen que sea más fácil mantener las cosas realistas y basadas en objetivos, en lugar de confiar en una idea ambigua como “recuperar y hacer funcionar lo más rápido posible”. Las generalizaciones son difíciles de definir en los acuerdos de nivel de servicio.

Es fácil visualizar un RTO funcionando. Es simplemente un objetivo establecido al analizar los costos y riesgos asociados con el tiempo de inactividad (es importante definir qué significa “tiempo de inactividad” para el cliente específico) y determinar cuánto tiempo pueden esperar para recuperarse antes de que las pérdidas sean significativas.

Algunos factores que pueden influir en el RTO de un usuario incluyen lo siguiente:

  • Cuántos ingresos perderá su empresa por cada hora de inactividad
  • La cantidad de pérdida financiera que pueden y podrán absorber durante una emergencia
  • La disponibilidad de los recursos necesarios para restaurar las operaciones
  • La tolerancia de sus propios clientes al tiempo de inactividad

Si un cliente necesita que sus sistemas funcionen dentro de tres horas, este es su RTO. Si su tiempo promedio calculado para la recuperación efectiva es de cinco horas, excedió su RTO por dos horas. Debido a que este es un cálculo preliminar, indica que se deben realizar más inversiones en BDR para reducir el tiempo real de recuperación.

¿Qué es un RPO?

El objetivo de punto de recuperación (RPO) es un umbral de riesgo o pérdida similar. Mientras que el RTO define la cantidad de tiempo que se puede perder, el RPO define la cantidad de datos que su cliente puede perder sin resultados significativos o catastróficos.

Esto se centra en gran medida en la cadencia de la copia de seguridad de datos, la frecuencia del último punto de la copia de seguridad. Si su cliente perdiera todo en este momento y solo tuviera su última copia de seguridad, ¿cuántos datos esenciales tendrían aún?

Muchos utilizan las operaciones de atención médica como ejemplo de RPO. Si bien algunas empresas pueden permitirse perder los datos que ingresan en el transcurso de una semana (es posible que vuelvan a ingresarlos de los documentos en papel), los hospitales, por lo general, no tienen ese margen de error. Con decenas de profesionales médicos dispensando miles de medicamentos cada día, hay muy pocas posibilidades de que el personal recuerde todo lo que ha hecho o necesita hacer con respecto al tratamiento.

Y como hablamos de productos farmacéuticos, perder incluso los datos de un día podría significar equivocarse en las dosis o mezclar medicamentos. Estos son posibles problemas fatales, por lo que esta operación necesita hacer una copia de seguridad de sus datos con frecuencia. Esa necesidad de datos actualizados informa su RPO.

Los RPO son importantes para el MSP porque ayudan a guiar sus recomendaciones para soluciones de copia de seguridad de datos, en especial cuando se trata de espacio y modalidad de almacenamiento. Copias de seguridad más frecuentes significan más uso de datos. Es importante que los clientes entiendan por qué su RPO es importante al explicar el valor de ese costo adicional.

Algunos factores que pueden influir en el RPO de un cliente incluyen lo siguiente:

  • Complejidad y número de aplicaciones y sistemas fundamentales
  • Volumen de datos y requisitos de acceso
  • Con qué frecuencia cambian los datos (es decir, cada cuánto se agrega o modifica información importante en un archivo)
  • Frecuencia y método de la copia de seguridad de datos

¿Cuál es la diferencia entre RTO y RPO?

Ambas métricas son importantes al formular planes de copias de seguridad y recuperación de datos. El RPO y RTO le ayudarán a decidir las funciones clave de la copia de seguridad y recuperación e informarán sus recomendaciones sobre las soluciones BDR del cliente. En definitiva, su objetivo es asegurarse de que los datos y sistemas fundamentales estén disponibles cuando sea necesario, y estos cálculos pueden ayudarle a lograr ese objetivo.

Si bien ambos son funcionales dentro de la planificación de la recuperación, son diferentes en la práctica. Los RTO activos, por lo general, se designan después de que ocurre un evento (dispensa a los que se usan de forma teórica durante la planificación). Los RPO siempre se determinan antes de que se necesite la recuperación.

En algunos casos, la planificación de la recuperación se centra en los sistemas y no en los datos. En estas situaciones, la única preocupación es el RTO. Tan pronto como los datos se conviertan en parte de la ecuación, el MSP deseará calcular y tener en cuenta el RPO. Vale la pena señalar que cuando se combinan los dos, un RTO corto por lo general requiere un RPO igual de corto.

Cálculo del RPO y RTO

Por lo general, determinará los objetivos del RTO y RPO relevantes durante un análisis de impacto empresarial (BIA) o un análisis de riesgo general.

Al usar un BIA, su objetivo es identificar los procesos empresariales esenciales e identificar las tecnologías y los datos necesarios para respaldar esas operaciones. Estos informes, a menudo, considerarán las implicaciones financieras del tiempo de inactividad o la interrupción e ilustrarán los posibles riesgos del tiempo de inactividad.

Por lo general, el MSP buscará aportes de la dirección del cliente o de la alta gerencia relevante para identificar objetivos y asignar valores numéricos a los escenarios de recuperación. Es posible que comience explorando el mejor y el peor de los casos y trabajando hacia atrás para encontrar números razonables y alcanzables.

No existe una fórmula estándar para calcular los valores de RTO y RPO, ya que son valores numéricos de tiempo exclusivos de cada organización. Un servidor esencial puede tener un RTO de una hora, mientras que el RTO de un sistema menos esencial puede ser de 24 horas. Todo el propósito del BIA es encontrar objetivos razonables basados ​​en qué tan necesarios son varios sistemas para el usuario.

A medida que disminuyen el RTO y RPO, es probable que aumenten los costos involucrados en alcanzar esos objetivos. En ese sentido, los cálculos de RTO y RPO le brindan la información que necesita para buscar soluciones y puntos de precio, una planificación esencial cuando se trata de mantener acuerdos rentables.

Las cifras de BIA, RTO y RPO también pueden ser útiles durante el proceso de ventas. A menudo surgen conflictos en torno a los costos, por lo que es importante poder demostrar el valor de los servicios de BDR. Esto es más fácil cuando se señala que las soluciones menos costosas no cumplirían con sus necesidades de RTO y RPO y generarían mayores costos en caso de que ocurriera un desastre.

Cómo NinjaOne ayuda a los MSP a cumplir con RTO y RPO

Según los resultados de su análisis de riesgo y BIA, debe conocer bien lo que podría poner en riesgo para su cliente. Parte del análisis general es determinar la frecuencia de las ocurrencias, la probabilidad del peligro y los posibles efectos que podrían tener en el cliente.

Una vez que haya cuantificado estas métricas basadas en el riesgo, puede convertir estos factores en activos y medidas recomendados. Un hub centralizado de supervisión y gestión remota como NinjaOne hace que ambos procesos sean mucho más simples. Al agregar datos sobre la utilización y los activos importantes del cliente, puede obtener una visión más profunda al determinar el RPO y el RTO.

Por naturaleza, el hecho de que BDR sea primordial para el uso de métricas RTO y RPO significa que la solución de copia de seguridad integrada de NinjaOne le ayudará a abordar el desafío sin problemas, no solo a evaluarlo.

Conclusión

Existen dos métricas que ayudan a los MSP a lograr los mejores resultados cuando se trata de copias de seguridad y recuperación de datos: Objetivo de tiempo de recuperación y Objetivo de punto de recuperación. Ambas métricas son esenciales y están interrelacionadas cuando se trabaja con soluciones de copia de seguridad y recuperación de datos, estrategias de continuidad empresarial y planes de recuperación ante desastres.

Para un MSP que proporciona copia de seguridad y recuperación de datos, estas métricas son fundamentales para planificar y valorizar la solución. El RTO y RPO ayudan a determinar la copia de seguridad de datos y la configuración de tecnología óptimas para lograr sus objetivos. Estas cifras también pueden ser importantes para el cumplimiento y la auditoría, ya que los auditores pueden buscar evidencia de estos valores como los controles de la copia de seguridad y recuperación de datos marcados.

NinjaOne puede ayudarle a obtener, calcular y utilizar RPO y RTO para sus clientes, al asegurar que brinde el mejor servicio y cumpla con las expectativas en lo que respecta al tiempo de actividad y la continuidad operativa.

También te puede gustar

¿Listo para convertirte en un Ninja informático?

Descubre cómo NinjaOne puede ayudarte a simplificar las operaciones de TI.

Términos y condiciones de NinjaOne

Al hacer clic en el botón «Acepto» que aparece a continuación, estás aceptando los siguientes términos legales, así como nuestras Condiciones de uso:

  • Derechos de propiedad: NinjaOne posee y seguirá poseyendo todos los derechos, títulos e intereses sobre el script (incluidos los derechos de autor). NinjaOne concede al usuario una licencia limitada para utilizar el script de acuerdo con estos términos legales.
  • Limitación de uso: sólo podrás utilizar el script para tus legítimos fines personales o comerciales internos, y no podrás compartirlo con terceros.
  • Prohibición de republicación: Bajo ninguna circunstancia está permitido volver a publicar el script en ninguna biblioteca de scripts que pertenezca o esté bajo el control de cualquier otro proveedor de software.
  • Exclusión de garantía: El script se proporciona «»tal cual» y «según disponibilidad», sin garantía de ningún tipo. NinjaOne no promete ni garantiza que el script esté libre de defectos o que satisfaga las necesidades o expectativas específicas del usuario.
  • Asunción de riesgos: El uso que el usuario haga del script corre por su cuenta y riesgo. El usuario reconoce que existen ciertos riesgos inherentes al uso del script, y entiende y asume cada uno de esos riesgos.
  • Renuncia y exención: El usuario no hará responsable a NinjaOne de cualquier consecuencia adversa o no deseada que resulte de su uso del script y renuncia a cualquier derecho o recurso legal o equitativo que pueda tener contra NinjaOne en relación con su uso del script.
  • CLUF: Si el usuario es cliente de NinjaOne, su uso del script está sujeto al Contrato de Licencia para el Usuario Final (CLUF).