Inicio > Glosario > Plan de recuperación de desastres de SAP

Plan de recuperación de desastres de SAP

Actualizado 14th septiembre 2022, Rob Morrison

Dado que SAP suele ser uno de los componentes más importantes del flujo de datos de una organización, el plan de recuperación de desastres de SAP siempre ha sido una prioridad para todos los usuarios de esta tecnología. Hay una gran variedad de desastres diferentes que pueden ocurrir repentinamente, y si no está preparado para ello, le costará mucho; desde daños irreparables en sus datos, hasta la pérdida total del negocio. Casi cada minuto de inactividad es un desastre para una empresa, y cada hora adicional puede suponer miles de dólares -y más- de coste adicional.

Por eso las empresas deben estar siempre preparadas y ser capaces de minimizar el posible tiempo de inactividad tanto como puedan. Hay algunos términos importantes para ello, como RTO y RPO.

RTO significa «objetivo de tiempo de recuperación». Representa la cantidad de tiempo que puede permitirse que los sistemas SAP de su empresa estén fuera de servicio. No debería importar el tipo exacto de desastre que se haya producido: un fallo de la red, un apagón, un huracán, lo que sea, querrá que su base de datos SAP o HANA vuelva a estar en funcionamiento dentro del periodo de tiempo «permitido», y eso es exactamente lo que significa RTO.

Ahora bien, hay bastantes activos y/o servicios diferentes que pueden verse involucrados o afectados en un desastre, y cada uno de ellos tiene un RTO diferente. Por ejemplo, los sistemas bancarios o las tiendas online de alta demanda miden su RTO en segundos reales, mientras que el RTO de una empresa menos relevante en términos de tiempo podría ser de hasta varios días. Por supuesto, también hay muchos casos diferentes entre estos ejemplos.

sap disaster recovery

El RPO es un objetivo de punto de recuperación y probablemente también será un factor importante de su plan de recuperación de desastres de SAP. El RPO representa la cantidad máxima de datos (medida en términos de antigüedad de los datos) que puede o no puede perderse en caso de desastre. Básicamente, algún tipo de pérdida de datos es casi inevitable, a menos que esté reflejando toda su base de datos en todo momento. Aquí es donde importa el RPO. ¿Qué es tolerable para su empresa? Al igual que el RTO, su RPO varía mucho según la naturaleza de su negocio. Por ejemplo, las operaciones bursátiles pueden tener un RPO extremadamente sensible, mientras que otros negocios pueden permitirse un RPO mucho mayor.

Hay varias opciones diferentes disponibles cuando se trata de la recuperación de desastres de SAP. Algunas de ellas están basadas en la nube y son relativamente nuevas, mientras que otras soluciones son algo más antiguas y utilizan un enfoque diferente. La elección de los planes de recuperación de desastres SAP, en general, hace que todo el proceso sea mucho más flexible, ya que puede encontrar más fácilmente una solución que se adapte mejor a las necesidades específicas de su empresa, incluyendo RPO y RTO asequibles, precios asequibles, desventajas aceptables de un método específico, etc.

Puede encontrar varios servicios que ofrecen diferentes planes de recuperación ante desastres de SAP, cada uno con sus propias ventajas e inconvenientes. A la hora de elegir una solución de DR de SAP para usted, hay algunas cuestiones que deberá tener en cuenta:

¿Cuáles son los límites de escalabilidad del proveedor?
¿Cuáles son los RTO y RPO más rápidos que pueden ofrecer, y cumplen con sus requisitos?
¿Este proveedor -y su solución- son fáciles de usar y se adaptan a las necesidades únicas de su empresa?
¿Hasta dónde puede llegar el proveedor en lo que respecta a la personalización cuando proporciona un servicio de recuperación de desastres SAP?

Normalmente, hay dos formas posibles de aplicar el plan de recuperación de desastres de SAP:

Síncrona. Como su nombre indica, la implementación síncrona de un plan de recuperación de desastres significa que no habrá cambios en la base de datos «principal» hasta que reciba una señal de un sitio de recuperación de desastres sobre que la base de datos está siendo actualizada.
Asíncrona. Esta es diferente, ya que la base de datos «de reserva» no se actualiza cada vez que hay un cambio en la base de datos «principal». En su lugar, la base de datos de recuperación de desastres se actualiza más tarde, muy probablemente dentro de una cantidad de tiempo fija. Esto significa que es posible que se pierdan más datos en caso de desastre, pero al mismo tiempo disminuye la carga que supone actualizar toda la base de datos con cada cambio, por pequeño que sea.

Hablando de planes de recuperación de desastres, existen varios tipos de ellos, cada uno con sus propias características y deficiencias:

Método tradicional de recuperación de datos. El propio nombre implica que es probablemente el método más antiguo que existe: dos servidores idénticos, el «principal» y el «de reserva». Los registros de la base de datos se recogen en el «principal» y se envían al de «reserva». Este método tiene muchos inconvenientes, el principal de los cuales es la velocidad del tiempo de actividad y el coste global de propiedad. No obstante, muchas empresas siguen utilizándolo como opción principal.
Utilizar servicios en la nube para la copia de seguridad y recuperación de datos. Esta opción también podría llamarse «económica», ya que el coste global de utilizar Amazon Web Services o similares no es tan grande y puede ser manejado por empresas más pequeñas. Los servicios en la nube son utilizados sobre todo por empresas que no tienen muchos cambios frecuentes en su base de datos, y los propios datos se respaldan de vez en cuando. De hecho, puede ser una buena opción para las empresas de nueva creación, pero las preocupaciones de seguridad general hacen que sea una opción difícil para las empresas más grandes con datos más sensibles.

Recuperación de desastres con Bacula. El módulo SAP de Bacula Enterprise implementa la interfaz oficial SAP BACKINT, que simplifica la copia de seguridad y la restauración de SAP, utilizando las herramientas tradicionales de bases de datos SAP. El módulo SAP utiliza varias técnicas y estrategias para realizar copias de seguridad de SAP y puede combinarse con el plugin Oracle SBT de Bacula Enterprise para permitir la transferencia directa de datos entre Oracle RMAN y Bacula Enterprise. Una vez instalado el módulo SAP, ejecuta las copias de seguridad y las restauraciones simultáneamente, y funciona de forma transparente en segundo plano. El administrador de copias de seguridad puede beneficiarse de las funciones de multiplexación de la edición de Bacula Enterprise para ejecutar copias de seguridad y restauraciones en paralelo.

En cuanto a los proveedores específicos de recuperación ante desastres de SAP, puede encontrar respuestas a estas y otras preguntas sobre Bacula Systems leyendo este whitepaper y este artículo. También hay una plantilla gratuita de plan de recuperación de desastres de SAP disponible aquí.

Sobre el autor

Rob Morrison es el director de marketing de Bacula Systems. Comenzó su carrera de marketing de TI con Silicon Graphics en Suiza, desempeñando con fuerza varios puestos de gestión de marketing durante casi 10 años. En los siguientes 10 años, Rob también ocupó varios puestos de gestión de marketing en JBoss, Red Hat y Pentaho, asegurando el crecimiento de la cuota de mercado de estas conocidas empresas. Se graduó en la Universidad de Plymouth y tiene una licenciatura en Medios Digitales y Comunicaciones, y completó un programa de estudios en el extranjero.