Introducing G2.ai, the future of software buying.Try now

Por qué su negocio necesita un objetivo de tiempo de recuperación para sobrevivir

14 de Julio de 2022
por Keerthi Rangan

A veces las cosas salen mal. A pesar de toda la planificación del mundo, las cosas pueden, y van a, salir mal.

La clave es prepararse para el fracaso. Eso significa predecir el desastre y planificar con anticipación para "¿qué sucederá cuando ocurra?". Pero tus mejores estrategias y mecanismos de respaldo durante una interrupción pueden ser en vano si no sabes cuánto tiempo estarán inactivos tus sistemas o qué aplicaciones son más críticas para las operaciones continuas del negocio.

Los objetivos de tiempo de recuperación (RTO) son un paso esencial en la definición de tu plan de continuidad de negocio y recuperación ante desastres (BCDR). Los RTO requieren que analices cuidadosamente tus aplicaciones y su importancia relativa para tu negocio.

Elegir software de recuperación ante desastres como servicio (DRaaS) permite a las empresas implementar una solución simple pero poderosa con un RTO bajo para minimizar la pérdida de datos críticos y el impacto financiero.

El RTO es una métrica importante para saber cuán rápida y eficientemente puedes recuperar información en caso de un desastre. Saber cuánto tiempo necesita sobrevivir tu información puede ayudarte a establecer una estrategia de respaldo eficiente y un plan general de compra de hardware de TI.

Para asegurar un RTO apropiado, los departamentos de TI utilizan failover para prevenir el tiempo de inactividad y facilitar una transición suave entre sistemas. Cuando ocurre un desastre, tu negocio debe estar preparado para una recuperación rápida. Además, tu equipo de TI necesita desarrollar planes de contingencia para saber qué aplicaciones recuperar y cuán rápido.

Línea de tiempo de RTO

Los equipos de TI también aseguran que las aplicaciones tengan un respaldo confiable listo para minimizar el tiempo de inactividad. De esta manera, otros servidores pueden tomar el control y tener tu aplicación funcionando en segundos en caso de un desastre.

Puedes medir los RTO en segundos, minutos, horas y días. Ten en cuenta estas unidades mientras desarrollas un plan de recuperación ante desastres (DRP).

Para facilitar un DRP efectivo, los administradores pueden elegir las soluciones de recuperación ante desastres (DR) más adecuadas para un RTO establecido. Por ejemplo, si el RTO de una aplicación es de una hora, un respaldo de base de datos redundante en sistemas remotos podría ser la solución ideal. El almacenamiento en cinta o en la nube fuera del sitio es más factible si el RTO es de cinco días.

¿Por qué es importante el objetivo de tiempo de recuperación?

El tiempo de inactividad es costoso. El cuarenta y cuatro por ciento de las empresas informan que el costo por hora del tiempo de inactividad, incluyendo el tiempo del personal de TI interno y externo, la pérdida de productividad y el reemplazo del sistema de TI fácilmente supera $1M. Con tanto dependiendo de tu infraestructura de TI y tiempo de actividad, los objetivos de tiempo de recuperación aseguran que las empresas estén bien preparadas para el tiempo de inactividad y la recuperación.

Los RTO te permiten planificar cuán rápido puedes recuperar una aplicación crítica si falla. Los RTO generalmente se miden en segundos. Si una aplicación no está disponible durante cinco segundos, no tiene sentido pagar a los desarrolladores para restaurar datos sobre la marcha. En cambio, las aplicaciones prioritarias deben tener sistemas de failover que inicien el proceso de restauración antes de que se vuelvan inoperativas.

En el improbable caso de un tiempo de inactividad prolongado del servidor o un evento prolongado de corrupción de datos, no querrías que los costosos esfuerzos de recuperación se desperdicien tratando de recuperar datos antes de agotar todos los respaldos disponibles. Los RTO permiten a las organizaciones priorizar sus inversiones y asignar presupuestos en consecuencia.

Para determinar un marco de RTO práctico, separa las aplicaciones de alta prioridad. Comienza estableciendo un proceso que determine el riesgo de pérdida de tu organización.

Puedes establecer RTOs apropiados con un proceso de evaluación de riesgos que identifique los componentes críticos y de valor agregado de tu operación. Las aplicaciones de alta prioridad generalmente tratan con cuentas de clientes, servicio al cliente y aplicaciones críticas para la misión, como operaciones de manufactura o logística que dependen en gran medida de la tecnología.

¿Quieres aprender más sobre Soluciones de Recuperación ante Desastres como Servicio (DRaaS)? Explora los productos de Recuperación de Desastres como Servicio (DRaaS).

¿Cómo funciona el objetivo de tiempo de recuperación?

Los objetivos de tiempo de recuperación determinan cuánto tiempo puede durar una empresa después de un contratiempo antes de recuperarse por completo. Por ejemplo, una empresa corporativa tenía un RTO de 24 horas hace algunos años. En ese caso, puede prosperar al menos 24 horas sin acceso a sus datos y sistemas típicos antes de sufrir daños irreversibles.

Los RTO no son estrictos ya que no especifican una fecha de recuperación. Te permiten enfocarte más en acercarte a un potencial específico a través de una planificación y evaluación rigurosas que en el objetivo final.

Muchos factores influyen en los tiempos de recuperación, incluyendo la hora del día y la semana en que ocurrió el incidente. También impactan tanto en los RTO como en los objetivos de punto de recuperación (RPO). Las aplicaciones de alta prioridad demandan objetivos más estrictos. Para tales aplicaciones, el equipo de TI necesita organizar replicación continua y de instantáneas.

Intervalos de muestra de RTO

El RTO es un tiempo de resistencia después de que se detecta una amenaza. La mayoría de las empresas de TI no pueden permitirse lograr un RTO cercano a cero. Sin embargo, pueden optimizar aplicaciones y servicios para acercarse lo más posible a un objetivo específico. Para aplicaciones menos críticas, el valor de RTO puede requerir períodos más largos de lo habitual. Los planes de RTO cercano a cero para aplicaciones críticas para la misión necesitan capacidad de failover instantánea.

Dependiendo de la gravedad de la interrupción, puedes establecer un objetivo de RTO realista para la recuperación de datos. Sin embargo, el tiempo de restauración también depende de las limitaciones de una empresa. Por ejemplo, si restaurar todos los servicios y procesos de TI toma tres horas, el RTO debe ser al menos de tres horas.

El reloj de RTO comienza instantáneamente cuando comienza el proceso de recuperación ante desastres. Considera la siguiente descomposición de categorías de RTO al calcular el RTO para tus unidades de negocio:

  • Una hora: Útil para procesos que requieren respaldo de datos redundantes en discos duros externos.
  • Cinco días: Hacer copias de seguridad de datos en un disco compacto, cinta o almacenamiento en disco remoto es el método más rentable en caso de un desastre.

Ejemplos de objetivos de tiempo de recuperación

Dependiendo del análisis de impacto empresarial (BIA), el objetivo de tiempo de recuperación para una interrupción de aplicación o servicio puede ser ligeramente diferente. Las aplicaciones críticas para la misión, por ejemplo, a menudo tienen un RTO más bajo. En contraste, los servicios menos críticos tienen un RTO más extenso, ya que la duración de una interrupción y la tolerancia a la pérdida relacionada es mayor.

Aquí hay algunos ejemplos de RTOs:

  • Servicios financieros: Estos son servicios de alta prioridad, con un RTO lo más cercano a cero posible.
  • Correo electrónico: Aunque el correo electrónico es un servicio esencial para muchos, el tiempo de recuperación puede llevar hasta 4 horas. Las interrupciones del correo electrónico no siempre equivalen directamente a pérdida de ingresos.
  • Servicios de impresión: Es inconveniente y a veces costoso cuando una impresora está inactiva o inutilizable. Estas pérdidas son mucho menores que las incurridas durante una interrupción de servicios financieros o incluso una interrupción de correo electrónico. El RTO para servidores de impresión puede alcanzar las 24 horas en circunstancias extremas.

Factores que influyen en el objetivo de tiempo de recuperación

Al determinar el ritmo de recuperación durante una copia de seguridad de intervalo largo, siempre debes establecer el RTO basado en los tiempos en que la aplicación o el sistema de seguridad está en servicio. Como el RTO es "sensible al tiempo" para aplicaciones de uso común, debes tener en cuenta los siguientes factores al calcular el RTO:

  • Análisis de costo-beneficio para sistemas de recuperación
  • Costos de interrupción y remediación
  • Desafíos del proceso de recuperación
  • Esfuerzos de los equipos de TI para reparar la infraestructura
  • Uso prioritario de sistemas y datos específicos

RTO en la planificación de recuperación ante desastres

La recuperación ante desastres es un plan claro que ayuda a una empresa a recuperarse y reanudar las operaciones comerciales regulares. Esto hace que definir el RTO sea vital para un plan de continuidad de negocio (BCP). Con un objetivo de tiempo de recuperación como objetivo principal, una empresa puede realinear sus estrategias de respaldo de datos y failover y desplegar la cantidad adecuada de nuevos servicios. Esto garantiza la velocidad de recuperación objetivo.

Sin un RTO, una empresa no tiene idea de cuán rápido debería recuperarse de una amenaza grave o pérdida de datos. La planificación de recuperación ante desastres se trata de estar preparado para interrupciones imprevistas. Para estar preparado, necesitas una pista o plan para estimar el tiempo de recuperación.

Las empresas deben establecer un plan de continuidad de negocio sólido con objetivos predefinidos como parte del proceso de planificación de recuperación ante desastres. Estos objetivos deben incluir el RTO y el RPO para garantizar una tasa de recuperación esperada.

RTO vs. RPO

Si bien tanto el objetivo de tiempo de recuperación como el objetivo de punto de recuperación son componentes esenciales de la recuperación ante desastres y la planificación de continuidad de negocio, sirven para diferentes propósitos. Estos propósitos pueden ayudar a seleccionar una estrategia de respaldo de datos adecuada y proporcionar un marco para identificar y evaluar soluciones potenciales para reanudar las operaciones comerciales en un plazo cercano o igual al RPO y RTO.

RTO vs. RPO

El objetivo de tiempo de recuperación se refiere a tener políticas y tecnología en su lugar para que una empresa se recupere en un tiempo determinado. En comparación, el objetivo de punto de recuperación asegura que las soluciones de recuperación y respaldo de datos estén en su lugar con anticipación para minimizar la cantidad de datos perdidos durante una emergencia.

El RTO y el RPO trabajan juntos para restaurar las actividades regulares de una empresa. Determinan el impacto en el negocio al considerar el tiempo que lleva restaurar los servicios y la tolerancia máxima de pérdida de una organización.

Cómo calcular el objetivo de tiempo de recuperación

Calcular los objetivos de recuperación es un proceso de múltiples etapas que involucra varios factores, incluyendo el análisis de impacto empresarial, la estrategia de recuperación ante desastres y los planes de continuidad. El objetivo principal de un RTO es evaluar cuánto tiempo lleva recuperarse de un desastre grave y restaurar las operaciones comerciales normales.

Al calcular el RTO, recuerda que tendrás RTOs únicos para cada servicio o aplicación. Por ejemplo, tu tolerancia al tiempo de inactividad en tu servidor de correo debe ser significativamente menor que en un servidor de archivos raramente utilizado. Considera estos factores para que tu estrategia de recuperación ante desastres sea lo más eficiente y exitosa posible.

El primer paso para calcular un RTO es evaluar a fondo todos los sistemas, aplicaciones críticas para la misión, entornos virtuales y silos de datos. No hay forma de establecer correctamente un RTO sin una auditoría completa.

Después de completar la evaluación, la siguiente tarea es calcular la calidad de cada servicio y aplicación crítica para la misión en términos de cómo impactan los procesos comerciales. Este valor debe calcularse de manera granular y relacionada con el tiempo. El valor de la aplicación puede estar vinculado a cualquier acuerdo de nivel de servicio (SLA) actual que defina cuán accesible debe ser un servicio y puede incluir repercusiones si no se cumplen ciertos niveles de servicio.

Puedes estimar el RTO evaluando el valor de todos los servicios y aplicaciones en funcionamiento. Sin embargo, ten en cuenta que los requisitos de RTO pueden variar según la importancia de un servicio medida por el valor que proporciona a la empresa.

Calcular el RTO implica determinar cuán rápido debe reanudarse el proceso para un programa, servicio, sistema o datos en particular después de un incidente significativo. Esto se basa en la tolerancia a la pérdida del negocio como parte de su BIA. Definir la tolerancia a la pérdida ayuda a establecer cuánto tiempo de actividad puede permitirse perder una empresa durante un evento antes de que se reanuden las operaciones comerciales normales.

Además, involucra a todos los interesados de tu empresa en el proceso. Si bien el impacto financiero del tiempo de inactividad probablemente esté en la parte superior de tu lista de prioridades, es fundamental entender cómo el tiempo de inactividad afectará a cada aspecto de tu negocio antes de desarrollar un plan que funcione para todos.

Desafíos del RTO

A menudo no es factible que una empresa reanude inmediatamente todas las operaciones después de un contratiempo. El RTO es el punto anticipado en el que una empresa necesita restaurar sus funciones para prevenir cualquier complicación relacionada con los objetivos. Los RTOs difieren para diferentes operaciones. Un proceso crucial podría tener un RTO escalonado para permitir que las operaciones se reanuden progresivamente. Por ejemplo, una actividad podría estar al 40% de capacidad en tres días y al 100% en ocho días.

Uno de los desafíos más complejos al establecer RTOs es la posibilidad de amenazas o crisis imprevistas que interrumpan los flujos de trabajo. Estos riesgos incluyen el colapso de una instalación, interrupciones en un área de procesamiento, fallas de conectividad debido a desastres naturales y escasez de empleados de procesamiento debido a huelgas o problemas de transporte.

Estas circunstancias únicas que afectan negativamente los procesos existen fuera de los RTO establecidos. Esto se debe a que el tiempo requerido para resolverlos no puede ser estimado o planificado. En tales casos, evitar riesgos es preferible a establecer un RTO.

Por ejemplo, una empresa con excelentes procesos de seguridad puede evitar numerosas violaciones de seguridad. La tasa de criminalidad general en su región y los detalles de la empresa influyen en la seguridad.

No dejes que el tiempo de inactividad destruya tu éxito

Es fundamental establecer tu RTO y RPO y configurar los servicios que los apoyan. Sin embargo, estas métricas no tienen sentido a menos que pruebes regularmente tus sistemas y asegures que las tecnologías de respaldo de datos y failover del sistema estén operativas. Las pruebas regulares son la clave del éxito.

Planifica para desastres antes de que ocurran. Lleva tu recuperación ante desastres al siguiente nivel con DRaaS.

Keerthi Rangan
KR

Keerthi Rangan

Keerthi Rangan is a Senior SEO Specialist with a sharp focus on the IT management software market. Formerly a Content Marketing Specialist at G2, Keerthi crafts content that not only simplifies complex IT concepts but also guides organizations toward transformative software solutions. With a background in Python development, she brings a unique blend of technical expertise and strategic insight to her work. Her interests span network automation, blockchain, infrastructure as code (IaC), SaaS, and beyond—always exploring how technology reshapes businesses and how people work. Keerthi’s approach is thoughtful and driven by a quiet curiosity, always seeking the deeper connections between technology, strategy, and growth.