Mejores prácticas para la recuperación ante desastres en entornos SAP: Copias de seguridad, alta disponibilidad y más

Hace unos años, estaba sentado en mi oficina tomando un café (por supuesto, Death Wish dark roast) cuando recibí una llamada frenética de nuestro equipo del centro de datos. Una enorme sobretensión en un transformador cercano había dejado a nuestro entorno SAP al borde del colapso.

La carrera frenética para iniciar nuestro plan de recuperación ante desastres fue una llamada de atención. Ocurre cuando menos lo esperas.

Aunque no nos gusta pensarlo mucho, un desastre puede (y probablemente lo hará) destruir tu arduo trabajo, poner en peligro funciones clave y poner en riesgo toda tu infraestructura. Opera el software empresarial el tiempo suficiente y algo amenazará su seguridad.

Pero incluso si Humpty Dumpty cae del muro, aún podemos volver a ponerlo en su lugar.

La recuperación ante desastres consiste en aceptar cierta cantidad de pérdida de datos pero reducir tu RTO tanto como sea posible (o al menos a algo con lo que puedas vivir).

A lo largo de los años, he desarrollado algunas mejores prácticas que ayudarán a que las aplicaciones SAP se pongan en marcha después del proverbial terremoto.

Copia de seguridad y restauración de varios niveles

Junto con copias de seguridad regulares, he mantenido soluciones de copia de seguridad de varios niveles. Por ejemplo, hay una estrategia de copia de seguridad incremental diaria y copia de seguridad completa semanal que mantiene los datos tanto en las instalaciones como en el almacenamiento en la nube para redundancia.

Automatiza el proceso de copia de seguridad con scripts que inician una copia de seguridad en SAP HANA utilizando Backint y posteriormente transfieren los archivos de copia de seguridad a una ubicación en la nube externa con versionado habilitado.

Programa un script tan simple como:

Y luego transfierelos utilizando algo como AWS CLI o Azure Blog Storage:

Alta disponibilidad y configuración de recuperación ante desastres

Configuré una combinación de HA y DR dentro de mi paisaje SAP. HA en el sitio principal asegura un tiempo de inactividad mínimo, mientras que el sitio secundario está listo para hacerse cargo si falla.

La replicación síncrona o asíncrona a un sitio de conmutación por error en una ubicación diferente (en la misma región) puede usarse, dependiendo de los requisitos comerciales y la tolerancia a la pérdida de datos.

En el sistema principal:

En el sistema secundario:

Si su RPO es relativamente alto, es posible que pueda prescindir de un servidor de conmutación por error terciario, pero si no pueden manejar mucha pérdida de datos, es mejor tener ese host de DR dedicado.

Envío de registros de base de datos

Enviar regularmente registros de transacciones a una ubicación externa ayuda a recuperar sistemas a un punto más cercano al fallo. Este enfoque me ha ayudado a recuperar la última transacción confirmada, esencialmente una copia completa de los datos previos al fallo.

Un servidor Microsoft SQL puede enviar continuamente registros a un servidor en espera, que luego puede activarse en caso de fallo.

Luego, para restaurarlo en el servidor en espera:

Virtualización y instantáneas

He utilizado instantáneas de VM para habilitar puntos de restauración que podrían ser rápidamente puestos en marcha en nuevo hardware o un entorno en la nube después de un fallo del servidor físico. vSphere de VMware es excelente para esto, capturando estados de servidor consistentes automáticamente.

Es tan simple como:

Standby cálido

A veces, necesitas tener un sistema en espera actualizado regularmente utilizando replicaciones de sistemas o copias de seguridad. Aunque no manejará la carga de producción, está listo para ser activado y poner en funcionamiento tu sitio de