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 (RTO) basado en la prioridad de su aplicación y en el presupuesto y los recursos asignados al RTO.
¿Qué es un RPO y en qué se diferencian los RTO?
Los RTO coinciden con los objetivos de punto de recuperación (RPO), una medición del tiempo desde el fallo, el desastre o un evento similar que cause pérdidas. Los RPO se calculan hacia atrás, hasta la última vez que sus datos fueron utilizables, probablemente la copia de seguridad más reciente. Los RPO y los RTO 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 RTO 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 RTO se puede expresar con seguridad en segundos, siempre y cuando el departamento de TI haya invertido en servicios de migración tras error. Los RTO 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 RTO
Los RTO 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 RTO representan las necesidades generales de su empresa y determinan cuánto tiempo puede sobrevivir su negocio sin infraestructura ni servicios informáticos. Los RTO 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 RTO que satisfaga las necesidades de la empresa. Por ejemplo, no se puede cumplir un RTO 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 RTO suelen ser complicados. Su departamento de TI puede agilizar parte del proceso de recuperación automatizando todo lo posible. El RTO puede tener costos mayores que los de un RPO granular, y un RTO exigente afecta a toda su infraestructura de negocio, y no solo a los datos. El costo de lograr un RTO o RPO 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.
Conseguir un RTO o RPO casi nulo
Aunque los RTO y RPO varían en función de la prioridad de las aplicaciones y los datos, es increíblemente costoso para cualquier empresa ofrecer un RTO o RPO casi nulo para todas sus aplicaciones. Un tiempo de actividad del 100% para el RTO y cero pérdida de datos para el RPO solo pueden alcanzarse invirtiendo en la réplica continua de datos y en entornos virtuales.
Ejemplo de un RTO
La recuperación de elementos granulares es un ejemplo de un RTO. 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 RPO 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 RTO y RPO 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.