Copia de seguridad y recuperación de mainframe: estrategias modernas para sistemas empresariales resilientes

¿Cuál es el panorama actual de la copia de seguridad y la recuperación ante desastres de mainframe?

En un entorno de TI —en particular, en el ámbito empresarial— la copia de seguridad de mainframe sigue siendo una de las disciplinas más críticas y, a menudo, subestimadas.

Las transacciones financieras, los archivos de seguros y los programas gubernamentales dependen cada vez más de los mainframes, lo que significa que los riesgos de interrupción del sistema también se encuentran en su nivel más alto. Una solución de copia de seguridad para mainframes debe ser capaz de satisfacer un tipo de demanda que el típico sistema de copia de seguridad distribuida nunca estuvo diseñado para ofrecer.

¿Por qué los mainframes siguen requiriendo enfoques especializados de copia de seguridad y recuperación?

Un mainframe no es simplemente un servidor de gran tamaño. Su arquitectura se ha construido en torno al concepto de disponibilidad continua, un rendimiento masivo de E/S y la separación de cargas de trabajo, factores que determinan el diseño y la ejecución de las copias de seguridad a un nivel fundamental.

Un entorno z/OS que gestiona miles de transacciones por segundo no puede permitir las mismas ventanas de copia de seguridad, los mismos modelos de consistencia y los mismos procedimientos de recuperación que utilizan los servidores de archivos Linux.

Los sistemas de copia de seguridad de mainframe deben lidiar con una serie de elementos propios de la plataforma y que no existen en ningún otro lugar —conjuntos de datos VSAM, catálogos z/OS, estructuras de coupling facility y entornos sysplex—, todos los cuales requieren sus propios mecanismos. Realizar una copia de seguridad de un clúster VSAM es muy diferente a realizar una copia de seguridad de un árbol de directorios, mientras que restaurar un sysplex a un estado coherente implica una coordinación que va mucho más allá de las capacidades de las herramientas de copia de seguridad genéricas.

La escala también es un problema en sí misma. Los mainframes gestionan volúmenes de datos a escala de petabytes de forma habitual, con estrictos requisitos de SLA que exigen que el proceso de copia de seguridad funcione simultáneamente al trabajo de producción sin ningún impacto perceptible. Esta restricción por sí sola descarta un gran número de soluciones estándar.

¿Cuáles son las amenazas y los modos de fallo habituales en los entornos de mainframe?

Aunque son extremadamente fiables por diseño, los mainframes no son invencibles. Los tipos de fallos que pueden poner en riesgo un entorno de mainframe son numerosos, y una estrategia de copia de seguridad de mainframe adecuada debe tenerlos todos en cuenta:

• Fallo de hardware: degradación del subsistema de almacenamiento, fallos de canal o fallos del procesador, que pueden corromper los datos o hacerlos inaccesibles incluso sin una interrupción total del sistema
• Error humano: eliminación accidental de conjuntos de datos, trabajos JCL mal configurados o actualizaciones erróneas del catálogo, que representan una parte significativa de los incidentes de recuperación en el mundo real
• Fallos de software y aplicaciones: errores en la lógica de procesamiento por lotes o en el middleware que escriben datos incorrectos, los cuales pueden no salir a la luz hasta que los registros ya se hayan propagado hacia abajo
• Ransomware y ataques maliciosos: un vector de amenaza cada vez más relevante, que se analiza en profundidad en la siguiente sección
• Desastres a nivel de sitio: cortes de energía, inundaciones o fallos de la infraestructura física que afectan a todo un centro de datos

Ninguna amenaza destaca por encima de las demás. La conmutación por error del hardware no es suficiente si no se gestionan los datos lógicamente dañados, y viceversa, a la hora de decidir la estrategia de copia de seguridad del mainframe.

¿Cómo cambian los requisitos empresariales modernos las expectativas en materia de copias de seguridad y recuperación ante desastres?

La definición de «recuperable» también ha cambiado considerablemente a lo largo de los años.

Un objetivo de RTO de 4 horas podría haber sido razonable hace una década para bastantes cargas de trabajo. Los equipos de continuidad del negocio actuales aspiran a un RTO de cero (o muy cercano a cero) para las aplicaciones críticas, impulsados por el comercio digital, las redes de pago en tiempo real y las normativas que tratan las interrupciones significativas como un incumplimiento normativo en lugar de un inconveniente operativo.

Muchas de estas expectativas se han documentado ahora en marcos normativos. En virtud de marcos como DORA y PCI DSS, las organizaciones están ahora obligadas a definir formalmente y probar periódicamente los objetivos de recuperación. El incumplimiento de estos compromisos se considera una falta de cumplimiento y se aborda en consecuencia.

Para las organizaciones que utilizan mainframes como núcleo de su negocio, esta dimensión normativa convierte la planificación de la recuperación ante desastres (DR) en una responsabilidad de gobernanza, no solo técnica.

¿Por qué están evolucionando las estrategias de copia de seguridad de mainframes en la era de las ciberamenazas?

Las ciberamenazas modernas han cambiado lo que debe ser capaz de hacer una copia de seguridad de mainframe. Los entornos de mainframe han dependido durante mucho tiempo de capacidades de resiliencia diseñadas específicamente —duplicación, copia en un momento determinado y redundancia por capas— que resultaban muy eficaces contra los modelos de amenaza para los que fueron concebidas: fallos de hardware, errores humanos y desastres a nivel de sitio.

Lamentablemente, el auge de los complejos ataques de ransomware y a la cadena de suministro ha introducido una nueva clase de problemas en los que las copias de seguridad también son el objetivo. La aparición de grupos de ransomware como Conti —cuyos manuales de ataque documentados incluían la identificación y destrucción de las copias de seguridad como objetivo principal antes de activar el cifrado— introdujo un modelo de amenaza para el que las estrategias de copia de seguridad de las empresas no habían sido diseñadas.

¿Cómo ataca el ransomware a los entornos heredados y de mainframe?

La suposición de que los mainframes están intrínsecamente protegidos contra el ransomware en virtud de su arquitectura ha estado muy extendida históricamente. Sin embargo, esa misma suposición se ve cada vez más cuestionada a medida que los entornos de mainframe se integran más profundamente con sistemas abiertos e infraestructuras distribuidas.

Los autores de ransomware modernos son calculadores y metódicos; escanean y mapean la infraestructura antes de activar una carga útil, buscando específicamente repositorios y catálogos de copias de seguridad para desactivar cualquier mecanismo de restauración antes de iniciar el proceso de cifrado.

Los entornos de mainframe presentan un riesgo de exposición particular a través de sus puntos de integración. Los sistemas z/OS se comunican constantemente con redes distribuidas, niveles de almacenamiento en la nube y middleware de sistemas abiertos (cualquiera de los cuales puede actuar como punto de entrada). A medida que los entornos de mainframe se integran cada vez más profundamente con la infraestructura distribuida, la superficie de ataque se expande: el compromiso de un sistema conectado podría, en arquitecturas de red suficientemente planas, proporcionar una vía hacia los niveles de almacenamiento compartido en los que residen los conjuntos de datos de copia de seguridad del mainframe.

En muchas configuraciones, los catálogos de copia de seguridad de mainframe y los conjuntos de datos de control residen en la misma estructura de almacenamiento que los datos que protegen, lo que significa que un atacante bien posicionado, o un evento de corrupción que se propague a través del almacenamiento compartido, podría afectar a ambos simultáneamente. No hace falta pensar mucho para llegar a la conclusión de que un catálogo de copia de seguridad que existe en la misma estructura de almacenamiento que los propios datos podría corromperse y destruirse en el mismo incidente.

Las arquitecturas modernas de copia de seguridad de mainframe deben abordar ahora precisamente esta situación.

¿Cuál es la función de las copias de seguridad inmutables y con aislamiento físico en los mainframes?

Estos son los dos enfoques arquitectónicos predominantes para combatir el ransomware: la inmutabilidad y el aislamiento físico. Aunque se trata de dos de los conceptos principales que se barajan para resolver el problema del ransomware, en realidad funcionan de manera diferente.

Los dos enfoques no son mutuamente excluyentes. Una estrategia de copia de seguridad de mainframe bien desarrollada puede abarcar ambos: una copia inmutable para proporcionar recuperación en muy poco tiempo en escenarios de ataque lógico, y una copia aislada físicamente para la recuperación definitiva en circunstancias en las que también se haya violado la inmutabilidad a nivel de almacenamiento (mediante el uso de cuentas de administrador con privilegios o ataques dirigidos directamente a la capa de almacenamiento).

Cuando la inmutabilidad de la capa de almacenamiento no se proporciona de forma nativa —como ocurre, por ejemplo, a través de IBM DS8000 Safeguarded Copy y el marco Z Cyber Vault—, la implementación en z/OS requiere una integración cuidadosa con las herramientas de copia de seguridad existentes para garantizar que las políticas de inmutabilidad se apliquen en la capa de almacenamiento y no solo en la capa de aplicación (donde podrían eludirse).

¿Cómo se aplican los principios de confianza cero a las arquitecturas de copia de seguridad de mainframe?

z/OS ha incorporado muchos de los principios que ahora se asocian con la arquitectura de confianza cero —controles de acceso obligatorios, separación estricta de funciones y registros de auditoría exhaustivos— desde mucho antes de que el término entrara en el discurso general sobre seguridad. En el caso concreto de las copias de seguridad de mainframe, la cuestión no es tanto introducir conceptos de confianza cero como garantizar que las políticas de RACF o ACF2 estén configuradas para aplicar esos principios de forma coherente al entorno de copia de seguridad, que a veces se considera de menor riesgo que el de producción y se le permite acumular privilegios excesivos con el tiempo.

En lo que respecta a las copias de seguridad de mainframe, el «zero-trust» implica que nunca se da por sentado que ningún dispositivo, usuario o proceso (ni siquiera los administradores de copias de seguridad) tenga acceso implícito o capacidad para gestionar los datos de copia de seguridad. En la práctica, esto implicaría una estricta separación de funciones, autenticación de dos factores para acceder a la consola de gestión de copias de seguridad y permisos estrictos basados en roles que limiten quién puede eliminar, modificar o desactivar los trabajos de copia de seguridad.

En z/OS, esto se traduce en un diseño de políticas RACF o ACF2 que restringe explícitamente el acceso al catálogo de copias de seguridad, combinado con alertas fuera de banda para cualquier acción administrativa que afecte a la configuración de retención o a las programaciones de copias de seguridad. El entorno de copias de seguridad de mainframe debe tratarse como un sistema crítico para la seguridad en sí mismo, de modo que tanto los ciclos de revisión de acceso como los registros de auditoría cumplan los mismos estándares que se aplican a los datos de producción.

¿Qué objetivos de recuperación deben guiar la estrategia de copia de seguridad del mainframe?

Los objetivos de recuperación no deben establecerse para luego ignorarse, ya que constituyen la base de toda la arquitectura de copia de seguridad del mainframe desde un punto de vista contractual. Todas las decisiones más allá de este punto (relativas a la frecuencia de las copias de seguridad, la topología de replicación y las opciones de niveles de almacenamiento) deben derivarse de los RTO y RPO establecidos. Las empresas que se saltan este paso suelen descubrir sus deficiencias durante un desastre real, el peor momento para que esto ocurra.

¿Cuál es la diferencia entre el RTO y el RPO para las cargas de trabajo de mainframe?

El RTO y el RPO son conceptos de recuperación ante desastres (DR) bien conocidos, pero su efecto en el contexto del mainframe es bastante significativo y puede tener un significado muy diferente al de las mismas métricas en los sistemas distribuidos.

El RPO (objetivo de punto de recuperación), el intervalo de tiempo máximo aceptable de pérdida de datos, resulta especialmente complicado para los mainframes debido a las relaciones entre las transacciones. Un mainframe que procese transacciones de pago de gran volumen podría tener fácilmente millones de registros por hora distribuidos en varios conjuntos de datos acoplados.

El RPO no es solo una instantánea tomada repetidamente tras un periodo de tiempo determinado, sino que implica la captura de todos los conjuntos de datos acoplados, catálogos y estructuras de acoplamiento en un momento concreto.

El RTO (Recovery Time Objective), el tiempo máximo asignado a las operaciones de restauración, conlleva sus propias complejidades en los mainframes. Recuperar un entorno z/OS no equivale a arrancar una máquina virtual a partir de una instantánea.

La mayoría de las veces, las empresas no se dan cuenta de su verdadero valor de RTO hasta que realizan una prueba de recuperación; en ese momento, nadie puede ignorar la diferencia entre el plazo de recuperación previsto y el real.

Ambos objetivos deben definirse por carga de trabajo, no por sistema. Un único mainframe puede alojar aplicaciones con tolerancias muy diferentes a la pérdida de datos y al tiempo de inactividad, que es precisamente lo que la clasificación por niveles de criticidad está diseñada para abordar.

¿Cómo deberían influir los niveles de criticidad en la frecuencia de las copias de seguridad y la retención?

No todas las cargas de trabajo que se ejecutan en un mainframe deben —ni pueden permitirse— protegerse de la misma manera. La clasificación por niveles de criticidad es el proceso mediante el cual la importancia crítica para el negocio se traduce en una política de copias de seguridad práctica. Asigna los recursos adecuados a las cargas de trabajo para las que se prevé una ventana de recuperación más larga, al tiempo que evita un exceso de protección en aquellas cargas de trabajo en las que se puede tolerar una ventana de recuperación más amplia.

Un modelo de clasificación práctico suele funcionar en tres niveles:

Las asignaciones de niveles deben basarse en un análisis del impacto en el negocio, más que en la conveniencia técnica, y deben revisarse al menos una vez al año: la criticidad de las cargas de trabajo cambia a medida que evolucionan las prioridades del negocio, y un conjunto de datos que el año pasado era de nivel 2 puede considerarse hoy de nivel 1.

¿Cómo afectan el cumplimiento normativo y los SLA a los objetivos de recuperación?

Los marcos de recuperación no solo incentivan una planificación sólida de la recuperación, sino que muchos exigen ahora resultados concretos y verificables.

• La normativa DORA exige que las entidades financieras definan y prueben las capacidades de recuperación frente a métricas predefinidas
• La norma PCI DSS establece requisitos específicos de disponibilidad e integridad para los sistemas que acceden a datos de titulares de tarjetas
• La norma de disponibilidad de la HIPAA establece obligaciones para mantener el acceso a la información médica protegida (PHI) en circunstancias específicas

El efecto práctico es que los objetivos de recuperación de una carga de trabajo regulada ya no están sujetos únicamente a una decisión interna. Siempre que los requisitos del SLA y los normativos se solapan, se elige el requisito más estricto. Por lo tanto, la solución de copia de seguridad del mainframe debe diseñarse, probarse y documentarse para satisfacer tanto a los auditores externos como a los internos.

¿Qué opciones de copia de seguridad in situ existen para los mainframes?

La copia de seguridad de mainframes in situ se basa en tres categorías tecnológicas distintas:

• Copia de seguridad basada en cinta (física y virtual)
• Copia de seguridad de disco a disco
• Copias puntuales

Cada una de estas opciones responde a diferentes necesidades de recuperación y limitaciones operativas. Saber dónde encaja cada enfoque es la base de cualquier estrategia de copia de seguridad de mainframes bien diseñada.

¿Cómo funcionan las copias de seguridad basadas en DASD (emulación de cinta, cintas virtuales) en los mainframes?

Las copias de seguridad en dispositivos de almacenamiento de acceso directo (DASD) forman parte de los entornos de mainframe desde hace muchos años, pero la tecnología ha cambiado significativamente con el tiempo.

Las bibliotecas de cintas virtuales (VTL) se utilizan ampliamente en entornos de mainframe como una capa de rendimiento delante de la cinta física, presentando una interfaz de cinta a z/OS mientras se escriben los datos en un almacenamiento basado en disco antes de migrarlos a cinta física para su retención a largo plazo. Una VTL se comporta como un dispositivo de cinta física desde la perspectiva del software del mainframe, pero escribe los datos en un almacenamiento basado en disco.

Como resultado, un JCL o un script de automatización escrito para realizar copias de seguridad en cinta física puede reutilizarse para copias de seguridad en VTL con pocas o ninguna modificación, lo que se traduce en un mejor rendimiento sin necesidad de cambiar toda la infraestructura de copias de seguridad.

La cinta física sigue siendo el medio de copia de seguridad principal en la mayoría de los entornos de mainframe hasta la fecha, y los VTL actúan como un intermediario con rendimiento optimizado que conserva las prácticas operativas basadas en cinta, al tiempo que reduce la manipulación mecánica y mejora el rendimiento de las copias de seguridad.

¿Cuándo es preferible optar por las copias de seguridad de disco a disco en lugar de las soluciones basadas en cinta?

La decisión de implementar copias de seguridad de disco a disco o en cinta para sus mainframes no es solo técnica, sino que a menudo viene determinada por una combinación de necesidades de recuperación, realidades empresariales y consideraciones económicas.

La copia de seguridad de disco a disco es la mejor opción cuando:

• La velocidad de recuperación es una prioridad: las restauraciones basadas en disco se completan en una fracción del tiempo que se requiere para localizar, montar y leer un volumen de cinta, lo que repercute directamente en el cumplimiento del RTO
• Los intervalos de copia de seguridad son ajustados: los destinos de disco de alto rendimiento pueden absorber los datos de copia de seguridad más rápido que la cinta, lo que reduce el riesgo de que los trabajos se salgan del intervalo asignado
• Se esperan pruebas de recuperación frecuentes: las restauraciones basadas en cinta introducen una sobrecarga operativa que desalienta las pruebas regulares de recuperación ante desastres, mientras que los destinos de disco hacen que las restauraciones de prueba sean rutinarias
• Se necesita una recuperación granular: restaurar un único conjunto de datos o un pequeño número de registros desde un disco es significativamente más práctico que buscar en volúmenes de cinta para localizar datos específicos

La cinta sigue siendo adecuada para aplicaciones en las que el almacenamiento a largo plazo, el archivo normativo o el almacenamiento externo la hacen rentable. Sin embargo, para cargas de trabajo con requisitos de RTO exigentes o necesidades de pruebas de recuperación frecuentes, el disco a disco puede ofrecer una ventaja operativa significativa como complemento de la copia de seguridad primaria basada en cinta.

¿Qué papel desempeñan las tecnologías de instantáneas y de punto en el tiempo en el mainframe?

Las instantáneas ocupan un lugar específico dentro del panorama de las copias de seguridad en mainframe; no son una alternativa a las copias de seguridad, sino un complemento a las capacidades de copia de seguridad existentes. Resultan especialmente valiosas en aquellos casos en los que las restricciones de las ventanas de copia de seguridad convencionales o las exigencias de granularidad de la recuperación superan las capacidades que los trabajos programados pueden ofrecer por sí mismos.

En z/OS, las tecnologías de copia en un momento determinado crean una copia dependiente instantánea de un conjunto de datos o volumen sin interrumpir la E/S de producción, siendo IBM FlashCopy la opción más destacada del mercado. Las características clave que definen cómo encajan estas tecnologías en una estrategia de copia de seguridad de mainframe incluyen:

• Requisitos de consistencia: una instantánea de un único volumen es sencilla, pero capturar una imagen coherente en un momento determinado de varios volúmenes relacionados en un entorno OLTP con mucha actividad requiere una coordinación cuidadosa para evitar capturar datos en medio de una transacción
• Granularidad de la recuperación: las instantáneas permiten una rápida recuperación a un estado reciente conocido como correcto, pero suelen conservarse durante períodos más cortos que las copias de seguridad tradicionales, lo que las hace inadecuadas como único mecanismo de recuperación
• Sobrecarga de almacenamiento: las copias dependientes consumen capacidad de almacenamiento adicional, y la relación entre los volúmenes de origen y destino debe gestionarse con cuidado para evitar que afecte al rendimiento de producción

Las instantáneas, cuando se utilizan correctamente, sirven como capa de recuperación rápida en un diseño de copia de seguridad de mainframe de varios niveles, donde pueden ocuparse de escenarios de recuperación frecuentes y recientes, mientras que la copia de seguridad tradicional se encarga del almacenamiento a largo plazo fuera del sitio.

¿Qué arquitecturas de recuperación ante desastres fuera del sitio y remotas hay disponibles?

La arquitectura de recuperación ante desastres fuera del sitio es donde la copia de seguridad de mainframe y la planificación de la continuidad del negocio están más interconectadas. Las decisiones específicas en la arquitectura de recuperación ante desastres fuera del sitio —el modo de replicación, la topología del sitio, la estrategia de almacenamiento— influyen no solo en el potencial de una recuperación a nivel de sitio, sino también en su velocidad y exhaustividad en condiciones reales.

¿Cómo afecta la replicación síncrona frente a la asíncrona a la capacidad de recuperación?

El modo de replicación es probablemente una de las decisiones arquitectónicas más importantes para una configuración de recuperación ante desastres de mainframe, ya que el modo de replicación especifica en realidad la cantidad mínima teórica de datos que las empresas pueden permitirse perder durante cualquier escenario de conmutación por error.

En la mayoría de los casos, no se trata de una elección simple y binaria. Muchos sistemas mainframe utilizan la replicación síncrona a un sitio secundario adyacente para satisfacer las necesidades de continuidad del negocio, junto con la replicación asíncrona a un sitio terciario más remoto para escenarios de desastres catastróficos. De esta manera, logran aceptar un RPO mayor debido a la separación geográfica de la copia de seguridad, ya que un enlace síncrono a gran distancia simplemente no sería práctico.

¿Cuáles son las ventajas y desventajas de los sitios de recuperación ante desastres (DR) activos-activos frente a los activos-pasivos?

La topología del sitio —cómo se relaciona el sitio secundario con la producción durante las operaciones normales— determina tanto el perfil de costes como el comportamiento de recuperación de toda la arquitectura de recuperación ante desastres.

Una configuración activa-activa ejecuta las cargas de trabajo de producción en ambos sitios simultáneamente. En este caso, la distribución de la carga de trabajo se realiza a través del sysplex. La principal ventaja de esta arquitectura es que la conmutación por error no es un evento discreto, ya que la capacidad ya está disponible en el sitio de recuperación ante desastres, y el cambio de un funcionamiento degradado a uno completo es significativamente más corto que en cualquier escenario de arranque en frío. Las copias de seguridad y la replicación del mainframe se utilizan siempre en lugar de permanecer inactivas, por lo que los fallos dentro de la postura de recuperación ante desastres (DR) aparecen durante el funcionamiento normal, no en un desastre real.

Tanto el coste como la complejidad son las contrapartidas en este caso. El modo activo-activo requiere una infraestructura completa de nivel de producción en ambos sitios, con un equilibrio continuo de la carga de trabajo y un diseño cuidadoso de las aplicaciones para gestionar la consistencia distribuida en las transacciones. Teniendo esto en cuenta, el modo activo-activo puede introducir más riesgos de los que puede eliminar para las organizaciones cuyas cargas de trabajo de mainframe están estrechamente integradas entre sí o son difíciles de particionar.

Los entornos activo-pasivo mantienen un sitio de respaldo en espera e inactivo, lo que reduce considerablemente el gasto en hardware. Esto implica que las soluciones de respaldo de mainframe que dan servicio a este sitio mantendrán el entorno pasivo lo suficientemente actualizado como para cumplir los requisitos de RTO —un reto que aumentará a medida que el nivel de actualización entre el primario y el secundario se diverja—. Lo que no se puede eludir en el activo-pasivo es el hecho de que la conmutación por error implica un periodo de transición real, y ese periodo debe someterse a pruebas periódicas para confirmar que se mantiene dentro de los límites aceptables.

¿Cuándo es adecuado el almacenamiento remoto en cinta o el almacenamiento en cinta basado en la nube?

La cinta —ya sea el almacenamiento físico o el basado en la nube— sigue siendo un elemento central de la arquitectura de copia de seguridad de mainframe, ya que satisface requisitos que las alternativas basadas en disco no siempre pueden cumplir, incluidos los requisitos de aislamiento físico y retención de soportes físicos exigidos explícitamente en marcos normativos como el PCI DSS. La cinta sigue siendo adecuada en un conjunto definido de condiciones:

• Retención reglamentaria a largo plazo: cuando las normas exigen años o décadas de conservación de datos y el coste de mantener esos datos en disco o en almacenamiento activo en la nube es prohibitivo
• Requisitos de aislamiento físico: cuando las políticas o normativas exigen una copia de los datos de copia de seguridad que esté física o lógicamente desconectada de toda la infraestructura accesible a través de la red
• Cargas de trabajo de archivo a las que se accede con poca frecuencia: cuando la probabilidad de necesitar una restauración es lo suficientemente baja como para que la latencia de recuperación sea una compensación aceptable por el coste de almacenamiento
• Protección complementaria para niveles de copia de seguridad activos: cuando la cinta sirve como copia secundaria de las copias de seguridad en disco, en lugar de como mecanismo de recuperación principal

Lo que el almacenamiento en cinta no debe ser es la solución principal de copia de seguridad de mainframe para ninguna carga de trabajo con un requisito de RTO significativo. La sobrecarga operativa que supone localizar, enviar y montar soportes físicos —o recuperar y preparar cintas basadas en la nube— hace que sea estructuralmente inadecuado para escenarios de recuperación en los que el tiempo es un factor crítico.

¿Cómo influyen la movilidad de datos y la integración multiplataforma en la recuperación de mainframes?

La recuperación del mainframe no se lleva a cabo de forma aislada. La infraestructura empresarial está ahora muy estrechamente interconectada; los motores de transacciones del mainframe alimentan bases de datos distribuidas, las aplicaciones de sistemas abiertos extraen datos del mainframe y los consumen en tiempo real, y las capas de API integran las plataformas de forma fluida y sin ambigüedades, creando muchas interdependencias que a menudo se pasan por alto en la planificación de la recuperación ante desastres.

Tratar la copia de seguridad y la recuperación del mainframe como un ejercicio autónomo —restaurando conjuntos de datos, catálogos y subsistemas sin tener en cuenta la coherencia de los sistemas distribuidos dependientes— producirá casi con toda seguridad un mainframe técnicamente recuperado con el que el resto del entorno empresarial no podrá interactuar de forma útil.

¿Cómo se pueden integrar los datos del mainframe con los sistemas distribuidos y abiertos para la recuperación ante desastres?

En el panorama empresarial moderno, es poco habitual que las cargas de trabajo del mainframe se ejecuten en sus propios entornos aislados. Los motores de transacciones del mainframe envían información a fuentes de datos que alimentan aplicaciones analíticas posteriores, mientras que los motores de transacciones de z/OS envían información a bases de datos distribuidas que las aplicaciones web consumen en tiempo real.

En caso de recuperación del mainframe, no se trata de la capacidad de restaurar el mainframe, sino de si todo el sistema dependiente puede volver a un estado de funcionamiento coherente junto con él. Las posibles técnicas de integración que lo permiten incluyen desde la replicación de datos basada en API hasta arquitecturas de almacenamiento compartido en las que el mainframe y los sistemas distribuidos pueden acceder a los mismos conjuntos de datos.

La elección correcta depende en gran medida de la latencia aceptable, el volumen de datos y el grado de criticidad de los requisitos de coherencia entre los dos sistemas. El elemento crucial del proceso de copia de seguridad del mainframe es que estos puntos de integración se asignen explícitamente y se incluyan en la planificación de la recuperación ante desastres, en lugar de tratarse como un problema ajeno.

¿Qué retos surgen al sincronizar cargas de trabajo de mainframe y no mainframe?

La sincronización entre plataformas es donde los planes de recuperación ante desastres heterogéneos fallan con mayor frecuencia. Los retos técnicos y operativos son lo suficientemente específicos como para merecer una atención especial:

• Desalineación de los límites de las transacciones: los sistemas mainframe suelen gestionar las transacciones con garantías ACID a nivel de conjunto de datos, mientras que los sistemas distribuidos pueden utilizar diferentes modelos de consistencia, lo que dificulta establecer un único punto de recuperación válido simultáneamente en ambos entornos
• Dependencias temporales: los trabajos por lotes que extraen datos del mainframe para su procesamiento posterior crean dependencias temporales implícitas que rara vez se documentan formalmente, lo que significa que una recuperación que restaure el mainframe a un punto anterior a la última ejecución por lotes puede dejar a los sistemas distribuidos por delante del mainframe en cuanto a la actualidad de los datos
• Consistencia del catálogo y los metadatos: restaurar conjuntos de datos del mainframe sin las actualizaciones correspondientes en los almacenes de metadatos distribuidos —o viceversa— puede dejar a las aplicaciones en un estado en el que hagan referencia a datos que no existen o que han sido sustituidos
• Compromisos de RTO y RPO divergentes: los equipos de mainframe y distribuidos suelen operar bajo SLA independientes, lo que puede dar lugar a esfuerzos de recuperación que restauran cada plataforma de forma independiente sin coordinar la consistencia en un momento dado requerida para las aplicaciones que abarcan ambos

Tampoco se trata de casos aislados. Los fallos de sincronización podrían ser una de las principales causas de una recuperación que, técnicamente, tiene éxito, pero que fracasa funcionalmente en entornos en los que los sistemas que no son mainframes acceden a los mismos datos que los mainframes o dependen operativamente de estos.

¿Cómo mejoran la resiliencia los entornos de copia de seguridad heterogéneos?

Uno de los principales impulsos en la TI empresarial es la estandarización: utilizar una única plataforma de copia de seguridad, un único conjunto de herramientas y un único modelo operativo. Los entornos de mainframe, por otro lado, son precisamente el lugar donde este enfoque podría no ser en absoluto el más adecuado.

Un entorno de copia de seguridad heterogéneo (en el que las soluciones de copia de seguridad nativas de mainframe operan junto a plataformas de sistemas abiertos con puntos de integración definidos) puede mejorar la resiliencia de formas que un enfoque de un único proveedor no siempre puede igualar. Ni las vulnerabilidades específicas de un proveedor ni los fallos de los productos pueden propagarse por todo el entorno de copia de seguridad. Una copia de seguridad nativa de mainframe utiliza conceptos propios de la plataforma, como los archivos VSAM, los catálogos z/OS y la integridad del sysplex, algo que los productos de sistemas abiertos generalmente no pueden hacer o no hacen bien, mientras que los productos de sistemas abiertos gestionan los componentes distribuidos para los que fueron diseñados.

La heterogeneidad no es lo mismo que la fragmentación. Se trata de una especialización intencionada con una integración conocida: no solo la presencia de múltiples herramientas no relacionadas entre sí, sino una arquitectura planificada que aprovecha lo que cada herramienta hace mejor.

¿Cómo se pueden aplicar los modelos de copia de seguridad híbridos e integrados en la nube a los mainframes?

La integración en la nube ha pasado de ser una consideración secundaria a convertirse en una opción arquitectónica habitual para las copias de seguridad de mainframes. Este cambio se debe principalmente a las presiones económicas, a las necesidades de flexibilidad geográfica y a la maduración de los niveles de almacenamiento en la nube, que ahora están diseñados para gestionar la escala de los volúmenes de datos de mainframe desde el principio.

También sería justo decir que, en la práctica, las opciones disponibles en este ámbito se centran en gran medida en el propio ecosistema de productos de IBM, dada la naturaleza propietaria de las interfaces de almacenamiento de z/OS.

¿Cuáles son las opciones para integrar las copias de seguridad de mainframe con el almacenamiento en la nube pública?

Existen varias formas en que las soluciones de copia de seguridad de mainframe pueden integrarse con la nube pública. Cada enfoque tiene características particulares y se adapta a diferentes tipos de necesidades de recuperación y niveles de volumen de datos. Los enfoques más ampliamente adoptados son:

• La nube como sustituto de las cintas: los datos de copia de seguridad se escriben en niveles de almacenamiento de objetos como AWS S3 o Azure Blob, utilizando interfaces compatibles con mainframe o dispositivos de puerta de enlace que traducen entre los formatos de copia de seguridad de z/OS y las API de almacenamiento en la nube
• La nube como destino de copia de seguridad secundario: las tareas de copia de seguridad locales se replican en el almacenamiento en la nube como una copia secundaria, lo que proporciona protección fuera del sitio sin sustituir la infraestructura de copia de seguridad principal in situ
• Bibliotecas de cintas virtuales basadas en la nube: soluciones VTL con backends nativos en la nube que presentan una interfaz de cinta familiar para z/OS mientras se escribe en almacenamiento de objetos en la nube escalable
• Arquitecturas de replicación híbridas: los datos del mainframe se replican a instancias de mainframe alojadas en la nube o a entornos compatibles, lo que permite una recuperación ante desastres (DR) basada en la nube en lugar de solo almacenamiento en la nube

El patrón de integración elegido determina directamente qué escenarios de recuperación se pueden facilitar en el nivel de la nube. Las soluciones de solo almacenamiento protegen contra el fallo del sitio, pero no aceleran la recuperación, lo que requiere recursos de computación dentro de la nube en lugar de solo datos.

¿Cómo se puede utilizar la orquestación de la recuperación ante desastres (DR) basada en la nube para la recuperación de mainframes?

Guardar copias de seguridad en la nube resuelve el problema de la conservación. Sin embargo, para recuperarlas rápidamente se necesita una orquestación: flujos de trabajo predefinidos que coordinen la serie de acciones que tienen lugar desde que se toma la decisión de realizar la conmutación por error hasta que el sistema mainframe está realmente en funcionamiento.

La coordinación de la recuperación ante desastres (DR) basada en la nube para soluciones de copia de seguridad de mainframe puede incluir:

• Activación automática de la conmutación por error: supervisión del estado que detecta fallos en el sitio principal e inicia flujos de trabajo de recuperación sin intervención manual
• Secuenciación de la recuperación: guías de ejecución predefinidas que ejecutan los pasos de IPL, recuperación del catálogo y reinicio de aplicaciones en el orden de dependencia correcto
• Aprovisionamiento del entorno: puesta en marcha automatizada de los recursos de computación y almacenamiento alojados en la nube necesarios para recibir y ejecutar las cargas de trabajo recuperadas
• Automatización de pruebas: pruebas de recuperación ante desastres programadas y sin interrupciones que validan los procedimientos de recuperación con los datos de copia de seguridad actuales sin afectar a la producción
• Coordinación de la reversión: procedimientos gestionados de conmutación de retorno que devuelven las cargas de trabajo al sitio primario una vez restaurado, sin pérdida de datos ni brechas de consistencia

La madurez de las capacidades de orquestación disponibles varía considerablemente entre los distintos proveedores. Tampoco todas las soluciones admiten de forma nativa toda la gama de pasos de recuperación específicos de z/OS.

¿Qué consideraciones de seguridad y rendimiento surgen al combinar mainframes con copias de seguridad en la nube?

Las implicaciones de ampliar las copias de seguridad de mainframe a la nube conllevan una serie de matices, al situarse en la encrucijada de dos paradigmas de infraestructura muy diferentes. Lo mejor es examinar estas ventajas e inconvenientes cara a cara:

Ni la seguridad ni el rendimiento pueden considerarse temas secundarios en las arquitecturas de copia de seguridad en la nube para mainframes, ya que comprometer cualquiera de ellos socavaría inmediatamente el valor de toda la integración.

¿Qué software y herramientas admiten la copia de seguridad y la recuperación de mainframes?

El panorama del software de copia de seguridad para mainframe es relativamente limitado, pero su complejidad es comparable a la de las soluciones de copia de seguridad distribuida en lo que respecta a la complejidad general.

La lista de soluciones disponibles abarca desde soluciones nativas de Z/OS profundamente integradas hasta plataformas empresariales más amplias con conectores para mainframe. Los actores consolidados en este ámbito —entre los que se encuentran IBM DFSMS y DFSMShsm, CA Disk de Broadcom y Backup for z/OS de Rocket Software— se analizan en detalle a continuación, junto con las consideraciones arquitectónicas que se aplican independientemente de la elección del producto.

La elección correcta varía mucho en función del entorno existente, los requisitos de recuperación y el modelo operativo.

¿Cómo facilitan las herramientas de copia de seguridad los estándares abiertos y las API (por ejemplo, las API de IBM o REST)?

La naturaleza históricamente cerrada de las herramientas de copia de seguridad para mainframe está empezando a evolucionar hacia modelos de integración más abiertos. La exposición por parte de IBM de las funciones de gestión de z/OS a través de API REST ha creado posibilidades para que los proveedores de copias de seguridad o los desarrolladores internos desarrollen diversas integraciones (algo que antes era imposible sin utilizar interfaces propietarias).

La interoperabilidad es la ventaja práctica en este caso. Las soluciones de copia de seguridad de mainframe que admiten (proporcionan o utilizan) API estándar tendrán cabida en soluciones de orquestación de copias de seguridad empresariales más amplias, proporcionando información de estado a herramientas de supervisión centralizadas, recibiendo cambios de políticas de plataformas de gestión unificadas o dirigiéndose al almacenamiento en la nube a través de interfaces de almacenamiento de objetos estándar.

La necesidad de especialistas en copias de seguridad de mainframe no desaparece por completo (los que cuentan con experiencia en copias de seguridad de z/OS), pero sí reduce el grado de separación entre las copias de seguridad de mainframe y el resto del entorno de copias de seguridad de la empresa.

¿Qué papel desempeñan las herramientas de automatización y orquestación en los flujos de trabajo de recuperación?

Los procedimientos de recuperación manuales son un lastre. Si se ejecutan guiones complejos de varios pasos bajo presión, la probabilidad de error humano aumenta drásticamente, incluyendo errores de secuencia, dependencias omitidas y otros retrasos.

La automatización consigue eliminar todos esos problemas por diseño. Las áreas en las que la automatización aporta el valor más directo en los flujos de trabajo de copia de seguridad y recuperación de mainframe son:

• Programación de trabajos de copia de seguridad y gestión de dependencias: garantiza que los trabajos se ejecuten en el orden correcto, con los pasos de pre y posprocesamiento adecuados, sin intervención manual
• Verificación del catálogo: comprobaciones automatizadas que confirman la integridad del catálogo de copias de seguridad después de cada trabajo, detectando problemas antes de que se conviertan en sorpresas durante la recuperación.
• Flujos de trabajo de alertas y escalado: notificación inmediata cuando los trabajos de copia de seguridad fallan, superan su ventana de tiempo o producen resultados inconsistentes, y se envían a los equipos adecuados sin necesidad de supervisión manual
• Ejecución del manual de recuperación: ejecución secuencial y mediante scripts de los pasos de recuperación que reduce la carga cognitiva de los operadores durante eventos de alta tensión y garantiza el orden correcto de las dependencias

Una mayor cobertura de la automatización conduce a la previsibilidad y la capacidad de prueba durante los procesos de recuperación. Un flujo de trabajo de recuperación que se ha llevado a cabo cientos de veces de forma automática es significativamente más fiable que un flujo de trabajo que solo existe como documento.

¿Qué productos de copia de seguridad comerciales hay disponibles para z/OS y plataformas relacionadas?

El mercado comercial de soluciones de copia de seguridad para mainframe está dominado por un reducido grupo de proveedores especializados cuyos productos han evolucionado junto con z/OS durante muchos años. Como tal, todas estas soluciones comparten una característica común: están construidas con un conocimiento nativo de las estructuras de z/OS que las plataformas de copia de seguridad de uso general no podrían replicar sin importantes concesiones.

Las principales categorías de capacidades que diferencian entre sí a los productos de copia de seguridad para mainframe incluyen:

• Granularidad a nivel de conjunto de datos: la capacidad de realizar copias de seguridad, catalogar y restaurar conjuntos de datos individuales en lugar de volúmenes completos, lo cual es esencial para las operaciones prácticas de recuperación del día a día
• Reconocimiento de Sysplex: gestión de estructuras de acoplamiento y conjuntos de datos compartidos en un Sysplex paralelo sin brechas de consistencia
• Gestión de catálogos: manejo integrado del catálogo ICF, que es en sí mismo una dependencia de recuperación que debe gestionarse con cuidado
• Compresión y deduplicación: reducción en línea de los volúmenes de datos de copia de seguridad, lo que repercute directamente en los costes de almacenamiento y en la duración de la ventana de copia de seguridad

A la hora de elegir una solución de copia de seguridad para mainframe, estas funcionalidades deben sopesarse en función de la combinación de cargas de trabajo y las necesidades de recuperación del entorno. Algunas de las soluciones comerciales de copia de seguridad para mainframe más ampliamente implementadas incluyen:

• IBM DFSMS y DFSMShsm: el gestor de almacenamiento nativo de z/OS de IBM y el gestor de almacenamiento jerárquico
• Broadcom ACF2 y CA Disk: herramientas de copia de seguridad y restauración a nivel de conjunto de datos de larga trayectoria, con una profunda integración con z/OS y una amplia adopción en el ámbito empresarial
• Rocket Backup for z/OS de Rocket Software: copia de seguridad de conjuntos de datos de alto rendimiento con potentes capacidades de compresión y gestión de catálogos

Estas soluciones no son directamente intercambiables: cada una tiene diferentes puntos fuertes en áreas como la compatibilidad con sysplex, la integración en la nube y la automatización operativa, por lo que la evaluación de las capacidades en función de los requisitos específicos del entorno es más importante que la mera reputación del proveedor.

¿Cómo se gestionan la seguridad, el cumplimiento normativo y la retención en las copias de seguridad de mainframe?

¿Qué opciones de cifrado y gestión de claves protegen los datos de copia de seguridad en reposo y en tránsito?

El cifrado basado en hardware lleva décadas presente en entornos de mainframe, con la familia IBM Crypto Express y el cifrado de conjuntos de datos de z/OS. Se trata de una ventaja consolidada frente a muchos entornos distribuidos que debe mantenerse una vez que los datos de copia de seguridad se encuentran fuera del ecosistema del mainframe. El cifrado de los datos de copia de seguridad del mainframe en reposo y en tránsito debe considerarse un requisito y no una característica opcional.

En reposo, el cifrado de conjuntos de datos de z/OS con AES-256 se realiza de forma implícita en la capa de almacenamiento, por lo que el cifrado puede llevarse a cabo sin necesidad de realizar cambios en el software de copia de seguridad ni en el código de la aplicación. En tránsito, la transmisión a una ubicación externa o a la nube está protegida con cifrado TLS.

La gestión de claves es donde la complejidad aumenta en la mayoría de los casos. La seguridad del cifrado depende de las medidas de protección aplicadas al almacenamiento de claves. En entornos de copia de seguridad de mainframe, estas claves deben ser accesibles durante la recuperación sin convertirse en una vulnerabilidad potencial.

El marco ICSF de IBM y los módulos de seguridad de hardware proporcionan la base para la gestión de claves empresariales en z/OS, pero las organizaciones que deseen ampliar las copias de seguridad a la nube o a destinos distribuidos deberán asegurarse de que siguen teniendo el control sobre la custodia de las claves (en lugar de delegar esta tarea a un proveedor externo de forma predeterminada).

¿Qué capacidades de auditoría y generación de informes son necesarias para la verificación del cumplimiento?

La verificación del cumplimiento normativo para las copias de seguridad de mainframe no se satisface con el mero hecho de contar con las políticas adecuadas, sino que requiere pruebas demostrables de que dichas políticas se ejecutan de forma coherente y de que las excepciones se registran y se abordan. Las capacidades de auditoría y generación de informes que deben ofrecer las soluciones de copia de seguridad de mainframe incluyen:

• Registro de finalización de trabajos: registros con marca de tiempo de cada trabajo de copia de seguridad, incluyendo el estado de éxito, fallo y finalización parcial, conservados durante todo el periodo de cumplimiento pertinente
• Informes de integridad del catálogo: verificación periódica de que los catálogos de copia de seguridad reflejan con precisión los datos que indexan, con resultados documentados disponibles para su revisión en auditorías
• Auditoría de accesos y cambios: registros de cada acción administrativa que afecte a la configuración de la copia de seguridad, a los ajustes de retención o a los propios datos de la copia de seguridad, incluyendo la identidad del responsable y la marca de tiempo
• Documentación de pruebas de recuperación: registros formales de la ejecución de pruebas de recuperación ante desastres, los resultados y cualquier deficiencia identificada, algo que los reguladores esperan cada vez más ver como prueba de la resiliencia operativa
• Historial de excepciones y alertas: registros documentados de fallos de copia de seguridad, ventanas perdidas e incumplimientos de políticas, junto con pruebas de cómo se resolvió cada uno de ellos

Incluso la falta de funcionalidad de registro de auditoría podría constituir un incumplimiento en virtud de varios marcos normativos, por lo que la infraestructura de generación de informes en torno a las copias de seguridad de mainframe no es una mera comodidad, sino un componente de la postura de cumplimiento.

¿Cómo deben las políticas de retención satisfacer las necesidades normativas y empresariales?

El diseño de las políticas de retención para las copias de seguridad de mainframe se encuentra en la encrucijada entre los mandatos normativos, los requisitos de recuperación empresarial y la gestión de los costes de almacenamiento. Lamentablemente, estos tres requisitos rara vez tienen los mismos objetivos: la normativa puede exigir una retención de 7 años, los requisitos de recuperación empresarial se cumplen tras 90 días y los costes de almacenamiento exigen el plazo más breve posible que sea justificable.

El panorama normativo establece mínimos innegociables para muchos entornos de mainframe:

Las políticas de conservación deben determinarse en función de la clasificación de los datos, no del sistema. Un único mainframe puede alojar datos sujetos a múltiples políticas de conservación simultáneamente, y una política de conservación general que aplique el requisito más conservador a todos los conjuntos de datos supone un desperdicio de almacenamiento y complica innecesariamente la gestión del ciclo de vida.

¿Cómo se elabora una hoja de ruta para mejorar la madurez de las copias de seguridad y la recuperación ante desastres (DR) del mainframe?

Mejorar la madurez de las copias de seguridad de mainframe rara vez es un proyecto único: se trata de un programa de mejoras incrementales que tiene como objetivo alcanzar una posición de recuperación ante desastres (DR) alcanzable, comprobable y verificada continuamente. La hoja de ruta que se elabora a partir de ahí comienza con un análisis honesto de la situación actual.

¿Qué preguntas de evaluación ayudan a determinar la madurez actual y las deficiencias?

Antes de priorizar las mejoras, las organizaciones necesitan tener una visión clara de su situación actual en materia de copias de seguridad de mainframe. Las siguientes preguntas constituyen la base de esa evaluación:

• ¿Están definidos formalmente los objetivos de recuperación? Deben existir objetivos de RTO y RPO documentados para cada carga de trabajo de mainframe, asignados a niveles de criticidad, y no supuestos o heredados de documentación heredada que no se haya revisado recientemente.
• ¿Cuándo se realizó la última prueba de recuperación completa? No se puede confiar plenamente en una estrategia de copia de seguridad de mainframe que no se haya probado de extremo a extremo en los últimos 12 meses: las suposiciones no comprobadas se acumulan silenciosamente con el tiempo. En z/OS, «de extremo a extremo» significa incluir la secuencia de IPL, la recuperación del catálogo ICF y los procedimientos de reinicio de subsistemas, no solo verificar que los datos de copia de seguridad existen.
• ¿Se almacenan los catálogos de copia de seguridad de forma independiente de los sistemas que protegen? La pérdida de catálogos durante un evento de recuperación es una de las causas más comunes y evitables de fallo en la recuperación. En z/OS, esto incluye tanto el catálogo maestro ICF como cualquier catálogo de usuario, así como los conjuntos de datos de control DFSMShsm, todos los cuales son dependencias de recuperación por derecho propio.
• ¿Están los datos de copia de seguridad protegidos contra amenazas internas y ransomware? Las políticas de inmutabilidad, los controles de acceso y los procedimientos de aislamiento físico deben estar documentados y ser verificables, y no darse por sentado que existen solo porque se implementaron en algún momento en el pasado. En z/OS, esto significa verificar específicamente la cobertura de las políticas RACF o ACF2 sobre los conjuntos de datos y catálogos de copia de seguridad, y no solo sobre los datos de producción.
• ¿Se han mapeado las dependencias entre plataformas? Cada sistema distribuido, API o aplicación descendente que dependa de datos del mainframe debe estar documentado, con su relación de recuperación con el mainframe definida explícitamente.
• ¿Cumple el entorno de copia de seguridad los requisitos de cumplimiento normativo actuales? Los periodos de retención, las normas de cifrado y las capacidades de registro de auditoría deben verificarse con respecto al marco normativo actual, no al que estaba vigente cuando se redactó por última vez la política de copia de seguridad.

¿Cómo deben priorizarse las mejoras incrementales (resultados rápidos frente a proyectos a largo plazo)?

No todas las deficiencias identificadas en la evaluación pueden abordarse simultáneamente. Un marco de priorización práctico va desde la reducción inmediata del riesgo hasta la mejora arquitectónica a largo plazo:

1. Corrija primero la vulnerabilidad del catálogo: si los catálogos de copia de seguridad no están protegidos de forma independiente, esa deficiencia representa un riesgo existencial para la recuperación que supera en urgencia a todas las demás mejoras.
2. Establecer o validar los objetivos de recuperación: sin objetivos RTO y RPO documentados, todas las mejoras posteriores carecen de un estándar medible hacia el que trabajar.
3. Implemente controles de inmutabilidad y acceso: las mejoras en la resiliencia frente al ransomware tienen un gran impacto y son relativamente factibles sin cambios arquitectónicos importantes, lo que las convierte en logros iniciales sólidos.
4. Realice una prueba de recuperación completa: antes de invertir en nuevas herramientas o arquitectura, valide lo que el entorno actual puede ofrecer realmente en condiciones de recuperación reales.
5. Abordar las deficiencias de sincronización entre plataformas: una vez estabilizada la postura de copia de seguridad del mainframe, ampliar el enfoque a las dependencias distribuidas y a la coordinación de la recuperación más allá de los límites de las plataformas.
6. Evalúe las deficiencias en herramientas y automatización: con una visión clara de los requisitos de recuperación y las capacidades actuales, las decisiones sobre herramientas pueden tomarse en función de criterios específicos y validados, en lugar de basarse en las afirmaciones de los proveedores.
7. Avance hacia la validación continua: la verificación automatizada de las copias de seguridad, las pruebas de recuperación ante desastres programadas y el seguimiento continuo de los KPI sustituyen las evaluaciones puntuales por una visión continuamente actualizada de la preparación para la recuperación ante desastres.

¿Qué KPI y métricas deben guiar la madurez continua del programa de recuperación ante desastres?

Un programa de copias de seguridad de mainframe que no se mide no se gestiona. Las siguientes métricas proporcionan un marco práctico para el seguimiento de la madurez de la recuperación ante desastres a lo largo del tiempo:

• Tiempo de recuperación real frente al objetivo: la diferencia entre el tiempo de recuperación probado y el RTO documentado, medido durante cada prueba de recuperación ante desastres y seguido como una tendencia a lo largo del tiempo.
• Punto de recuperación real frente al objetivo: la ventana de pérdida de datos real alcanzada durante las pruebas de recuperación, comparada con el RPO documentado para cada nivel de carga de trabajo.
• Tasa de éxito de los trabajos de copia de seguridad: el porcentaje de trabajos de copia de seguridad de mainframe programados que se completan con éxito dentro de su ventana definida, que se supervisa semanalmente y se investiga cuando cae por debajo de un umbral acordado.
• Tiempo medio de detección de fallos de copia de seguridad: rapidez con la que se identifican los fallos de copia de seguridad tras producirse, lo que repercute directamente en el tiempo que el entorno opera con una brecha no detectada en su protección.
• Frecuencia de verificación de la integridad del catálogo: con qué frecuencia se verifica la exactitud y la integridad de los catálogos de copia de seguridad, documentándose los resultados con fines de auditoría.
• Cobertura de la coordinación de la recuperación de Sysplex: el porcentaje de cargas de trabajo de Nivel 1 para las que se documentan y prueban explícitamente las dependencias de recuperación entre sistemas, incluidas las estructuras de acoplamiento y las relaciones entre conjuntos de datos compartidos.
• Frecuencia y cobertura de las pruebas de recuperación ante desastres: el número de pruebas de recuperación ante desastres realizadas al año y el porcentaje de cargas de trabajo de Nivel 1 y Nivel 2 incluidas en cada ciclo de pruebas.
• Tiempo de corrección de las deficiencias identificadas: el tiempo medio que transcurre entre la identificación de una deficiencia —mediante pruebas, auditorías o supervisión— y la implementación de una solución validada.

Conclusión

La copia de seguridad y la recuperación del mainframe no es un proyecto que se resuelve una vez y nunca más se vuelve a tocar. El panorama de amenazas evoluciona, los requisitos empresariales cambian, los marcos normativos se endurecen y los sistemas que dependen de los datos del mainframe se vuelven más interconectados con el tiempo. La estrategia de copia de seguridad del mainframe que era suficiente hace tres años probablemente tenga hoy una serie de deficiencias, no porque haya fallado, sino porque el entorno que la rodea ha cambiado mientras que la estrategia no lo ha hecho.

Las organizaciones que logran mantener una verdadera resiliencia de recuperación ante desastres (DR) abordan la copia de seguridad de mainframe como un programa continuo, no como un proyecto puntual. Los objetivos de recuperación definidos, los procedimientos probados, los controles de seguridad aplicados y las políticas de retención revisadas periódicamente no son entregables puntuales, sino hábitos operativos que determinan si la recuperación es posible cuando realmente importa.

Preguntas frecuentes

¿Se pueden utilizar los datos de las copias de seguridad del mainframe para respaldar iniciativas de análisis o de lagos de datos?

Los datos de las copias de seguridad de mainframe pueden servir como fuente para iniciativas de análisis, pero requieren un manejo cuidadoso: los conjuntos de datos de las copias de seguridad están estructurados para la recuperación, no para la consulta, y normalmente necesitan una transformación antes de que resulten útiles en el contexto de un lago de datos. El enfoque más práctico consiste en tratar las copias de seguridad de mainframe como una fuente de datos secundaria que complemente los procesos de extracción de datos diseñados específicamente para tal fin, en lugar de sustituirlos. Las organizaciones que intentan utilizar directamente los datos de copia de seguridad sin procesar para el análisis suelen descubrir que la sobrecarga operativa que suponen la conversión de formatos y la validación de la coherencia supera el valor de los propios datos.

¿Cuáles son los riesgos de confiar únicamente en la replicación para la recuperación ante desastres?

La replicación aborda eficazmente los fallos a nivel de sitio, pero no ofrece protección contra la corrupción lógica: si se escriben datos erróneos en el sitio primario, la replicación propaga esos datos erróneos al sitio secundario casi en tiempo real. Una estrategia de copia de seguridad de mainframe basada únicamente en la replicación no tiene ningún punto de recuperación anterior al evento de corrupción, lo que significa que los errores lógicos, el cifrado por ransomware y los errores de las aplicaciones que producen datos incorrectos pueden dejar ambos sitios igualmente inutilizables. La replicación debe ser una capa de una arquitectura de copia de seguridad de mainframe más amplia, no la estrategia completa.

¿Cómo deben adaptarse las estrategias de copia de seguridad de mainframe a los requisitos de ESG y soberanía de datos?

Los requisitos de soberanía de datos —que exigen que ciertos datos permanezcan dentro de límites geográficos o jurisdiccionales específicos— limitan directamente las opciones de copia de seguridad fuera del sitio y en la nube disponibles para los entornos de mainframe que operan en múltiples regiones. Las soluciones de copia de seguridad de mainframe deben evaluarse en función de los requisitos de soberanía de cada jurisdicción en la que opera la organización, no solo de la ubicación del centro de datos principal. Las consideraciones ESG añaden una dimensión adicional, ya que el consumo energético de la infraestructura de copia de seguridad —en particular, las grandes bibliotecas de cintas y la replicación permanente— se convierte en un factor en los informes de sostenibilidad de las organizaciones con compromisos formales en materia de ESG.