La sauvegarde des réseaux n’est plus cantonnée à un rôle essentiellement tactique. Avec l’engouement pour les progiciels de gestion intégrés de type ERP (Enterprise resource planning) et leur utilisation en tant que véritables colonnes vertébrales de l’informatique d’entreprise, la protection des applications revêt une importance des plus stratégiques. Or, ces ERP, déjà de nature modulaire (ils couvrent un large éventail de fonctions financières, comptables, commerciales, logistiques, productiques, etc.) donnent parfois lieu à des applications client-serveur complexes.
Une disponibilité quasi continue
Ces applications peuvent être organisées en plusieurs niveaux (serveur de données, client et serveur d’applications) et distribuées sur de multiples serveurs. Les vieilles recettes de la sauvegarde hors ligne appliquées aux serveurs de fichiers départementaux des réseaux LAN risquent de ne plus être efficaces dans des environnements où les volumes de données ne cessent de croître ?” certains gros projets R/3 gèrent désormais des bases de l’ordre du téraoctet ?” et où les contraintes de disponibilité quasi continue tendent à devenir la norme. Heureusement, les outils ont progressé, en termes de méthodes d’accès aux données et d’optimisation des processus de sauvegarde-restauration. Après s’être attaqués, il y a quatre ou cinq ans, à la sauvegarde des SGBD (systèmes de gestion de bases de données), des éditeurs tels que Cheyenne (racheté par Computer Associates), Legato et Veritas Software ont commencé, à partir de 1997, à adapter leurs produits phares ?” respectivement ARCserveIT, NetWorker et NetBackup ?” à la sauvegarde applicative. De telles solutions sont intrinsèquement complexes, puisqu’elles peuvent être mises en ?”uvre dans le cadre d’infrastructures client-serveur multiniveaux.
Ainsi, NetBackup peut être déployé sur trois niveaux : des clients de la sauvegarde (les machines à sauvegarder pourvues d’agents NetBackup) jusqu’au serveur central NetBackup (chargé du pilotage de la stratégie de sauvegarde, de l’ordonnancement des règles et des processus à mettre en ?”uvre), en passant par un niveau intermédiaire, celui du serveur de médias (qui gère les enregistrements de ressources locales, d’une catégorie d’applications ou d’une zone géographique donnée).
Avec l’évolution technique, on en est venu à proposer, aux côtés des agents clients génériques, des modules plus spécialisés. Ces derniers sont chargés de la sauvegarde d’un SGBD (Oracle, SQL Server, Sybase, etc.) ou d’un ERP, le plus souvent du progiciel R/3, de l’éditeur allemand SAP. Il est vrai que les principaux éditeurs ?” Computer Associates, Legato, Veritas, d’abord, suivis de HP, Quadratec, Sterling Software ou Tivoli ?” ont tous à leur catalogue des produits certifiés SAP, adaptés à la sauvegarde de R/3 dans ses versions 3.x et 4.x. Est-ce à dire que seul R/3 bénéficie de solutions de sauvegarde avancées ? En aucun cas. Après avoir travaillé à intégrer étroitement leurs solutions de backup à R/3, les éditeurs regardent maintenant du côté des autres ERP. Ainsi Legato s’intéresse-t-il aux offres progicielles de Baan. Il est, à cet égard, un des partenaires du programme BaanConnect, de l’éditeur hollandais.
L’offre NetWorker comporte un module spécialisé lui permettant de sauvegarder l’ensemble des bases de données et les fichiers de configuration ou de contrôle relatifs à une application Baan. Tivoli, pour sa part, cherche aussi à dépasser le simple cadre de la certification SAP et envisage de gérer également les ERP de PeopleSoft et de Baan.
Les écueils de la sauvegarde ” à chaud “
Son ancien logiciel de sauvegarde, ADSM, a subi récemment une importante cure de jouvence et s’est transformé en Tivoli Storage Manager, dont les agents clients ont été améliorés et sont désormais inclus dans les Tivoli Data Protection, livrés notamment dans leurs versions pour Oracle, Informix, DB2 et R/3. Même certifié pour un progiciel ERP spécifique, un logiciel de backup ne sera pas pour autant inapte à prendre en charge d’autres applications. Les ERP étant systématiquement implémentés au-dessus des SGBD du marché, les solutions de backup devront surtout montrer des aptitudes à s’interfacer avec ces SGBD et à assurer des missions de sauvegarde en ligne des applications. La technologie adaptée n’est vraiment arrivée à maturité que depuis deux ou trois ans. Il est vrai que, dans son principe, la sauvegarde ” à chaud ” d’une application ouverte était un problème difficile à résoudre. Il fallait s’assurer que les transactions ou modifications apportées à une base de données pendant l’opération avaient bien été prises en compte, sous peine de perte d’intégrité des fichiers de l’application. Pour ce faire, les éditeurs ont mis au point des procédures spécifiques. Elles consistent à basculer une base de données dans un mode de sauvegarde, à figer une image des tables de la base à sauvegarder (grâce à des commandes telles que le Dump de SQL Server), à enregistrer cette image et, dans le même temps, les transactions dans des fichiers journaux (tels les redo log d’une base Oracle). Ces fichiers journaux seront eux-mêmes sauvegardés de façon à autoriser la reconstitution de l’application dans l’état où elle se trouvait en fin d’opération de sauvegarde. En trois ans, les spécialistes ont complété leurs gestionnaires de sauvegarde par des modules clients leur permettant d’enregistrer en ligne DB2 Oracle, Informix, SQL Server, Sybase, etc., et, par voie de conséquence, les ERP. Ces modules spécialisés sont des sortes de bibliothèques supplémentaires complétant les agents génériques de sauvegarde. Ils ont pour finalité de coopérer avec les utilitaires ” officiels ” dont les interfaces sont standardisées (tels Backup & Recovery, pour DB2 ; Backup Server, pour Sybase ; EBU ou RMAN, pour Oracle ; et ON-Bar, pour Informix) ; qui sont proposés par les éditeurs de SGBD en complément de leurs moteurs de bases de données ; ou même avec certains utilitaires de sauvegarde de tierce origine, tel SQL BackTrack, de BMC. Leur fonction est de récupérer les données transmises par le biais des interfaces de sauvegarde des SGBD, puis de les convoyer sous la forme de ” streams ” de données, vers le(s) serveur(s) de backup. Ces modules sont régulièrement mis à jour ou revalidés en laboratoire pour tenir compte à la fois des évolutions des systèmes d’exploitation et des SGBD. Il est toujours possible de développer des interfaces de sauvegarde en s’appuyant sur les mécanismes de communication interprotocoles standards des systèmes d’exploitation tels que les ” pipes ” (canaux de communication) Unix. Mais une telle pratique, courante il y a encore cinq ans, n’a maintenant plus de raison d’être, compte tenu de l’arrivée d’outils d’interfaces et de modules garantissant la fiabilité et la cohérence des traitements.
Les fourches Caudines de la certification SAP
Certes, toutes les interfaces de sauvegarde des SGBD ne sont pas aussi performantes ou matures les unes que les autres. Le moteur de sauvegarde proposé par Sybase est jugé très satisfaisant. En revanche, SAP n’a pas cru bon de se contenter des seules API Oracle pour la sauvegarde de ses solutions R/3. Cela l’a conduit à développer son propre outil d’interface, Backint, et à spécifier la façon dont les outils de sauvegarde allaient devoir coopérer avec R/3 et Backint. Le passage des éditeurs d’outils de sauvegarde sous les fourches Caudines de la certification SAP avait pour finalité technique de faire adopter ces interfaces ” officielles ” et d’inciter à une intégration étroite entre R/3 et les gestionnaires de sauvegarde. R/3 dispose de son propre outil graphique d’administration, CCMS (Computer Center Management System), à partir duquel l’administrateur R/3 peut activer des fonctions des applications R/3 telles que les processus d’administration des données R/3, brbackup, brarchive et brrestore. Grâce à l’interface Backint, la sauvegarde d’une application R/3 en production peut être directement pilotée à partir de CCMS, alors que le streaming des données, leur enregistrement sur support magnétique et l’équilibrage des tâches de sauvegarde seront l’affaire d’un gestionnaire de sauvegarde de tierce origine ?” NetWorker, par exemple ?”, actif en arrière-plan sur le réseau. Backint fait, en effet, office de passerelle entre les commandes natives de R/3 et les modules clients R/3 des logiciels de sauvegarde. D’un côté, il transforme les requêtes brbackup, brarchive ou brrestore en fonctions Backint, tandis que, de l’autre, il est en mesure d’évoquer les fonctions du module de sauvegarde client d’un NetWorker, NetBackup, Omniback, etc. Malgré l’importance de la certification SAP sur le plan de la promotion commerciale ou de la garantie apportée à l’utilisateur, l’interfaçage façon Backint n’exclut pas la possibilité de faire appel à d’autres méthodes de sauvegarde. C’est le cas de la version R/3 d’Omniback II, l’outil de sauvegarde d’entreprise proposé par HP dans le cadre de son offre OpenView. Il est conçu pour utiliser deux interfaces, Backint de SAP (pour R/3 4.x sur Oracle, version Windows NT, Solaris, AIX, et R/3 4 ou 4.5) et RMAN d’Oracle (pour R/3 4.x sur Oracle, version HP-UX).
Employer des modules de sauvegarde pour SGBD
Notons également que les procédures rigoureuses mises en ?”uvre autour de Backint n’intéressent que les implémentations de R/3 sur le SGBD Oracle. Certes, les applications R/3 en production sont, dans la grande majorité des cas, basées sur le SGBD Oracle, mais le progiciel de SAP est aussi implémenté sur Informix, et de plus en plus souvent déployé sur SQL Server, de Microsoft. En outre, SAP s’attache maintenant à monter en puissance une offre sur DB2, le SGBD d’IBM. Les méthodes de sauvegarde applicables à toutes ces implémentations particulières de R/3 nécessiteront de travailler au niveau des interfaces SGBD précédemment évoquées et de s’appuyer, in fine, sur des modules de sauvegarde pour SGBD. En fin de compte, le traitement des applications R/3 portées sur d’autres SGBD qu’Oracle ne va pas être différent de ce qui serait mis en ?”uvre pour sauvegarder d’autres types d’ERP. Ainsi, Oracle, éditeur de l’offre progicielle Oracle Application, spécifie simplement de s’appuyer sur les interfaces de backup de EBU ou RMAN pour sauvegarder les applications reposant sur ses progiciels.
Les barrières techniques d’accès aux données sont aujourd’hui levées
Quant au français Quadratec, éditeur de Time Navigator, qui s’était attaché, à la fin de l’année 1998, à décrocher la certification SAP pour son logiciel, il compte néanmoins parmi ses références de grandes entreprises ayant choisi l’ERP Baan. Faire certifier ou officialiser la distribution d’un module de sauvegarde particulier est simplement une question d’opportunisme commercial. Qu’un éditeur ne propose pas à son catalogue telle ou telle offre dédiée n’implique pas pour autant qu’il n’a pas à son actif de réalisations spécifiques menées dans le cadre de contrats de conseil. Il arrive d’ailleurs, à l’image de ce que la société Europcar a mis en place pour interfacer ses applications centrales NetBackup, que de grands utilisateurs préfèrent développer leurs propres interfaces entre applicatifs stratégiques et logiciels de sauvegarde, de façon à répondre à des cahiers des charges très stricts du point de vue des fenêtres de sauvegarde à respecter. Cela prouve qu’aucune barrière technique réelle n’existe en matière de méthode d’accès aux données. Les fournisseurs tels que Veritas continuent d’ailleurs de mettre au point de nouvelles procédures de sauvegarde (lire l’encadré). Mais il faudra à ces méthodes parcourir un long chemin et acquérir la maturité suffisante, avant de se voir définitivement acceptées sur le marché.
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
