15.7 Récupération de la base de données en cas d'échec de la vérification de la restauration

Le processus de restauration comprend une étape de vérification qui consiste à comparer la base de données eDirectory sur le serveur en cours de restauration et celles des autres serveurs de l'anneau de répliques, par rapprochement des vecteurs de transition. Pour plus d'informations sur le processus de restauration, reportez-vous aux sections Présentation du processus de restauration avec l'outil de restauration et Vecteurs de transition et processus de vérification de la restauration.

Si les vecteurs de transition ne correspondent pas, la vérification échoue. Il faut généralement en déduire qu'il manque des données dans les fichiers utilisés pour la restauration. Les raisons peuvent être les suivantes, par exemple :

Vous n'avez pas activé la consignation de transactions individuelles par fichier avant d'effectuer la dernière sauvegarde.
Vous n'avez pas introduit les journaux de transactions individuelles dans l'opération de restauration.
Le jeu de fichiers journaux de transactions individuelles fourni pour la restauration est incomplet.

Par défaut, la base de données eDirectory restaurée ne s'ouvre pas à l'issue de la restauration si elle est incohérente par rapport aux autres répliques.

Si vous possédez tous les fichiers de sauvegarde et tous les fichiers journaux de transactions individuelles nécessaires à une restauration complète, mais avez oublié de les fournir pendant le processus, vous pouvez vous contenter d'exécuter de nouveau la restauration avec l'ensemble complet de fichiers. Si la restauration est complète lors du second essai, la vérification réussit et la base de données restaurée s'ouvre.

Si vous ne possédez pas tous les fichiers de sauvegarde et fichiers journaux de transactions individuelles nécessaires pour effectuer une restauration complète et garantir la réussite de la vérification, vous devez suivre les instructions de cette section pour restaurer le serveur. Voici un récapitulatif des éléments récupérables en cas d'échec de la vérification :

Vous pouvez toujours récupérer l'identité du serveur et les droits d'accès au système de fichiers.
Vous ne pouvez pas récupérer les répliques qui figuraient sur le serveur à partir de la sauvegarde, mais vous pouvez utiliser ce dernier pour ces répliques après avoir exécuté la procédure de récupération présentée ici. Vous devez enlever le serveur de l'anneau de répliques et utiliser les options de restauration avancées ainsi que l'outil DSRepair pour remettre le serveur dans un état qui permette sa réintégration dans l'anneau de répliques. Vous pouvez ensuite réinstaller les répliques de votre choix.
Néanmoins, si le serveur détenait l'unique copie d'une partition de la base de données (absence d'autres répliques), celle-ci ne peut pas être récupérée.

En cas d'échec de la vérification, suivez les instructions contenues dans cette section pour récupérer l'identité du serveur ainsi que les droits d'accès au système de fichiers, et pour enlever le serveur de l'anneau de répliques et l'y réintégrer. Une fois cette procédure exécutée et la réplication terminée, le serveur devrait fonctionner comme avant la défaillance (exception faite des partitions qui n'ont pas été répliquées et ne peuvent donc pas être récupérées).

Reportez-vous d'abord à la section Nettoyage de l'anneau de répliques. Consultez ensuite la section Réparation du serveur défaillant et réinstallation des répliques.

15.7.1 Nettoyage de l'anneau de répliques

Cette procédure vous explique comment effectuer les tâches suivantes :,

Réassigner des répliques maîtresses. Si le serveur défaillant contient la réplique maîtresse d'une partition, utilisez DSRepair pour désigner une nouvelle réplique maîtresse sur un autre serveur de la liste des répliques.
Supprimer de la liste de répliques les références au serveur défaillant. Tous les serveurs faisant partie de l'anneau de répliques qui incluait le serveur défaillant doivent être informés de l'indisponibilité de ce dernier.

Conditions préalables

eDirectory est installé sur la machine sur laquelle vous tentez de restaurer le serveur défaillant.
Une restauration a été tentée, mais la vérification a échoué.
La base de données eDirectory est ouverte et opérationnelle, et la base de données RST se trouve toujours sur la machine (elle y a été laissée par le processus de restauration).
Vous savez quelles partitions répliquées ont été stockées sur le serveur défaillant. Les répliques que contenait le serveur sont listées dans l'en-tête du fichier de sauvegarde.

Procédure

Pour nettoyer l'anneau de répliques :

Depuis la console de l'un des serveurs qui partageaient une réplique avec le serveur défaillant, chargez DSRepair avec le paramètre permettant d'accéder aux options avancées.
- Windows : utilisez le paramètre -a.
- Linux : utilisez le paramètre -Ad.
Pour plus d'informations sur l'exécution de DSRepair avec le paramètre d'options avancées -a ou -Ad, reportez-vous à la Section 12.9, Options DSRepair.

AVERTISSEMENT :si vous utilisez DSRepair avec le paramètre -a ou -Ad, certaines des options avancées peuvent endommager votre arborescence.
Sélectionnez Opérations de partition et de réplique.
Sélectionnez la partition à modifier, afin de pouvoir enlever le serveur défaillant de l'anneau de répliques pour cette partition.
Sélectionnez Afficher l'anneau de répliques pour afficher la liste des serveurs disposant de répliques de la partition.
(Conditionnel) Si le serveur défaillant contenait la réplique maîtresse, choisissez un autre serveur pour cette réplique en sélectionnant l'option Désigner ce serveur en tant que nouvelle réplique maîtresse.

L'anneau de répliques comporte désormais une nouvelle réplique maîtresse. Toutes les répliques faisant partie de l'anneau sont informées de son existence.
Patientez pendant la mise en place de la réplique maîtresse. Avant de poursuivre, vérifiez que les autres serveurs de l'anneau ont bien enregistré le changement.
Revenez à l'écran Afficher l'anneau de répliques. Sélectionnez le nom du serveur défaillant, puis l'option Supprimer ce serveur de l'anneau de répliques.

Si vous n'avez pas chargé DSRepair avec le paramètre -a ou -Ad (selon la plate-forme) pour accéder aux options avancées, cette option ne figure pas dans la liste.

AVERTISSEMENT :veillez à ne pas effectuer cette opération si le serveur défaillant est désigné comme réplique maîtresse. Cette information est indiquée dans la liste des serveurs de l'anneau. S'il s'agit de la réplique maîtresse, désignez un autre serveur en tant que maître, comme expliqué à l'Étape 5. Revenez ensuite à cette étape et retirez le serveur défaillant de l'anneau de répliques.
Connectez-vous en tant qu'utilisateur Admin.
Après avoir lu le message d'explication, indiquez que vous souhaitez poursuivre.
Quittez DSRepair.

Tous les serveurs qui font partie de l'anneau de répliques sont notifiés.
Répétez cette procédure sur un serveur pour chaque anneau de répliques dont le serveur défaillant faisait partie.

Pour terminer la préparation du serveur défaillant en vue de charger de nouvelles copies des répliques, consultez la procédure de la section suivante Réparation du serveur défaillant et réinstallation des répliques.

15.7.2 Réparation du serveur défaillant et réinstallation des répliques

Cette procédure vous permet de changer en références externes les informations relatives aux répliques qui figurent sur le serveur, de sorte que celui-ci ne se considère plus comme faisant partie de l'anneau de répliques. Une fois que vous avez appliqué cette méthode pour enlever les répliques du serveur, vous pouvez déverrouiller la base de données.

Après avoir retiré les répliques, vous terminez la procédure en les réinstallant sur le serveur. Celui-ci reçoit ainsi une nouvelle copie actualisée de chaque réplique. Après la réinstallation de chaque réplique, le serveur doit fonctionner de la même façon qu'avant la défaillance.

Pour retirer les répliques à l'aide de DSRepair, puis les réinstaller à l'aide de la fonction de réplication :

Assurez-vous que vous avez terminé la procédure décrite à la section Nettoyage de l'anneau de répliques.
Utilisez l'option de restauration avancée permettant de remplacer la restauration et précisez un nom de fichier journal :

dsbk restadv -v -l nom_fichier_journal

Cette option de restauration avancée renomme la base de données RST (la base de données qui a été restaurée, mais dont la vérification a échoué) en NDS, mais la laisse verrouillée.
Depuis la console du serveur, changez en références externes toutes les informations relatives aux répliques figurant sur le serveur, à l'aide des options avancées de DSRepair.
- Windows : Cliquez sur Démarrer > Paramètres > Panneau de configuration > NetIQ eDirectory Services. Sélectionnez dsrepair.dlm. Dans le champ Paramètres de démarrage, saisissez -XK2 -rd. Cliquez sur Démarrer.
- Linux : Saisissez la commande suivante :
```
ndsrepair -R -Ad -xk2
```
Le paramètre -rd ou R permet de réparer la base de données locale et la réplique.

AVERTISSEMENT :l'utilisation incorrecte des options avancées de DSREPAIR risque d'endommager votre arborescence.
Lorsque la réparation est terminée, supprimez le verrouillage et ouvrez la base de données à l'aide des options de restauration avancées suivantes du client eMBox :
```
dsbk restadv -o -k -l logfilename
```
Le paramètre -o permet d'ouvrir la base de données et le paramètre -k de supprimer le verrouillage.
Utilisez iManager pour réintroduire le serveur dans l'anneau de répliques :
1. Dans NetIQ iManager, cliquez sur le bouton Rôles et tâches .
2. Cliquez sur Gestion des partitions et des répliques > Affichage des répliques.
3. Spécifiez le nom et le contexte de la partition à répliquer, puis cliquez sur OK.
4. Cliquez sur Ajouter une réplique.
5. En regard du champ Nom du serveur, cliquez sur le bouton Parcourir , puis sélectionnez le serveur que vous venez de restaurer.
6. Sélectionnez le type de réplique souhaité, cliquez sur OK, puis sur Terminé.
7. Répétez cette procédure pour chaque anneau de répliques dont le serveur faisait partie.
Attendez la fin du processus de réplication.

Le processus de réplication est terminé lorsque les répliques passent de l'état Nouveau à Actif. Vous pouvez vérifier l'état dans iManager. Pour plus d'informations, reportez-vous à la section Affichage des informations concernant une réplique.
Pour restaurer les fichiers de sécurité NICI, commencez par restaurer uniquement les fichiers NICI, puis redémarrez le serveur NDSD et restaurez la DIB.
(Conditionnel) Si vous souhaitez utiliser la consignation de transactions individuelles par fichier sur le serveur, vous devez recréer votre configuration afin de vous assurer que cette fonction est activée et que les fichiers journaux sont enregistrés dans un emplacement assurant la tolérance aux pannes. Après avoir activé les journaux de transactions individuelles, vous devez également effectuer une nouvelle sauvegarde complète.

Cette opération est nécessaire car, au cours d'une restauration, la consignation de transactions individuelles par fichier reprend sa configuration par défaut, autrement dit elle est désactivée et l'emplacement par défaut est rétabli. Vous devez effectuer une nouvelle sauvegarde complète afin de vous protéger contre toute défaillance susceptible de survenir avant la prochaine sauvegarde complète sans surveillance planifiée.

Pour plus d'informations sur les fichiers journaux de transactions individuelles et leur emplacement, reportez-vous à la Section 15.3, Utilisation des fichiers journaux de transactions individuelles.