WHITE PAPER

10 consejos para la planificación de la recuperación de desastres y la continuidad del negocio La continuidad del negocio, es decir, la planificación, preparación e implementación de sistemas de negocios más resistentes en previsión del tiempo de inactividad no programado, suele ser considerada como un problema de TI, y la mayoría de las organizaciones dejan en manos del departamento de TI la entrega de una solución. Esto conduce invariablemente a la implementación de una amplia gama de soluciones tácticas, sin una estrategia predominante que proporcione orientación. En realidad, como el término lo indica, la continuidad del negocio es un problema del negocio y requiere un enfoque de negocio para resolverlo. ¿Cómo saber si su plan de continuidad del negocio actual es sólido? Esta es una lista de control rápida. • ¿Su plan requiere de mucha intervención manual? • ¿Su plan acepta la pérdida de datos por más de unos pocos segundos en los sistemas críticos? • ¿Su plan tarda más de una hora en restaurar el acceso a los sistemas críticos? • ¿Su plan depende de tecnología de backup y recuperación que tiene más de 30 años? Si su respuesta a cualquiera de las preguntas anteriores es sí, lo más probable es que usted esté expuesto a la pérdida de datos y al tiempo de inactividad del negocio. Todos hablan de cómo implementar la recuperación de desastres adecuada, pero ¿no sería igual de útil echar un vistazo a los peligros que le esperan si lo hace mal? Por eso, hemos preparado 10 consejos para ayudarlo a planificar y tomar decisiones.

1. Se trata del negocio, ¡no de la tecnología! Es importante recordar que la recuperación de desastres se trata de satisfacer una necesidad del negocio y debe ser impulsada por los requerimientos del negocio. Antes de tratar de encontrar la manera de poner en práctica la recuperación de desastres, es necesario dedicar tiempo a pensar en el por qué. Hable con líderes de negocio para entender sus prioridades. Ya sea que lo haga por correo electrónico o en charlas cara a cara, el punto es que usted no sabrá qué sistemas son los más importantes a menos que se lo pregunte a los usuarios de negocio. Comprender las necesidades de la organización le permitirá establecer prioridades que orienten sus opciones de tecnología.

2. Es una catástrofe, o quizá no Cuando piensa en la recuperación de desastres, probablemente imagine huracanes, inundaciones, ataques terroristas o cosas similares, y no una actualización de software fallida o un error de hardware en una pieza fundamental del equipo de red. Planificar el peor de los escenarios y ser sorprendido por errores triviales diarios es muy común. Su planificación debe tener en cuenta todas las eventualidades, desde las más ordinarias hasta las catastróficas.

3. ¿Cómo puede asignar presupuesto sin conocer el costo de la inactividad? En la mayoría de los casos, las organizaciones asignan un valor monetario a la planificación de la recuperación de desastres antes de determinar el riesgo financiero del tiempo de inactividad y de la pérdida de datos para el negocio. A menos que pueda cuantificar cuánto perdería con una interrupción de los sistemas críticos, será

10 consejos para la planificación de la recuperación de desastres y la continuidad del negocio | 1

WHITE PAPER

difícil establecer cuánto puede gastar para evitar esas pérdidas. Esto significa evaluar el costo financiero del tiempo de inactividad antes de asignar un presupuesto. No se olvide de incluir el cumplimiento regulatorio en su cálculo del costo del tiempo de inactividad. A menudo existen sanciones financieras si no se cumple con las obligaciones legales.

4. Se trata de medir el riesgo La clasificación precisa de un acontecimiento como un desastre puede cambiar de una organización a otra, e incluso de un departamento a otro. Algunos acontecimientos, como terremotos, pueden ser tan catastróficos que es obvio que la organización debe protegerse. Otros pueden ser comunes, como una falla en el hardware de red, aunque tienen un impacto financiero descomunal. Al pensar en la recuperación de desastres, es esencial preguntarse: ¿De qué estamos tratando de protegernos? No pase por alto el lugar común. Las pequeñas pérdidas por problemas comunes se acumulan rápidamente.

5. ¿Tiene un plan? Si su plan de recuperación de desastres es una nota adhesiva en las cintas de backup bajo la cama de su administrador de sistemas, está en problemas. Aunque suene alocado, un número sorprendente de organizaciones no tienen un plan de recuperación de desastres. Es esencial que desarrolle un documento formal que detalle todas las aplicaciones, el hardware, los servicios, los proveedores de servicios, el personal y las prioridades, y que contenga un compromiso con el documento por parte de todas las partes interesadas en la organización. El plan debe representar a todas las áreas funcionales y ofrecer una orientación clara sobre lo que sucede antes, durante y después de un desastre.

6. Tenemos un plan, pero no lo probamos Mantener un plan de recuperación de desastres sólo es útil si funciona. La única manera de garantizar que su plan funcione es probándolo. Probar el plan en condiciones simuladas de desastres es esencial, pero también puede ser difícil. Realizar pruebas de recuperación de desastres es costoso y requiere tiempo y recursos de las operaciones diarias. Sin embargo, a menos que la recuperación esté completamente probada a nivel de la aplicación, sin dudas encontrará dificultades durante un desastre del mundo real. Busque soluciones de protección de datos que lo ayuden a crear entornos de prueba de su plan de recuperación de desastres sin interrupciones.

7. ¿Quién es responsable y por qué? Un desastre en la vida real sería caótico y confuso. Si el personal clave no entiende sus responsabilidades en la recuperación de desastres, el proceso de recuperación será largo y estará lleno de problemas. Su plan de recuperación de desastres debe indicar claramente las funciones y responsabilidades de todos los involucrados, incluyendo qué hacer si el personal clave no está disponible. Estas personas también deben participar en las pruebas de su plan de recuperación.

8. ¿Objetivos de punto y tiempo de recuperación? ¿Qué es eso? Dos indicadores se utilizan para registrar la tolerancia de una aplicación al tiempo de inactividad y la pérdida de datos: el objetivo de punto de recuperación (RPO) y el objetivo de tiempo de recuperación (RTO). El RPO es una medida de la pérdida de datos. Cuanto mayor sea el RPO, mayor es la pérdida de datos que cada aplicación puede tolerar antes de que sea un problema para el negocio. Piense en ello como el momento específico hasta el que se pueden recuperar con éxito los datos. Todos los datos entre ese punto y el momento de la catástrofe se habrán perdido. El RTO es una medida del tiempo de recuperación. Cuanto menor sea el RTO, más rápido debe trabajar para que la aplicación vuelva a estar online antes de que la organización comience a sufrir pérdidas significativas. Si no conoce el RPO y RTO de cada aplicación, la recuperación de desastres será insuficiente. El RPO y el RTO son referencias que permiten definir los niveles de servicio ofrecidos.

10 consejos para la planificación de la recuperación de desastres y la continuidad del negocio | 2

WHITE PAPER

9. La recuperación le tomará más tiempo de lo que piensa Es esencial saber cuánto tiempo tardará en recuperar los sistemas clave del negocio. Incluso si puede acceder a las copias de backup en un sitio remoto, no hay garantía de que pueda recuperar las aplicaciones en tiempo y forma. ¿Puede restaurar los datos y reconstruir los sistemas de aplicaciones lo suficientemente rápido como para satisfacer a los usuarios de negocio? ¿Tiene el ancho de banda necesario para recuperar datos de un proveedor de servicios en la nube? Saber cuánto tiempo tardará en recuperar las aplicaciones y cuál será el efecto del tiempo de inactividad en el negocio puede ayudarlo a tomar decisiones diferentes acerca de la tecnología.

10. Irse a casa Volver a casa después de moverse a un sitio de recuperación de desastres es un componente que a menudo se pasa por alto en la planificación de la recuperación de desastres. Es fácil ver por qué. Cuando pensamos en un desastre, nuestras mentes se centran exclusivamente en la protección de los activos valiosos y se presta poca atención a lo que sucede con esos activos una vez que el desastre ha pasado. La capacidad de realizar el failback a los sistemas de producción es tan importante como la capacidad de failover. A menos que se planifique cuidadosamente, es poco probable que un centro de datos de backup tenga la misma capacidad o rendimiento que un sitio de producción. Sin un plan de failback, es posible realizar un failover inicial exitoso y luego ver cómo se acumulan las pérdidas mientras su negocio cojea durante semanas al operar desde un sitio de backup aprovisionado inadecuadamente.

El tiempo de inactividad y la pérdida de datos son una realidad para las empresas que dependen de TI. Compensar este riesgo con la tecnología adecuada debe ser un aspecto a tener en cuenta en las primeras etapas de los ciclos de vida de desarrollo e implementación del software. Entender el nivel de protección exigido por cada aplicación permite asignar los recursos adecuados. En el momento en que una aplicación es utilizada en producción por los usuarios de negocio, sus RPO y RTO deben estar claramente identificados y se deben implementar las soluciones de continuidad del negocio adecuadas para proporcionar una recuperación segura en caso de una interrupción.

Arcserve® Unified Data Protection Arcserve ha estado proporcionando protección de tiempo de inactividad cero a organizaciones de todo el mundo durante más de 20 años. Ahora, Arcserve Unified Data Protection (UDP) ofrece un punto único para todas sus necesidades de protección de datos y alta disponibilidad. Con un control centralizado, Arcserve UDP unifica el backup, las instantáneas, la replicación y la deduplicación de sus activos de aplicaciones virtuales, físicas, on-premise y en la nube. Arcserve UDP Assured Recovery™ ofrece un proceso completo y en tiempo real de prueba de la preparación ante desastres para la validación no disruptiva de los planes de continuidad del negocio. Para conocer más, visite www.arcserve.com/ar. .

Copyright © 2015 Arcserve (USA), LLC y sus filiales y subsidiarias. Todos los derechos reservados. Todas las marcas registradas, nombres comerciales, marcas de servicio y logotipos mencionados aquí pertenecen a sus respectivos propietarios. Este documento es provisto sólo a título informativo. Arcserve no asume ninguna responsabilidad por la exactitud o exhaustividad de la información. En la medida permitida por la legislación aplicable, Arcserve proporciona este documento "tal como está" sin garantía de ningún tipo, incluyendo, sin limitación, garantías implícitas de comercialización, idoneidad para un propósito particular o no contravención. En ningún caso, Arcserve será responsable por cualquier pérdida o daño, directo o indirecto, derivado del uso de este documento, incluyendo, sin limitación, lucro cesante, interrupción de negocios, daños en la marca o pérdida de datos, incluso si Arcserve ha sido expresamente advertida con antelación de la posibilidad de tales daños.