Scénario : perte d'un disque dur contenant eDirectory dans un réseau monoserveur
Scénario : perte d'un disque dur contenant eDirectory dans un environnement multiserveur
Scénario : perte d'un serveur complet dans un environnement multiserveur
Scénario : perte de plusieurs serveurs dans un environnement multiserveur
Scénario : perte de tous les serveurs dans un environnement multiserveur
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. L'outil de sauvegarde constitue un moyen simple et efficace pour sauvegarder et restaurer eDirectory. Il s'agit d'une solution rapide, basée sur le serveur.
Sous eDirectory 8.7.3 ou une version ultérieure, Ingrid configure des sauvegardes sans surveillance pour son serveur, en utilisant des fichiers de traitement par lots pour exécuter l'outil de sauvegarde.
Ingrid souhaite effectuer une sauvegarde complète d'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 d'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, Indira vérifie le journal de sauvegarde pour s'assurer que la sauvegarde complète a abouti. 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 :
Comme elle ne possède pas de périphérique de stockage distinct sur son serveur, l'activation des fichiers journaux de transactions individuelles ne lui permet pas d'effectuer des sauvegardes supplémentaires d'eDirectory. Une défaillance du périphérique de stockage entraînerait la perte des fichiers journaux en même temps que celle d'eDirectory. La création de ces derniers ne présente donc aucun intérêt.
L'arborescence ne change pas énormément. Ingrid se contente de pouvoir la restaurer dans l'état qu'elle avait au moment de la sauvegarde de la dernière nuit. Elle n'a pas besoin de pouvoir restaurer eDirectory dans l'état où il se trouvait avant la défaillance.
Étant donné que le serveur ne fait pas partie d'un anneau de répliques comprenant d'autres serveurs, les fichiers journaux de transactions individuelles ne sont pas nécessaires à la réussite du processus de vérification de la restauration.
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 nécessaire 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 d'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, Ingrid se contente de pouvoir restaurer l'arborescence dans l'état où elle se trouvait lors de la sauvegarde de la nuit dernière. Elle estime qu'exécuter des fichiers journaux de transaction individuelle ne serait pas avantageux compte tenu de la surcharge administrative qui y est associée.
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 d'eDirectory a lieu peu avant la sauvegarde sur bande du système de fichiers.
Tous les serveurs font partie d'un anneau 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 d'eDirectory. Il surveille l'espace disponible afin de s'assurer que les fichiers journaux de transaction individuelle 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 des 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'un anneau de répliques. S'il doit restaurer un serveur, celui-ci se retrouve dans 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 transaction individuelle 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 restaurer 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 :
Il se procure un disque dur de rechange pour le serveur.
Il récupère la bande de la sauvegarde complète du serveur, effectuée le dimanche soir précédent.
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 :
Il se procure également les bandes qui contiennent les sauvegardes incrémentielles de lundi, mardi et mercredi soir.
Le fichier de traitement par lots qu'il utilise pour effectuer des sauvegardes incrémentielles tous les soirs de la 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 d'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.
Georges installe le disque dur de remplacement.
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.
Georges restaure le système de fichiers depuis la sauvegarde sur bande, pour les deux partitions de disque affectées.
Il réinstalle eDirectory et place le serveur dans une nouvelle arborescence temporaire (le processus de restauration le replace dans l'arborescence d'origine par la suite).
Georges crée un répertoire /adminfiles/restore sur le serveur, pour y stocker les fichiers à restaurer.
Il copie les deux fichiers de sauvegarde complète dans ce répertoire.
Ensuite, il y copie les sauvegardes incrémentielles de lundi, mardi et mercredi.
Comme elles se nomment toutes backupincr.bk, lorsqu'il les copie dans le répertoire, il les renomme comme suit :
REMARQUE :les sauvegardes complètes et incrémentielles ne doivent pas toutes se trouver dans le même répertoire. En revanche, toutes les sauvegardes incrémentielles doivent être placées dans le même répertoire.
Il utilise iManager pour restaurer eDirectory :
Il ouvre iManager et clique sur Maintenance > Restaurer.
Il se connecte au serveur, en utilisant le contexte de la nouvelle arborescence temporaire.
Dans l'écran Assistant de restauration - Configuration du fichier, il effectue les opérations suivantes :
Il spécifie /adminfiles/restore comme emplacement des fichiers de sauvegarde.
Il spécifie /adminfiles/restore/restore.log comme emplacement du journal de restauration.
Dans l'écran Assistant de restauration - Facultatif, il effectue les opérations suivantes :
Il sélectionne l'option Restaurer la base de données.
Il sélectionne aussi l'option Restaurer les fichiers journaux de transaction individuelle.
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 d'eDirectory, la panne qui s'est produite ne les a pas affectés et ils sont toujours disponibles.)
Il sélectionne l'option Restaurer les fichiers de sécurité.
Il sélectionne l'option Activer la base de données restaurée après vérification.
Il sélectionne l'option Ouvrir la base de données après restauration.
Il souhaite que eDirectory s'ouvre si la vérification de la restauration réussit.
Il lance la restauration et entre les noms des fichiers de sauvegarde incrémentielle lorsqu'il y est invité.
La vérification de la restauration réussit, de sorte que la base de données s'ouvre avec l'arborescence originale.
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.
Une fois la restauration terminée, Georges recrée la configuration des fichiers journaux de transactions individuelles sur le serveur. Il effectue ensuite une nouvelle sauvegarde complète.
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.
Bob 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 d'eDirectory a lieu peu avant la sauvegarde sur bande du système de fichiers.
Tous les serveurs font partie d'un anneau de répliques. Bob 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. Bob avait activé les fichiers journaux de transaction individuelle 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 le serveur ne tombe en panne.
En revanche, il peut recréer l'identité eDirectory du serveur en le restaurant à partir des fichiers de sauvegarde existants. Étant donné que Bob ne peut pas inclure les fichiers journaux de transaction individuelle dans la restauration, le serveur ne correspond pas à l'état de synchronisation attendu par les autres serveurs (reportez-vous à la section 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, Bob supprime le serveur de l'anneau de répliques en utilisant DSRepair pour changer en références externes toutes les informations obsolètes relatives aux répliques qui figurent sur le serveur. Ensuite, il ajoute au serveur une nouvelle copie de chaque partition en effectuant une réplication à partir des autres serveurs contenant les répliques à jour. Ces opérations sont décrites à la Section 15.7, 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 Bob n'avait pas répliquée était un conteneur dans lequel figuraient des objets Impression en réseau de la succursale, tels qu'un fax/imprimante et une imprimante couleur grand format. Les informations de cette partition ne peuvent pas être récupérées à l'aide de la méthode décrite ci-dessus, puisque aucun autre serveur ne dispose d'une réplique. Bob 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.
Bob 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 d'eDirectory pour tous les serveurs. Toutefois, ceux-ci font partie d'un anneau de répliques. Le problème est de les réinstaller dans l'arborescence sans fichiers journaux de transaction individuelle, 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 de NetIQ 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 pris les dispositions nécessaires pour pouvoir récupérer des serveurs individuels, en sauvegardant régulièrement tous leurs serveurs à l'aide de l'outil de sauvegarde, 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 du plan de reprise en cas de 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 transaction individuelle dans la restauration car ils ont été perdus lors de la destruction des serveurs. Dolorès et son équipe ont configuré 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 journaux de transactions individuelles afin de pouvoir restaurer un serveur dans l'état où il se trouvait avant son arrêt et de rétablir l'état de synchronisation attendu par les autres serveurs de l'anneau de répliques. Le serveur peut ainsi reprendre les communications là où elles ont été interrompues, et recevoir des autres répliques les mises à jour requises afin que l'ensemble de l'anneau soit synchronisé.
Dans le cas du présent sinistre, cependant, Dolorès et son équipe ne disposent pas des fichiers journaux de transactions individuelles. Sans ces derniers, 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 qu'attendent les autres serveurs (reportez-vous à la section 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 :
Ils vérifient que les répliques placées sur les serveurs DSMASTER sont désignées comme répliques maîtresses.
Ils suppriment tous les serveurs de l'anneau de répliques, à l'exception des serveurs DSMASTER.
Ils restaurent les sauvegardes complètes et incrémentielles pour chacun des autres serveurs.
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.
Ils activent la base de données restaurée, à l'aide des options de restauration avancées, mais ils la maintiennent verrouillée.
Ils utilisent DSREPAIR pour modifier en références externes toutes les informations sur les répliques.
Ils déverrouillent la base de données restauré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.
Ils réinstallent les répliques sur chacun des serveurs en les dupliquant à partir de la copie qui figure sur le serveur DSMASTER.
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.
Ils recréent la configuration des journaux de transactions individuelles après la remise en ligne des serveurs (puisque la restauration désactive la fonction de consignation et rétablit les valeurs par défaut des paramètres), puis effectuent une nouvelle sauvegarde complète qui servira de base pour faire face aux défaillances susceptibles de survenir avant la prochaine sauvegarde complète sans surveillance.
(Ces étapes sont décrites plus en détail à la Section 15.7, 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.