Recuperación ante desastres para SAP en IBM i: lecciones de un failover real

Por el equipo de Infraestructura de Redsis · Octubre 2026 · 6 min de lectura

Por qué la continuidad pesa tanto en el retail

El retail colombiano es un sector grande y concentrado: las 20 mayores empresas sumaron ingresos por $117,3 billones de pesos en 2025, con un crecimiento de 12,3 %, y las cinco primeras concentraron el 65,2 % de esos ingresos, según El Colombiano. En ese nivel de escala, cada hora de sistemas detenidos se mide en ventas, en pedidos que no salen hacia los proveedores y en clientes que se van a la competencia.

La cadena de nuestro caso opera alrededor de 420 tiendas, unos 4.800 puntos de venta y cerca de 8.000 usuarios de SAP, además de más de 200 bases de datos SQL Server alrededor del core. Una contingencia en su centro de datos principal no es un problema de TI: es un problema de todo el negocio.

RTO y RPO: las dos cifras que importan

Toda estrategia de recuperación se resume en dos objetivos que el negocio debe definir y la tecnología debe cumplir:

• RTO (Recovery Time Objective): cuánto tiempo puede estar detenido el sistema antes de volver a operar. En este caso, 3 horas para el core SAP ante una contingencia mayor.
• RPO (Recovery Point Objective): cuánta información se puede perder, medida en tiempo. En este caso, una ventana máxima de 15 minutos en la replicación.

Con 80 TB de datos, esas cifras son muy difíciles de alcanzar solo con respaldos tradicionales: restaurar un volumen así desde copias periódicas suele tomar mucho más que unas horas, y la pérdida puede ser de todo lo ocurrido desde la última copia. La única forma de alcanzarlas es mantener una réplica viva del ambiente en otro sitio.

Cómo funciona IBM PowerHA para IBM i

IBM PowerHA es la solución de alta disponibilidad y recuperación ante desastres de IBM para la plataforma Power. En IBM i, se integra de forma nativa con el sistema operativo y ofrece:

• Clústeres entre sitios que agrupan los sistemas del centro principal y del alterno como una sola solución.
• Replicación continua de datos , ya sea a nivel del sistema operativo o apoyada en la replicación del almacenamiento, según el diseño.
• Conmutación controlada ( switchover ) para pruebas planeadas y conmutación por falla ( failover ) ante una contingencia real.
• Dominio administrativo que mantiene sincronizados perfiles de usuario, configuraciones y objetos del sistema entre nodos, para que el sitio alterno esté listo para operar.

En este proyecto, los 80 TB de SAP se replican entre dos ciudades y Redsis administra la infraestructura IBM Power en ambos centros de datos.

Cinco lecciones de más de tres años en operación

1. Que el negocio defina el RTO y el RPO

Las cifras de recuperación no son un parámetro técnico: son una decisión de negocio sobre cuánto tiempo y cuánta información se puede perder. Cuando las define la operación, la arquitectura se diseña para cumplirlas, y no al revés.

2. La distancia es parte del diseño

Un sitio alterno en la misma ciudad protege contra una falla de equipos, pero no contra un evento regional. Llevar la réplica a otra ciudad amplía la protección, a cambio de diseñar con cuidado los enlaces, la latencia y el modo de replicación.

3. Probar, probar y volver a probar

La solución de este caso se prueba de forma continua, y en julio de 2026 se ejecutó un failover real. Esa es la diferencia entre creer que el plan funciona y saberlo. Una práctica recomendable es alternar pruebas planeadas con ejercicios lo más parecidos posible a una contingencia real.

4. Mirar más allá del core

SAP es el corazón, pero no está solo: puntos de venta, integraciones y bases de datos satélite también deben volver. Documentar el orden de recuperación de todo el ecosistema evita que el core esté disponible mientras las tiendas siguen sin poder vender.

5. Operar la alta disponibilidad como un servicio

La replicación se degrada si nadie la vigila: cambios de configuración, crecimiento de datos o actualizaciones pueden romperla en silencio. Contar con un equipo que administra la infraestructura en ambos sitios, como hace Redsis en este caso, mantiene la solución lista para el día en que se necesita.

El resultado: continuidad demostrada, no prometida

Hoy el core SAP de la cadena tiene un tiempo de recuperación de 3 horas y una ventana máxima de pérdida de datos de 15 minutos, sobre una solución que lleva más de tres años en operación y que ya demostró su valor en un failover real en julio de 2026. Para una operación de 420 tiendas y 4.800 puntos de venta, eso significa algo muy concreto: ante una contingencia mayor, el negocio sabe cuánto tarda en volver y cuánto puede perder.

¿Por dónde empezar?

Si su organización no tiene claras sus cifras de RTO y RPO, o si su plan de contingencia no se ha probado en el último año, vale la pena empezar por un diagnóstico de continuidad. En Redsis combinamos más de 25 años de experiencia en infraestructura de misión crítica en América Latina con nuestra condición de socio IBM Platinum para diseñar, implementar y operar alta disponibilidad sobre IBM Power e IBM i.