Ingrid est l'administrateur d'un réseau monoserveur chez Stationery Supply, Inc. Elle ne peut pas recourir à la réplication pour la tolérance aux pannes, car son environnement ne comporte qu'un seul serveur. La nouvelle fonctionnalité Backup eMTool de eDirectory 8.7.3 offre à Ingrid une solution simple pour sauvegarder et restaurer eDirectory. Cette solution est centrée sur le serveur et, qui plus est, rapide.
Après avoir mis à niveau son serveur Windows NT en passant de eDirectory 8.6.2 à eDirectory 8.7.3, Ingrid configure des sauvegardes sans surveillance pour ce serveur, à l'aide de fichiers de traitement par lots qui exécutent Backup eMTool.
Ingrid souhaite effectuer une sauvegarde complète de eDirectory chaque dimanche soir, et une sauvegarde incrémentielle chaque nuit, en semaine. Elle configure les sauvegardes sans surveillance pour qu'elles s'exécutent chaque nuit, peu avant ses sauvegardes complètes et incrémentielles du système de fichiers. Ainsi, les sauvegardes sur bande contiennent les fichiers de sauvegarde de eDirectory en même temps que ceux du système de fichiers. Elle a passé un contrat avec une société de stockage de données à distance afin d'envoyer les sauvegardes sur bande hors site.
Tous les lundis matin, Ingrid vérifie le journal de sauvegarde pour s'assurer de la réussite de la sauvegarde. Pendant la semaine, elle contrôle occasionnellement les fichiers journaux pour vérifier que les sauvegardes incrémentielles ont abouti.
Ingrid décide de ne pas activer les fichiers journaux de transactions individuelles pour les raisons suivantes :
Stationery Supply, Inc. décide de réorganiser les ressources humaines. Ingrid fait donc une sauvegarde manuelle avant d'apporter des changements importants à l'arborescence et après les avoir appliqués. Sa stratégie consiste à faire une nouvelle sauvegarde des changements un jour de la semaine, lorsque cela s'avérera nécessaire, au lieu d'exécuter en permanence des fichiers journaux de transactions individuelles.
Pour s'assurer que sa stratégie de sauvegarde sera prête à fonctionner lorsqu'elle en aura besoin, Ingrid la teste de temps à autre. Comme elle ne dispose pas du budget requis pour acquérir un second serveur afin d'effectuer les tests, elle passe un accord avec un laboratoire de test local. Sur un serveur du laboratoire comparable au sien, elle installe son système d'exploitation et son système de fichiers pour obtenir un environnement proche de celui de sa base de données eDirectory. Elle restaure ses sauvegardes et vérifie que la restauration de eDirectory correspond à ses attentes.
Un mercredi matin, le disque dur qui contient eDirectory sur le serveur tombe en panne. Ingrid se procure un nouveau disque dur et réunit les fichiers de la sauvegarde complète du dimanche soir, de la sauvegarde incrémentielle du lundi soir et de celle du mardi soir. Elle met en place le nouveau disque dur et installe eDirectory sur ce dernier. Elle restaure ensuite les sauvegardes complète et incrémentielles. Les modifications apportées à l'arborescence le mercredi matin, avant la défaillance du disque dur, sont perdues puisque Ingrid n'effectuait pas de consignation de transactions individuelles par fichier sur le serveur. Toutefois, le fait de pouvoir effectuer la restauration jusqu'à la sauvegarde de la dernière nuit seulement convient à Ingrid ; pour elle, l'exécution de fichiers journaux de transactions individuelles, compte tenu de la surcharge administrative que cela représenterait, ne présente pas d'intérêt.
Chez Outdoor Recreation, Inc., Georges dispose de dix serveurs qui exécutent eDirectory. Il effectue des sauvegardes complètes chaque dimanche soir et des sauvegardes incrémentielles toutes les nuits. La sauvegarde de eDirectory a lieu peu avant la sauvegarde sur bande du système de fichiers.
Tous les serveurs font partie d'anneaux de répliques. Georges utilise la consignation de transactions individuelles par fichier sur chacun d'eux. Pour chaque serveur, il a placé les fichiers journaux de transactions individuelles sur un périphérique de stockage différent de celui de eDirectory. Il surveille l'espace disponible afin de s'assurer que les fichiers journaux de transactions individuelles ne le saturent pas. Il contrôle en outre les droits sur le périphérique de stockage. De temps à autre, il sauvegarde sur bande les fichiers journaux de transactions individuelles, puis les supprime tous, à l'exception de celui utilisé par eDirectory, afin de libérer de l'espace.
Pour Georges, la surcharge administrative liée à la mise en oeuvre de la consignation continue de transactions individuelles par fichier est compensée par le fait qu'il dispose d'une sauvegarde jusqu'à la dernière minute, ce qui est nécessaire pour des serveurs faisant partie d'anneaux de répliques. S'il doit restaurer un serveur, celui-ci retrouve l'état de synchronisation qu'attendent les autres serveurs de l'anneau de répliques.
Dans son laboratoire de test, Georges teste périodiquement les fichiers de sauvegarde pour s'assurer que sa stratégie de sauvegarde répond à ses objectifs.
Un jeudi à 14 heures, le serveur Linux Stocks_DB1 subit une défaillance de disque dur, sur l'unité qui contient eDirectory.
Georges doit se procurer la dernière sauvegarde complète et les sauvegardes incrémentielles effectuées depuis celle-ci. Il peut ainsi restaurer la base de données dans l'état où elle se trouvait avant la sauvegarde incrémentielle réalisée la nuit précédente à une heure du matin. Les fichiers journaux de transactions individuelles ayant enregistré les modifications apportées à la base depuis la sauvegarde de la dernière nuit, Georges les introduit dans la restauration. Il peut ainsi rétablir la base dans l'état où elle se trouvait juste avant la défaillance du disque dur.
Georges procède de la façon suivante :
Le fichier de traitement par lots qu'il utilise pour effectuer des sauvegardes complètes chaque dimanche soir place le fichier de sauvegarde dans /adminfiles/backup/backupfull.bk.
Comme il avait spécifié une taille limite de 200 Mo dans les paramètres de configuration de la sauvegarde, il y a deux fichiers de sauvegarde :
Le fichier de traitement par lots qu'il utilise pour effectuer des sauvegardes incrémentielles tous les soirs en semaine place le fichier de sauvegarde dans /adminfiles/backup/backupincr.bk.
Étant donné qu'il exécute le même fichier de traitement par lots chaque soir de la semaine pour les sauvegardes incrémentielles de eDirectory, celles-ci ont toutes le même nom de fichier. Il doit leur assigner un nouveau nom lorsqu'il les recopie sur le serveur car elles doivent toutes être placées dans le même répertoire pendant la restauration.
Comme le système d'exploitation du serveur n'était pas sur le disque dur défaillant, il n'a pas besoin d'installer Linux.
Elles se nomment toutes backupincr.bk. Par conséquent, lorsqu'il les copie dans le répertoire, il doit modifier les noms de fichiers en
NOTE: les sauvegardes complètes et incrémentielles ne doivent pas toutes se trouver dans un même répertoire. Cependant, toutes les sauvegardes incrémentielles doivent être placées dans le même répertoire.
Il entre /adminfiles/restore comme emplacement des fichiers de sauvegarde.
Il entre /adminfiles/restore/restore.log pour l'emplacement du journal de restauration.
Il coche Restaurer la base de données.
Il coche aussi Restaurer les fichiers journaux de transactions individuelles.
Il entre l'emplacement des fichiers journaux de transactions individuelles.
(Il s'agit de l'emplacement distinct qu'il a créé spécifiquement pour stocker les fichiers journaux de transactions individuelles. Comme il les a placés sur un disque dur différent de celui de eDirectory, la panne qui s'est produite ne les a pas affectés et ils sont toujours disponibles.)
Il coche Restaurer les fichiers de sécurité.
Il coche Activer la base de données restaurée après vérification.
Il coche Ouvrir la base de données après restauration.
Il souhaite que eDirectory s'ouvre si la vérification de la restauration réussit.
Elle a réussi parce que les fichiers journaux de transactions individuelles étaient en service sur le serveur lors de la défaillance du disque dur, et que Georges les a inclus dans la restauration.
Comme les paramètres reprennent leur valeur par défaut durant une restauration, la consignation de transactions individuelles par fichier est désactivée. Il doit la réactiver. Il doit, en outre, effectuer une nouvelle sauvegarde complète afin de se prémunir contre toute défaillance survenant avant la prochaine sauvegarde complète sans surveillance.
Georges vérifie le fonctionnement du serveur. Celui-ci semble être normal.
Bruno est l'administrateur de 15 serveurs chez GK Designs Company. Il effectue des sauvegardes complètes chaque samedi soir et des sauvegardes incrémentielles toutes les nuits. La sauvegarde de eDirectory a lieu peu avant la sauvegarde sur bande du système de fichiers.
Tous les serveurs font partie d'anneaux de répliques. Bruno utilise la consignation de transactions individuelles par fichier sur chacun d'eux.
Un incendie d'origine électrique détruit l'un des serveurs d'une succursale située de l'autre côté de la ville. Heureusement, toutes les partitions de ce serveur, sauf une, sont répliquées sur d'autres serveurs. Bruno avait activé les fichiers journaux de transactions individuelles sur ce serveur, mais ils ont été perdus avec toutes les autres données. Il ne peut donc pas restaurer la base de données eDirectory du serveur dans l'état où elle se trouvait juste avant que ce dernier tombe en panne.
Il peut cependant recréer l'identité eDirectory du serveur en le restaurant à partir des fichiers de sauvegarde existants. Étant donné que Bruno ne peut pas inclure les fichiers journaux de transactions individuelles dans la restauration, le serveur ne correspond pas à l'état de synchronisation attendu par les autres serveurs (voir Vecteurs de transition et processus de vérification de la restauration). Par conséquent, le processus de vérification de la restauration échoue. Cela signifie que, par défaut, la base de données eDirectory n'est pas ouverte après la restauration.
Pour résoudre ce problème, Bruno enlève le serveur des anneaux de répliques en utilisant DSRepair pour changer en références externes toutes les informations périmées relatives aux répliques qui figurent sur le serveur. Ensuite, il ajoute une nouvelle copie de chaque partition du serveur en effectuant une réplication à partir des autres serveurs contenant les répliques à jour. (Ces opérations sont décrites dans la section Récupération de la base de données en cas d'échec de la vérification de la restauration.)
La seule partition du serveur que Bruno n'avait pas répliquée était un conteneur dans lequel figuraient des objets Impression en réseau de la succursale, tels qu'une imprimante/fax et une imprimante couleur grand format. Les informations de cette partition ne peuvent pas être récupérées avec la méthode indiquée ci-dessus, puisque aucun autre serveur n'en possède de réplique. Bruno doit donc recréer les objets de la partition. Cette fois, il choisit de les répliquer sur d'autres serveurs pour assurer, à l'avenir, une meilleure tolérance aux pannes.
Bruno recrée également la configuration des fichiers journaux de transactions individuelles après la remise en ligne du serveur (car la restauration désactive la fonction de consignation et rétablit les paramètres par défaut), puis il crée une nouvelle sauvegarde complète qui servira de point de départ.
Julien administre 20 serveurs sur trois sites. Sur l'un de ces sites, la rupture d'une canalisation d'eau détruit cinq des huit serveurs.
Julien dispose de sauvegardes de eDirectory pour tous les serveurs. Toutefois, ceux-ci font partie d'anneaux de répliques. Le problème est de les réinstaller dans l'arborescence sans fichiers journaux de transactions individuelles, puisque ces derniers ont aussi été perdus. Il ne sait pas sur quels serveurs il doit restaurer eDirectory d'abord, ni comment gérer les incohérences entre les répliques. En raison de la complexité de ces problèmes, il appelle le support technique de Novell afin d'être conseillé sur le choix de la méthode de restauration.
Dolorès et son équipe de Human Resources Consulting, Inc. gèrent 50 serveurs sur un site.
Pour assurer la tolérance aux pannes dans les conditions normales d'exploitation, ils ont créé trois répliques de chaque partition de leur arborescence. Si un serveur est arrêté, les objets des partitions qu'il contient restent ainsi disponibles sur d'autres serveurs. Ils ont également prévu la récupération de serveurs individuels en sauvegardant régulièrement tous leurs serveurs avec Backup eMTool, en activant la consignation de transactions individuelles par fichier et en stockant les bandes de sauvegarde sur un site distant.
Dans le cadre d'un plan de reprise après sinistre, Dolorès et son équipe ont également désigné deux de leurs serveurs comme serveurs DSMASTER. Deux serveurs sont nécessaires en raison de la taille de l'arborescence. Un seul serveur DSMASTER ne suffit pas à accueillir les répliques de toutes les partitions. Chaque partition de l'arborescence est répliquée sur l'un des deux serveurs DSMASTER. Les deux serveurs DSMASTER ne contiennent aucune réplique de la même partition, de sorte qu'il n'y a pas de chevauchement entre eux. Il s'agit là d'un aspect important de leur plan de reprise après sinistre.
Dans leur laboratoire de test, Dolorès et son équipe testent périodiquement les sauvegardes afin de s'assurer que la stratégie de sauvegarde répond à leurs objectifs.
Une nuit, le bâtiment abritant Human Resources Consulting, Inc. est endommagé par un ouragan, et tous les serveurs de l'infocentre sont détruits.
À la suite de ce sinistre, Dolorès et son équipe commencent par restaurer les deux serveurs DSMASTER, qui contiennent les répliques de toutes les partitions. Ils utilisent la dernière sauvegarde complète et les sauvegardes incrémentielles consécutives, mais ils ne peuvent pas inclure les fichiers journaux de transactions individuelles dans la restauration du fait qu'ils ont été perdus lors de la destruction des serveurs. Dolorès et son équipe ont structuré les serveurs DSMASTER afin qu'ils ne partagent pas de répliques. De ce fait, le processus de vérification de la restauration réussit sur les deux serveurs, même si les fichiers journaux de transactions individuelles ne sont pas inclus dans la restauration. Une fois les deux serveurs DSMASTER restaurés, tous les objets de l'arborescence de Human Resources Consulting, Inc. sont à nouveau disponibles.
Les serveurs DSMASTER sont importants, car Dolorès et son équipe peuvent les utiliser pour recréer une arborescence sans incohérences à la suite d'un sinistre.
Ils utilisaient des fichiers journaux de transactions individuelles afin de pouvoir restaurer un serveur dans l'état où il se trouvait avant son arrêt et rétablir l'état de synchronisation attendu par les autres serveurs de l'anneau de répliques. Le serveur pouvait ainsi reprendre les communications là où elles avaient été interrompues et recevoir des autres répliques les mises à jour nécessaires à la synchronisation de l'ensemble de l'anneau.
Dans le cas du présent sinistre, cependant, Dolorès et son équipe ne disposent pas des fichiers journaux de transactions individuelles. En leur absence, seul un serveur peut être restauré sans erreurs dans un anneau de répliques, à savoir le premier. Pour les autres serveurs, la vérification de la restauration échoue parce que les états de synchronisation ne correspondent pas à ce qui est attendu (voir Vecteurs de transition et processus de vérification de la restauration). Si la vérification de la restauration échoue, le processus de restauration n'active pas la base de données eDirectory restaurée.
Dolorès et son équipe ont prévu cette situation et se sont organisés en conséquence. Ils utilisent comme point de départ les deux serveurs DSMASTER et ne disposent donc que d'une réplique de chaque partition. Il est possible de restaurer ces serveurs sans erreurs, et les répliques qu'ils contiennent peuvent servir de répliques maîtresses qui seront copiées sur tous les autres serveurs.
Après la restauration des serveurs DSMASTER, la restauration des autres serveurs nécessite quelques opérations supplémentaires. Dolorès et son équipe doivent restaurer chacun des serveurs restants en procédant comme suit :
Dolorès et son équipe savent que le processus de vérification de la restauration va échouer pour le reste des serveurs parce qu'ils n'ont pas pu utiliser les fichiers journaux de transactions individuelles durant leur restauration. Ils obtiennent donc une base de données restaurée mais non activée.
À ce stade, le serveur a la même identité qu'auparavant, mais il ne tente pas de synchroniser les informations de réplique. Il est toutefois prêt à recevoir une nouvelle copie des répliques qu'il contenait précédemment.
Pour les serveurs NetWare, Dolorès et son équipe s'assurent que la restauration du système de fichiers intervient une fois eDirectory restauré.
Dolorès et son équipe savent assez précisément quelles répliques étaient détenues par chaque serveur, mais ils peuvent consulter l'en-tête des fichiers de sauvegarde de chacun d'eux pour voir la liste des répliques qu'ils contenaient au moment de la dernière sauvegarde.
(Ces étapes sont décrites plus en détail dans la section Récupération de la base de données en cas d'échec de la vérification de la restauration.)
Dolorès et son équipe ont beaucoup de travail en vue, mais ils peuvent remettre l'arborescence en service assez rapidement et peuvent s'attendre à récupérer l'identité eDirectory de tous leurs serveurs.