Saltar al contenido principal

Explicación del objetivo de tiempo de recuperación

 

Recuperación ante desastres y continuidad empresarial

Interrupciones de energía. Robo. Servidores y unidades de disco duro dañadas. Ciberataques y ransomware. Tornados, terremotos y huracanes. Hay muchos tipos de catástrofes que pueden causar estragos en su negocio si no está preparado para ello. Dado que estas catástrofes son a menudo inevitables, contar con una infraestructura de TI sólida y establecer tiempos de recuperación y objetivos puntuales y regulares es esencial para reforzar su recuperación. Es posible que su departamento de TI realice una migración tras error de una aplicación y replique sus datos para una pérdida casi nula, pero hacerlo requiere recursos considerables. Su departamento informático necesita establecer un recuperación ante desastres y continuidad empresarial basado en la prioridad de su aplicación y en el presupuesto y los recursos asignados al un objetivo de tiempo de recuperación .

¿Qué es un objetivo de punto de recuperación y en qué se diferencia de un objetivo de tiempo de recuperación?

Los objetivo de tiempo de recuperación (OTR) coinciden con los objetivos de punto de recuperación (OPR), una medición del tiempo desde el fallo, el desastre o un evento similar que cause pérdidas. Los OPR se calculan hacia atrás, hasta la última vez que sus datos fueron utilizables, probablemente la copia de seguridad más reciente. Los OPR y los OTR son conceptos cruciales para la continuidad del negocio y son métricas de negocio necesarias para determinar con qué frecuencia su empresa debe planificar sus copias de seguridad de datos.

¿Qué es un objetivo de tiempo de recuperación?

Los OTR representan la cantidad de tiempo que una aplicación puede estar fuera de servicio sin que suponga un daño significativo para una empresa y el tiempo que tarda el sistema en pasar de la pérdida a la recuperación. Este proceso de recuperación incluye los pasos que TI debe seguir para devolver la aplicación y sus datos a su estado anterior al desastre. Para aplicaciones de alta prioridad, un OTR se puede expresar con seguridad en segundos, siempre y cuando el departamento de TI haya invertido en servicios de migración tras error.   Los OTR requieren que su departamento de TI clasifique primero las aplicaciones en función de su prioridad y del riesgo de pérdida de negocio. Después, el departamento informático asigna a estas aplicaciones la cantidad adecuada de recursos de su empresa, es decir, tiempo, dinero e infraestructura informática.

Determinación de un objetivo de tiempo de recuperación  

Los OTR se utilizan para medir el tiempo que tarda el departamento informático en recuperar los datos tras el desastre. Para su base de evaluación, los OTR representan las necesidades generales de su empresa y determinan cuánto tiempo puede sobrevivir su negocio sin infraestructura ni servicios informáticos. Los OTR necesitan primero ajustarse a las posibilidades de su departamento de TI. Los administradores informáticos necesitan comprender a la perfección los diferentes tipos de velocidades de restauración para calcular un OTR que satisfaga las necesidades de la empresa. Por ejemplo, no se puede cumplir un OTR de una hora si el tiempo mínimo de restauración posible es de dos horas.   

Dado que el proceso implica restaurar todas las operaciones de TI, los OTR suelen ser complicados. Su departamento de TI puede agilizar parte del proceso de recuperación automatizando todo lo posible.  El OTR puede tener costos mayores que los de un RPO granular, y un OTR exigente afecta a toda su infraestructura de negocio, y no solo a los datos. El costo de lograr un OTR o OPR se corresponde con la priorización de aplicaciones y datos del departamento de TI. TI prioriza las aplicaciones y los datos en función de sus ingresos y de sus riesgos.  Si los datos de una aplicación están regulados, la pérdida de datos de dicha aplicación podría dar lugar a fuertes sanciones, independientemente de la frecuencia con la que se utilice dicha aplicación.

Alcanzar un objetivo de tiempo de recuperación o un objetivo de punto de recuperación casi nulo.

Aunque los OTR y OPR varían en función de la prioridad de las aplicaciones y los datos, es increíblemente costoso para cualquier empresa ofrecer un OTR o OPR casi nulo para todas sus aplicaciones. Un tiempo de actividad del 100% para el OTR y cero pérdida de datos para el OPR solo pueden alcanzarse invirtiendo en la réplica continua de datos y en entornos virtuales.

Ejemplo de objetivo de tiempo de recuperación  

La recuperación de elementos granulares es un ejemplo de un OTR. Para este ejemplo, un usuario de una empresa con mucha actividad suprime un correo electrónico importante y vacía la carpeta de la papelera. Esta empresa utiliza Microsoft Exchange como aplicación esencial, y es el departamento informático quien siempre hace una copia de seguridad de los cambios a nivel delta en Exchange junto con una aplicación de copias de seguridad, que cuenta con copias de seguridad y recuperación granulares. Esta característica permite al departamento de TI recuperar rápidamente el correo electrónico importante en unos cinco minutos, en lugar de tener que restaurar una máquina virtual completa para un único correo electrónico.

Coordinación de resiliencia y recuperación tras desastre

Hay muchos retos para una estrategia de recuperación tras desastre, en particular para una recuperación tras desastre de un entorno de TI híbrido. Estos retos incluyen, entre otros, los siguientes:

  • Cargas de trabajo desplegadas en distintos entornos
  • Interdependencias entre infraestructura de TI y aplicaciones
  • Devolver todos los dispositivos, componentes y aplicaciones al OPR y restablecer el pleno funcionamiento de la empresa
  • La restauración del sistema puede retrasarse todavía más si la recuperación de sistemas y aplicaciones se realiza en el orden incorrecto.

¿Qué se puede hacer para desarrollar y aplicar con éxito una estrategia de recuperación tras desastre a pesar de todos los obstáculos? Recuperar algunas aplicaciones cruciales en pocas horas es tradicionalmente posible con el equipo de TI adecuado, pero requiere una gran cantidad de valiosos recursos. Hoy en día se exigen mayores OTR y OPR y una recuperación del sistema en la que se restauren rápidamente múltiples aplicaciones esenciales. Ahora es posible minimizar el impacto de la interrupción y realizar una recuperación en cuestión de minutos tras una interrupción. La automatización es crucial, ya que permite que los programas de recuperación tras desastre se escalen mediante la automatización de los flujos de trabajo entre las diferentes aplicaciones de forma rápida y fiable en una transición a entornos híbridos. 

La tecnología actual de coordinación de la resiliencia le ayuda a implementar con éxito su estrategia de recuperación tras desastre y a reducir las demandas de tiempo de inactividad de la producción y la exposición del negocio como resultado de las interrupciones. En términos de preparación, la coordinación de la resiliencia ayuda a las organizaciones a realizar con éxito pruebas de recuperación tras desastre con menos personal. La coordinación de la resiliencia también ayuda a estas organizaciones a producir una mayor reducción en la preparación y validación de los simulacros de recuperación tras desastre. Una de las principales ventajas de la tecnología de coordinación de resiliencia es su capacidad para funcionar en entornos físicos, virtuales y en la nube, al tiempo que se mantiene el conocimiento de las aplicaciones. Dado que el autoservicio y los bajos parámetros de los acuerdos de nivel de servicio se están convirtiendo constantemente en expectativas de los usuarios finales para los servicios en cloud, las estrategias de resiliencia basadas en la coordinación son cada vez más cruciales para las empresas modernas que buscan adoptar entornos en cloud.