Sauvegardes des environnements IBM Power : comment AVAT sécurise vos configurations critiques

Votre salle informatique a disparu. Combien de temps pour tout reconstruire ?

Prenons un scénario que personne n’a envie de vivre : un incendie, un dégât des eaux, une attaque qui rend la salle machine inutilisable. Bonne nouvelle, les données sont sauvegardées. Les bandes sont à l’abri, les copies externalisées sont intactes. On commande du matériel, il arrive quelques jours plus tard.

Et là, devant des équipements parfaitement vierges, une question très concrète se pose : comment était configuré tout ça ?

Quel était le zoning exact des switchs SAN ? Quels volumes étaient présentés à quel hôte sur la baie de stockage ? Combien de processeurs, de mémoire, d’adaptateurs virtuels pour chaque partition ? Comment étaient mappés les disques sur les VIOS ? Quels VLAN sur le switch réseau ?

C’est souvent à ce moment-là qu’on découvre que la vraie difficulté n’était pas les données.

La couche que l’on oublie

Quand on parle de sauvegarde, on pense spontanément aux données applicatives, puis aux systèmes d’exploitation. Ces deux niveaux sont généralement bien couverts, avec des outils éprouvés et des politiques de rétention claires.

Entre les systèmes et le matériel, il existe pourtant une couche intermédiaire : la configuration des équipements eux-mêmes. HMC, serveurs, partitions, VIOS, baies de stockage, VTL, switchs SAN, switchs LAN. Chacun porte des paramètres accumulés au fil des années, ajustés, corrigés, rarement documentés de façon exhaustive.

Cette couche pèse très peu. Une planification système de serveur Power tient en moins de 100 Ko. Un fichier de configuration de switch SAN, quelques dizaines de kilo-octets. Mais sa valeur, le jour où il faut repartir de zéro, est considérable.

Pourquoi est-elle si souvent négligée ? Parce que chaque équipement a sa propre méthode de sauvegarde, sa propre syntaxe, son propre format. Parce que les compétences sont réparties entre plusieurs personnes (Power, SAN, stockage, réseau). Parce que les scripts maison finissent par échouer en silence après une mise à jour de firmware. Et parce que, trop souvent, la seule copie de la configuration se trouve… sur l’équipement lui-même, ou sur un serveur situé dans la même salle.

Le RTO se joue sur la configuration

Le RTO (Recovery Time Objective), c’est la durée maximale d’interruption que l’entreprise accepte avant que l’activité reparte. Il est défini dans le PRA, validé par la direction, parfois imposé contractuellement.

Or dans un scénario de perte totale, le temps de restauration des données est en général connu et maîtrisé. Ce qui fait exploser le délai, c’est tout ce qui précède : reconstruire l’infrastructure qui va accueillir ces données.

Recréer à la main plusieurs centaines de zones Fibre Channel à partir d’un tableur dont on n’est pas sûr qu’il soit à jour, ce sont des heures, voire des jours, avec un risque d’erreur à chaque ligne. Recharger un fichier de configuration sur un switch neuf, ce sont quelques minutes. Même constat pour les profils de partitions, les VIOS ou la définition des hôtes sur une baie.

Autrement dit : sans sauvegarde des configurations, le RTO affiché dans le PRA reste théorique. Avec, il devient atteignable.

Ce qu’apporte AVAT

AVAT est une solution développée pour simplifier la gestion des environnements IBM Power : création de partitions et de leur environnement (SAN, stockage, bandes), gestion du PRA, et sauvegarde des configurations. C’est ce dernier point qui nous intéresse ici.

Un point d’archivage unique. Le serveur AVAT collecte, via des connexions SSH sécurisées par clés, les configurations de l’ensemble des équipements gérés et les centralise au même endroit.

Un périmètre large. Pour chaque type d’équipement, AVAT récupère ce qui sera réellement utile à une reconstruction :

• HMC : données de console, données de mise à niveau, inventaire HMCScanner ;
• serveurs Power : données de profils, planifications système (sysplan), et informations permettant de recréer en deux minutes une partition sur un autre serveur ;
• VIOS : sauvegarde système , sauvegarde de la configuration et export lisible de la configuration ;
• baies de stockage IBM FlashSystem et Storwize, et depuis la version 2.5 les VTL Data Domain ;
• switchs SAN Brocade : fichier de configuration directement réutilisable ;
• équipements réseau : switchs Cisco Catalyst.

Une rétention maîtrisée. Les sauvegardes sont planifiées et le nombre de versions conservées est paramétrable par type d’équipement. Détail important : une ancienne sauvegarde n’est purgée que si la nouvelle s’est correctement déroulée. On ne se retrouve pas sans rien parce qu’un équipement était injoignable lors des précédentes tentatives de sauvegarde.

De la visibilité. Un rapport des opérations est envoyé régulièrement, avec les erreurs et avertissements éventuels. La liste des sauvegardes disponibles est consultable à tout moment. Une sauvegarde dont on ne sait pas si elle a fonctionné ne vaut pas grand-chose.

Une restauration qui reste entre vos mains. Les fichiers collectés permettent une restauration de type Bare Metal Recovery, en suivant les procédures des constructeurs et celles documentées dans le guide d’administration. AVAT ne cherche pas à se substituer aux administrateurs : il leur donne, le jour J, tout ce dont elles ont besoin sous la main.

En conclusion

La question n’est pas de savoir si vos données sont sauvegardées : elles le sont très probablement. La question c’est : combien de temps vous faudrait-il pour reconstruire l’infrastructure qui les fait vivre ?

Si la réponse est « je ne sais pas » ou « ça dépend de qui est disponible », la sauvegarde des configurations mérite sans doute une place dans votre prochaine revue de PRA.