El 7 de julio de 2012, un fallo en la actualización del software de Knight Capital Group, uno de los mayores market makers del NYSE, ejecutó millones de órdenes incorrectas en 45 minutos, generando pérdidas de 440 millones de dólares. La empresa quebró días después. No fue un fallo eléctrico, pero ilustra perfectamente la naturaleza de los riesgos en el sector financiero: cuando algo sale mal, el reloj corre en contra con una velocidad que no existe en ningún otro sector.
En el contexto de la protección eléctrica y la continuidad operativa, el disaster recovery (DR) no es simplemente una copia de seguridad o un servidor de repuesto. Es una arquitectura completa de redundancia geográfica, procesos operativos, contratos, pruebas periódicas y métricas de rendimiento medibles (RPO y RTO) que determinan si una entidad financiera puede sobrevivir a un desastre mayor — físico o tecnológico.
Conceptos fundamentales: RPO, RTO y MTD
Recovery Time Objective (RTO): el tiempo máximo de interrupción
El RTO es el tiempo máximo que un sistema puede estar inactivo después de un incidente antes de que el impacto para la entidad sea inaceptable. Se expresa en segundos, minutos u horas, y es específico de cada sistema o proceso de negocio.
Ejemplos de RTO en entidades financieras españolas:
| Sistema | RTO típico bancos grandes | RTO típico bancos medianos | |---------|--------------------------|---------------------------| | Sistemas de liquidación interbancaria (TARGET2, SNCE) | < 1 hora | 1-2 horas | | Core bancario (cuentas, préstamos) | 2-4 horas | 4-8 horas | | Sistemas de pagos (Bizum, transferencias) | < 1 hora | 1-4 horas | | Banca digital (app, web) | 15-30 minutos | 1-2 horas | | Sistemas de trading y mercados | 0-15 minutos | No aplica (generalmente) | | Back-office y sistemas de soporte | 4-8 horas | 8-24 horas | | Sistemas de reporting regulatorio | 24-48 horas | 48-72 horas |
La definición del RTO es una decisión de negocio, no solo técnica: cuánto tiempo puede el banco estar sin ese sistema antes de incumplir obligaciones regulatorias, perder ingresos inaceptables o causar daño reputacional irreparable.
Recovery Point Objective (RPO): la pérdida de datos máxima tolerable
El RPO es la cantidad máxima de datos que puede perderse en un incidente, expresada en tiempo. Si el RPO de un sistema es de 15 minutos, significa que en el peor caso se aceptaría perder hasta 15 minutos de transacciones — aunque en la práctica el objetivo es siempre cero pérdida de datos para sistemas transaccionales.
RPO en sistemas financieros:
| Sistema | RPO objetivo | Tecnología para conseguirlo | |---------|-------------|----------------------------| | Core bancario | 0 (zero data loss) | Replicación síncrona en tiempo real | | Base de datos de transacciones | 0-15 segundos | Log shipping síncrono o semi-síncrono | | Sistemas de trading | 0 (zero data loss) | Active-active con replicación in-memory | | Sistemas de reporting | 15 minutos – 1 hora | Replicación asíncrona con ventana tolerada | | Archivos y documentación | 24 horas | Backup nocturno con retención larga |
Maximum Tolerable Downtime (MTD): el límite absoluto
El MTD (también llamado MTPD — Maximum Tolerable Period of Disruption en estándares ISO) es el tiempo máximo que puede estar inactivo un proceso antes de que el banco no pueda recuperarse de forma viable. Supera al RTO en tiempo y representa el umbral de catástrofe:
- Si el sistema de pagos está inactivo durante más del MTD, el banco puede no poder procesar las operaciones acumuladas y enfrentarse a una crisis de liquidez
- El MTD obliga a definir qué ocurre cuando el RTO no se cumple: procesos manuales de emergencia, comunicación con reguladores, limitación temporal de servicios al cliente
Arquitecturas de disaster recovery para entidades financieras
Modelo 1: Activo-Pasivo (warm standby)
El data center secundario tiene los sistemas replicados pero no activos. Ante un fallo del DC primario:
- Se activa el proceso de failover
- Los sistemas del DC secundario arrancan y cargan la última copia de los datos
- El servicio se restablece
Tiempo de activación del modelo activo-pasivo: 15 minutos – 4 horas, dependiendo de la complejidad del sistema y el nivel de automatización del proceso de failover.
Ventajas: menor coste de infraestructura del DC secundario (no requiere potencia total activa), menor complejidad operativa.
Desventajas: el RTO es relativamente largo (minutos a horas), no adecuado para sistemas con RTO < 15 minutos. Requiere pruebas de failover periódicas (que implican interrumpir el DC secundario).
Implicaciones para la infraestructura eléctrica: el DC secundario necesita SAI en modo "standby" o en operación con carga parcial (sistemas de monitorización, replicación de datos, infraestructura de red). La potencia total del SAI secundario debe ser suficiente para el arranque completo de todos los sistemas.
Modelo 2: Activo-Activo (hot standby / split-brain activo)
Ambos data centers están activos simultáneamente, procesando carga real en paralelo. Los datos se replican de forma síncrona entre ambos. Ante el fallo de uno:
- La carga se transfiere automáticamente al otro (sin proceso de failover, solo conmutación de tráfico de red)
- El servicio continúa sin interrupción percibida
Tiempo de activación: segundos (automático, sin intervención humana para los sistemas diseñados correctamente).
Ventajas: RTO prácticamente 0, RPO 0 (zero data loss), pruebas de continuidad más sencillas (el DC secundario está activo y probado en producción continua).
Desventajas: coste significativamente mayor (dos DCs a plena potencia), mayor complejidad técnica (gestión de consistencia distribuida, resolución de conflictos en escrituras simultáneas), latencia de replicación síncrona limita la distancia geográfica entre los DCs.
Implicaciones para la infraestructura eléctrica: ambos DCs requieren la misma infraestructura de protección eléctrica de producción, incluyendo SAIs de plena potencia con redundancia 2N. La inversión se duplica, pero la disponibilidad resultante puede superar el 99,999%.
Modelo 3: Activo-Activo Geográficamente Distribuido (multi-site)
Extensión del modelo activo-activo con más de dos ubicaciones, cada una procesando una fracción de la carga total. Si un DC falla, las demás ubicaciones absorben su carga.
Este modelo es el utilizado por los grandes bancos españoles (Santander, BBVA, CaixaBank) para sus sistemas más críticos. Requiere una arquitectura técnica sofisticada (sharding geográfico de bases de datos, global load balancing, replicación multi-master) pero proporciona la máxima resiliencia posible.
El rol del SAI en la estrategia de DR
La infraestructura eléctrica es el primer eslabón de la cadena de DR. Un plan de DR perfectamente diseñado puede fallar si el data center de contingencia no puede arrancar porque:
- Las baterías del SAI están degradadas y no pueden sostener el arranque del DC mientras los grupos electrógenos alcanzan la velocidad nominal
- El SAI del DC secundario no tiene capacidad suficiente para arrancar todos los sistemas simultáneamente (pico de corriente de arranque)
- La infraestructura de refrigeración del DC secundario no arranca automáticamente con el SAI
Requisitos del SAI para un data center de contingencia:
- Estado de baterías verificado periódicamente (monitorización remota continua)
- Potencia suficiente para arrancar el 100% de los sistemas del DC (considerando corriente de pico de arranque, que puede ser 2-3x la corriente nominal)
- Autonomía mínima de 30 minutos (suficiente para que los grupos electrógenos alcancen estabilidad y para verificar que todo el sistema ha arrancado correctamente)
- Grupos electrógenos con arranque automático probado mensualmente
- Integración de monitorización del DC secundario con el NOC principal (para detectar problemas antes de necesitar el DR)
Para el diseño de la arquitectura de grupos electrógenos y SAIs como dos niveles complementarios, consulta el artículo sobre grupos electrógenos y SAIs: los dos niveles de protección.
El plan de continuidad de negocio (BCP) en entidades financieras
Estructura del BCP bancario
El Plan de Continuidad de Negocio (Business Continuity Plan, BCP) es el documento maestro que define cómo la entidad responde a un desastre. No es solo un documento técnico — es un plan operativo que involucra a personas, procesos y tecnología.
Componentes del BCP bancario:
1. Análisis de Impacto en el Negocio (BIA — Business Impact Analysis) Identifica y clasifica todos los procesos de negocio según su criticidad y los impactos de su interrupción. Para cada proceso critico define:
- RTO y RPO objetivos
- Recursos mínimos necesarios para la recuperación (personal, sistemas, infraestructura)
- Dependencias entre procesos y sistemas
2. Análisis de Riesgos Identifica los escenarios de desastre posibles y su probabilidad/impacto:
- Desastre físico en el DC principal (incendio, inundación, fallo eléctrico mayor)
- Ataque cibernético que afecta a la disponibilidad (ransomware, DDoS)
- Fallo de proveedor crítico (operadora de telecomunicaciones, proveedor cloud)
- Pandemia o evento que afecta al personal clave
- Fallo de la infraestructura eléctrica del edificio (fallo de compañía distribuidora en la zona)
3. Estrategias de Recuperación Para cada escenario identificado, el BCP define la estrategia de recuperación:
- Qué sistemas se recuperan primero (prioridad de restauración según criticidad del BIA)
- Qué arquitectura DR se activa (activo-activo automático vs. failover manual)
- Quién toma las decisiones de activación (comité de crisis, umbral de activación automática)
4. Procedimientos de Recuperación Runbooks detallados (paso a paso) para ejecutar la recuperación de cada sistema crítico. Estos procedimientos deben ser ejecutables por el equipo de operaciones sin depender de personas específicas (gestión del conocimiento, rotación de personal).
5. Plan de Comunicación de Crisis
- Comunicación interna (personal, gestores, alta dirección)
- Comunicación a reguladores (Banco de España, CNMV, BCE según DORA)
- Comunicación a clientes (mensajes en app, web, call center)
- Comunicación a contrapartes (otras entidades financieras, sistemas de pago)
Integración del BCP con la infraestructura eléctrica
Un error frecuente en los BCPs bancarios es no integrar adecuadamente los planes de contingencia de infraestructura eléctrica con el BCP general. La infraestructura eléctrica tiene sus propios:
- Procedimientos de respuesta a fallos (con tiempos de respuesta del proveedor)
- Escalado de alertas (quién llama a quién cuando el SAI entra en modo batería a las 3:00 AM)
- Puntos de decisión (¿cuándo se activa el DC de contingencia vs. esperar que vuelva la red?)
- Requisitos de documentación para notificación regulatoria DORA
La plataforma de monitorización Vertiv Trellis Enterprise permite establecer reglas de escalado automático que integran la monitorización eléctrica con el proceso de gestión de incidentes del banco: cuando el SAI entra en modo batería y el tiempo de autonomía estimado cae por debajo de un umbral configurable, el sistema puede crear automáticamente un ticket en ServiceNow, alertar al equipo de guardia y registrar el evento con timestamp para el proceso de notificación DORA.
Pruebas de DR: la diferencia entre un plan teórico y uno que funciona
Por qué las pruebas son obligatorias (DORA y EBA)
Un plan de DR no probado es un plan que probablemente no funcionará cuando se necesite. DORA (artículos 24-27) exige pruebas periódicas de los planes de continuidad operativa, con documentación de los resultados y acciones correctoras. Las directrices EBA refuerzan este requisito.
Tipos de pruebas para data centers bancarios:
1. Prueba de escritorio (tabletop exercise) El equipo de crisis se reúne y recorre verbalmente los procedimientos del BCP para un escenario determinado. Identifica gaps en los procedimientos sin impacto en los sistemas productivos.
- Frecuencia mínima: anual para todos los escenarios principales
- Duración: medio día a día completo
2. Prueba de componente Se prueba un componente específico del plan: prueba de arranque del grupo electrógeno con carga real, prueba de transferencia del SAI a baterías, prueba de failover de la base de datos principal al DC secundario.
- Frecuencia mínima: semestral para componentes críticos (SAI, generadores), anual para pruebas de failover completo
- Requiere ventana de mantenimiento planificada
3. Prueba de DR completa (full DR test) Se activa el DC secundario con carga real o simulada, reproduciéndose el escenario de fallo completo del DC principal. Es la prueba más completa y la que más confianza genera.
- Frecuencia mínima: anual según EBA/DORA
- Requiere coordinación extensa (impacto en clientes, comunicación previa, equipo de rollback listo)
4. Pruebas TLPT (entidades grandes bajo DORA) Las pruebas de penetración basadas en amenazas reales (Threat-Led Penetration Tests) que DORA exige cada 3 años para las entidades más grandes pueden incluir escenarios de ataque a la infraestructura física, incluyendo sistemas de suministro eléctrico.
El rol de la monitorización eléctrica en las pruebas
Las pruebas de DR deben incluir verificación de la infraestructura eléctrica del DC secundario:
-
Antes de la prueba: verificar estado de baterías del SAI del DC secundario (monitorización remota), nivel de combustible de generadores, última fecha de mantenimiento de ambos.
-
Durante la prueba: monitorizar en tiempo real la carga asumida por el SAI del DC secundario, temperatura de las salas, consumo de los equipos al arrancar.
-
Después de la prueba: registrar tiempos de arranque, identificar equipos que no arrancaron correctamente, medir temperatura máxima alcanzada durante el arranque masivo de servidores.
Separación geográfica: la distancia mínima recomendada
Requisitos del BCE para bancos significativos
El BCE establece que los bancos significativos bajo su supervisión directa deben tener sus centros de datos principal y de contingencia en ubicaciones geográficamente separadas, con una distancia mínima de 50-200 km dependiendo del nivel de resiliencia requerido. Esta distancia garantiza que un desastre físico local (terremoto, inundación, incendio de gran magnitud) no afecte simultáneamente a ambos DCs.
Implicaciones eléctricas de la separación geográfica
La separación geográfica entre DCs tiene implicaciones directas para la estrategia de protección eléctrica:
- Cada DC debe ser completamente autónomo desde el punto de vista de la alimentación eléctrica (acometidas independientes de la red de distribución, grupos electrógenos propios)
- La replicación síncrona de datos entre DCs a 50-200 km requiere latencias de red de 1-10 ms, lo que limita qué tecnologías de replicación son viables
- Los proveedores de servicios (incluyendo mantenimiento de SAIs) deben tener capacidad de respuesta en ambas ubicaciones dentro de los SLAs pactados
Selección de infraestructura eléctrica para el DC de contingencia
¿Mismo nivel de protección que el DC principal?
Una pregunta frecuente: ¿debe el DC de contingencia tener el mismo nivel de redundancia (ej. Tier IV) que el DC principal? La respuesta depende del modelo de DR:
Modelo activo-activo: sí, ambos DCs deben tener el mismo nivel de protección, ya que ambos procesan carga de producción simultáneamente.
Modelo activo-pasivo con RTO corto (< 2 horas): el DC secundario debe tener un nivel de protección similar al principal, porque necesita estar operativo de forma fiable cuando se necesita. Un DC secundario Tier II no puede garantizar que esté disponible justo cuando el DC principal falla.
Modelo activo-pasivo con RTO largo (4-24 horas): el DC secundario puede tener un nivel de protección algo menor (Tier III vs. Tier IV del principal), aceptando un riesgo mayor de que el propio proceso de arranque tenga complicaciones, ya que hay tiempo para resolverlas.
Equipamiento recomendado para DC de contingencia bancario
Para un DC de contingencia de tamaño medio (100-300 kW de carga IT):
| Componente | Recomendación | |-----------|---------------| | SAI principal | Vertiv Liebert EXL S1 200 kVA (N+1 modular) | | SAI secundario (2N si activo-activo) | Vertiv Liebert EXL S1 200 kVA adicional | | Climatización | Liebert CRV 25/35 kW In-Row, configuración N+1 | | Monitorización | Vertiv Trellis Enterprise (integrado con DC principal) | | Grupos electrógenos | N+1, autonomía 72h, prueba mensual | | PDUs | Vertiv Geist Switched 32A con monitorización por toma |
Preguntas frecuentes
¿Qué diferencia hay entre BCP, DRP y DR?
Son términos relacionados pero con alcances distintos. El BCP (Business Continuity Plan) es el plan general para mantener las operaciones de negocio durante y después de un desastre — incluye personas, procesos y tecnología. El DRP (Disaster Recovery Plan) es el componente técnico del BCP que detalla cómo recuperar los sistemas TI. El DR (Disaster Recovery) es el proceso o arquitectura técnica que hace posible la recuperación (DC de contingencia, replicación de datos, etc.). En banca, los reguladores suelen pedir el BCP completo, que debe incluir un DRP técnico detallado.
¿Cuánto tiempo tarda en activarse un DC de contingencia bancario en el modelo activo-pasivo?
Depende de la madurez del plan y el nivel de automatización. Con un plan bien diseñado y probado periódicamente: los sistemas de menor criticidad pueden tardar 2-4 horas en estar operativos, los sistemas críticos con automatización bien configurada pueden estar operativos en 30-90 minutos, y los sistemas con alta criticidad que requieren RTO < 15 minutos necesitan arquitectura activo-activo o al menos una configuración de warm standby muy avanzada. El tiempo de activación del DC de contingencia empieza en el momento en que el SAI asume la carga — si el SAI del DC secundario no puede arrancar porque las baterías están degradadas, todo el tiempo de RTO se pierde antes de empezar.
¿Qué pasa si el DC de contingencia también falla durante una activación?
Este es el escenario que los equipos de DR llaman "desastre dentro del desastre" y es más frecuente de lo que los equipos de planificación suelen admitir. Generalmente ocurre porque el DC secundario no se prueba con suficiente frecuencia y los problemas latentes (baterías degradadas, configuraciones obsoletas, equipos que han cambiado sin actualizar los runbooks) solo se descubren en la activación real. La solución es combinar monitorización remota continua del DC secundario con pruebas de DR anuales completas y pruebas de componente semestrales. La monitorización remota del SAI del DC secundario con Vertiv Trellis Enterprise es especialmente importante: permite saber en tiempo real si las baterías del DC secundario están en condiciones, sin esperar a la activación del DR.
¿Cómo afecta DORA a los requisitos de DR de las entidades financieras en 2025?
DORA formaliza y hace ejecutables regulatoriamente muchos requisitos de DR que antes eran simplemente buenas prácticas. Los cambios más relevantes son: la obligación de definir y documentar el RTO/RPO para todas las funciones críticas o importantes (no solo para el core bancario), la obligación de probar el plan de DR periódicamente y documentar los resultados, la notificación obligatoria al Banco de España cuando se activa el plan de DR si la causa es un incidente TIC mayor, y la revisión del riesgo de terceros aplicada a los proveedores del DC de contingencia. Las entidades que no tenían un plan de DR formal antes de 2025 deben desarrollarlo urgentemente, y las que lo tenían deben revisarlo para asegurarse de que cumple con las exigencias de documentación, pruebas y notificación de DORA.