À propos de l'outil eDirectory Backup eMTool

Backup eMTool permet d'effectuer une sauvegarde continue à chaud de la base de données eDirectory sur un serveur individuel. Si vous sauvegardez eDirectory sur votre serveur sans fermer la base de données, vous obtenez néanmoins d'une sauvegarde complète, image fidèle de l'état de la base au début de la sauvegarde. Grâce à cette fonction, vous pouvez lancer une sauvegarde à tout moment, eDirectory restant accessible tout au long du processus. (La sauvegarde continue à chaud est adoptée par défaut. Vous pouvez, si nécessaire, demander une sauvegarde « à froid » lorsque la base de données est fermée.)

La nouvelle fonction de sauvegarde permet également d'activer la consignation de transactions individuelles par fichier, pour conserver un enregistrement des transactions dans la base de données depuis la dernière sauvegarde. Vous pouvez ainsi restaurer un serveur dans l'état où il se trouvait avant son arrêt. Vous devez activer cette consignation pour les serveurs qui font partie d'un anneau de répliques, afin de rendre à un serveur l'état de synchronisation attendu par les autres serveurs. Si vous ne le faites pas, des erreurs se produisent lors de la restauration à partir des fichiers de sauvegarde et la base de données ne s'ouvre pas. Par défaut, la consignation de transactions individuelles par fichier est désactivée. Pour plus d'informations, reportez-vous à la section Utilisation des fichiers journaux de transactions individuelles.

Backup eMTool ne sauvegarde pas tous les objets de eDirectory à la fois, mais seulement les partitions d'un serveur individuel. Cela permet une meilleure restauration du serveur et des sauvegardes plus rapides qu'avec l'utilitaire de sauvegarde classique TSA pour NDS^®. (Celui-ci continue de fonctionner comme expliqué dans eDirectory 8.6 ; vous pouvez l'employer avec la nouvelle fonction de sauvegarde, si nécessaire.) Pour une comparaison, reportez-vous à la section Quelles sont les différences des fonctions de sauvegarde et de restauration de eDirectory 8.7.3 ?.

Le nouvel outil de sauvegarde de eDirectory doit être utilisé en association avec les sauvegardes du système de fichiers, afin d'enregistrer sur bande les fichiers de sauvegarde de eDirectory, par mesure de sécurité. Novell a établi des partenariats avec plusieurs grands fournisseurs de solutions de sauvegarde. Vous trouverez une liste à la page NetWare Partner Products: Backup, Restore, & Recovery (Produits partenaires NetWare : sauvegarde, restauration et reprise après sinistre).

Sous NetWare, vous devrez peut-être également utiliser l'outil de sauvegarde eDirectory en association avec les sauvegardes des droits du système de fichiers. Pour plus d'informations, reportez-vous à la section Préservation des droits lors de la restauration des données du système de fichiers sous NetWare.

Dans iManager, vous pouvez employer toutes les fonctions, exception faite de la sauvegarde à froid, des sauvegardes sans surveillance et des options de restauration avancées, comme expliqué dans la section Utilisation de Novell iManager pour la sauvegarde et la restauration. Toutes les tâches de sauvegarde et de restauration, y compris les sauvegardes sans surveillance, peuvent être exécutées à partir du client Java à ligne de commande eMBox, comme expliqué dans la section Utilisation du client eMBox pour la sauvegarde et la restauration.

Pour obtenir une description des options de sauvegarde et de restauration dans iManager, consultez l'aide en ligne. Pour une description des options du client eMBox, reportez-vous à la section Options de ligne de commande pour la sauvegarde et la restauration.

Pour obtenir une description du processus de restauration, reportez-vous à la section Présentation du processus de restauration avec Backup eMTool.

eDirectory Backup eMTool fait partie du jeu d'outils eMBox. Installé sur le serveur, eMBox est un service qui fait partie de eDirectory.

Backup eMTool comprend les fichiers suivants :

Pour obtenir une description du format des fichiers de sauvegarde et des fichiers journaux créés par Backup eMTool, reportez-vous aux sections Format du fichier journal de sauvegarde et Format de l'en-tête des fichiers de sauvegarde.

IMPORTANT:  Le processus de vérification de la restauration est rétrocompatible avec eDirectory 8.5 et versions ultérieures uniquement. Si vous souhaitez utiliser le nouvel outil de sauvegarde et de restauration sur des serveurs qui font partie d'un anneau de répliques, veillez à les mettre à niveau vers eDirectory 8.5 ou une version ultérieure. (Reportez-vous également à la section Rétrocompatibilité du processus de vérification de la restauration avec eDirectory 8.5 et versions ultérieures uniquement.)

Quelles sont les différences des fonctions de sauvegarde et de restauration de eDirectory 8.7.3 ?

Dans les versions précédentes de eDirectory, les fonctions de sauvegarde et de restauration étaient axées sur la sauvegarde de l'arborescence, objet par objet.

Le nouvel outil Backup eMTool de eDirectory 8.7 a introduit une méthode totalement différente, ainsi qu'une nouvelle architecture. En effet, il est axé sur le serveur, et non sur l'arborescence. Vous sauvegardez la base de données eDirectory individuellement sur chaque serveur. De plus, il est beaucoup plus rapide que l'utilitaire de sauvegarde classique TSA pour NDS.

Vous pouvez continuer d'utiliser celui-ci pour sauvegarder l'arborescence, mais nous vous conseillons d'employer le nouvel outil.

La sauvegarde des informations propres au serveur a été mise en oeuvre à l'aide de Backup eMTool. Pour plus de détails, reportez-vous à la section Modifications apportées à la sauvegarde des informations propres au serveur (NetWare uniquement).

Pour plus d'informations, consultez le tableau ci-dessous.

Présentation du processus de restauration avec Backup eMTool

Avant d'effectuer la restauration, vous devez collecter tous les fichiers de sauvegarde en suivant les instructions contenues dans la section Préparation d'une restauration. Lorsque vous demandez à l'outil Backup eMTool de commencer la restauration, à l'aide de iManager ou du client eMBox, celui-ci exécute la procédure suivante :

1. Il ferme l'agent DS.
2. Il transforme l'ensemble DIB (Data Information Base) actif nommé NDS en un nouvel ensemble DIB nommé RST.

   (La base de données NDS existante est conservée sur le serveur ; si la vérification de la restauration échoue, elle redevient l'ensemble DIB actif.)

3. Il effectue la restauration dans l'ensemble DIB nommé RST.
4. Il désactive l'ensemble DIB.

   Il applique l'attribut de login désactivé sur le pseudo-serveur, ce qui empêche l'agent DS de s'ouvrir avec cet ensemble DIB.

5. Il rétablit les paramètres par défaut des fichiers journaux de transactions individuelles.

   Ainsi, après une restauration, la consignation de transactions individuelles par fichier est toujours désactivée. De plus, l'emplacement par défaut des fichiers journaux de transactions individuelles est rétabli.

   (Si vous souhaitez activer la consignation de transactions individuelles par fichier sur le serveur, vous devez prévoir de recréer la configuration appropriée après une restauration 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 fichiers journaux de transactions individuelles, vous devez également effectuer une nouvelle sauvegarde complète.)

6. Il vérifie la base de données RST restaurée.

   Le serveur tente de vérifier la cohérence des données restaurées. Pour ce faire, il contacte chaque serveur avec lequel il partage une réplique et compare les vecteurs de transition.

   Le résultat de ce processus de vérification est enregistré dans le fichier journal.

   Si le vecteur de transition du serveur distant est en avance par rapport au vecteur local, il manque alors des données dans la restauration et la vérification échoue.

   Voici un exemple des informations enregistrées dans le fichier journal en cas d'échec de la vérification pour l'une des répliques. Il montre les vecteurs de transition qui ont été comparés :

   Server: \T=LONE_RANGER\O=novell\CN=CHIP 
      Replica: \T=LONE_RANGER\O=novell 
         Status: ERROR = -6034 
            Local TV             Remote TV 
            s3D35F377 r02 e002   s3D35F3C4 r02 e002 
            s3D35F370 r01 e001   s3D35F370 r01 e001 
            s3D35F363 r03 e001   s3D35F363 r03 e001 
            s3D35F31E r04 e004   s3D35F372 r04 e002 
            s3D35F2EE r05 e001   s3D35F2EE r05 e001 
            s3D35F365 r06 e003   s3D35F365 r06 e003 
   

   Pour plus d'informations, reportez-vous à la section Vecteurs de transition et processus de vérification de la restauration.

7. Si la vérification réussit, l'ensemble DIB RST est renommé NDS et l'attribut de login désactivé est effacé, de sorte que la base de données eDirectory concernée devient la base de données active sur le serveur. Si la vérification échoue, l'ensemble DIB RST n'est pas renommé, et NDS redevient l'ensemble DIB actif.

   En cas d'échec de la vérification, reportez-vous à la section Récupération de la base de données en cas d'échec de la vérification de la restauration pour savoir comment récupérer le serveur. (Il est possible de forcer l'activation et le déverrouillage de la base de données RST à l'aide des options de restauration avancées, mais cela n'est pas conseillé, sauf si Novell vous le propose.)

Format de l'en-tête des fichiers de sauvegarde

Les fichiers de sauvegarde comportent un en-tête que vous pouvez lire pour accéder à des informations importantes, notamment :

• Le nom assigné au fichier de sauvegarde lors de sa création.

  Cela est utile si le fichier a été renommé depuis la création de la sauvegarde.

• Le nom du fichier journal de transaction individuelle utilisé au moment de la sauvegarde.

  S'il s'agit de la dernière sauvegarde du jeu à partir duquel vous effectuez la restauration (par exemple la dernière sauvegarde incrémentielle d'un ensemble constitué d'une sauvegarde complète et de trois sauvegardes incrémentielles), cette information vous est utile puisqu'elle indique le premier fichier journal de transaction individuelle dont vous avez besoin pour effectuer une restauration complète.

• Les répliques que contenait le serveur.

  Cette information est utile si vous n'avez pas noté l'emplacement de vos répliques. Si vous êtes confronté à un sinistre impliquant la perte de nombreux serveurs, la liste des répliques figurant dans l'en-tête du fichier de sauvegarde peut vous aider à choisir les serveurs à restaurer en premier.

• Les noms des fichiers inclus dans la sauvegarde, listés dans un fichier d'inclusion utilisateur.
• Le nombre de fichiers figurant dans le jeu de sauvegarde.

Pour chaque sauvegarde individuelle, l'en-tête du fichier est au format XML. Immédiatement après l'en-tête viennent les données de sauvegarde de la base de données exprimées en code binaire. (Étant donné que des données binaires sont incluses à la fin du fichier, l'analyse de ce dernier produirait des erreurs. Toutefois, l'en-tête est conforme au standard XML.) Si la sauvegarde s'étend sur plusieurs fichiers, les informations d'en-tête sont incluses dans chacun d'eux.

WARNING:  lorsque vous ouvrez un fichier de sauvegarde, contentez-vous de consulter l'en-tête. N'essayez pas d'enregistrer ni de modifier le fichier, car il pourrait alors devenir tronqué. La plupart des applications ne peuvent pas enregistrer correctement les données binaires.

Voici la partie DTD de l'en-tête XML. (Elle est incluse également dans l'en-tête du fichier de sauvegarde, pour référence).

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?> 
<!DOCTYPE backup [ 
<!ELEMENT backup (file|replica)*> 
<!ELEMENT file (#PCDATA)> 
<!ELEMENT replica EMPTY> 
<!ATTLIST backup version CDATA #REQUIRED 
    backup_type (full|incremental) #REQUIRED 
    idtag CDATA #REQUIRED 
    time CDATA #REQUIRED 
    srvname CDATA #REQUIRED 
    dsversion CDATA #REQUIRED 
    compression CDATA "none" 
    os CDATA #REQUIRED 
    current_log CDATA #REQUIRED 
    number_of_files CDATA #IMPLIED 
    backup_file CDATA #REQUIRED 
    incremental_file_ID CDATA #IMPLIED 
    next_inc_file_ID CDATA #IMPLIED> 
<!ATTLIST file size CDATA #REQUIRED 
    name CDATA #REQUIRED 
    encoding CDATA "base64" 
    type (user|nici) #REQUIRED> 
<!ATTLIST replica partition_DN CDATA #REQUIRED 
    modification_time CDATA #REQUIRED 
    replica_type (MASTER|SECONDARY|READONLY|SUBREF| 
    SPARSE_WRITE|SPARSE_READ|Unknown) #REQUIRED 
    replica_state (ON|NEW_REPLICA|DYING_REPLICA|LOCKED| 
    CRT_0|CRT_1|TRANSITION_ON|DEAD_REPLICA| 
    BEGIN_ADD|MASTER_START|MASTER_DONE| 
    FEDERATED|SS_0|SS_1|JS_0|JS_1|MS_0|MS_1| 
    Unknown) #REQUIRED> 
]>

Le tableau ci-dessous décrit les attributs que contient cette partie.

Voici un exemple d'en-tête de fichier de sauvegarde d'un serveur Windows NT. Les fichiers de sécurité NICI sont inclus dans la sauvegarde.

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?> 
<!DOCTYPE backup [ 
<!ELEMENT backup (file|replica)*> 
<!ELEMENT file (#PCDATA)> 
<!ELEMENT replica EMPTY> 
<!ATTLIST backup version CDATA #REQUIRED 
    backup_type (full|incremental) #REQUIRED 
    idtag CDATA #REQUIRED 
    time CDATA #REQUIRED 
    srvname CDATA #REQUIRED 
    dsversion CDATA #REQUIRED 
    compression CDATA "none" 
    os CDATA #REQUIRED 
    current_log CDATA #REQUIRED 
    number_of_files CDATA #IMPLIED 
    backup_file CDATA #REQUIRED 
    incremental_file_ID CDATA #IMPLIED 
    next_inc_file_ID CDATA #IMPLIED> 
<!ATTLIST file size CDATA #REQUIRED 
    name CDATA #REQUIRED 
    encoding CDATA "base64" 
    type (user|nici) #REQUIRED> 
<!ATTLIST replica partition_DN CDATA #REQUIRED 
    modification_time CDATA #REQUIRED 
    replica_type (MASTER|SECONDARY|READONLY|SUBREF| 
    SPARSE_WRITE|SPARSE_READ|Unknown) #REQUIRED 
    replica_state (ON|NEW_REPLICA|DYING_REPLICA|LOCKED| 
    CRT_0|CRT_1|TRANSITION_ON|DEAD_REPLICA| 
    BEGIN_ADD|MASTER_START|MASTER_DONE| 
    FEDERATED|SS_0|SS_1|JS_0|JS_1|MS_0|MS_1| 
    Unknown) #REQUIRED> 
]> 
 
<backup version="2" backup_type="full" idtag="3D611DA2" time="2002-8-19'T10:32:35" srvname="\T=MY_TREE\O=novell\CN=DSUTIL-DELL-NDS" dsversion="1041081" compression="none" os="windows" current_log="00000003.log" next_inc_file_ID="2" number_of_files="0000001" backup_file="c:\backup\header.bak"><replica partition_DN="\T=MY_TREE" modification_time="s3D611D95_r1_e2" replica_type="MASTER" replica_state="ON" /><replica partition_DN="\T=MY_TREE\O=part1" modification_time="s3D611D95_r1_e2" replica_type="MASTER" replica_state="ON" /><replica partition_DN="\T=MY_TREE\O=part2" modification_time="s3D611D95_r1_e2" replica_type="MASTER" replica_state="ON" /><replica partition_DN="\T=MY_TREE\O=part3" modification_time="s3D611D96_r1_e2" replica_type="MASTER" replica_state="ON" /><file size="190" name="C:\WINNT\system32\novell\nici\bhawkins\XARCHIVE.001" encoding="base64" type="nici">the data is included here</file> 
 
<file size="4228" name="C:\WINNT\system32\novell\nici\bhawkins\XMGRCFG.KS2" encoding="base64" type="nici">the data is included here</file> 
 
<file size="168" name="C:\WINNT\system32\novell\nici\bhawkins\XMGRCFG.KS3" encoding="base64" type="nici">the data is included here</file> 
 
<file size="aaac" name="C:\WINNT\system32\novell\nici\nicintacl.exe" encoding="base64" type="nici">the data is included here</file> 
 
<file size="150" name="C:\WINNT\system32\novell\nici\NICISDI.KEY" encoding="base64" type="nici">the data is included here 
</file> 
 
<file size="4228" name="C:\WINNT\system32\novell\nici\system\Xmgrcfg.ks2" encoding="base64" type="nici">the data is included here 
</file> 
 
<file size="168" name="C:\WINNT\system32\novell\nici\system\Xmgrcfg.ks3" encoding="base64" type="nici">the data is included here 
</file> 
 
<file size="1414" name="C:\WINNT\system32\novell\nici\xmgrcfg.wks" encoding="base64" type="nici">the data is included here 
</file> 
 
</backup>

Les données binaires de la sauvegarde de la base de données sont ajoutées dans le fichier de sauvegarde à la suite de l'en-tête.

Format du fichier journal de sauvegarde

eDirectory Backup eMTool tient à jour un journal qui présente une vue d'ensemble de son activité et comporte des informations sur les sauvegardes antérieures. Le fichier journal contient un historique de toutes les sauvegardes et consigne l'heure de début et de fin de chacune d'entre elles. Il fournit également des informations sur les erreurs survenues éventuellement pendant le processus de sauvegarde. Ce fichier est complété à chaque sauvegarde. Il est également enregistré à l'emplacement que vous désignez.

Le fichier journal permet de s'assurer de la réussite des sauvegardes sans surveillance. Le résultat (réussite ou échec) est indiqué sur la dernière ligne avec le code d'erreur éventuel.

Le fichier journal de Backup eMTool mentionne également l'ID des sauvegardes effectuées, ce qui facilite la collecte des fichiers de sauvegarde complète et incrémentielle corrects en vue d'une restauration. Les quatre premières lignes reprennent les informations de l'en-tête du fichier de sauvegarde.

Les autres fichiers inclus dans la sauvegarde de la base de données, tels que les fichiers NICI ou ceux listés dans un fichier d'inclusion, sont également consignés dans le fichier journal.

Pour une restauration, ce dernier enregistre aussi les fichiers inclus qui ont été restaurés.

Voici deux exemples d'entrées de fichier journal :

|==================DSBackup Log: Backup================| 
Backup type: Full 
Log file name: sys:/backup/backup.log 
Backup started: 2002-6-21'T19:53:5GMT 
Backup file name: sys:/backup/backup.bak 
Server name: \T=VIRTUALNW_TREE\O=novell\CN=VIRTUALNW 
Current Roll Forward Log: 00000001.log 
DS Version: 1041072 
Backup ID: 3D138421 
Backing up security file: sys:/system/nici/INITNICI.LOG 
Backing up security file: sys:/system/nici/NICISDI.KEY 
Backing up security file: sys:/system/nici/XARCHIVE.000 
Backing up security file: sys:/system/nici/XARCHIVE.001 
Backing up security file: sys:/system/nici/XMGRCFG.KS2 
Backing up security file: sys:/system/nici/XMGRCFG.KS3 
Backing up security file: sys:/system/nici/XMGRCFG.NIF 
Starting database backup... 
Database backup finished 
Completion time 00:00:03 
Backup completed successfully 
 
|==================DSBackup Log: Restore================| 
Log file name: sys:/save/doc.log 
Restore started: 2002-7-19'T19:1:34GMT 
Restore file name: sys:/backup/backup.bak 
Starting database restore... 
Restoring file sys:/backup/backup.bak 
Restoring file sys:/system/nici/INITNICI.LOG 
Restoring file sys:/system/nici/NICISDI.KEY 
Restoring file sys:/system/nici/XARCHIVE.000 
Restoring file sys:/system/nici/XARCHIVE.001 
Restoring file sys:/system/nici/XMGRCFG.KS2 
Restoring file sys:/system/nici/XMGRCFG.KS3 
Restoring file sys:/system/nici/XMGRCFG.NIF 
Database restore finished 
Completion time 00:00:15 
Restore completed successfully

Utilisation de serveurs DSMASTER dans le cadre d'un plan de reprise après sinistre

Si vous possédez un environnement multiserveur et souhaitez planifier la reprise après un sinistre entraînant la perte de tous vos serveurs, vous pouvez utiliser des serveurs DSMASTER dans le cadre du plan de restauration de votre arborescence.

L'outil Backup eMTool s'emploie pour sauvegarder chaque serveur séparément ; il est axé sur le serveur, et non sur l'arborescence. Si toutefois, vous créez des serveurs DSMASTER, vous pouvez utiliser les fonctionnalités de Backup eMTool pour sauvegarder toute la structure de votre arborescence. Un exemple de sauvegarde impliquant des serveurs DSMASTER est présenté à la section Scénario : perte de tous les serveurs dans un environnement multiserveur.

Lors d'une restauration après un sinistre, l'un des principaux problèmes consiste à éviter de restaurer des répliques de la même partition qui ne concordent pas. Si, à la suite d'un sinistre, vous perdez les fichiers journaux de transactions individuelles de vos serveurs, vous ne pouvez pas restaurer ces derniers au même point dans le temps. Sans ces fichiers journaux, les répliques qui se trouvent dans vos sauvegardes ne concordent pas. Cela entraîne des problèmes si elles sont toutes restaurées au même moment et intégrées ensemble à l'arborescence. (Le processus de vérification de la restauration a pour but d'éviter ces problèmes : par défaut, une base de données eDirectory restaurée ne s'ouvre pas après une restauration si elle ne concorde pas avec les autres répliques.)

Vous pouvez recourir à des serveurs DSMASTER pour vous préparer à cette situation, en créant une copie maîtresse de l'arborescence que vous utiliserez comme point de départ.

Pour utiliser des serveurs DSMASTER en prévision d'un éventuel sinistre :

• Organisez vos répliques pour qu'un serveur contienne une réplique de chaque partition de l'arborescence. Ainsi, vous pouvez disposer d'une copie de l'ensemble de l'arborescence dans la base de données eDirectory d'un seul serveur (si l'arborescence est trop grande, vous pouvez utiliser deux serveurs clés). Ce type de serveur est souvent appelé serveur DSMASTER. Les répliques du serveur DSMASTER doivent être de type maîtresse ou Lecture/écriture.

  NOTE:  si vous utilisez deux serveurs DSMASTER clés, gardez à l'esprit que chacun doit en principe disposer d'un ensemble unique de répliques de partitions. Il ne doit pas y avoir de chevauchement pour éviter les incohérences entre les répliques lors de la restauration après un sinistre.

  Si un sinistre entraîne la perte de vos serveurs, vous n'aurez pas accès aux derniers fichiers journaux de transactions individuelles pour la restauration ; en effet, ceux-ci sont enregistrés localement sur le serveur, de sorte qu'il sera probablement impossible de restaurer tous les serveurs DSMASTER au même point dans le temps. Si la même réplique est stockée sur deux serveurs DSMASTER, les deux copies ne seront probablement pas identiques, ce qui entraînera des incohérences dans l'arborescence. Pour préparer une reprise après sinistre, il est donc préférable qu'une même partition ne soit pas répliquée sur plusieurs serveurs DSMASTER.

  Pour obtenir des informations générales sur les répliques, reportez-vous à la section Répliques.

• Sauvegardez régulièrement les serveurs DSMASTER pour créer une copie de sauvegarde de votre arborescence. Il peut, en outre, être judicieux de prendre des précautions supplémentaires pour le stockage des sauvegardes des serveurs DSMASTER dans le cadre de votre plan de reprise après sinistre.

Si vous concevez votre arborescence de cette façon, en cas de sinistre, la structure de l'arborescence pourra rapidement redevenir opérationnelle ; il vous suffira de restaurer le serveur concerné (ou le petit groupe de serveurs clés) et de vous assurer que les répliques qu'il contient sont bien celles désignées comme maîtresses.

Une fois la structure de l'arborescence redevenue opérationnelle, vous pourrez restaurer les autres serveurs perdus en utilisant uniquement les fichiers de sauvegarde complète et incrémentielle. Cependant, comme vous ne disposez pas des fichiers journaux de transactions individuelles, la vérification de la restauration échoue pour ces autres serveurs. Pour les réintégrer dans l'arborescence, vous devrez les supprimer de l'anneau de répliques, changer en références externes toutes les informations concernant leurs répliques à l'aide de DSRepair, puis leur ajouter de nouveau les répliques en effectuant la réplication à partir de la copie figurant sur le serveur DSMASTER. Ces opérations sont décrites à la section Récupération de la base de données en cas d'échec de la vérification de la restauration.

Si, lors d'un sinistre, vous perdez une grande partie de vos serveurs, la procédure liée aux répliques risque d'être complexe. Dans ce cas, nous vous conseillons de contacter le support technique de Novell.

Vecteurs de transition et processus de vérification de la restauration

Un vecteur de transition est un tampon horaire pour une réplique. Ce tampon est constitué d'une représentation du nombre de secondes écoulées depuis un point de référence historique commun (1er janvier 1970), du numéro de réplique et du numéro d'événement en cours. En voici un exemple :

s3D35F377 r02 e002

Dans le contexte de la sauvegarde et de la restauration, le vecteur de transition est important car il sert à vérifier que le serveur restauré est synchronisé avec les anneaux de répliques auxquels il participe.

Les serveurs qui contiennent des répliques d'une même partition communiquent entre eux pour que celles-ci restent synchronisées en permanence. Chaque fois qu'un serveur communique avec un autre serveur de l'anneau de répliques, il conserve un enregistrement du vecteur de transition de l'autre serveur au moment de la communication. Les vecteurs de transition permettent aux serveurs d'un anneau de répliques de savoir quelles informations ils doivent envoyer à chacune des répliques de l'anneau pour assurer leur synchronisation. Lorsqu'un serveur s'arrête, il cesse de communiquer. Les autres serveurs ne lui envoient plus de mises à jour et ne modifient plus le vecteur de transition qu'ils ont enregistré pour lui jusqu'à ce qu'il recommence à communiquer.

Lorsque vous restaurez eDirectory sur un serveur, le processus de vérification de la restauration compare le vecteur de transition du serveur en cours de restauration et celui des autres serveurs de l'anneau de répliques. Cela permet de s'assurer que les répliques restaurées sont dans l'état attendu par les autres serveurs.

Si le vecteur de transition du serveur distant est en avance par rapport au vecteur local, il manque alors des données dans la restauration et la vérification échoue. (Par exemple, des données peuvent être manquantes pour les raisons suivantes : vous n'avez pas activé la consignation continue de transactions individuelles par fichier avant la dernière sauvegarde complète ou incrémentielle, vous n'avez pas inclus les fichiers journaux de transactions individuelles dans la restauration ou l'ensemble de fichiers journaux que vous avez fourni pour la restauration est incomplet.)

Par défaut, la base de données eDirectory restaurée n'est pas ouverte si elle est incohérente par rapport aux autres répliques.

Pour obtenir un exemple d'entrée de fichier journal lorsque les vecteurs de transition ne concordent pas, reportez-vous à la section Présentation du processus de restauration avec Backup eMTool.

Pour obtenir une description des problèmes de compatibilité pouvant faire échouer la vérification de la restauration, reportez-vous à la section Rétrocompatibilité du processus de vérification de la restauration avec eDirectory 8.5 et versions ultérieures uniquement.

Pour plus d'informations sur la procédure à suivre en cas d'échec de la vérification de la restauration, reportez-vous à la section Récupération de la base de données en cas d'échec de la vérification de la restauration.

Rétrocompatibilité du processus de vérification de la restauration avec eDirectory 8.5 et versions ultérieures uniquement

Le processus de vérification de la restauration est rétrocompatible avec eDirectory 8.5 et versions ultérieures uniquement. Si le serveur que vous restaurez partage une réplique avec un serveur qui exécute une version de eDirectory antérieure à 8.5, le journal de restauration indique l'erreur -666 (version DS incompatible) pour cette réplique. Cela n'indique pas si les répliques sont désynchronisées ; cette erreur signifie simplement que le processus de vérification de la restauration ne peut pas comparer les vecteurs de transition étant donné que la version de eDirectory est antérieure à 8.5.

Par défaut, la base de données ne s'ouvre pas car la vérification de la restauration ne s'est pas déroulée correctement. Dans ce cas, faites appel à votre bon sens. Si la seule erreur provient d'un serveur 8.5 et si les autres serveurs ont été correctement vérifiés, vous pouvez choisir d'ouvrir la base de données en sélectionnant l'option de remplacement de la restauration, disponible dans le client eMBox.

Vous pouvez aussi supprimer de l'anneau de répliques le serveur exécutant une version antérieure, puis recommencer la restauration.

Pour plus d'informations sur le processus de restauration et les vecteurs de transition, reportez-vous aux sections Présentation du processus de restauration avec Backup eMTool et Vecteurs de transition et processus de vérification de la restauration.

Préservation des droits lors de la restauration des données du système de fichiers sous NetWare

Sous NetWare uniquement, la restauration des droits du système de fichiers (appelés aussi assignations d'ayant droit) dépend de l'objet qui est l'ayant droit actuel dans eDirectory. Compte tenu de cette relation, vous devez procéder avec précaution lorsque vous restaurez eDirectory et les données du système de fichiers sous NetWare, afin de préserver les droits du système de fichiers.

Si vous restaurez eDirectory avant les données du système de fichiers, les droits du système de fichiers devraient normalement être préservés lors de la restauration des données. Vous devez néanmoins être conscient des problèmes Recherchez les problèmes éventuels et prenez des mesures préventives au besoin.