Sauvegarde et reprise sur mainframe : stratégies modernes pour des systèmes d’entreprise résilients

Quel est le paysage actuel de la sauvegarde et de la reprise après sinistre des mainframes ?

Dans un environnement informatique – en particulier dans l’informatique d’entreprise –, la sauvegarde mainframe reste l’une des disciplines les plus critiques et souvent sous-estimées.

Les transactions financières, les dossiers d’assurance et les programmes gouvernementaux dépendent de plus en plus des mainframes, ce qui signifie que les risques de panne du système sont également à un niveau record. Une solution de sauvegarde mainframe doit être capable de répondre à un type de demande que le système de sauvegarde distribué classique n’a jamais été conçu pour offrir.

Pourquoi les mainframes nécessitent-ils encore des approches spécialisées en matière de sauvegarde et de reprise après sinistre ?

Un mainframe n’est pas simplement un serveur surdimensionné. Son architecture a été conçue autour des concepts de disponibilité continue, de débit d’E/S massif et de séparation des charges de travail – des facteurs qui déterminent la conception et l’exécution des sauvegardes à un niveau fondamental.

Un environnement z/OS gérant des milliers de transactions par seconde ne peut pas se contenter des mêmes fenêtres de sauvegarde, des mêmes modèles de cohérence et des mêmes procédures de récupération que ceux utilisés par les serveurs de fichiers Linux.

Les systèmes de sauvegarde mainframe doivent gérer un certain nombre de concepts propres à la plateforme et qui n’existent nulle part ailleurs : les ensembles de données VSAM, les catalogues z/OS, les structures de couplage et les environnements sysplex, qui nécessitent tous leurs propres mécanismes. La sauvegarde d’un cluster VSAM est très différente de celle d’une arborescence de répertoires, tandis que la restauration d’un sysplex vers un état cohérent implique une coordination bien au-delà des capacités des outils de sauvegarde génériques.

L’échelle est également un enjeu à part entière. Les mainframes gèrent régulièrement des volumes de données de l’ordre du pétaoctet, avec des exigences SLA strictes qui imposent que le processus de sauvegarde fonctionne en parallèle de l’activité de production sans aucun impact perceptible. Cette contrainte à elle seule exclut un grand nombre de solutions standard.

Quelles sont les menaces et les modes de défaillance courants dans les environnements mainframe ?

Bien que conçus pour être extrêmement fiables, les mainframes ne sont pas invincibles. Les types de défaillances susceptibles de mettre en danger un environnement mainframe sont nombreux, et une stratégie de sauvegarde mainframe appropriée doit tous les prendre en compte :

• Panne matérielle – Dégradation du sous-système de stockage, pannes de canaux ou défaillances de processeurs, pouvant corrompre les données ou les rendre inaccessibles même sans panne totale du système
• Erreur humaine – Suppression accidentelle de jeux de données, tâches JCL mal configurées ou mises à jour erronées du catalogue, qui représentent une part importante des incidents de récupération réels
• Défauts logiciels et applicatifs – Des bogues dans la logique de traitement par lots ou dans les intergiciels qui écrivent des données incorrectes, et qui peuvent ne se manifester qu’une fois que les enregistrements se sont déjà propagés en aval
• Ransomware et attaques malveillantes – Un vecteur de menace de plus en plus pertinent, abordé en détail dans la section suivante
• Catastrophes au niveau du site – Coupure de courant, inondation ou défaillance de l’infrastructure physique affectant l’ensemble d’un centre de données

Aucune menace ne prime sur les autres. Le basculement matériel ne suffit pas si les données logiquement corrompues ne sont pas traitées, et inversement, lorsqu’il s’agit de définir la stratégie de sauvegarde du mainframe.

En quoi les exigences commerciales modernes modifient-elles les attentes en matière de sauvegarde et de reprise après sinistre ?

La définition du terme « récupérable » a également considérablement évolué au fil des ans.

Un objectif de RTO de 4 heures pouvait être raisonnable il y a dix ans pour bon nombre de charges de travail. Aujourd’hui, les équipes chargées de la continuité des activités visent un RTO de zéro (ou très proche de zéro) pour les applications critiques, sous l’impulsion du commerce numérique, des réseaux de paiement en temps réel et des réglementations qui considèrent les pannes importantes comme une violation de la conformité réglementaire plutôt que comme un simple désagrément opérationnel.

Bon nombre de ces attentes sont désormais consignées dans des cadres réglementaires. En vertu de normes telles que DORA et PCI DSS, les organisations sont désormais tenues de définir formellement et de tester régulièrement leurs objectifs de reprise. Le fait de ne pas établir ou respecter ces engagements est considéré comme un manquement à la conformité et traité en conséquence.

Pour les organisations dont l’activité repose sur des mainframes, cette dimension réglementaire fait de la planification de la reprise après sinistre (DR) une responsabilité de gouvernance, et pas seulement une responsabilité technique.

Pourquoi les stratégies de sauvegarde des mainframes évoluent-elles à l’ère des cybermenaces ?

Les cybermenaces modernes ont modifié les capacités requises pour la sauvegarde des mainframes. Les environnements mainframe s’appuient depuis longtemps sur des capacités de résilience spécialement conçues – mise en miroir, copie à un instant donné et redondance en couches – qui étaient très efficaces contre les modèles de menaces pour lesquels elles avaient été conçues : pannes matérielles, erreurs humaines et sinistres au niveau du site.

Malheureusement, la montée en puissance des ransomwares complexes et des attaques de la chaîne d’approvisionnement a introduit une nouvelle catégorie de problèmes où les sauvegardes sont également ciblées. L’émergence de groupes de ransomwares tels que Conti – dont les manuels d’attaque documentés citaient l’identification et la destruction des sauvegardes comme objectif principal avant de déclencher le chiffrement – a introduit un modèle de menace auquel les stratégies de sauvegarde des entreprises n’étaient pas préparées.

Comment les ransomwares ciblent-ils les environnements hérités et les mainframes ?

L’hypothèse selon laquelle les mainframes sont intrinsèquement protégés contre les ransomwares en raison de leur architecture a longtemps été largement répandue. Cependant, cette hypothèse est de plus en plus remise en question à mesure que les environnements mainframe s’intègrent davantage aux systèmes ouverts et aux infrastructures distribuées.

Les auteurs de ransomware modernes sont calculateurs et méthodiques ; ils analysent et cartographient l’infrastructure avant d’activer une charge utile, recherchant spécifiquement les référentiels et catalogues de sauvegarde afin de désactiver tout mécanisme de restauration avant de lancer le processus de chiffrement.

Les environnements mainframe présentent un risque d’exposition particulier en raison de leurs points d’intégration. Les systèmes z/OS communiquent en permanence avec des réseaux distribués, des niveaux de stockage cloud et des intergiciels de systèmes ouverts (chacun pouvant servir de point d’entrée). À mesure que les environnements mainframe s’intègrent de plus en plus profondément aux infrastructures distribuées, la surface d’attaque s’étend : la compromission d’un système connecté pourrait, dans des architectures réseau suffisamment plates, ouvrir une voie vers les niveaux de stockage partagés sur lesquels résident les ensembles de données de sauvegarde mainframe.

Dans de nombreuses configurations, les catalogues de sauvegarde mainframe et les ensembles de données de contrôle résident sur la même structure de stockage que les données qu’ils protègent – ce qui signifie qu’un attaquant bien placé, ou un incident de corruption se propageant à travers le stockage partagé, pourrait affecter les deux simultanément. Il ne faut pas réfléchir longtemps pour conclure qu’un catalogue de sauvegarde existant sur la même structure de stockage que les données elles-mêmes pourrait être corrompu et détruit lors du même incident.

C’est précisément cette situation que doivent désormais résoudre les architectures modernes de sauvegarde mainframe.

Quel est le rôle des sauvegardes immuables et isolées physiquement pour les mainframes ?

Il s’agit des deux principales approches architecturales pour lutter contre les ransomwares : l’immuabilité et l’isolation physique. Bien qu’il s’agisse de deux concepts majeurs évoqués dans le cadre de la lutte contre les ransomwares, ils fonctionnent en réalité de manière différente.

Ces deux approches ne s’excluent pas mutuellement. Une stratégie de sauvegarde mainframe bien conçue peut englober les deux : une copie immuable pour permettre une restauration très rapide en cas d’attaques logiques, et une copie isolée physiquement pour une restauration ultime dans les cas où l’immuabilité au niveau du stockage a également été compromise (via l’utilisation d’un compte administrateur privilégié ou des attaques ciblant directement la couche de stockage).

Lorsque l’immuabilité de la couche de stockage n’est pas déjà fournie en natif – comme c’est le cas, par exemple, avec IBM DS8000 Safeguarded Copy et le framework Z Cyber Vault –, la mise en œuvre sur z/OS nécessite une intégration minutieuse avec les outils de sauvegarde existants afin de garantir que les politiques d’immuabilité sont appliquées au niveau de la couche de stockage plutôt qu’au niveau de la couche applicative (où elles peuvent potentiellement être contournées).

Comment les principes du « zero trust » s’appliquent-ils aux architectures de sauvegarde mainframe ?

z/OS a intégré bon nombre des principes désormais associés à l’architecture « zero-trust » – contrôles d’accès obligatoires, séparation stricte des tâches et pistes d’audit complètes – bien avant que ce terme n’entre dans le discours courant sur la sécurité. En ce qui concerne spécifiquement la sauvegarde mainframe, la question porte donc moins sur l’introduction des concepts « zero-trust » que sur la garantie que les politiques RACF ou ACF2 sont configurées pour appliquer ces principes de manière cohérente à l’environnement de sauvegarde, qui est parfois considéré comme présentant moins de risques que l’environnement de production et autorisé à accumuler des privilèges excessifs au fil du temps.

En matière de sauvegarde mainframe, le « zero-trust » implique qu’aucun périphérique, utilisateur ou processus (même les administrateurs de sauvegarde) ne soit jamais présumé disposer d’un accès implicite ou de la capacité de gérer les données de sauvegarde. Concrètement, cela implique une séparation stricte des tâches, une authentification à deux facteurs pour accéder à la console de gestion des sauvegardes, ainsi que des autorisations strictes basées sur les rôles limitant les personnes autorisées à supprimer, modifier ou désactiver des tâches de sauvegarde.

Sous z/OS, cela se traduit par la conception de politiques RACF ou ACF2 qui restreignent explicitement l’accès au catalogue de sauvegarde, combinée à des alertes hors bande pour toute action administrative touchant aux paramètres de conservation ou aux calendriers de sauvegarde. L’environnement de sauvegarde mainframe doit être traité comme un système critique pour la sécurité en soi, de sorte que les cycles de révision des accès et les pistes d’audit répondent aux mêmes normes que celles appliquées aux données de production.

Quels objectifs de reprise doivent guider la stratégie de sauvegarde du mainframe ?

Les objectifs de reprise ne doivent pas être définis puis ignorés, car ils constituent la base de l’ensemble de l’architecture de sauvegarde du mainframe sur une base contractuelle. Toutes les décisions au-delà de ce point (concernant la fréquence des sauvegardes, la topologie de réplication, les choix de niveaux de stockage) doivent découler des RTO et RPO établis. Les entreprises qui sautent cette étape découvrent généralement leurs lacunes lors d’un sinistre réel – le pire moment pour que cela se produise.

Quelle est la différence entre le RTO et le RPO pour les charges de travail mainframe ?

Le RTO et le RPO sont des concepts bien connus en matière de reprise après sinistre, mais leur impact dans le contexte du mainframe est considérable et peut revêtir une signification très différente de celle de ces mêmes indicateurs dans les systèmes distribués.

Le RPO (Recovery Point Objective), c’est-à-dire le délai maximal acceptable de perte de données, est particulièrement difficile à gérer pour les mainframes en raison des relations entre les transactions. Un mainframe traitant un volume élevé de transactions de paiement peut facilement générer des millions d’enregistrements par heure répartis sur plusieurs ensembles de données couplés.

Le RPO n’est pas simplement un instantané pris de manière répétée après un intervalle de temps défini : il implique la capture de tous les ensembles de données couplés, catalogues et structures de couplage à un moment donné.

Le RTO (Recovery Time Objective), c’est-à-dire le délai maximal alloué aux opérations de restauration, présente ses propres complexités sur les mainframes. La restauration d’un environnement z/OS n’équivaut pas au démarrage d’une machine virtuelle à partir d’un instantané.

La plupart du temps, les entreprises ne se rendent pas compte de leur véritable valeur RTO avant d’effectuer un test de restauration – moment auquel personne ne peut ignorer l’écart entre le délai de restauration supposé et le délai réel.

Ces deux objectifs doivent être définis par charge de travail, et non par système. Un seul mainframe peut héberger des applications présentant des tolérances très différentes en matière de perte de données et de temps d’arrêt, ce à quoi le classement par niveau de criticité est précisément destiné à remédier.

Comment les niveaux de criticité devraient-ils influencer la fréquence des sauvegardes et la durée de conservation ?

Toutes les charges de travail exécutées sur un mainframe ne doivent pas nécessairement – ni ne peuvent se permettre – d’être protégées de la même manière. La hiérarchisation en fonction de la criticité est le processus par lequel la criticité métier se traduit en une politique de sauvegarde concrète. Elle alloue les ressources appropriées aux charges de travail pour lesquelles on prévoit la fenêtre de reprise la plus courte, tout en évitant de surdimensionner la protection pour les charges de travail où une fenêtre de reprise plus longue peut être tolérée.

Un modèle de hiérarchisation pratique s’articule généralement autour de trois niveaux :

L’affectation des niveaux doit être guidée par une analyse de l’impact sur l’activité plutôt que par des considérations techniques, et elle doit être réexaminée au moins une fois par an : la criticité des charges de travail évolue au fur et à mesure que les priorités de l’entreprise changent, et un ensemble de données qui était de niveau 2 l’année dernière peut déjà être considéré comme de niveau 1 aujourd’hui.

Comment la conformité et les SLA influencent-ils les objectifs de reprise ?

Non seulement les cadres de reprise encouragent une planification rigoureuse de la reprise, mais beaucoup exigent désormais des résultats concrets et vérifiables.

• La réglementation DORA impose aux entités financières de définir et de tester leurs capacités de reprise à l’aune de métriques prédéfinies
• La norme PCI DSS fixe des exigences spécifiques en matière de disponibilité et d’intégrité pour les systèmes accédant aux données des titulaires de cartes
• La règle de disponibilité HIPAA définit des obligations pour maintenir l’accès aux informations médicales protégées (PHI) dans des circonstances spécifiques

En pratique, cela signifie que les objectifs de reprise d’une charge de travail réglementée ne relèvent plus uniquement d’un jugement interne. Lorsque les exigences des SLA et les exigences réglementaires se recoupent, c’est l’exigence la plus stricte qui est retenue. Ainsi, la solution de sauvegarde mainframe doit être conçue, testée et documentée de manière à satisfaire à la fois les auditeurs externes et les exigences internes.

Quelles sont les options de sauvegarde sur site pour les mainframes ?

La sauvegarde sur site des mainframes s’appuie sur trois catégories technologiques distinctes :

• Sauvegarde sur bande (physique et virtuelle)
• Sauvegarde disque à disque
• Copies à un instant donné

Chacune de ces options répond à des besoins de restauration et à des contraintes opérationnelles différents. Savoir où chaque approche trouve sa place est la base de toute stratégie de sauvegarde de mainframe bien conçue.

Comment fonctionnent les sauvegardes sur DASD (émulation de bande, bandes virtuelles) sur les mainframes ?

La sauvegarde sur périphérique de stockage à accès direct (DASD) fait partie des environnements mainframe depuis de nombreuses années, mais la technologie elle-même a considérablement évolué au fil du temps.

Les bibliothèques de bandes virtuelles (VTL) sont largement utilisées dans les environnements mainframe comme couche de performance devant la bande physique, présentant une interface de bande à z/OS tout en écrivant les données sur un stockage sur disque avant qu’elles ne soient migrées vers une bande physique pour une conservation à long terme. Une VTL se comporte comme un périphérique de bande physique du point de vue du logiciel mainframe, mais elle écrit les données sur un stockage sur disque.

Par conséquent, un script JCL ou d’automatisation écrit pour les sauvegardes sur bande physique peut être réutilisé pour les sauvegardes VTL avec peu ou pas de modification, ce qui se traduit par de meilleures performances sans qu’il soit nécessaire de changer l’ensemble de l’infrastructure de sauvegarde.

La bande physique reste à ce jour le principal support de sauvegarde dans la plupart des environnements mainframe, les VTL servant d’intermédiaire optimisé en termes de performances qui préserve les pratiques opérationnelles basées sur la bande tout en réduisant la manipulation mécanique et en améliorant le débit de sauvegarde.

Quand faut-il privilégier les sauvegardes disque-à-disque par rapport aux solutions sur bande ?

La décision de mettre en œuvre une sauvegarde disque-à-disque ou sur bande pour vos mainframes n’est pas seulement technique, mais est souvent déterminée par une combinaison de besoins en matière de reprise, de réalités commerciales et de considérations économiques.

La sauvegarde disque-à-disque est le choix le plus judicieux lorsque :

• La vitesse de restauration est une priorité : les restaurations sur disque s’effectuent en une fraction du temps nécessaire pour localiser, monter et lire un volume de bande, ce qui a un impact direct sur le respect du RTO
• Les fenêtres de sauvegarde sont courtes : les cibles sur disque à haut débit peuvent absorber les données de sauvegarde plus rapidement que les bandes, ce qui réduit le risque que les tâches dépassent la fenêtre qui leur est allouée
• Des tests de restauration fréquents sont prévus : les restaurations sur bande entraînent une charge opérationnelle qui décourage les tests de reprise après sinistre réguliers, tandis que les cibles sur disque permettent de faire des restaurations de test de manière routinière
• Une récupération granulaire est nécessaire : restaurer un seul ensemble de données ou un petit nombre d’enregistrements à partir d’un disque est nettement plus pratique que de parcourir des volumes de bandes pour localiser des données spécifiques

La bande reste adaptée aux applications pour lesquelles le stockage à long terme, l’archivage réglementaire ou la mise en coffre-fort hors site la rendent rentable. Cependant, pour les charges de travail soumises à des exigences de RTO strictes ou nécessitant des tests de restauration fréquents, le disque-à-disque peut offrir un avantage opérationnel significatif en complément de la sauvegarde primaire sur bande.

Quel rôle jouent les technologies de snapshot et de point-in-time sur le mainframe ?

Les instantanés occupent une place à part dans l’environnement de sauvegarde des mainframes ; ils ne constituent pas une alternative à la sauvegarde, mais un complément aux capacités de sauvegarde existantes. Ils s’avèrent particulièrement utiles lorsque les contraintes liées aux fenêtres de sauvegarde classiques ou les exigences en matière de granularité de restauration dépassent les capacités que les tâches planifiées peuvent offrir à elles seules.

Sous z/OS, les technologies de copie à un instant donné créent une copie dépendante instantanée d’un ensemble de données ou d’un volume sans interrompre les E/S de production – IBM FlashCopy étant l’option la plus répandue sur le marché. Les principales caractéristiques qui définissent la manière dont ces technologies s’intègrent dans une stratégie de sauvegarde mainframe sont les suivantes :

• Exigences de cohérence – un instantané d’un volume unique est simple à réaliser, mais la capture d’une image cohérente à un instant donné sur plusieurs volumes liés dans un environnement OLTP très actif nécessite une coordination minutieuse pour éviter de capturer des données en cours de transaction
• Granularité de la restauration – les instantanés permettent une restauration rapide vers un état récent connu pour être correct, mais ils sont généralement conservés pendant des périodes plus courtes que les copies de sauvegarde traditionnelles, ce qui les rend inadaptés en tant que seul mécanisme de restauration
• Surcoût de stockage – les copies dépendantes consomment une capacité de stockage supplémentaire, et la relation entre les volumes source et cible doit être gérée avec soin pour éviter d’affecter les performances de production

Utilisés correctement, les instantanés servent de couche de restauration rapide dans une architecture de sauvegarde mainframe à plusieurs niveaux, où ils peuvent gérer des scénarios de restauration fréquents et récents, tandis que la sauvegarde traditionnelle se charge du stockage à long terme hors site.

Quelles sont les architectures de reprise après sinistre hors site et à distance disponibles ?

C’est dans l’architecture de reprise après sinistre hors site que la sauvegarde mainframe et la planification de la continuité des activités sont le plus étroitement liées. Les choix spécifiques à l’architecture de reprise après sinistre hors site – le mode de réplication, la topologie du site, la stratégie de stockage – influencent non seulement le potentiel de reprise au niveau du site, mais aussi sa rapidité et son exhaustivité dans des conditions réelles.

Quel est l’impact de la réplication synchrone par rapport à la réplication asynchrone sur la récupérabilité ?

Le mode de réplication est probablement l’une des décisions architecturales les plus importantes pour une configuration de reprise après sinistre sur mainframe, car il spécifie en effet la quantité minimale théorique de données que les entreprises peuvent se permettre de perdre lors d’un scénario de basculement.

Dans la plupart des cas, il ne s’agit pas d’un choix binaire simple. De nombreux systèmes mainframe utilisent la réplication synchrone vers un site secondaire adjacent pour répondre aux besoins de continuité des activités, associée à une réplication asynchrone vers un site tertiaire plus éloigné pour les scénarios de catastrophe majeure. De cette manière, ils parviennent à accepter un RPO plus important pour la séparation géographique de la sauvegarde, car une liaison synchrone sur une grande distance ne serait tout simplement pas pratique.

Quels sont les avantages et les inconvénients des sites de reprise après sinistre actifs-actifs par rapport aux sites actifs-passifs ?

La topologie du site – c’est-à-dire la manière dont le site secondaire s’articule avec la production en fonctionnement normal – détermine à la fois le profil de coûts et le comportement de reprise de l’ensemble de l’architecture de reprise après sinistre.

Une configuration active-active exécute les charges de travail de production sur les deux sites simultanément. Dans ce cas, la répartition de la charge de travail s’effectue à travers le sysplex. Le principal avantage de cette architecture est que le basculement n’est pas un événement isolé, car la capacité est déjà en place sur le site de reprise après sinistre, et le passage d’un fonctionnement dégradé à un fonctionnement complet est nettement plus rapide que dans n’importe quel scénario de démarrage à froid. Les sauvegardes et la réplication pour le mainframe sont toujours utilisées plutôt que de rester inactives, ce qui explique pourquoi les défaillances au sein de la posture de reprise après sinistre apparaissent pendant les opérations normales, et non lors d’un sinistre réel.

Le coût et la complexité constituent ici des compromis. Le mode actif-actif nécessite une infrastructure de niveau production complète sur les deux sites, avec un équilibrage continu des charges de travail et une conception minutieuse des applications pour gérer la cohérence distribuée des transactions. Dans cette optique, le mode actif-actif peut introduire plus de risques qu’il n’en élimine pour les organisations dont les charges de travail mainframe sont étroitement intégrées les unes aux autres ou difficiles à partitionner.

Les environnements actif-passif maintiennent un site de secours en veille et inactif, ce qui réduit considérablement les dépenses en matériel. Cela implique que les solutions de sauvegarde mainframe desservant ce site doivent maintenir l’environnement passif suffisamment à jour pour répondre aux exigences de RTO – un défi qui s’accentuera à mesure que le niveau d’actualité entre le site principal et le site secondaire divergera. Ce qui est inévitable avec l’approche actif-passif, c’est que le basculement implique une période de transition réelle, et que cette période doit être testée régulièrement pour confirmer qu’elle reste dans des limites acceptables.

Quand le stockage de bandes à distance ou sur le cloud est-il approprié ?

La bande – qu’il s’agisse d’un stockage physique ou dans le cloud – reste un élément central de l’architecture de sauvegarde mainframe, répondant à des exigences que les alternatives sur disque ne peuvent pas toujours satisfaire, notamment les exigences d’isolation physique et de conservation des supports physiques explicitement requises par des cadres normatifs tels que la norme PCI DSS. La bande reste appropriée dans un ensemble défini de conditions :

• Conservation réglementaire à long terme – lorsque les obligations exigent la conservation des données pendant des années, voire des décennies, et que le coût de stockage de ces données sur disque ou dans un cloud actif est prohibitif
• Exigences d’isolation physique – lorsque les politiques ou la réglementation exigent une copie des données de sauvegarde qui soit physiquement ou logiquement déconnectée de toute infrastructure accessible via le réseau
• Charges de travail d’archivage rarement consultées – lorsque la probabilité d’avoir besoin d’une restauration est suffisamment faible pour que le temps de latence de récupération constitue un compromis acceptable par rapport au coût de stockage
• Protection supplémentaire pour les niveaux de sauvegarde actifs – lorsque la bande sert de copie en aval des sauvegardes sur disque plutôt que de mécanisme de récupération principal

Le stockage sur bande ne doit en aucun cas constituer la solution de sauvegarde principale pour les mainframes dans le cadre de charges de travail soumises à des exigences de RTO (délai de reprise) significatives. La charge opérationnelle liée à la localisation, à l’expédition et au montage des supports physiques – ou à la récupération et à la mise en place de bandes stockées dans le cloud – rend cette solution structurellement inadaptée aux scénarios de restauration où le temps est un facteur critique.

Quel est l’impact de la mobilité des données et de l’intégration multiplateforme sur la reprise après sinistre des mainframes ?

La reprise sur mainframe ne s’effectue pas de manière isolée. L’infrastructure d’entreprise est désormais très étroitement interconnectée ; les moteurs de transaction mainframe alimentent des bases de données distribuées, les applications des systèmes ouverts extraient les données mainframe et les exploitent en temps réel, et les couches API intègrent les plateformes de manière transparente et indifférenciée – créant ainsi de nombreuses interdépendances qui sont souvent négligées dans la planification de la reprise après sinistre.

Considérer la sauvegarde et la reprise du mainframe comme un exercice autonome – en restaurant les ensembles de données, les catalogues et les sous-systèmes sans tenir compte de la cohérence des systèmes distribués dépendants – aboutira presque certainement à un mainframe techniquement rétabli, mais avec lequel le reste de l’environnement d’entreprise ne pourra pas interagir de manière utile.

Comment les données du mainframe peuvent-elles être intégrées aux systèmes distribués et ouverts pour la reprise après sinistre ?

Dans un environnement d’entreprise moderne, il est rare que les charges de travail mainframe s’exécutent dans leurs propres environnements isolés. Les moteurs de transaction mainframe transmettent des données à des flux qui alimentent des applications analytiques en aval, tandis que les moteurs de transaction z/OS transmettent des données à des bases de données distribuées que les applications Web exploitent en temps réel.

En cas de reprise du mainframe, la question n’est pas de savoir s’il est possible de restaurer le mainframe, mais si l’ensemble du système dépendant peut être ramené à un état de fonctionnement cohérent parallèlement à celui-ci. Les techniques d’intégration possibles qui prennent cela en charge vont de la réplication des données pilotée par API aux architectures de partage de stockage où le mainframe et les systèmes distribués peuvent accéder aux mêmes pools de données.

Le choix approprié dépend fortement de la latence acceptable, du volume de données et du degré de criticité des exigences de cohérence entre les deux systèmes. L’élément crucial du processus de sauvegarde du mainframe est que ces points d’intégration soient explicitement cartographiés et inclus dans la planification de la reprise après sinistre, au lieu d’être considérés comme le problème de quelqu’un d’autre.

Quels défis se posent lors de la synchronisation des charges de travail mainframe et non mainframe ?

C’est au niveau de la synchronisation inter-plateformes que les plans de reprise après sinistre hétérogènes échouent le plus souvent. Les défis techniques et opérationnels sont suffisamment spécifiques pour mériter une attention particulière :

• Décalage des limites de transaction – les systèmes mainframe gèrent généralement les transactions avec des garanties ACID au niveau des ensembles de données, tandis que les systèmes distribués peuvent utiliser des modèles de cohérence différents, ce qui rend difficile l’établissement d’un point de récupération unique valable simultanément dans les deux environnements
• Dépendances temporelles – les tâches batch qui extraient des données du mainframe pour un traitement en aval créent des dépendances temporelles implicites qui sont rarement documentées formellement, ce qui signifie qu’une restauration du mainframe à un point antérieur à la dernière exécution batch peut laisser les systèmes distribués en avance sur le mainframe en termes d’actualité des données
• Cohérence du catalogue et des métadonnées – la restauration de jeux de données mainframe sans mises à jour correspondantes des magasins de métadonnées distribués – ou inversement – peut laisser les applications dans un état où elles font référence à des données qui n’existent pas ou qui ont été remplacées
• Engagements RTO et RPO divergents – les équipes mainframe et distribuées opèrent souvent selon des SLA distincts, ce qui peut se traduire par des efforts de reprise qui restaurent chaque plateforme indépendamment, sans coordonner la cohérence ponctuelle requise pour les applications qui s’étendent sur les deux

Il ne s’agit pas non plus de cas marginaux. Les échecs de synchronisation pourraient être l’une des principales causes d’une restauration techniquement réussie mais fonctionnellement défaillante dans les environnements où les systèmes non-mainframe accèdent aux mêmes données que les mainframes ou dépendent opérationnellement de ces derniers.

Comment les environnements de sauvegarde hétérogènes améliorent-ils la résilience ?

L’une des principales tendances dans l’informatique d’entreprise est la standardisation : utiliser une seule plateforme de sauvegarde, un seul ensemble d’outils, un seul modèle opérationnel. Les environnements mainframe, en revanche, sont précisément le domaine où cette approche pourrait ne pas être la meilleure solution.

Un environnement de sauvegarde hétérogène (où des solutions de sauvegarde natives du mainframe coexistent avec des plateformes de systèmes ouverts dotées de points d’intégration définis) peut améliorer la résilience d’une manière qu’une approche mono-fournisseur ne peut pas toujours égaler. Ni les failles spécifiques à un fournisseur ni les défaillances de produits ne peuvent se propager à l’ensemble du parc de sauvegarde. Une sauvegarde native sur mainframe utilise des concepts propres à la plateforme, tels que les fichiers VSAM, les catalogues z/OS et l’intégrité du sysplex, que les produits pour systèmes ouverts ne peuvent généralement pas prendre en charge ou ne gèrent pas bien, tandis que ces derniers gèrent les composants distribués pour lesquels ils ont été conçus.

L’hétérogénéité n’est pas synonyme de fragmentation. Il s’agit d’une spécialisation voulue avec une intégration connue – non pas simplement la coexistence de multiples outils sans lien entre eux, mais une architecture planifiée qui tire parti des atouts de chaque outil.

Comment les modèles de sauvegarde hybrides et intégrés au cloud peuvent-ils être appliqués aux mainframes ?

L’intégration au cloud est passée d’une considération secondaire à un choix architectural courant pour la sauvegarde des mainframes. Ce changement est principalement motivé par des pressions économiques, des besoins de flexibilité géographique et la maturation des niveaux de stockage dans le cloud, désormais conçus pour gérer dès le départ l’échelle des volumes de données des mainframes.

Il serait également juste de dire que, dans la pratique, les options disponibles dans ce domaine sont largement centrées sur l’écosystème de produits d’IBM, compte tenu de la nature propriétaire des interfaces de stockage z/OS.

Quelles sont les options pour intégrer les sauvegardes mainframe au stockage dans le cloud public ?

Il existe plusieurs façons d’intégrer les solutions de sauvegarde mainframe au cloud public. Chaque approche présente des caractéristiques particulières et répondra à différents types de besoins de restauration et à différents niveaux de volume de données. Les approches les plus couramment adoptées sont les suivantes :

• Le cloud en remplacement des bandes – es données de sauvegarde sont écrites sur des niveaux de stockage objet tels qu’AWS S3 ou Azure Blob, à l’aide d’interfaces compatibles avec les mainframes ou d’appareils passerelles qui assurent la conversion entre les formats de sauvegarde z/OS et les API de stockage cloud
• Le cloud comme cible de sauvegarde secondaire – les tâches de sauvegarde sur site sont répliquées vers le stockage cloud sous forme de copie en aval, offrant ainsi une protection hors site sans remplacer l’infrastructure de sauvegarde principale sur site
• Bibliothèques de bandes virtuelles basées sur le cloud – solutions VTL dotées de backends cloud natifs qui présentent une interface de bande familière à z/OS tout en écrivant vers un stockage objet cloud évolutif
• Architectures de réplication hybrides – les données mainframe sont répliquées vers des instances mainframe hébergées dans le cloud ou des environnements compatibles, permettant une reprise après sinistre (DR) basée sur le cloud plutôt qu’un simple stockage dans le cloud

Le modèle d’intégration choisi détermine directement les scénarios de reprise qui peuvent être mis en œuvre dans la couche cloud. Les solutions de stockage seul protègent contre les pannes de site, mais elles n’accélèrent pas la reprise, ce qui nécessite des ressources de calcul au sein du cloud plutôt que de simples données.

Comment l’orchestration de la reprise après sinistre (DR) basée sur le cloud peut-elle être utilisée pour la reprise mainframe ?

La sauvegarde des copies de sauvegarde dans le cloud résout le problème de la conservation. Cependant, pour les récupérer rapidement, vous aurez besoin d’une orchestration : des workflows prédéfinis coordonnant la série d’actions qui se déroulent entre le moment où la décision de basculement est prise et celui où le système mainframe est effectivement opérationnel.

L’orchestration de la reprise après sinistre (DR) dans le cloud pour les solutions de sauvegarde mainframe peut inclure :

• Déclenchement automatisé du basculement – surveillance de l’état de santé qui détecte une défaillance du site principal et lance les workflows de reprise sans intervention manuelle
• Séquençage de la reprise : des guides d’exécution prédéfinis qui exécutent les étapes d’IPL, de restauration du catalogue et de redémarrage des applications dans l’ordre de dépendance correct
• Provisionnement de l’environnement – mise en service automatisée des ressources de calcul et de stockage hébergées dans le cloud nécessaires pour recevoir et exécuter les charges de travail restaurées
• L’automatisation des tests – des tests de reprise après sinistre planifiés et sans interruption qui valident les procédures de reprise par rapport aux données de sauvegarde actuelles sans impact sur la production
• Coordination de la restauration – procédures de basculement de secours gérées qui renvoient les charges de travail vers le site principal une fois celui-ci restauré, sans perte de données ni incohérence

La maturité des capacités d’orchestration disponibles varie considérablement d’un fournisseur à l’autre. Toutes les solutions ne prennent pas non plus en charge nativement l’ensemble des étapes de reprise spécifiques à z/OS.

Quelles sont les considérations en matière de sécurité et de performances à prendre en compte lors de la combinaison de mainframes et de sauvegardes dans le cloud ?

Les implications de l’extension de la sauvegarde mainframe vers le cloud comportent un certain nombre de nuances, car elles se situent à la croisée de deux paradigmes d’infrastructure radicalement différents. Il est préférable d’examiner ces compromis en les comparant directement :

Ni la sécurité ni les performances ne peuvent être considérées comme des aspects secondaires dans les architectures de sauvegarde mainframe dans le cloud, car compromettre l’un ou l’autre saperait immédiatement la valeur de l’ensemble de l’intégration.

Quels logiciels et outils prennent en charge la sauvegarde et la reprise après sinistre des mainframes ?

Le paysage des logiciels de sauvegarde mainframe est relativement restreint, mais sa complexité globale est comparable à celle des solutions de sauvegarde distribuées.

La liste des solutions disponibles s’étend des solutions natives Z/OS profondément intégrées aux plateformes d’entreprise plus larges dotées de connecteurs mainframe. Les acteurs établis dans ce domaine – parmi lesquels IBM DFSMS et DFSMShsm, CA Disk de Broadcom et Backup for z/OS de Rocket Software – sont présentés en détail ci-dessous, ainsi que les considérations architecturales qui s’appliquent quel que soit le choix du produit.

Le choix approprié varie considérablement en fonction de l’environnement existant, des exigences de reprise et du modèle opérationnel.

Comment les normes ouvertes et les API (par exemple, les API IBM, REST) facilitent-elles l’utilisation des outils de sauvegarde ?

La nature historiquement fermée des outils de sauvegarde mainframe commence à évoluer vers des modèles d’intégration plus ouverts. La mise à disposition par IBM des fonctions de gestion z/OS via des API REST a ouvert la voie à diverses intégrations pouvant être développées par des fournisseurs de sauvegarde ou des développeurs internes (ce qui était auparavant impossible sans recourir à des interfaces propriétaires).

L’interopérabilité constitue ici l’avantage pratique. Les solutions de sauvegarde mainframe qui prennent en charge (fournissent ou utilisent) des API standard trouveront leur place dans des solutions d’orchestration de sauvegarde d’entreprise plus larges : elles fourniront des informations d’état aux outils de surveillance centraux, recevront les modifications de politique provenant de plateformes de gestion unifiées ou cibleront le stockage cloud via des interfaces de stockage d’objets standard.

Le besoin de spécialistes de la sauvegarde mainframe n’est pas complètement éliminé (ceux possédant une expertise en sauvegarde z/OS), mais cela réduit le degré de séparation entre les sauvegardes mainframe et le reste du parc de sauvegarde de l’entreprise.

Quel rôle jouent les outils d’automatisation et d’orchestration dans les workflows de restauration ?

Les procédures de reprise manuelles constituent un risque. Si des runbooks complexes en plusieurs étapes sont exécutés sous pression, la probabilité d’erreurs humaines augmente considérablement, notamment les erreurs de séquencement, les dépendances manquées et autres retards.

L’automatisation parvient à éliminer tous ces problèmes de par sa conception. Les domaines dans lesquels l’automatisation apporte la valeur la plus directe dans les workflows de sauvegarde et de restauration mainframe sont les suivants :

• Planification des tâches de sauvegarde et gestion des dépendances – garantir que les tâches s’exécutent dans le bon ordre, avec les étapes de pré- et post-traitement appropriées, sans intervention manuelle
• Vérification du catalogue – des contrôles automatisés qui confirment l’intégrité du catalogue de sauvegarde après chaque tâche, mettant en évidence les problèmes avant qu’ils ne deviennent des surprises au moment de la restauration
• Workflows d’alerte et d’escalade – notification immédiate en cas d’échec des tâches de sauvegarde, de dépassement de leur fenêtre ou de résultats incohérents, transmise aux équipes concernées sans surveillance manuelle
• Exécution du guide de restauration – exécution scriptée et séquencée des étapes de restauration qui réduit la charge cognitive des opérateurs lors d’événements à forte pression et impose l’ordre correct des dépendances

Une couverture d’automatisation plus large garantit la prévisibilité et la testabilité pendant les processus de restauration. Un workflow de restauration qui a été exécuté automatiquement des centaines de fois est nettement plus fiable qu’un workflow qui n’existe que sous forme de document.

Quels sont les produits de sauvegarde commerciaux disponibles pour z/OS et les plateformes associées ?

Le marché commercial des solutions de sauvegarde pour mainframe est dominé par une poignée de fournisseurs spécialisés dont les produits ont évolué parallèlement à z/OS depuis de nombreuses années. À ce titre, toutes ces solutions partagent une caractéristique commune : elles sont conçues avec une compréhension native des constructions z/OS que les plateformes de sauvegarde polyvalentes ne seraient pas en mesure de reproduire sans compromis majeurs.

Les principales catégories de fonctionnalités qui distinguent les produits de sauvegarde pour mainframe les uns des autres sont les suivantes :

• Granularité au niveau des ensembles de données – la capacité à sauvegarder, cataloguer et restaurer des ensembles de données individuels plutôt que des volumes entiers, ce qui est essentiel pour les opérations de restauration quotidiennes
• Prise en charge du sysplex – gestion des structures de couplage et des ensembles de données partagés au sein d’un sysplex parallèle sans perte de cohérence
• Gestion du catalogue – gestion intégrée du catalogue ICF, qui constitue en soi une dépendance de restauration devant être gérée avec soin
• Compression et déduplication – réduction en ligne des volumes de données de sauvegarde, ce qui a un impact direct sur les coûts de stockage et la durée de la fenêtre de sauvegarde

Lors du choix d’une solution de sauvegarde pour mainframe, ces fonctionnalités doivent être évaluées en fonction de la composition de la charge de travail et des besoins de récupération de l’environnement. Parmi les solutions commerciales de sauvegarde pour mainframe les plus largement déployées, on peut citer :

• IBM DFSMS et DFSMShsm – gestion native du stockage z/OS et gestionnaire de stockage hiérarchique d’IBM
• Broadcom ACF2 et CA Disk – outils de sauvegarde et de restauration au niveau des ensembles de données bien établis, offrant une intégration poussée avec z/OS et largement adoptés par les entreprises
• Rocket Backup for z/OS de Rocket Software – solution de sauvegarde de jeux de données haute performance dotée de solides capacités de compression et de gestion de catalogue

Ces solutions ne sont pas directement interchangeables : chacune présente des atouts différents dans des domaines tels que la prise en charge des sysplex, l’intégration au cloud et l’automatisation opérationnelle. C’est pourquoi l’évaluation des capacités par rapport aux exigences spécifiques de l’environnement est plus importante que la seule réputation du fournisseur.

Comment la sécurité, la conformité et la conservation sont-elles gérées pour les sauvegardes mainframe ?

Quelles options de chiffrement et de gestion des clés protègent les données de sauvegarde au repos et en transit ?

Le chiffrement matériel est présent dans les environnements mainframe depuis des décennies, avec la gamme IBM Crypto Express et le chiffrement des ensembles de données z/OS. Il s’agit d’un avantage bien établi par rapport à de nombreux environnements distribués, qui doit être maintenu une fois que les données de sauvegarde se trouvent en dehors de l’écosystème mainframe. Le chiffrement des données de sauvegarde mainframe au repos et en transit doit être considéré comme une exigence et non comme une fonctionnalité optionnelle.

Au repos, le chiffrement des ensembles de données z/OS avec AES-256 est effectué implicitement au niveau de la couche de stockage, de sorte que le chiffrement peut se dérouler sans aucune modification du logiciel de sauvegarde ou du code de l’application. En transit, la transmission vers un site distant ou vers le cloud est protégée par le chiffrement TLS.

C’est au niveau de la gestion des clés que la complexité s’accroît dans la plupart des cas. La robustesse du chiffrement dépend des mesures de protection appliquées au stockage des clés. Dans les environnements de sauvegarde mainframe, ces clés doivent être accessibles lors de la restauration sans devenir une vulnérabilité potentielle en soi.

Le cadre ICSF et les modules de sécurité matériels d’IBM constituent la base de la gestion des clés d’entreprise sur z/OS, mais les organisations qui souhaitent étendre leurs sauvegardes vers le cloud ou des cibles distribuées doivent s’assurer qu’elles conservent le contrôle de la conservation des clés (au lieu de déléguer cette tâche à un fournisseur tiers par défaut).

Quelles sont les capacités d’audit et de reporting nécessaires pour la vérification de la conformité ?

La vérification de la conformité des sauvegardes mainframe ne se limite pas à la mise en place de politiques adéquates : elle nécessite des preuves tangibles que ces politiques sont appliquées de manière cohérente et que les exceptions sont détectées et traitées. Les capacités d’audit et de reporting que les solutions de sauvegarde mainframe doivent prendre en charge comprennent :

• Journalisation de l’exécution des tâches – enregistrements horodatés de chaque tâche de sauvegarde, y compris les statuts de réussite, d’échec et d’exécution partielle, conservés pendant toute la durée de la période de conformité concernée
• Rapports sur l’intégrité du catalogue – vérification régulière que les catalogues de sauvegarde reflètent fidèlement les données qu’ils indexent, avec des résultats documentés disponibles pour examen lors d’un audit
• Audit des accès et des modifications – enregistrements de chaque action administrative affectant la configuration de la sauvegarde, les paramètres de conservation ou les données de sauvegarde elles-mêmes, y compris l’identité de l’acteur et l’horodatage
• Documentation des tests de restauration – enregistrements formels de l’exécution des tests de reprise après sinistre, des résultats et de toute lacune identifiée, que les régulateurs attendent de plus en plus de voir comme preuve de la résilience opérationnelle
• Historique des exceptions et des alertes – enregistrements documentés des échecs de sauvegarde, des fenêtres manquées et des violations de politique, accompagnés de preuves de la manière dont chacun a été résolu

Même l’absence de fonctionnalité de piste d’audit pourrait constituer un manquement à la conformité dans le cadre de plusieurs réglementations ; l’infrastructure de reporting relative à la sauvegarde mainframe n’est donc pas une simple commodité, mais un élément à part entière de la posture de conformité.

Comment les politiques de conservation doivent-elles répondre aux besoins réglementaires et opérationnels ?

La conception des politiques de conservation pour les sauvegardes mainframe se situe au carrefour des obligations réglementaires, des exigences de reprise d’activité et de la gestion des coûts de stockage. Malheureusement, ces trois exigences ont rarement les mêmes objectifs : la réglementation peut exiger une conservation de 7 ans, les exigences de reprise d’activité sont satisfaites après 90 jours, et les coûts de stockage nécessitent une fenêtre de conservation aussi courte que possible tout en restant justifiable.

Le paysage réglementaire fixe des seuils minimaux non négociables pour de nombreux environnements mainframe :

Les politiques de conservation doivent être déterminées en fonction de la classification des données, et non par système. Un seul mainframe peut héberger des données soumises simultanément à plusieurs politiques de conservation, et une politique de conservation globale appliquant l’exigence la plus stricte à l’ensemble des ensembles de données gaspille de l’espace de stockage et complique inutilement la gestion du cycle de vie.

Comment établir une feuille de route pour améliorer la maturité des processus de sauvegarde et de reprise après sinistre (DR) sur mainframe ?

L’amélioration de la maturité de la sauvegarde mainframe est rarement le fruit d’un projet unique : il s’agit d’un programme d’améliorations progressives visant à atteindre un niveau de reprise après sinistre réalisable, vérifiable et continuellement validé. La feuille de route qui en découle commence par une analyse honnête de la situation actuelle.

Quelles questions d’évaluation permettent de déterminer le niveau de maturité actuel et les lacunes ?

Avant de hiérarchiser les améliorations, les organisations doivent avoir une vision claire de leur posture actuelle en matière de sauvegarde mainframe. Les questions suivantes constituent la base de cette évaluation :

• Les objectifs de reprise sont-ils formellement définis ? Des objectifs RTO et RPO documentés doivent exister pour chaque charge de travail mainframe, mis en correspondance avec des niveaux de criticité – et non supposés ou hérités d’une documentation héritée qui n’a pas été révisée récemment.
• Quand le dernier test de reprise complet a-t-il été effectué ? Une stratégie de sauvegarde mainframe qui n’a pas fait l’objet d’un test de bout en bout au cours des 12 derniers mois ne peut être considérée comme fiable : les hypothèses non vérifiées s’accumulent silencieusement au fil du temps. Sous z/OS, « de bout en bout » signifie inclure le séquencement IPL, la reprise du catalogue ICF et les procédures de redémarrage des sous-systèmes — et pas seulement vérifier que les données de sauvegarde existent.
• Les catalogues de sauvegarde sont-ils stockés indépendamment des systèmes qu’ils protègent ? La perte d’un catalogue lors d’un événement de restauration est l’une des causes les plus courantes et évitables d’échec de la restauration. Sous z/OS, cela inclut à la fois le catalogue maître ICF et tous les catalogues utilisateur, ainsi que les ensembles de données de contrôle DFSMShsm — qui constituent tous des dépendances de restauration à part entière.
• Les données de sauvegarde sont-elles protégées contre les menaces internes et les ransomwares ? Les politiques d’immuabilité, les contrôles d’accès et les procédures d’isolation physique doivent être documentés et vérifiables — on ne doit pas supposer qu’ils existent simplement parce qu’ils ont été mis en œuvre à un moment donné dans le passé. Sous z/OS, cela implique de vérifier que les politiques RACF ou ACF2 couvrent spécifiquement les ensembles de données et les catalogues de sauvegarde, et pas seulement les données de production.
• Les dépendances inter-plateformes sont-elles cartographiées ? Chaque système distribué, API ou application en aval qui dépend des données du mainframe doit être documenté, avec une définition explicite de sa relation de reprise par rapport au mainframe.
• L’environnement de sauvegarde répond-il aux exigences de conformité actuelles ? Les durées de conservation, les normes de chiffrement et les capacités de piste d’audit doivent être vérifiées par rapport au cadre réglementaire actuel, et non à celui qui était en vigueur lors de la dernière rédaction de la politique de sauvegarde.

Comment hiérarchiser les améliorations incrémentielles (gains rapides vs projets à long terme) ?

Toutes les lacunes identifiées lors de l’évaluation ne peuvent pas être comblées simultanément. Un cadre de hiérarchisation pratique va de la réduction immédiate des risques à l’amélioration architecturale à long terme :

1. Commencez par combler les vulnérabilités du catalogue – si les catalogues de sauvegarde ne sont pas protégés de manière indépendante, cette lacune représente un risque existentiel pour la reprise qui prime sur toutes les autres améliorations en termes d’urgence.
2. Définir ou valider les objectifs de reprise – sans cibles RTO et RPO documentées, toute amélioration ultérieure manque d’une norme mesurable vers laquelle tendre.
3. Mettez en œuvre l’immuabilité et les contrôles d’accès – les améliorations en matière de résilience face aux ransomwares ont un impact important et sont relativement faciles à réaliser sans changements architecturaux majeurs, ce qui en fait des gains rapides et significatifs.
4. Réalisez un test de reprise complet – avant d’investir dans de nouveaux outils ou une nouvelle architecture, vérifiez ce que l’environnement actuel est réellement capable de fournir dans des conditions de reprise réelles.
5. Combler les lacunes en matière de synchronisation inter-plateformes – une fois la posture de sauvegarde du mainframe stabilisée, étendre l’attention aux dépendances distribuées et à la coordination de la reprise au-delà des frontières des plateformes.
6. Évaluez les lacunes en matière d’outils et d’automatisation – avec une vision claire des exigences de reprise et des capacités actuelles, les décisions relatives aux outils peuvent être prises en fonction de critères spécifiques et validés plutôt que des affirmations des fournisseurs.
7. Misez sur une validation continue – la vérification automatisée des sauvegardes, les tests de reprise après sinistre planifiés et le suivi continu des indicateurs clés de performance (KPI) remplacent les évaluations ponctuelles par une vue actualisée en permanence de l’état de préparation à la reprise après sinistre.

Quels indicateurs clés de performance (KPI) et mesures devraient guider la maturité continue du programme de reprise après sinistre ?

Un programme de sauvegarde mainframe qui n’est pas mesuré n’est pas géré. Les indicateurs suivants fournissent un cadre pratique pour suivre la maturité de la reprise après sinistre au fil du temps :

• Temps de reprise réel par rapport à l’objectif – l’écart entre le temps de reprise testé et le RTO documenté, mesuré lors de chaque test de reprise après sinistre et suivi sous forme de tendance au fil du temps.
• Point de récupération réel vs objectif – la fenêtre de perte de données réelle obtenue lors des tests de reprise, comparée au RPO documenté pour chaque niveau de charge de travail.
• Taux de réussite des tâches de sauvegarde – pourcentage des tâches de sauvegarde mainframe planifiées qui s’exécutent avec succès dans la fenêtre définie, suivi chaque semaine et examiné lorsqu’il tombe en dessous d’un seuil convenu.
• Temps moyen de détection des échecs de sauvegarde – la rapidité avec laquelle les échecs de sauvegarde sont identifiés après leur survenue, ce qui a un impact direct sur la durée pendant laquelle l’environnement fonctionne avec une faille non détectée dans sa protection.
• Fréquence de vérification de l’intégrité du catalogue – fréquence à laquelle l’exactitude et l’exhaustivité des catalogues de sauvegarde sont vérifiées, les résultats étant documentés à des fins d’audit.
• Couverture de la coordination de la reprise Sysplex – pourcentage des charges de travail de niveau 1 pour lesquelles les dépendances de reprise intersystèmes, y compris les structures de couplage et les relations entre ensembles de données partagés, sont explicitement documentées et testées.
• Fréquence et couverture des tests de reprise après sinistre (DR) – nombre de tests de reprise après sinistre effectués par an et pourcentage des charges de travail de niveau 1 et 2 incluses dans chaque cycle de test.
• Délai de correction des lacunes identifiées – délai moyen entre l’identification d’une lacune (par le biais de tests, d’audits ou de la surveillance) et la mise en place d’une correction validée.

Conclusion

La sauvegarde et la reprise après sinistre du mainframe ne constituent pas un projet qui se résout une fois pour toutes. Le paysage des menaces évolue, les exigences métier changent, les cadres réglementaires se durcissent et les systèmes qui dépendent des données du mainframe deviennent de plus en plus interconnectés au fil du temps. La stratégie de sauvegarde du mainframe qui était suffisante il y a trois ans présente probablement aujourd’hui un certain nombre de lacunes – non pas parce qu’elle a échoué, mais parce que l’environnement qui l’entoure a changé alors que la stratégie est restée inchangée.

Les organisations qui parviennent à maintenir une véritable résilience en matière de reprise après sinistre (DR) abordent la sauvegarde des mainframes comme un programme continu, et non comme un projet ponctuel. Des objectifs de reprise définis, des procédures testées, des contrôles de sécurité appliqués et des politiques de conservation régulièrement révisées ne sont pas des livrables ponctuels, mais des habitudes opérationnelles qui déterminent si la reprise est possible lorsque cela compte vraiment.

Foire aux questions

Les données de sauvegarde mainframe peuvent-elles être utilisées pour soutenir des initiatives d’analyse ou de lac de données ?

Les données de sauvegarde des mainframes peuvent servir de source pour les initiatives d’analyse, mais elles nécessitent un traitement minutieux : les ensembles de données de sauvegarde sont structurés pour la restauration, et non pour l’interrogation, et ils doivent généralement être transformés avant de pouvoir être exploités dans le cadre d’un lac de données. L’approche la plus pragmatique consiste à considérer les sauvegardes mainframe comme une source de données secondaire qui vient compléter les pipelines d’extraction de données spécialement conçus, plutôt que de les remplacer. Les organisations qui tentent d’utiliser directement les données de sauvegarde brutes à des fins d’analyse constatent souvent que la charge opérationnelle liée à la conversion de format et à la validation de la cohérence dépasse la valeur des données elles-mêmes.

Quels sont les risques liés au fait de s’appuyer uniquement sur la réplication pour la reprise après sinistre ?

La réplication traite efficacement les pannes au niveau du site, mais n’offre aucune protection contre la corruption logique : si des données erronées sont écrites sur le site principal, la réplication propage ces données erronées vers le site secondaire en temps quasi réel. Une stratégie de sauvegarde mainframe reposant uniquement sur la réplication ne dispose d’aucun point de récupération antérieur à l’événement de corruption, ce qui signifie que les erreurs logiques, le chiffrement par ransomware et les bogues d’application générant des données incorrectes peuvent rendre les deux sites tout aussi inutilisables. La réplication doit constituer une couche d’une architecture de sauvegarde mainframe plus large, et non la stratégie dans son ensemble.

Comment les stratégies de sauvegarde mainframe doivent-elles s’adapter aux exigences ESG et de souveraineté des données ?

Les exigences en matière de souveraineté des données – qui imposent que certaines données restent à l’intérieur de limites géographiques ou juridictionnelles spécifiques – restreignent directement les options de sauvegarde hors site et dans le cloud disponibles pour les environnements mainframe opérant dans plusieurs régions. Les solutions de sauvegarde mainframe doivent être évaluées au regard des exigences de souveraineté de chaque juridiction dans laquelle l’organisation opère, et pas seulement de l’emplacement du centre de données principal. Les considérations ESG ajoutent une dimension supplémentaire, la consommation énergétique de l’infrastructure de sauvegarde – en particulier les grandes bibliothèques de bandes et la réplication en continu – devenant un facteur dans les rapports de développement durable des organisations ayant pris des engagements ESG formels.