Passer au contenu

Sauvegarder un ERP : un projet à part entière

Optimiser les performances de la solution de backup tout en minimisant son impact sur le réseau. Une opération qui implique, en définitive, la prise en compte de la totalité des contraintes liées aux métiers de l’entreprise.

La sauvegarde, sur le papier, peut sembler aisée. Dans la réalité, rien n’est moins simple. Il convient, en effet, de faire en sorte que cette solution ne pénalise pas la production. Étant donné les volumes à sauvegarder, les contraintes pesant sur les fenêtres de sauvegarde, sur les performances des serveurs ou sur la bande passante du réseau ne sont pas négligeables. Selon une étude de Tivoli, le trafic généré par de telles opérations représente même jusqu’à 60 % du trafic réseau. Le déploiement d’applications lourdes de type ERP constitue un argument de poids en faveur des réseaux de stockage de type SAN (Storage area network). En attendant l’acceptation de ce concept SAN, il est nécessaire de faire coexister les flux applicatifs et ceux qui sont liés au stockage sur une même infrastructure de communication. L’effort à consentir pour monter une solution de sauvegarde performante ne doit pas être sous-estimé. En outre, l’architecture des applications ERP est très variable, les serveurs de données et d’applications pouvant être répartis sur de multiples serveurs Unix intermédiaires ?” HP 9000, de HP, ou Risc 6000, d’IBM ?” ou, à l’inverse, être centralisés sur un grand serveur d’entreprise de type Enterprise 10000, de Sun, ou NUMAServer, de Sequent. Chaque solution de sauvegarde relèvera donc du cas particulier. Pour ce qui est des très gros projets ERP en production, l’audit, la spécification, le déploiement et la configuration d’une solution de sauvegarde peuvent s’étendre sur deux à six mois et représenter des besoins en personnel d’environ une année-homme.

Les politiques de sauvegarde se font au niveau du serveur

Il est évidemment difficile de faire l’impasse sur un tel investissement. Même si les mécanismes Raid mettent le stockage primaire à l’abri de la plupart des pannes matérielles, ils ne peuvent rien contre les désastres, les bogues logiciels et, surtout, les incidents ou erreurs d’administration système, plus courants qu’on ne pourrait le penser. Que sauvegarder dans ces conditions ? Dans le cas des ERP, il s’agit d’objets applicatifs très divers, comme les tables, le code applicatif, les données d’archivage, mais aussi les fichiers de configuration, les fichiers Log d’activité. Les conditions de sauvegarde peuvent être paramétrées dès l’installation des modules clients des serveurs de sauvegarde. La configuration de tels modules installés en interface de SGBD, comme Oracle ou SQL Server, ou de progiciels, comme R/3, relève d’opérations systèmes assez pointues. En ce qui concerne NetWorker pour R/3, par exemple, l’installation d’un module client BusinessSuite pour SAP sur un serveur R/3 sous Unix exige également l’implémentation et le paramétrage du programme Backint, qui assure l’interface avec R/3. Les fichiers d’initialisation de R/3 devront aussi être configurés de façon à autoriser l’utilisation de Backint. Quant au fichier de paramétrage de Backint, il permettra de spécifier le nombre d’options de sauvegarde (parallélisme, durée de vie des données sauvegardées, pool de sauvegarde, partitions à sauvegarder, etc.). Les politiques de sauvegarde seront, elles, pilotées au niveau du serveur de sauvegarde. Les règles et procédures à définir seront affaire de compromis entre les contraintes imposées par le métier de l’entreprise, l’architecture de l’application de production et les méthodes de sauvegarde (hors ligne ou ” à chaud “, totale ou incrémentielle) qu’il sera possible d’appliquer. On peut, par exemple, estimer qu’il ne sera vraiment utile de sauvegarder en ligne que les redo log d’une base Oracle, et se contenter de sauvegarder ” à froid “, lors des périodes d’inactivité nocturnes, les table spaces, ainsi que, de façon incrémentielle, les données des postes clients et les codes applicatifs. Tel processus de gestion ayant des contraintes de disponibilité de 24 heures sur 24 ne pourra être sauvegardé que ” à chaud ” ; tel autre service logiciel, moins stratégique, tolérera une mise hors service de quelques heures. Une application pourra être sécurisée à l’extrême et sauvegardée totalement une fois par semaine, par le biais d’un enregistrement incrémentiel quotidien et d’un cumul hebdomadaire. A l’inverse, une sauvegarde totale mensuelle, cumulant les images obtenues par consolidations hebdomadaires d’enregistrements incrémentiels journaliers, pourra se révéler suffisante. L’optimisation de la sauvegarde exigera la prise en compte de nombreux critères technologiques (tels la capacité des logiciels de sauvegarde à traiter en parallèle et à multiplexer les flux de données et le choix du type de support) et aussi architecturaux (nombre de lecteurs de bande mis en parallèle, équilibrage des charges entre serveurs de sauvegarde, etc).

Sauvegarde et restauration : deux opérations différentes

Il ne faut pas non plus sous-estimer la puissance de calcul du processeur consommée par les opérations de sauvegarde en ligne : le fait de basculer une base Oracle en mode backup va utiliser 10 à 20 % de la puissance du serveur, tandis qu’un module de backup standard pourra momentanément drainer jusqu’à 80 % de celle d’un gros serveur. Il conviendra de veiller à respecter les conditions requises pour une bonne qualité de restauration. Les deux opérations, sauvegarde et restauration, sont différentes. L’optimisation des flux de données envoyées vers les bibliothèques est l’une des priorités de l’étape de la sauvegarde, tandis qu’en phase de restauration on cherche à minimiser le temps de reconstruction d’états cohérents d’une application. En outre, la sauvegarde est une opération que l’on peut automatiser, à l’inverse de la restauration, qui est dépendante, à chaque fois, de types d’erreurs particuliers, et nécessite l’intervention de l’administrateur. Sur ce plan, le choix d’un logiciel de sauvegarde peut ne pas être neutre. Quadratec, par exemple, met en avant les capacités de restauration de Time Navigator. L’interface d’administration de ce dernier permet de visualiser les objets de la sauvegarde. L’administrateur a, de ce fait, toute facilité pour restaurer les objets de son choix, sans avoir à se préoccuper de la localisation physique précise de ces fichiers sur les bandes magnétiques.

🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.


Thierry Jacquot